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 document is 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”