L3VPN Working Group R. Bonica
Internet-Draft Y. Rekhter
Expires: June 1, 2005 Juniper Networks
E. Rosen
R. Raszuk
D. Tappan
Cisco Systems
December 2004
CE-to-CE Member Verification for Layer 3 VPNs
draft-ietf-l3vpn-l3vpn-auth-01
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 1, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document describes a CE-based verification mechanism that VPN
customers can use to detect security breaches caused by
misconfiguration of the provider network.
Bonica, et al. Expires June 1, 2005 [Page 1]
Internet-Draft CE Verification December 2004
Table of Contents
1. Conventions Used In This Document . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Customer-to-PE Signaling . . . . . . . . . . . . . . . . . . . 7
5. PE-to-PE Signaling . . . . . . . . . . . . . . . . . . . . . . 8
6. PE-to-Customer Signaling . . . . . . . . . . . . . . . . . . . 9
7. VPN Token Propagation Protocol . . . . . . . . . . . . . . . . 10
8. Configurability . . . . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 13
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
12. Normative References . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . 16
Bonica, et al. Expires June 1, 2005 [Page 2]
Internet-Draft CE Verification December 2004
1. Conventions Used In This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [3].
Bonica, et al. Expires June 1, 2005 [Page 3]
Internet-Draft CE Verification December 2004
2. Overview
When properly configured, a Layer 3 Virtual Private Network (L3VPN)
permits communications within a VPN, but prevents communication
across VPN boundaries. In order to maintain this posture, the
Service Provider must configure its network correctly. If the SP
assigns a customer interface to the wrong VPN, or commits some other
configuration error, unauthorized parties might join a VPN, while
legitimate VPN members are unaware of the security breach.
Therefore, some VPN customers may require a CE-based mechanism for
VPN membership verification. VPN customers could use the mechanism
to detect security breaches caused by misconfiguration of the
provider network.
This document describes a token-based approach to VPN membership
verification. In order to join a VPN, each VPN site sends a token to
the Provider Edge (PE) router to which it is attached. In many
cases, the Customer Edge (CE) router originates the token. In
configurations where the SP manages the CE, the customer can
designate another device contained by the VPN site as the token
originator.
Having received a token, the PE joins the VPN site to the VPN. The
PE accepts and activates routes to the VPN site and distributes those
routes throughout the provider network. The PE router also
distributes the token throughout the provider network. All PE
routers that support the VPN receive the token and relay it to each
directly connected customer device that participates in the VPN.
Customer devices use the token to verify membership of the newly
joined VPN site.
If a customer device receives a token that it does not recognize, it
issues an alarm requesting operator intervention. The customer
device may also withdraw from the VPN, neither sending traffic to the
VPN nor accepting traffic from it until an operator clears the
security condition.
Note that the PE will not reveal any tokens to a customer device
until it has received a token from the site that the customer device
supports.
The token-based approach described by this document contains three
components. These are:
Bonica, et al. Expires June 1, 2005 [Page 4]
Internet-Draft CE Verification December 2004
Customer-to-PE signaling
PE-to-PE signaling
PE-to-Customer signaling
This document dedicates a section to each component.
Bonica, et al. Expires June 1, 2005 [Page 5]
Internet-Draft CE Verification December 2004
3. Motivation
Currently, L3VPN customers cannot detect security breaches that are
caused by accidental misconfiguration of the SP network. For
example, assume that an SP maintains two VPN's. The first VPN
supports Customer A while the second VPN supports Customer B. Assume
also that Customer B requests a new VPN service connection. The SP
processes Customer B's request, but accidentally configures Customer
B's new connection into Customer A's VPN.
Typically, Customer B is first to detect the problem. Customer B
tells the SP that an error has occurred and the SP corrects the
error. The SP may or may not tell Customer A that his/her VPN has
been breached.
The CE-to-CE verification mechanism, described herein, informs both
customers of the VPN breach, providing immediate and automatic
notification. It does not prevent the breach or the misconfiguration
that caused it.
The CE-to-CE verification mechanism does not protect VPN customers
from intentional misbehavior on the SP's part. The VPN customer must
trust the SP to implement this mechanism faithfully.
Bonica, et al. Expires June 1, 2005 [Page 6]
Internet-Draft CE Verification December 2004
4. Customer-to-PE Signaling
In order to join a VPN, each VPN site sends a token to the PE router
to which it is attached. In many cases, the CE will originate the
token. In configurations where the SP manages the CE, the customer
may designate another device contained by the VPN site as the token
originator.
If the device that originates the token also maintains a BGP [1]
peering session with the PE, the originating device can append the
token to each BGP update. To support this purpose, this document
defines a new transitive extended community [EXTBGP] called CE-to-CE
Verification Token. This community uses the format of the opaque
extended community.
The high-order octet of the Type field of the CE-to-CE Authentication
Token is 0x03. The low-order octet of the Type field is 0x02. The 6
octets of the Value field carries the token itself.
If the device that originates the token does not maintain a BGP
peering session with the PE, the VPN site can use new protocol
described in Section 7 of this document to send tokens to the PE.
This protocol can be used in any VPN configuration, regardless of
whether the originating device maintains a BGP peering session with
the PE.
Bonica, et al. Expires June 1, 2005 [Page 7]
Internet-Draft CE Verification December 2004
5. PE-to-PE Signaling
In order to support CE-based verification, the PE router MUST not
activate routes to a directly connected VPN site until it has
received a token from that site. When the PE has received a token,
it activates those routes and advertise them to its iBGP peers.
(That is, the PE advertises those routes to remote PE routers that
support the VPN.)
If the provider network uses BGP to distribute VPN routes among PE
routers, it appends the token to each BGP update. Section 4 of this
document describes a BGP extended community attribute that supports
this purpose.
If the provider network does not use BGP to distribute VPN routes
among PE routers, it can use the new protocol described in Section 7
of this document to distribute tokens among PE routers.
Bonica, et al. Expires June 1, 2005 [Page 8]
Internet-Draft CE Verification December 2004
6. PE-to-Customer Signaling
In order to support CE-based verification, the PE router MUST relay
tokens that it receives from other PE routers to directly connected
customer devices. The customer device can be a CE router or a
directly connected host. If the PE and customer device maintain a
BGP peering session with one another, the PE can use this BGP peering
session to send tokens to the customer device. Section 4 of this
document describes a BGP extended community attribute that supports
this purpose.
Section 7 of this document describes a new protocol that also can be
used to propagate tokens from PE to customer device. This protocol
can be used in any VPN configuration, regardless of whether the
customer device maintains a BGP peering session with the PE.
The PE MUST relay every token that it has acquired regarding a VPN to
each directly connected customer device that participates in the VPN.
When the PE router receives a new token, it MUST relay it to the
appropriate customer devices immediately. Furthermore, the PE router
MUST not reveal any tokens to customer devices that are contained by
sites from which a token has not yet been received.
Bonica, et al. Expires June 1, 2005 [Page 9]
Internet-Draft CE Verification December 2004
7. VPN Token Propagation Protocol
The VPN Token Propagation Protocol is used to distribute tokens.
Figure 1 depicts the format of all messages.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | AuType | Token (Octets 1 - 2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token (Octets 3-6) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
Figure 1: message
The Version field is equal to 1.
The AuType field indicates how this message should be authenticated.
It may contain the following values:
No Authentication 0
Simple Password 1
Message Digest-5 2
The Token field contains the verification token.
The Authentication field contains 64 bits of authentication data used
to authenticate the message. The AuType field specifies how these 64
bits are to be used.
The VPN Token Propagation Protocol establishes soft state between PE
and customer device. Announcements expire automatically upon
expiration of a configurable timer. Therefore announcements must be
repeated periodically. By default, announcements expire in 30
minutes, and should be refreshed 10 minutes.
The VPN Token Propagation Protocol obtains transport services from
UDP. All VPN Token Propagation Protocol messages are directed to UDP
port 3694.
Bonica, et al. Expires June 1, 2005 [Page 10]
Internet-Draft CE Verification December 2004
8. Configurability
SPs can deploy the verification mechanisms described above globally
or on a per-VPN basis. In either case, a particular VPN site within
the verification domain may not be capable of announcing a token to
the PE that supports it. In this case, the SP can configure the PE
router so that it will permit that particular VPN site to join the
VPN. The PE router will associate a null token (i.e.,
0x000000000000) with the VPN site. The PE router will distribute
this null token into the VPN as if it had been announced by the VPN
site.
Although the null token may be useful during migration periods,
customer should avoid its long term use.
Bonica, et al. Expires June 1, 2005 [Page 11]
Internet-Draft CE Verification December 2004
9. Security Considerations
If VPN customer receives a token that it does not recognize, the VPN
customer should contact his/her SP immediately. The VPN customer
should also consider changing its token value, as the SP may have
revealed that value to an unauthorized party.
Bonica, et al. Expires June 1, 2005 [Page 12]
Internet-Draft CE Verification December 2004
10. IANA Considerations
IANA will assign a new extended BGP community sub-type, with the
high-order octet of the Type field equal to 0x03 and low-order octet
equal to 0x02. This BGP extended community type will represent the
CE-to-CE Authentication Token.
IANA will has assigned UDP port number 3694 to the VPN Token
Propagation Protocol, described in Section 7.
Bonica, et al. Expires June 1, 2005 [Page 13]
Internet-Draft CE Verification December 2004
11. Acknowledgements
Thanks to Beth Alwin, Eduard Metz, Richard Morgan, Benson Schliesser
and Paul Hoffman for their comments on this draft.
12 Normative References
[1] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
RFC 1771, March 1995.
[2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] Sangli, S., Tappan, D. and Y. Rekhter, "BGP Extended Communities
Attribute", draft-ietf-idr-bgp-ext-communities-07 (work in
progress), March 2004.
Authors' Addresses
Ronald P. Bonica
Juniper Networks
2251 Corporate Park Drive
Herndon, VA 20171
US
Phone: +1 571 203 1704
EMail: rbonica@juniper.net
Yakov Rekhter
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
US
EMail: yakov@juniper.net
Bonica, et al. Expires June 1, 2005 [Page 14]
Internet-Draft CE Verification December 2004
Eric C. Rosen
Cisco Systems
250 Apollo Drive
Chelmsford, MA 01824
US
EMail: erosen@cisco.com
Robert Raszuk
Cisco Systems
170 West Tasman Dr
San Jose, CA 95134
US
EMail: raszuk@cisco.com
Dan Tappan
Cisco Systems
250 Apollo Drive
Chelmsford, MA 01824
US
EMail: tappan@cisco.com
Bonica, et al. Expires June 1, 2005 [Page 15]
Internet-Draft CE Verification December 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Bonica, et al. Expires June 1, 2005 [Page 16]
