Subject: [secdir] SecDir review of draft-ietf-tsvwg-rsvp-l3vpn-02

From: Stefan Santesson <[email-masked]>
Date: Tue, 23 Jun 2009 18:51:29 +0200

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.

This specification define a set of procedures to overcome challenges with
deployment of Resource Reservation Protocols over BGP/MPLS VPNs.

The BGP/MPLS VPN (RFC 4364) is a VPN technique that doesn't rely encryption
to ensure secrecy or message integrity. The security properties are instead
dependent on the security of the network infrastructure.

It appears that this draft makes a serious effort to describe and analyze
relevant security considerations. With my limited expertise in this
particular area I can't find any thing that is obviously missing.

However, one question that comes to my mind, which might be worth looking at
from a security perspective, is whether the procedures introduced by this
document requires the communication to be unencrypted and if so, whether
deployment of this protocol blocks or prevents legitimate use of e.g. IPsec
based VPN as discussed in RFC 4364 and RFC 4023. If this is the case, should
it be discussed in the security considerations section?

Stefan Santesson
AAA-sec.com

---

From: Francois Le Faucheur IMAP <[email-masked]>
Date: Tue, 30 Jun 2009 18:58:28 +0200

Hello Stefan,

Thanks for your review. Please find a response to your question  
embedded below:

On 23 Jun 2009, at 18:51, Stefan Santesson wrote:

> I have reviewed this document as part of the security directorate's  
> ongoing effort to review all IETF documents being processed by the  
> IESG.  These comments were written primarily for the benefit of the  
> security area directors.  Document editors and WG chairs should  
> treat these comments just like any other last call comments.
>
> This specification define a set of procedures to overcome challenges  
> with deployment of Resource Reservation Protocols over BGP/MPLS VPNs.
>
> The BGP/MPLS VPN (RFC 4364) is a VPN technique that doesn't rely  
> encryption to ensure secrecy or message integrity. The security  
> properties are instead dependent on the security of the network  
> infrastructure.
>
> It appears that this draft makes a serious effort to describe and  
> analyze relevant security considerations. With my limited expertise  
> in this particular area I can't find any thing that is obviously  
> missing.
>
> However, one question that comes to my mind, which might be worth  
> looking at from a security perspective, is whether the procedures  
> introduced by this document requires the communication to be  
> unencrypted and if so, whether deployment of this protocol blocks or  
> prevents legitimate use of e.g. IPsec based VPN as discussed in RFC  
> 4364 and RFC 4023. If this is the case, should it be discussed in  
> the security considerations section?

The short answer is that this document does not require that  
communication be un-encrypted.

The longer answer would be:

RFC4364 mentions use of IPsec both CE-CE and PE-PE:
Specifically, I noticed: "Cryptographic privacy is not provided by  
this architecture, nor by Frame Relay or ATM VPNs. These architectures  
are all compatible with the use of cryptography on a CE-CE basis, if  
that is desired. The use of cryptography on a PE-PE basis is for  
further study."

Regarding PE-PE IPsec:
	* RSVP over VPN would work just fine (as currently specified) for PE- 
CE links
	* RSVP over VPN would not allow CAC over MPLS Core as we need TE  
tunnels to do that which I believe could not be used with MPLS over IP/ 
IPsec in the core.

Regarding CE-CE IPsec (or if IPsec starts deeper inside the VPN site):
RFC 4923 "Quality of Service (QoS) Signaling in a Nested Virtual  
Private Network" describes a model for RSVP operation through IPsec  
Gateways (in a nutshell, the idea is that there is effectively a form  
of hierarchical RSVP where an RSVP reservation is made for the IPsec  
tunnel and then individual RSVP reservations are admitted/aggregated  
over the tunnel reservation). This would apply in case to the case of  
CE-CE IPsec (or if IPsec starts deeper inside the VPN site) and the  
procedures defined in the document would simply apply "as is" to the  
reservation for the tunnel(s) (and not to the individual end to end  
RSVP reservation).

If this answers your question appropriately, we could add text  
capturing this in the Security Considerations (whenever we issue the  
next rev). Please let us if this works for you.

Thanks

Francois