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

[Stephen Kent <[e-mail]>]

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"