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

[Dan Frost <[e-mail]>]

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.
> 
> 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.

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.

> 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.

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

> Steve