[secdir] review of draft-ietf-mpls-loss-delay-03

[Stephen Kent <[e-mail]>]

I 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 abstract for draft-ietf-mpls-tp-loss-delay-profile-03 describes 
it as "a profile of the general MPLS loss, delay, and throughput 
measurement techniques that suffices [sic] to meet the specific 
requirements of MLS-TP." It is a very brief (5 pages, including 
boilerplate) document intended as an informational RFC. The document 
that forms the basis for this profile, draft-ietf-mpls-loss-delay-01, 
is also in progress.

The security considerations section of this document refers to the 
base document cited above. Since this document is a profile of that 
one, this is a reasonable indirection. (I note that the document 
under review cites version 1 of that base document, and that version 
2 is now current, something that can be addressed later.) I looked at 
the security considerations section of the base specification. It is 
two paragraph in length. The first paragraph does a reasonable job of 
describing the top level security concerns associated with the 
exchange of performance monitoring messages in a context such as 
this. (The text would be better if the third concern were identified 
as "confidentiality.") The second paragraph, however, states:

    If reception or alteration of performance-related data by
    unauthorized devices is an operational concern, authentication
    and/or encryption procedures should be used to ensure message
    integrity and confidentiality.  Such procedures are outside the
    scope of this document, but have general applicability to OAM
    protocols in MPLS networks.

First, this paragraph is poorly worded (e.g., the mixed uses of 
"authentication," "encryption," "integrity," and "confidentiality"). 
Second, there is concrete reference to any candidate security 
mechanisms that can provide such services. I am not aware of any IETF 
standards that might offer such services for MPLS traffic. If there 
are none, this second paragraph is not adequate; if there are, they 
should be cited here.