Last Call Review of draft-ietf-mpls-ldp-dod-08

Request Review of draft-ietf-mpls-ldp-dod
Requested rev. no specific revision (document currently at 09)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-05-27
Requested 2013-05-16
Authors Thomas Beckhaus, Bruno Decraene, Kishore Tiruveedhula, Maciek Konstantynowicz, Luca Martini
Draft last updated 2013-05-23
Completed reviews Genart Last Call review of -08 by Francis Dupont (diff)
Genart Telechat review of -09 by Francis Dupont
Secdir Last Call review of -08 by Stephen Kent (diff)
Secdir Telechat review of -09 by Stephen Kent
Assignment Reviewer Stephen Kent
State Completed
Review review-ietf-mpls-ldp-dod-08-secdir-lc-kent-2013-05-23
Reviewed rev. 08 (document currently at 09)
Review result Has Issues
Review completed: 2013-05-23


I reviewed this document as part of the
        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), and


RIP (v2 or ng),
        by the access


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
        applicable to security concerns that arise in the MPLS DoD
        context. RFC 5920
        devotes several pages to a discussion of service provider and
        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
        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
        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


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 (

        recommendation is not a precise recommendation and thus ought to
        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


        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
        reasonable, but the advice is pretty generic, and the wording
        here is
        especially poor.