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

From: Pekka Savola <[email-masked]>
Date: Tue, 10 Nov 2009 15:04:35 +0200 (EET)

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.