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

[Dan Frost <[e-mail]>]

Hi Stephen,

Thanks for your review!  However, it looks like you reviewed an
out-of-date version of draft-ietf-mpls-loss-delay.  The current version
is -03 and this version includes a rewrite of the security
considerations.  (The reference pointers between the two drafts often
don't show the latest versions of the targets so this may have caused
some confusion.)

Cheers,
-d

On Sun, Jun 12, 2011 at 07:20:22PM -0400, Stephen Kent wrote:
> 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.