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

[Stephen Kent <[e-mail]>]

At 10:46 AM +0100 6/16/11, Dan Frost wrote:
>Hi Steve,
>...
>
>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).

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

>
>>  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 for the clarification.

Steve