Telechat Review of draft-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-07
review-ietf-teas-mpls-tp-rsvpte-ext-associated-lsp-07-secdir-telechat-kent-2015-03-12-00

I
        have 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 with the intent of improving security requirements
        and
        considerations in IETF drafts.

  

Comments
not
        addressed in last call may be included in AD reviews during the
        IESG
        review.

  

Document editors
        and WG chairs
        should treat these comments just like any other last call
        comments.




 




As far as
        security is
        concerned, I see no problems with this document. Tracing back
        through the list
        of Security Consideration sections of cited documents in one
        case leads to a
        disappointing origin in RFC 2747. The other chain is shorter and
        more relevant,
        and it provides greater confidence that this document yields no
        new security
        concerns.




 




This document
        describes
        extensions to RSVP to enable creating a bidirectional LSP from
        two p-t-p
        unidirectional LSPs. 




 




The security
        considerations section consists of just two paragraphs. The
        first cites the
        security considerations section of RFC 6780 (RSVP Association
        Objects) as
        encompassing any security issues that might arise in this
        context. (The
        assertion is that this document introduces no new signaling
        information, and
        thus no new security concerns.) 




 




The Security
        Considerations section of 6780 is also two paragraphs in length.
        That text
        states that no new security considerations have been introduced,
        because no new
        procedures have been defined. Hence it cites the

  

Security Considerations
        sections of RFC 4872
        and 4873.




 




RFC 4872
        cites RFC 4426
        (RFC 4873 cites RFC 4872). 




 




The
        security considerations section of 4426 is almost a full page.
        It specifies
        security services that are required to protect the GMPLS
        recovery mechanisms
        defined in that document, but does not point to ANY security
        mechanisms that
        should be employed.




 




RFC 4872 also
        establishes
        a few security-relevant requirements for RSVP signaling, and
        cites RFC 2747 as
        specifying the required security mechanisms. (4872 also notes
        that IPsec could
        be employed for hop-by-hop integrity and authentication, and
        cites RFC 3473. I
        note that 3473 is from 2003, and thus refers to IPsec and IKE
        RFCs that have
        been obsoleted!) 




 




RFC 2747
        specifies
        crypto authentication mechanisms for RSVP, but dates from 2000.
        It anticipates
        that 

“ … 

the
IETF
        will define a standard key management protocol” and thus omits
        specification of such in that document. (A fun walk down memory
        lane …)




 




 




The second
        paragraph of
        the Security Considerations section of this I-D notes that
        additional
        information is conveyed in the REVERSE_LSP object, but that the
        information is
        not fundamentally different from what is carried in a
        bidirectional LSP
        message. Thus, the argument is that no fundamentally different
        information is
        being transmitted. This paragraph cites RFC 5920 

(

Security
        Framework for MPLS
        and GMPLS Networks) as relevant. I agree that 5920 seems to be
        most appropriate
        RFC in this context.