Last Call Review of draft-ietf-mpls-ldp-dod-08
review-ietf-mpls-ldp-dod-08-secdir-lc-kent-2013-05-23-00

• Status
• Email expansions
• History

• Versions
• 00

Review
review-ietf-mpls-ldp-dod-08-secdir-lc-kent-2013-05-23

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), and

  

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