Last Call Review of draft-ietf-bfd-seamless-use-case-04
review-ietf-bfd-seamless-use-case-04-secdir-lc-gondrom-2016-04-14-00

Request Review of draft-ietf-bfd-seamless-use-case
Requested rev. no specific revision (document currently at 08)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2016-04-12
Requested 2016-03-23
Other Reviews Genart Last Call review of -04 by Dale Worley (diff)
Genart Telechat review of -06 by Dale Worley (diff)
Opsdir Telechat review of -05 by Benoît Claise (diff)
Review State Completed
Reviewer Tobias Gondrom
Review review-ietf-bfd-seamless-use-case-04-secdir-lc-gondrom-2016-04-14
Posted at https://www.ietf.org/mail-archive/web/secdir/current/msg06490.html
Reviewed rev. 04 (document currently at 08)
Review result Has Issues
Draft last updated 2016-04-14
Review completed: 2016-04-14

Review
review-ietf-bfd-seamless-use-case-04-secdir-lc-gondrom-2016-04-14



 

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





        The draft aims for informational and is about various use cases
        for Bidirectional Forwarding Detection (BFD) and various
        requirements. 


        Note: Solutions to the identified uses cases and protocol
        specific enhancements are outside the scope of this document.





        If this document is seen as use case document only, it appears
        in good shape. 


        However, it also includes a section 4 about requirements and it
        seems security requirements have not been considered among them.
        


        Maybe that is not intended or not necessary. I will leave that
        question up for the judgement by the WG.  





        One main comment: 


        1. section 5: Security Considerations


        is empty as it states not to introduce any new protocols. In
        principle that is ok, as long as it is understood that the
        following proposed protocols for these use cases will need to
        answer to security considerations. 


        However, as the document also speaks about requirements, it
        would have been nice to spell out specific security requirements
        that are to be considered from these use cases. Security
        requirements (from protection against malicious actors) should
        have been considered in section 4. 


        Also the various use cases should be explored for whether they
        may expose a system to abuse. 


        E.g. several requirements are stated as "MUST" (which btw. I am
        not sure is the proper use of RFC2119 definition). The question
        would be if a system will follow these requirements whether it
        would be exposed to additional security risks. E.g. Req#2 "MUST
        be able to establish a unidirectional BFD session without the
        bidirectional handshake", #3 "BFD session MUST be able to be
        established without the need for session negotiation". Overall I
        can see the request for these requirements. I would also like to
        see a discussion of their security implications and risks. 








        nitbits: 


        some of the language seems not so clean. Not outright wrong, but
        very hard to understand. 


        Maybe some native speakers or the RFC editor can help clean this
        up: 


        e.g. section 3.2 "All it takes is for the network entities to
        know what the discriminator values to be used for the session."


        I read this sentence a few times and not quite sure which words
        to add to match the intended meaning of the authors. ;-) 





        Thank you and best regards.





        Tobias