Last Call Review of draft-ietf-mpls-flow-ident-06

Request Review of draft-ietf-mpls-flow-ident
Requested rev. no specific revision (document currently at 07)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2018-01-02
Requested 2017-12-19
Authors Stewart Bryant, Carlos Pignataro, Mach Chen, Zhenbin Li, Greg Mirsky
Draft last updated 2018-01-10
Completed reviews Rtgdir Early review of -02 by Manav Bhatia (diff)
Rtgdir Last Call review of -05 by Manav Bhatia (diff)
Secdir Last Call review of -06 by Daniel Franke (diff)
Assignment Reviewer Daniel Franke 
State Completed
Review review-ietf-mpls-flow-ident-06-secdir-lc-franke-2018-01-10
Reviewed rev. 06 (document currently at 07)
Review result Has Nits
Review completed: 2018-01-10


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 know next to nothing about MPLS. The proposed functionality seems reasonable and persuasively justified, but it is possible that there are significant issues I'm overlooking. I have a couple nitpicks about the Security Considerations section. 

The lowercased (i.e., non-RFC-2119) "must"s and "should"s are weasel words when not connected with a statement of what objective is achieved by following those recommendations. For example, the sentence "Propagation of identification information outside the MPLS network imposing it must be disabled by default" ought to be prefaced or suffixed with something along the lines of "In order to preserve present assumptions about MPLS privacy properties". 

I see a lot of discussion about confidentiality concerns when flow information is propagated across trust boundaries, but no discussion about the dual integrity concerns. I suggest including some word of warning that flow information received from an untrusted LSR cannot be assumed correct, so caution is advised before relying on it, e.g., to determine for billing purposes whether SLAs are being met.