Re: [secdir] SECDIR review of draft-ietf-mpls-forwarding-06

[Curtis Villamizar <[e-mail]>]

Steve,

Thanks for providing this review.  Responses are inline.

In message <[e-mail]>
Stephen Kent writes:
> 
> SECDIR review of draft-ietf-mpls-forwarding-06
>  
> I reviewed this document as part of the security directorate's ongoing 
> effort to review all IETF documents being processed by the IESG.These 
> comments were written primarily for the benefit of the security area 
> directors.Document editors, WG chairs and ADs should treat these 
> comments just like any other last call comments.
>  
> This documentis a candidate Informational RFC. It cites about 25 MPLS 
> RFCs (normatively) as a basis for guidelines for MPLS router 
> implementers and network providers, with respect to forwarding of MPLS 
> traffic.
>  
> The Security Considerations Section is very brief. It correctly states 
> that it is a review of forwarding behavior specified in numerous MPLS 
> RFCs, and thus introduces no new security requirements. It makes 
> specific reference to Section 4.6, which specifies (at a high level) 
> some tests for DoS susceptibility in MPLS routers. The paragraph that 
> includes this reference should be extended to include pointers to 
> Section 2.6.1 (which discusses DoS concerns), and to Section 3.6 (which 
> includes a list of DoS protection questions to be posed to suppliers).

Proposed change:

 OLD

   Some advice on hardware support and other equipment hardening
   against DoS attack can be found in Section 4.6.

 NEW

   Discussion of hardware support and other equipment hardening
   against DoS attack can be found in Section 2.6.1.  Section 3.6
   provides a list of question regarding DoS to be asked of suppliers.
   Section 4.6 suggests types of testing that can provide some
   assurance of the effectiveness of supplier DoS hardening claims.

The original reference to 4.6 was intended to refer to 2.6.1 but wrong
xml2rfc anchor was used.  Thanks for pointing out that DoS is
mentioned in three places.

> It might be nice to summarize the security considerations 
> recommendations from the MPLS RFCs that are normative references in this 
> document. Since this document is a summary of forwarding-relevant 
> requirements from these documents, plus practical advice, such a summary 
> would be useful here, and fitting.

That would be quite a task and largely out of scope since many of the
documents deal with a larger issue that MPLS forwarding.  Most
security concerns wrt MPLS or most protocols have to do with the
control protocols rather than the forwarding requirements.
Regardless, here is a suggested addition:

 NEW

   The set of normative references each contain security
   considerations.  A brief summarization of MPLS security
   considerations applicable to forwarding follows:

   1.  MPLS encapsulation does not support an authentication
       extension.  This is reflected in the security section of
       [RFC3032].  Documents which clarify MPLS header fields such as
       TTL [RFC3443], the explicit null label [RFC4182], renaming EXP
       to TC [RFC5462], ECN for MPLS [RFC5129], MPLS Ethernet
       encapsulation [RFC5332] make no changes to security
       considerations in [RFC3032].

   2.  Some cited RFCs are related to Diffserv forwarding.  [RFC3270]
       refers to MPLS and Diffserv security.  [RFC2474] mentions theft
       of service and denial of service due to mismarking.  [RFC2474]
       mentions IPsec interaction, but with MPLS, not being carried by
       IP, this type of interaction in [RFC2474] is not relevant.

   3.  [RFC3209] is cited here due only to make-before-break
       forwarding requirements.  This is related to resource sharing
       and the theft of service and denial of service concerns in
       [RFC2474] apply.

   4.  [RFC4090] defines FRR which provides protection but does not
       add security concerns.  RFC4201 defines link bundling but
       raises no additional security concerns.

   5.  Various OAM control channels are defined in [RFC4385] (PW CW),
       [RFC5085] (VCCV), [RFC5586] (G-Ach and GAL).  These documents
       describe potential abuse of these OAM control channels.

   6.  [RFC4950] defines ICMP extensions when MPLS TTL expires and
       payload is IP.  This provides MPLS header information which is
       of no use to an IP attacker, but sending this information can
       be suppressed through configuration.

   7.  GTSM [RFC5082] provides a means to improve protection against
       high traffic volume spoofing as a form of DoS attack.

   8.  BFD [RFC5880][RFC5884][RFC5885] provides a form of OAM used in
       MPLS and MPLS-TP.  The security considerations related to the
       OAM control channel are relevant.  The BFD payload supports
       authentication unlike the MPLS encapsulation or MPLS or PW
       control channel encapsulation is carried in.  Where an IP
       return OAM path is used IPsec is suggested as a means of
       securing the return path.

   9.  Other forms of OAM are supported by [RFC6374][RFC6375] (Loss
       and Delay Measurement), [RFC6428] (Connectivity
       Check/Verification based on BFD), and [RFC6427] (Fault
       Management).  The security considerations related to the OAM
       control channel are relevant.  IP return paths, where used, can
       be secured with IPsec.

   10. Linear protection is defined by [RFC6378] and updated by
       [draft-ietf-mpls-psc-updates].  Security concerns related to
       MPLS encapsulation and OAM control channels apply.  Security
       concerns reiterate [RFC5920] as applied to protection
       switching.

   11. The PW Flow Label [RFC6391] and MPLS Entropy Label [RFC6790]
       affect multipath load balancing.  Security concerns reiterate
       [RFC5920].  Security impacts would be limited to load
       distribution.

   MPLS security including data plane security is discussed in greater
   detail in [RFC5920] (MPLS/GMPLS Security Framework).

Note: RFC6720 (GTSM for LDP) was misclassified as normative.  It is
not normative wrt MPLS forwarding.

I'll add this if you think it adds value to the document.

> Some suggested edits:
> 
> 2.1.2.  MPLS Differentiated Services
>  
>  
>    [RFC2474] deprecates the IP Type of Service (TOS) and IP Precedence
>    (Prec) fields and replaces them with the Differentiated Services
>    Field more commonly known as the Differentiated Services Code Point
>    (DSCP) field.  [RFC2475] defines the Differentiated Services
>    architecture, which in other forum is often called a Quality of
>    Service (QoS) architecture.
>  
> Either use "fora" (correct Latin) or "forums" (common English)

OK.  forums.

> 2.1.8.1.  Pseudowire Sequence Number
>  
>  
>    Pseudowire (PW) sequence number support is most important for PW
>    payload types with a high expectation of lossless and/or in-order
>    delivery.  Identifying lost PW packets and exact amount of lost
>    payload is critical for PW services which maintain bit timing, such
>    as Time Division Multiplexing (TDM) services since these services
>    MUST compensate lost payload on a bit-for-bit basis.
>  
> "the exact amount"

OK.

> With PW services which maintain bit timing, packets that have been
>  
>    received out of order also MUST be identified and may be either
>    re-ordered or dropped.
>  
> Uppercase MAY?

OK.

> The term "microflow" does not appear to be defined anywhere in this
> document, but is used a number of times. I suggest including the
> definition from RFC 2474.

The first occurance of microflow is in "within a common microflow
SHOULD NOT be reordered [RFC2474]".  Since this references RFC2474, I
think this is adequate.  Other uses refer back to this section and/or
cite RFC2474 and/or RFC2475.

> 2.4.4.  MPLS Entropy Label
>  
>    The MPLS entropy label simplifies flow group identification
>    [RFC6790] at midpoint LSR.  Prior to the MPLS entropy label
>    midpoint LSR needed to inspect the entire label stack and often the
>    IP headers to provide ...
>  
> Missing an article, or make LSR plural.

In both occurances above plus one additional in this paragraph:
s/midpoint LSR/midpoint LSRs/

>    Many service providers consider it a hard requirement that use of
>    UDP and TCP ports can be disabled.  Therefore there is a stong
>    incentive for implementations to provide both options.
>  
> "strong"

OK

>    Cryptographic authentication can is some circumstances be subject
>    to DoS attack by overwhelming the capacity of the decryption with a
>    high volume of malicious traffic.
>  
> "in"

s/can is some/can in some/

Please let me know if these changes address your comments adequately.

Thanks,

Curtis