[secdir] SECDIR review of draft-ietf-mpls-ldp-dod-08

[Stephen Kent <[e-mail]>]

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 and WG chairs should treat these comments 
just like any other last call comments.

An overall comment: There are numerous (minor) English errors throughout 
the document, which I hope will be addressed through the RFC Editor process.

The abstract says that the document describes LDP DoD (downstream on 
demand) use cases and lists required LDP DoD procedures in the context 
of Seamless MPLS design. It also describes a new, optional TLV type in 
the LDP Label Request message. The intent of creating the new type is to 
enable "fast-up" convergence.

Section 2 of the document is devoted to a description of reference 
access topologies that will make use of this new MPLS feature. These 
topologies are divided into two classes: ones that can be supported via 
static routes and ones that require use of a dedicated IGP, e.g., ISIS, 
OSPF (v2 or v3), andRIP (v2 or ng), by the access network.

Section 3 describes use cases for LDP DoD. It too distinguishes between 
topologies that use static routing vs. an IGP, and examines various 
types of failures that may affect the LDP DoD nodes. This section 
includes a lot of normative text, yet almost all instances of the words 
"must" and "should" are lowercase. The authors should revisit this 
section to determine if there need to be more MUSTs and SHOULDs.

Section 4 describes the label request procedure. It too contains 
normative text, yet almost all instances of "must" and "should" are 
lowercase. As with Section 3, the authors should revisit this section to 
determine if there need to be more MUSTs and SHOULDs.

Section 5 describes the LDP extension to enable "Fast-Up" convergence. 
In this very brief section the authors seem to have done a better job of 
using uppercase terms in normative text.

Section 7 addresses Security Considerations. It cites RFC 5920, the 
Security Framework for MPLS and GMPLS as the primary reference 
applicable to security concerns that arise in the MPLS DoD context. RFC 
5920 devotes several pages to a discussion of service provider and 
inter-provider security topics, so it seems natural to cite it here. (It 
too suffers from a tendency to use the words "must," "should," and "may" 
only in lowercase, despite the apparent normative nature of the comments 
being made.) Sections 9.1 and 9.2 are odd parts of 5920; the former 
enumerates potential attacks, and the latter enumerates "deference 
techniques" without bothering to establish the mapping between the two!

**

This I-D also cites the Security Consideration section of the MPLS LDP 
specification (RFC 5036), noting a need for message authenticity and 
integrity, and for protection against spoofing and DoS attacks. RFC 5036 
contains a more conventional Security Considerations section, which 
seems appropriate to cite here.

In addition to the references to prior RFCs, this section analyzes 
several security contexts:, in terms of tampering with packet flow 
direction, data and control plane security, and network node security. 
The discussion of attacks on packet flow direction seems fairly good, 
except for the ABR LSR network side case, for which the offered advice 
is vague. The data place security discussion seems to be a set of 
suggestions, but with a mix of normative and informative terms; Section 
7.2 definitely needs work.

The discussion of control plane security in Section 7.3 is shorter, but 
not much better. It suggests that the reader be familiar with a KARP I-D 
(I-D.ietf-karp-routing-tcp-analysis. This recommendation is not a 
precise recommendation and thus ought to be reconsidered. The text here 
also suggests use of TCP/MD5, recommending TCP/AO only if the former is 
not considered good enough. RFC 5925 (TCP-AO) obsoletes RFC 2385 (use of 
TCP/MD5 in BGP). This calls into question whether it is appropriate to 
recommend use of TCP/MD5 at all. The subsection ends with two 
suggestions: employ better authentication in access locations with lower 
physical security, and use "stricter network protection mechanism." The 
former advice seems good, but the latter is too amorphous to be of much use.

The final subsection in Security Considerations (7.4) discusses 
additional precautions an operator might employ for nodes that are 
considered to be at risk due to degraded physical security. Addressing 
this concern seems reasonable, but the advice is pretty generic, and the 
wording here is especially poor.