l3vpn@ietf.org
[Top] [All Lists]

Re: Comment on draft-ietf-l3vpn-l3vpn-auth-01.txt - Customer is not pref

Subject: Re: Comment on draft-ietf-l3vpn-l3vpn-auth-01.txt - Customer is not preferred method of error detection
From: Ronald Bonica
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

David McDysan wrote:
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: l3vpn-bounces@xxxxxxxx [mailto:l3vpn-bounces@xxxxxxxx] On Behalf Of Internet-Drafts@xxxxxxxx
Sent: Monday, January 10, 2005 3:50 PM
To: i-d-announce@xxxxxxxx
Cc: l3vpn@xxxxxxxx
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 i-d-announce-request@xxxxxxxx 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:
        mailserv@xxxxxxxxx
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.






<Prev in Thread] Current Thread [Next in Thread>