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

[Magnus Westerlund <[e-mail]>]

Hi,

I haven't seen any follow up on this discussion. Can Stefan and Francois
please come to conlusion on what to do?

Cheers

Magnus

Francois Le Faucheur IMAP skrev:
> 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
> 
>>
>>
>> *Stefan Santesson
>> *AAA-sec.com
>>
>>
>>
>>
>>
> 


-- 

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------