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

[Stephen Kent <[e-mail]>]

At 11:15 AM +0100 6/13/11, Dan Frost wrote:
>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

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