Subject: Comment on draft-ietf-l3vpn-l3vpn-auth-01.txt - Customer is not preferred method of error detection

From: David McDysan <[email-masked]>
Date: Mon, 07 Mar 2005 13:32:42 -0500

This proposal seems to only address the following requirement from section
6.4 of the l3vpn requirements:

  In the case of a PE-based VPN, a solution SHOULD support the means 
   for attached CEs to authenticate each other and verify that the SP's 
   VPN network is correctly configured. 

However, it does not appear to address the more general authentication
requirements stated in section 6.9.2:

 Furthermore, traffic exchanged within the scope of VPN MAY involve 
   several categories of equipment that must cooperate together to 
   provide the service [Y.1311.1]. These network elements can be CE, 
   PE, firewalls, backbone routers, servers, management stations, etc. 
   These network elements learn about each others identity, either via 
   manual configuration or via discovery protocols, as described in 
   section 6.4. When network elements must cooperate, these network 
   elements SHALL authenticate peers before providing the requested 
   service. This authentication function MAY also be used to control 
   access to network resources. 
    
   The peer identification and authentication function described above 
   applies only to network elements participating in the VPN. Examples 
   include: 
   - traffic between a CE and a PE, 
   - traffic between CEs belonging to the same VPN, 
   - CE or PE routers dealing with route announcements for a VPN, 
   - policy decision point [RFC 3198] and a network element, 
   - management station and an SNMP agent. 
    
   Each L3VPN solution SHOULD describe for a peer authentication 
   function: where it is necessary, how it shall be implemented, how 
   secure it must be, and the way to deploy and maintain identification 
   and authentication information necessary to operate the service.  

Having the customer detect network configuration errors and then report them
is an undesirable situation from a service provider perspective. 

I suggest that the working group consider extending this protocol to include
a "token" which would allow authentication by the PE as well as the CE.
There should be a mode where the PE as well as the CE can confirm that the
CE is in fact joining the intended VPN. For example, a digital certificate
using public key crytography (or something along these lines) could be used
as another form of token could meet this need. 

Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of [email-masked]
> Sent: Monday, January 10, 2005 3:50 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: I-D ACTION:draft-ietf-l3vpn-l3vpn-auth-01.txt
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories. This draft is a work item of the 
> Layer 3 Virtual Private Networks Working Group of the IETF.
> 
> 	Title		: CE-to-CE Member Verification for Layer 3 VPNs
> 	Author(s)	: R. Bonica, et al.
> 	Filename	: draft-ietf-l3vpn-l3vpn-auth-01.txt
> 	Pages		: 16
> 	Date		: 2005-1-10
> 	
> This document describes a CE-based verification mechanism that VPN
>    customers can use to detect security breaches caused by
>    misconfiguration of the provider network.
> 
> A URL for this Internet-Draft is: 
> http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-l3vpn-auth-01.txt
> 
> To remove yourself from the I-D Announcement list, send a message to 
> [email-masked] with the word unsubscribe in 
> the body of the message.  
> You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce 
> to change your subscription settings.
> 
> 
> Internet-Drafts are also available by anonymous FTP. Login 
> with the username "anonymous" and a password of your e-mail 
> address. After logging in, type "cd internet-drafts" and then
> 	"get draft-ietf-l3vpn-l3vpn-auth-01.txt".
> 
> A list of Internet-Drafts directories can be found in 
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-l3vpn-l3vpn-auth-01.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail 
> reader implementation to automatically retrieve the ASCII 
> version of the Internet-Draft.
>

---

From: Ronald Bonica <[email-masked]>
Date: Tue, 08 Mar 2005 09:00:11 -0500

Dave,

Thanks for this comment. You are correct in that 
draft-ietf-l3vpn-l3vpn-auth addresses the requirement stated in Section 
6.4 while draft-behringer-mpls-vpn-auth addresses the more general 
requirement stated in section 6.9.2.

I think that both drafts would do well to distinguish the difference 
between one another by referencing the requirement that they address. I 
will add this to draft-ietf-l3vpn-l3vpn-auth.

                                            Ron