Skip to main content

Last Call Review of draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-14
review-ietf-mpls-lsp-ping-mpls-tp-oam-conf-14-secdir-lc-osterweil-2015-11-26-00

Request Review of draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf
Requested revision No specific revision (document currently at 16)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2015-11-17
Requested 2015-10-08
Authors Elisa Bellagamba , Greg Mirsky , Loa Andersson , Pontus Skoldstrom , David Ward , John Drake
I-D last updated 2015-11-26
Completed reviews Genart Last Call review of -14 by Roni Even (diff)
Secdir Last Call review of -14 by Eric Osterweil (diff)
Opsdir Last Call review of -14 by Mehmet Ersue (diff)
Assignment Reviewer Eric Osterweil
State Completed
Request Last Call review on draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf by Security Area Directorate Assigned
Reviewed revision 14 (document currently at 16)
Result Has issues
Completed 2015-11-26
review-ietf-mpls-lsp-ping-mpls-tp-oam-conf-14-secdir-lc-osterweil-2015-11-26-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 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.

I believe this draft is ready with (possibly minor) issues:

In Section 2.1.1, the authors describe BFD Authentication, and it seems quite
appropriate and well described.  I was, however, wondering if authentication
(the same sub-TLV or different) was needed or should be used for the mechanisms
in Sections 2.1.2 and 2.1.3.  If the authentication described by 2.1.1 is
already expected to be applicable to these other TLVs, it was not immediately
clear.  Maybe some additional description of this would be helpful to readers.

In Section 3, there is a great level of granularity proposed around describing
authorization errors: Auth not supported, Type not supported, and Key mismatch
(this is excellent).  One question, is there a missing statement for an
outright authentication failure?

In Section 6 Security Considerations, it would be nice (if possible) to mention
any privacy considerations.  For example, can an unauthorized agents probe
capabilities or configurations (such as, authentication or otherwise) of
devices?  That is, can someone learn that authentication is being required, and
what parameters are needed, etc?  Is all data transmitted in the clear?

Eric