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

From: Paul Hoffman <[email-masked]>
Date: Tue, 16 Feb 2010 17:35:47 -0800

Greetings again. This is a last-call review of draft-ietf-ccamp-gmpls-ether-svcs-04, focusing on security issues.

This document does not introduce any new security concerns. The Security Considerations section says:

   This document introduces new message object formats for use in GMPLS
   signaling [RFC3473].  It does not introduce any new signaling
   messages, nor change the relationship between LSRs that are adjacent
   in the control plane. As such, this document introduces no additional
   security considerations.  See [RFC3473] for relevant security
   considerations.

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, which they apparently rarely do in real-world deployments. To be clear, draft-ietf-ccamp-gmpls-ether-svcs doesn't make anything in RSVP-TE any worse, it just uses the existing completely-unprotected notifications. The lack of security is an operational issue, not a protocol issue.

--Paul Hoffman, Director
--VPN Consortium

---

From: Adrian Farrel <[email-masked]>
Date: Wed, 17 Feb 2010 12:06:20 +0000

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.

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.

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.

Cheers,
Adrian

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 17 Feb 2010 08:38:26 -0800

At 12:06 PM +0000 2/17/10, Adrian Farrel wrote:
>>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
>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.