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.
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
- 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.
From: l3vpn-bounces@xxxxxxxx [mailto:l3vpn-bounces@xxxxxxxx]
On Behalf Of Internet-Drafts@xxxxxxxx
Sent: Monday, January 10, 2005 3:50 PM
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
A list of Internet-Drafts directories can be found in
Internet-Drafts can also be obtained by e-mail.
Send a message to:
In the body type:
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
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.