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

Francois Le Faucheur IMAP <> Tue, 30 June 2009 16:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3DD7E3A6CF1; Tue, 30 Jun 2009 09:59:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.312
X-Spam-Status: No, score=-10.312 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cBsydgrfQneP; Tue, 30 Jun 2009 09:59:35 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 474633A68E5; Tue, 30 Jun 2009 09:59:34 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="4.42,317,1243814400"; d="scan'208,217"; a="44025404"
Received: from ([]) by with ESMTP; 30 Jun 2009 16:58:38 +0000
Received: from ( []) by (8.12.11/8.12.11) with ESMTP id n5UGwZDl032720; Tue, 30 Jun 2009 18:58:35 +0200
Received: from ( []) by (8.13.8/8.14.3) with ESMTP id n5UGwZV6017238; Tue, 30 Jun 2009 16:58:35 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jun 2009 18:58:35 +0200
Received: from [] ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jun 2009 18:58:31 +0200
Message-Id: <>
From: Francois Le Faucheur IMAP <>
To: Stefan Santesson <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary=Apple-Mail-25--361547119
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Tue, 30 Jun 2009 18:58:28 +0200
References: <>
X-Mailer: Apple Mail (2.935.3)
X-OriginalArrivalTime: 30 Jun 2009 16:58:31.0656 (UTC) FILETIME=[FF64EE80:01C9F9A3]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8269; t=1246381115; x=1247245115; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;;; z=From:=20Francois=20Le=20Faucheur=20IMAP=20<flefauch@cisco. com> |Subject:=20Re=3A=20SecDir=20review=20of=20draft-ietf-tsvwg -rsvp-l3vpn-02 |Sender:=20; bh=fkOM+me4q4It9a4Y2JfmkhYUwYkI9/aeO2HsGc4M3a4=; b=t4bUyA6IKgZbqY1hWohi+lFWu+idiwuoJLoI8lNWZ45Yj213tSYH/SCv01 Ik25CaG8P6jTmyH7Ybsn0/vBIc6fBmxHZLnMFOvHgH4OacOF7ju1Jk9AVXD3 cK6BG/WPln;
Authentication-Results: ams-dkim-2;; dkim=pass ( sig from verified; );
Cc: Gorry Fairhurst <>, Magnus Westerlund <>, Francois Le Faucheur IMAP <>, Bruce Davie <>,,, Ashok Narayanan <>, James Polk <>
Subject: Re: [secdir] SecDir review of draft-ietf-tsvwg-rsvp-l3vpn-02
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 30 Jun 2009 16:59:36 -0000

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.



> Stefan Santesson