Re: Last Call: draft-ietf-mpls-mpls-and-gmpls-security-framework (Security Framework for MPLS and GMPLS Networks) to Informational RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]