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

From: Stephen Kent <[email-masked]>
Date: Mon, 03 Feb 2014 16:05:59 -0500

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).

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.

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)

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"

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?

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.

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.

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"

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"

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 04 Feb 2014 23:17:38 -0500

Steve,

Thanks for providing this review.  Responses are inline.

> 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.

> 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
>  
>  
>    (DSCP) field.  [RFC2475] defines the Differentiated Services

OK.  forums.

> 2.1.8.1.  Pseudowire Sequence Number
>  
>  
>    delivery.  Identifying lost PW packets and exact amount of lost

OK.

>    received out of order also MUST be identified and may be either
>    re-ordered or dropped.
>  
> Uppercase MAY?

OK.

> 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 ...
>  

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

OK

>    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

---

From: Loa Andersson <[email-masked]>
Date: Wed, 05 Feb 2014 12:34:36 +0800

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

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Stephen Kent <[email-masked]>
Date: Wed, 05 Feb 2014 09:24:52 -0500

Curtis,

Thanks for the quick reply.

I agree that a thorough summary of the relevant security considerations
from the many normative references would be a non-trivial task ;-).
The brief summary you assembled is excellent!

I am satisfied with the changes/responses.

Steve

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 5 Feb 2014 15:24:38 +0000

Thanks, Stephen!

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 05 Feb 2014 15:24:27 -0500

Steve,

If you don't mind I'd like to add a little to this.  This is the very
last paragraph and follows the numbered list.

 OLD PROPOSED

 NEW PROPOSED

   MPLS security including data plane security is discussed in greater
   detail in [RFC5920] (MPLS/GMPLS Security Framework).  THe MPLS-TP
   security framework [RFC6941] build upon this, focusing largely on
   the MPLS-TP OAM additions and OAM channels with some attention
   given to using network management in place of control plane setup.
   In both security framework documents MPLS is assumed to run within
   a "trusted zuone", defined as being where a single service provider
   (SP) has total operational control over that part of the network.

   If control plane security and management plane security are
   sufficiently robust, compromise of a single network element may
   result in chaos in the data plane anywhere in the network through
   denial of service attacks, but not a Byzantine security failure in
   which other network elements are fully compromised.

   MPLS security, or lack of, can affect whether traffic can be
   misrouted and lost, or intercepted, or intercepted and reinserted
   (a man-in-the-middle attack) or spoofed.  End user applications,
   including control plane and management plane protocols used by the
   SP, are expected to make use of appropriate end-to-end
   authentication and where appropriate end-to-end encryption.

I think the original, while not incorrect, was too brief.  This new
text provides a better summary, indicating the underlying "trusted
zuone" assumption and the lack of any meaningful data plane security
if that underlying assumption proves invalid for any reason, but most
likely invalid due to a breach or a physical intercept along
transmission media.

Please let me know if this further change is an improvement or if we
should leave it out (or change it).

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 05 Feb 2014 16:09:27 -0500

In message <[email-masked]>
 
> should leave it out (or change it).

s/THe/The/
s/zuone/zone/

---

From: Stephen Kent <[email-masked]>
Date: Wed, 05 Feb 2014 16:30:19 -0500

Curtis,

I agree; the new text is better.

Thanks,

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 13 Feb 2014 10:26:19 -0500

I skimmed the 08 version of the doc and I am comfortable (actually, very 
happy)
with the changes that have been made since I reviewed the 06 version. My 
thanks
to Curtis for his quick responses and for a great job in making the 
requested
revisions, and more.

Steve