Internet Draft R. Bonica Expiration Date: May 2002 WorldCom Y. Rekhter Juniper Networks November 2001 CE-to-CE Authentication for RFC 2547 VPNs draft-bonica-l3vpn-auth-00.txt 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC-2026]. 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. 2. Abstract This document describes a CE-based VPN authentication mechanism. Specifically, this document describes a "magic cookie" approach to VPN authentication. According to this approach, the Customer Edge (CE) router must send the PE a magic cookie before the PE permits the CE to participate in the VPN. Having received the magic cookie, the PE router distributes it throughout the provider network. All PEs that support the VPN receive the magic cookie and relay it to each attached CE router that participates in the VPN. CE routers use the magic cookie to authenticate their VPN peers. If a CE router receives a magic cookie that it cannot authenticate, the CE issues an alarm requesting operator intervention. If required by local security policy, the CE also ceases to send traffic to the PE from which the cookie was received, and discards all traffic from that PE. Note that the PE will not accept any VPN traffic from the CE until it has received a magic cookie from that CE. Furthermore, the PE will not distribute any VPN routes for which the CE is next hop until it has received magic cookie from the CE. 3. Overview RFC 2547 VPNs [2547bis] support routing privacy among customer interfaces. In order to support routing privacy, service providers associate customer interfaces with a VPN. Provider Edge (PE) routers support multiple forwarding table instances, with each forwarding table instance supporting a specific VPN. Each VPN specific forwarding table instance contains routes to destinations that belong to its VPN. The service provider assures the VPN customer that it will not forward the customer's datagrams outside of its VPN. Conversely, the service provider assures the VPN customer that its network interfaces will not receive datagrams that originated outside of the customer's VPN. In order to provide these assurances, the service provider must configure PE routers correctly. If the service provider assigns a customer interface to the wrong VPN (or more precisely to the wrong forwarding table instance), or commits some other configuration error, unauthorized parties might join a VPN, while legitimate VPN members would be unaware of the security breach. Therefore, some VPN customers may require a CE-based authentication mechanism. VPN customers could use the CE-based authentication mechanism to protect themselves from security breaches caused by misconfiguration of the provider network. This document describes such a mechanism. Specifically, this document describes a "magic cookie" approach to VPN authentication. According to this approach, the Customer Edge (CE) router must send the PE a magic cookie before the PE permits the CE to participate in the VPN. Having received the magic cookie, the PE router distributes it throughout the provider network. All PE's that support the VPN receive the magic cookie and relay it to each attached CE router that participates in the VPN. CE routers use the magic cookie to authenticate their VPN peers. If a CE router receives a magic cookie that it cannot authenticate, the CE issues an alarm requesting operator intervention. If required by local security policy, the CE also ceases to send traffic to the PE from which the cookie was received, and discards all traffic from that PE. Note that the PE will not accept any VPN traffic from the CE until it has received a magic cookie from that CE. Furthermore, the PE will not distribute any VPN routes for which the CE is next hop until it has received magic cookie from the CE. The magic cookie approach described by this document contains three components. These are 1) CE-to-PE signaling, 2) PE-to-PE signaling and 3) PE-to-CE signaling. This document dedicates a section to each component. 4. 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 [RFC-2119]. 5. CE-to-PE Signaling The CE uses existing routing mechanisms to send the following information to the PE: - magic cookie - magic cookie address The magic cookie is a plain-text password. The magic cookie address identifies the CE that originated the magic cookie. The magic cookie address MUST be unique within the VPN. If the CE uses BGP [RFC-1771] to announce reachability information to the PE, it also uses BGP to send magic cookie information to the PE. Specifically, the CE MUST send the PE a BGP announcement that contains exactly one /32 prefix. This prefix represents the magic cookie address, and is identical to the CE's BGP Identifier, as specified in the BGP OPEN message. The BGP announcement MUST also contain a BGP extended community that represents the CE router's magic cookie. Section 4 of this document defines a new BGP extended community attribute that supports this purpose. If the CE uses OSPF [RFC-2178] to advertise link state information to the PE, it also uses OSPF to send magic cookie information to the PE. In this case, the CE MUST authenticate all of its messages to the PE, as described in Section D.2 of RFC 2178. The CE MUST specify a plain-text password that contains six or fewer octets. The plain- text password serves as a magic cookie. The router-id specified by each OSPF message that the CE originates serves as the magic cookie address. If the CE uses IS-IS [RFC-1195] to advertise link state information to the PE, it also uses IS-IS to send magic cookie information to the PE. In this case, the CE MUST authenticate all of its messages to the PE, as described in Section 3.9 of RFC 1195. The CE MUST specify a plain-text password that contains six or fewer octets. The plain-text password serves as a magic cookie. The source address specified in the IP header of each IS-IS message that the CE originates serves as the magic cookie address. If the CE uses RIP-2 [RFC-1723] to announce reachability information to the PE, it also uses RIP-2 to send magic cookie information to the PE. In this case, the CE MUST authenticate all of its messages to the PE, as described in Section 3.1 of RFC 1723. The CE MUST specify a plain-text password that contains six or fewer octets. The plain-text password serves as a magic cookie. Furthermore, the CE must announce reachability to a /32 sub-network from which the RIP-2 message originates. This /32 address serves as the magic cookie address. If the CE and PE do not use any dynamic routing protocol to exchange routing information with one another, the CE should use RIP-2 to send magic cookie information to the PE, as described in the previous paragraph. 6. PE-to-PE Signaling When the PE acquires new magic cookie information from a CE, it MUST distribute this information to all distant PE routers that support the VPN. Specifically, the PE MUST send the each distant PE a BGP announcement that contains exactly one prefix that represents the magic cookie address. The BGP announcement MUST contain a BGP extended community that represents the newly acquired magic cookie. This document defines a new extended community attribute type, called CE-to-CE Authentication Token, to support this purpose. The extended community attribute [EXTBGP] is data structure that contains eight octets. The first two octets represent a community type and the remaining six octets represent a value. The high-order octet of the Type field is set to 0x03. The low-order octet of the Type field is TBD (to be assigned by the IANA). The Value field carries the magic cookie. 7. PE-to-CE Signaling The PE MUST distribute all magic cookie information that it has acquired regarding a particular VPN. It MUST distribute this information to all directly connected CE routers configured to participate in the VPN. The PE router acquires magic cookie information from directly connected CE routers, as well as distant PE routers. The PE router MUST distribute magic cookie information from both sources to directly connected CE routers, as required by VPN membership. The PE router MUST distribute magic cookie information immediately, upon acquisition. The PE router MUST also store magic cookie information so that it can distribute this information to CE routers that will attempt to join the VPN long after the information acquisition. The PE uses existing routing mechanisms to send the following information to the CE: - magic cookie - magic cookie address (when possible) If the PE uses BGP to announce reachability information to the CE, it also uses BGP to send magic cookie information to the CE. Specifically, the PE MUST send the CE a BGP announcement representing each magic cookie that it has received within the VPN context. The BGP announcement contains exactly one /32 prefix that represents the magic cookie address. The announcement also contains a BGP extended community that represents the magic cookie. If the PE uses OSPF to advertise link state information to the CE, it also uses OSPF to send magic cookie information to the CE. In this case, the PE MUST authenticate all of its messages to the CE, as described in Section D.2 of RFC 2178. Specifically, the PE includes a locally configured plain-text password in each OSPF message. If the PE has acquired any other magic cookies within the VPN context, it sends extra OSPF HELLO messages at each HELLOINTERVAL. Each of these additional OSPF HELLO messages specifies one of the magic cookies as its plain-text password. Unfortunately, OSPF does not include a mechanism through which the PE can send the CE the magic cookie address. If the PE uses IS-IS to advertise link state information to the CE, it also uses IS-IS to send magic cookie information to the CE. In this case, the PE MUST authenticate all of its messages to the CE, as described in Section 3.9 of RFC 1195. Specifically, the PE includes a locally configured plain-text password in each IS-IS message. If the PE has acquired any other magic cookies within the VPN context, it sends extra IS-IS HELLO messages at each HELLOINTERVAL. Each of these additional IS-IS HELLO messages specifies one of the magic cookies as its plain-text password. Unfortunately, IS-IS does not include a mechanism through which the PE can send the CE the magic cookie address. If the PE uses RIP-2 to announce reachability information to the CE, it also uses RIP-2 to send magic cookie information to the CE. In this case, the CE MUST authenticate all of its messages to the PE, as described in Section 3.1 of RFC 1723. The PE MUST specify a locally configured plain-text password as its authentication token. If the PE has received any magic cookies within the VPN context, it MUST announce reachability to each magic cookie address using the associated magic cookie as its authentication token. If the CE and PE do not use any dynamic routing protocol to exchange routing information with one another, the PE should use RIP-2 to send magic cookie information to the CE, as described in the previous paragraph. 8. Security Considerations If VPN customer receives a magic cookie that it cannot authenticate, the VPN customer should contact his/her service provider immediately. The VPN customer should also consider changing its magic cookie value, as the service provider may have revealed that value to an unauthorized party. If the VPN customer maintains backdoor interfaces outside of the VPN, the VPN customer MUST ensure that parties outside of the VPN cannot sends signaling traffic to PE-CE interfaces. 9. IANA Considerations IANA will assign a new extended BGP community sub-type, with the high-order octet of the Type field equal to 0x03. This BGP extended community type will represent the CE-to-CE Authentication Token. 10. References [2547bis], Rosen, E. et al., "BGP/MPLS VPSs", July, 2001, draft- ietf-ppvpn-rfc2547bis-00. [RFC-1195], Callon, R., "Use of IS-IS for Routing in TCP/IP and Dual Environments", RFC 1195, December 1990. [RFC-1723], Malkin, G., "RIP Version 2 Carrying Additional Information", RFC 1723, November 1994. [RFC-1771], Rekhter, Y., Li, T., "A Border Gateway Protocol (BGP- 4)", RFC 1771, March 1995. [RFC-2026], Bradner, S., "Internet Standards Process Revision 3", RFC 2026, Harvard University, October 1996. [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997 [RFC-2178], Moy, J., "OSPF Version 2", RFC 2178, July 1997 [EXTBGP], "BGP Extended Communities Attribute", Ramachandra, S., Tappan, D., Rekhter, Y., June 2001, draft-ietf-idr-bgp-ext- communities-02.txt 11. Author's Addresses Ronald P. Bonica WorldCom 22001 Loudoun County Pkwy Ashburn, Virginia, 20147 Phone: 703 886 1681 Email: ronald.p.bonica@wcom.com Yakov Rekhter Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, California 94089 Email: yakov@juniper.net 12. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.