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

From: Stephen Kent <[email-masked]>
Date: Sun, 12 Jun 2011 19:20:22 -0400

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.

---

From: Dan Frost <[email-masked]>
Date: Mon, 13 Jun 2011 11:15:24 +0100

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:
> security area directors.  Document editors and WG chairs should
> treat these comments just like any other last call comments.
> 
> that forms the basis for this profile,
> draft-ietf-mpls-loss-delay-01, is also in progress.
> 
> 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
> 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.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 14 Jun 2011 13:47:05 -0400

>don't show the latest versions of the targets so this may have caused

Dan,

Thanks for pointing me to the most recent version of the base spec. As you
noted, the profile reference didn't list a version number so ...

In looking at the new version, I see that the intro text is much improved.
It cites use of BFD as an authentication mechanism, and refers the 
reader to 5920, presumably for integrity and authentication 
mechanisms.

I looked quickly at 5920, and it appears that it does not specify any
crypto-based mechanisms for a generic pseudowire link (where the 
traffic being carried is not IP). Is that accurate? Also, 5920 cites 
4447, for LDP-based
links, but that RFC seems to cite only TCP-MD5 as a crypto-based 
option, which is now obsoleted by TCP-AO. So It is not clear that 
there are any IETF crypto-based security standards available for 
protecting these messages. I'm not saying that this is a show 
stopper, but rather that this should be more clearly stated somewhere.

Finally, the cite of IPsec in the next text (in the base document) 
provides te sort of concrete, crypto-based security mechanism I had 
in mind when I raised this question. However, I have a question: are 
the loss and delay measurement messages sent via the MPLS G-ACh 
always encapsulated in IP? I could not determine this from looking at 
the base doc, and RFC 5586 seems to indicate that IP is only one 
option for carriage of MPLS OAM packets.

Steve

---

From: Dan Frost <[email-masked]>
Date: Thu, 16 Jun 2011 10:46:39 +0100

Hi Steve,

On Tue, Jun 14, 2011 at 01:47:05PM -0400, Stephen Kent wrote:
> Thanks for pointing me to the most recent version of the base spec. As
> you noted, the profile reference didn't list a version number so ...
> 
> In looking at the new version, I see that the intro text is much
> improved.  It cites use of BFD as an authentication mechanism, and
> refers the reader to 5920, presumably for integrity and authentication
> mechanisms.
> 
> 4447, for LDP-based links, but that RFC seems to cite only TCP-MD5 as
> a crypto-based option, which is now obsoleted by TCP-AO. So It is not
> clear that there are any IETF crypto-based security standards
> available for protecting these messages. I'm not saying that this is a
> show stopper, but rather that this should be more clearly stated
> somewhere.

Yes, that's true; the MPLS data plane is generally implemented and
highly optimized in hardware, so heavyweight security mechanisms like
encryption are left to other layers.  Similarly trying to encrypt these
hardware-assisted loss/delay measurement messages is likely to cause
more problems than it solves; the information they contain is unlikely
to be sensitive enough to justify a complex and costly encryption layer
(which would at best require very specialized hardware support in order
not to interfere with the measurements themselves).

We can add a note about this in the text if that will help.

> provides te sort of concrete, crypto-based security mechanism I had in
> mind when I raised this question. However, I have a question: are the
> loss and delay measurement messages sent via the MPLS G-ACh always
> encapsulated in IP? I could not determine this from looking at the
> base doc, and RFC 5586 seems to indicate that IP is only one option
> for carriage of MPLS OAM packets.

Right, the G-ACh is independent of IP and was designed, among other
things, to meet requirements for MPLS-TP (RFC 5654) that include being
able to function in networks that lack an IP data plane.  The reference
to IPsec in this document pertains to the special case of out-of-band
measurement message responses over IP networks.

Thanks again for the review!

-d

---

From: Stephen Kent <[email-masked]>
Date: Thu, 16 Jun 2011 09:52:58 -0400

At 10:46 AM +0100 6/16/11, Dan Frost wrote:
>...

If you are looking to provide integrity and authentication, then you 
would not be performing encryption, per se, although use of 
cryptographic mechanisms was the question I was asking.

>We can add a note about this in the text if that will help.

If there is a way to use crypto to protect payloads, then saying how 
to do that would be fine. If not, then it should be stated clearly. 
It took a lot of digging to discover that, for the measurement 
messages, there appears to be no crypto option :-).

>measurement message responses over IP networks.

Thanks for the clarification.

Steve