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

[Loa Andersson <[e-mail]>]

Curtis,

I had started a mail for this thread suggesting that you add a
reference to RFC 5920. I thought that that should be enough, but
since you have added the 11 bullets (all good) I think this is more
than meet what is required for this draft.

Now, Stephen's idea to document the security aspects of MPLS forwarding
is not bad; but it would require that we had someone sec savvy person to
work with someone that understand MPLS forwarding. If Stephen (or one
of the security ADs) can help find the security person, we can work to
find the forwarding person.

/Loa

On 2014-02-05 12:17, Curtis Villamizar wrote:
> 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
>

-- 


Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Huawei Technologies (consultant)     phone: [phone]