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]