Re: [secdir] draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-15

[Gregory Mirsky <[e-mail]>]

Hi Eric,

thank you for the review and the comments. Please find my answers in-line and tagged GIM>>.

Your questions, suggestions are greatly appreciated.



                Regards,

                                Greg



-----Original Message-----
From: Osterweil, Eric [mailto:[e-mail]]
Sent: Thursday, November 19, 2015 8:20 AM
To: [e-mail]; [e-mail]; [e-mail]
Subject: draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-15



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.

GIM>> MPLS-TP Performance Measurement being defined in RFC 6375 is the profile of RFC 6374 and, as we can find across MPLS OAM, does not use any authentication mechanism. Authentication mechanisms been defined for BFD over IP networks and are available when BFD used to monitor MPLS-TP LSP.



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?

GIM>> The document defines configuration of MPLS-TP OAM and thus supports diagnostic of misconfiguration situations. Failure of authentication would be operational state and should be diagnosed and troubleshooted by other instruments then defined in this document.



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?

GIM>> RFC 4379 does not define any authentication mechanism for MPLS LSP ping and the data are transmitted in the clear. That may be viewed as security concern and perhaps can be discussed as part of work on RFC4379bis<https://tools.ietf.org/html/draft-smack-mpls-rfc4379bis-06>. At the same time, LSP ping doesn't have constructs to allow an agent, authorized or not, to learn of capabilities and/or configuration of the LSR.



Eric