On Tue, 27 Oct 2009, The IESG wrote:
The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document:
- 'Security Framework for MPLS and GMPLS Networks '
<draft-ietf-mpls-mpls-and-gmpls-security-framework-07.txt> as an
Informational RFC
This is an assigned ops-dir review.
The document is somewhat lengthy but easy-to-read description of
various security threats and mitigation techniques applicable to MPLS
and GMPLS networks. A lot of the material is focused on higher-layer
issues, i.e., VPNs. I would argue that the document would be more
focused if security framework for VPNs and for lower-layer stuff like
MPLS and signaling would be separated. But I also understand and can
live with keeping them combined. Specifically, I think there is a lot
of duplication with RFC 4111 (Security Framework for
Provider-Provisioned Virtual Private Networks (PPVPNs)) here and it's
acknowledged in the document.
There are a couple of places where the document appears to be overly
verbose and veers into tangential issues (e.g. providing description
of IPsec and IKE algorithms, modes; or 4 pages of router filtering or
firewalling discussion) and I'd suggest summarizing. There are a
couple of minor technical errors or omissions. IMHO, the document
should be revised prior to publication.
Some higher-level observations
------------------------------
In S 5.2, P-to-P or P-to-PE protection is touched on only very
briefly, and PWE3 protection is deemed out of scope. While these are
declared out of scope or left for future study, it would have been
useful to have a paragraph or subsection in Security Considerations
section that underlines these remainder threats.
In S 5.3, there are 4 pages dedicated to explaining how packet
filtering and firewalling works. I'd argue most of that is tangential
to this document and should be removed. A succint description should
be possible in 0.5-1 pages. If you add informative reference to
(expired, dead) I-D draft-ietf-opsec-filter-caps-09, it should cover
the background.
S 6 appears to discuss only SNMP/syslog type monitoring and detection
mechanisms but these can only detect few attacks (usually resulting
from flapping protocol adjacencies, CPU overload scenarios, etc.).
The rest will fly below the radar. Other techniques such as
netflow-based traffic fingerprinting are needed for more detailed
detection and reporting.
S 7.1.1 describes control plane protection but I believe this document
should mention uRPF/ACLs towards customers and ACLs at the edges. It
does mention destination-address based filtering as one possibility,
but this has its own set of issues. If you're able to do
comprehensive source-address based filtering, you're in a much better
position to block someone spoofing your own (management or routers')
IP address.
The key point here is that if you're able to prevent anyone from
spoofing your infrastructure IP addresses at ingress, you don't need
(or you get an additional layer of protection) TCP-MD5, iBGP, IGP etc.
protection.
FWIW, draft-savola-rtgwg-backbone-attacks-03 describes this approach,
and it may be applicable especially with smaller and reasonably
well-defined service provider networks. (Some of the topics described
in the draft are also touched on in S 7.2; this should also be added
to S 9.3.1 point 1)
S 8 does not discuss the differences of MPLS domain cross-connection
in various established models, see e.g. RFC4364 S 10 options a)-c) and
RFC4761 (L2VPN) section 3.4 options a)-c). One of th key issues not
discussed here is whether a signalling protocol is run between service
providers, or whether everything is demultiplexed/multiplexed at the
border. This also has an impact on some of the security properties of
the network. It seems as if the document is assuming that a signaling
protocol is run between the providers; this may or may not be due to
MPLS-ICI specifications but I don't know.
Some more detailed comments
---------------------------
In S 4.3,
Bidirectional Forwarding
Detection (BFD), however, does have support for carrying an
authentication object. It also supports Time-To-Live (TTL)
processing as an anti-replay measure. Implementations conformant
with this MPLS-ICI should support BFD authentication and must
support the procedures for TTL processing.
.. I'd observe that the TTL check in BFD is not primarily an
anti-replay mechanism (the same also in S 8.1.1). Also it's not clear
if the MPLS-ICI specification imposes the requirements in the last
sentence, or whether these are from this document. (If these are
"originated" by this document, this may be an issue because this is
targeting Informational.)
The ease of forging TCP/IP packets is the main
reason network management protocols lacking strong security have not
been used to configure network elements (e.g., with the SNMP SET
command).
.. lacking a reference, it seems a bit of guesswork to say this has
been the main reason. In our case, we've prevented this forging yet
still don't see the need to use SNMP sets; authentication and
confidentiality is a bigger issue but for us the root issue is that
it's more cumbersome to use than using CLI and related automated
scripts. I wonder if there's a consensus-driven document that
describes this.
... In general I felt S 4.3 to be a good summary but most of it was a
description of general TCP/IP issues about host and TCP/IP security,
and I wonder whether there should be additional references here, or if
some of the material could be removed.
In S 4.4 on insider attacks,
Protection against insider attacks is largely for future study in
MPLS and GMPLS networks. Some protection can be obtained by
providing strict security for software upgrades, and preventing
general (e.g. FTP) access to LSRs. Further protection can be
achieved by strict control of user (i.e. operator) access to LSRs.
Lastly, software tools may be used to monitor and report network
behavior and activity in order to quickly spot any irregularities
that may be the result of an insider attack.
.. the "general access" (with FTP example) may be misleading. Are you
referring to general access to the whole internet or (I suppose so)
general access to all the OAM staff? A better phrasing might help.
Additionally, this section could be improved. IMHO it would be
especially important to mention (software) configuration management
and change tracking mechanisms. This is similar to spotting
irregularities as already described, but from configuration rather
than from externally visible behaviour. In some cases, configuration
change approval processes etc. may also be warranted. In our case,
CVS diffs are produced from configuration changes and there are
scripts which look for misconfigurations and irregularities as well.
In S 5.2,
- If the user requires remote access to its site from a
system at a location that is not a customer location (for
example, access by a traveler) there may be a requirement
for cryptographically protecting the traffic between that
system and an access point or a customer's site. If the
MPLS/GMPLS provider supplies the access point, then the
customer must cooperate with the provider to handle the
access control services for the remote users. These access
control services are usually protected cryptographically,
as well.
.. this appears to be a generic "VPN concentrator" case, and has
(AFAICS) very little to do with MPLS/GMPLS security. Maybe this
should be removed or reworded so that the issue is clearer? E.g. if
the point is that the VPN concentrator has access to multiple VPNs,
it's important to authenticate the user appropriately so that it won't
get access to other VPNs. But even with this kind of formulation, the
scope for this document is not clear.
In S 5.2.1,
IPsec [RFC4301] [RFC4302] [RFC4835] [RFC4306] [RFC4309] [RFC2411]
is the security protocol of choice for protection at the IP layer.
.. adding an informative reference to draft-ietf-ipsecme-roadmap-xx
might also be useful; I suppose it would give a more up-to-date
overview than RFC2411.
In S 5.2.1,
Encryption algorithms generally come with two parameters: mode such
as Cipher Block Chaining and key length such as AES-192. (This
should not be confused with two other senses in which the word
"mode" is used: IPsec itself can be used in Tunnel Mode or
Transport Mode, and IKE [version 1] uses Main Mode, Aggressive
Mode, or Quick Mode). It should be stressed that IPsec encryption
without an integrity check is a state of sin.
.. this appears to be mostly tangential and out of scope of this spec,
and should be considered for removal. There is also other material in
S 5.2.1 that IMHO goes beyond the basics of IPsec (mostly relating to
IPsec modes and hashing/integrity algorithms) that seem unnecessary
here.
5.2.2. MPLS / GMPLS DiffServ and IPsec
Using
IPsec without IKE or IKEv2 (the better choice) is not advisable. [...]
.. over half of this section has nothing to do with DiffServ, it's
mostly discussion of IKE protocol suite and key management. The title
needs to be changed, these need to be moved somewhere else (e.g. S
5.2.1) or this should be removed.
In S 5.3.1,
Stateful filtering maintains packet-specific state information to
aid in determining whether a filter rule has been met. For example,
a device might apply stateless filtering to the first fragment of a
fragmented IPv4 packet. If the filter matches, then the data unit
ID may be remembered and other fragments of the same packet may
then be considered to match the same filter. Stateful filtering is
more commonly done in firewalls, although firewall technology may
be added to routers. Data unit ID can also be Fragment Extension
Header Identification field in IPv6.
.. what is this "data unit ID"? Are you referring to the IP
identification field or something else? Note that stateless IP
fragmentation filtering is very difficult or impossible to do securely
e.g. due to overlapping fragments and other issues (e.g. rfc 1858,
3128,..)
- Rate Limit
In some cases the set of packets matching a particular filter may
be limited to a specified bandwidth. In this case, packets or bytes
would be counted, and would be forwarded normally up to the
specified limit. Excess packets may be discarded or may be marked
(for example by setting a "discard eligible" bit in the IPv4 ToS
field or the MPLS EXP field).
.. there is no such thing as "discard eligible" bit in the IPv4 ToS
field!
In S 5.3.2,
As with other access control techniques, the value of firewalls
depends on a clear understanding of the topologies of the
MPLS/GMPLS core network, the user networks, and the threat model.
Their effectiveness depends on a topology with a clearly defined
inside (secure) and outside (not secure).
.. in todays security models, there often isn't such a clear
separation of inside=secure and outside=insecure perimeter.
In S 6,
MPLS/GMPLS devices. Syslog WG is specifying "Logging Capabilities
for IP Network Infrastructure". (The specific references will be
made only if the draft(s) became RFC before this draft.)
.. actually, I suppose you refer to OPSEC WG and
http://tools.ietf.org/html/draft-ietf-opsec-logging-caps which was
discontinued due to (afaik) lack of interest. I don't see why this
couldn't be referenced as an informational reference even if the work
was discontinued.
In S 7(?),
Isolation
mechanisms might also be bypassed by IPv4 Router Alert or IPv6
using Next Header 0 packets. A solution could consists of disabling
the processing of IP options. This drops or ignores all IP packets
with IPv4 options, including the router alert option used by RSVP;
however, this may have an impact on other protocols using IPv4
options. An alternative is to configure access-lists on all
incoming interfaces dropping IPv4 protocol or IPv6 next header 46
(RSVP).
... did you mean s/Next Header 0/Next Header 46/ ?
... Can you actually configure such an ACL? At least with some
vendors, you can only match the router alert option and can't know
what's beyond that?
RSVP neighbor filtering at the data plane level, with an access
list to accept IP packets with port 46 only for specific neighbors
requires Router Alert mode to be deactivated and does not protect
against spoofing.
.. "port 46" ? More confusion here... I suppose you mean "protocol"
but see above, this may not be filterable?
7.1.3. Control Plane Protection with LDP
The approaches to protect MPLS routers against LDP-based attacks
are similar to those for RSVP, ...
... while true to some extent, it's much easier to protect LDP because
it's not using router-alert option.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf