Telechat Review of draft-ietf-mpls-loss-delay-
review-ietf-mpls-loss-delay-secdir-telechat-kent-2011-06-17-00

Title: 

review of
draft-ietf-mpls-loss-delay-03




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.