Re: [secdir] Secdir review of draft-ietf-ccamp-gmpls-ether-svcs

[Paul Hoffman <[e-mail]>]

At 12:06 PM +0000 2/17/10, Adrian Farrel wrote:
>Hi Paul,
>
>Thanks for the review.
>
>Off-topic of the draft, I think, you say...
>
>>RFC 3473 is GMPLS signalling with RSVP-TE. RSVP has hop-by-hop integrity protection
>>that is often used in real-world deployments; no privacy is assumed in the signalling. However,
>>RSVP-TE introduces non-hop-by-hop notifications that are adopted by draft-ietf-ccamp-
>>gmpls-ether-svcs. Unlike the rest of RSVP-TE, those notifications have no integrity protection
>>unless that operators run the protocol under a security service like IPsec
>
>I am not sure why you make this assertion.
>The GMPLS Notification message is open to all of the security features available in RSVP-TE.

Right, I said that.

>It is true that Notification messages can be sent using "non-adjacent signaling" which would require the existence of security peerings between non-adjacent nodes. This can be achieved by group keying, but peer keying need not be so arduous in most use cases.

Having looked again, I don't see how group keying achieves non-hop-by-hop security. You would need to combine group keying with guarantees that every hop uses the same key. I don't see where that guarantee is specified, but I could have missed it.

>But an alternative mechanism for delivery of Notification messages is defined in RFC3473 where the messages are forwarded hop-by-hop within RSVP-TE. This enables the use of the normal RSVP-TE security model.

We agree there. What I am saying is that the "normal RSVP-TE security model" does not actually provide end-to-end notification integrity. If I'm wrong about that, I'm happy to correct my assertion.