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
- 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.
> -----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:
> 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
> 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
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> Internet-Drafts can also be obtained by e-mail.
> Send a message to:
> 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.