R. Bonica WorldCom Internet Draft Y. Rekhter Expiration Date: April 2003 Juniper Networks R. Raszuk E. Rosen D. Tappan Cisco Systems October 2002 CE-to-CE Authentication for Layer 3 VPNs draft-ietf-ppvpn-l3vpn-auth-01.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 authentication mechanism that PPVPN customers can use to detect security breaches caused by misconfiguration of the provider network. 3. Overview Provider Provisioned Virtual Private Networks (PPVPN) support routing privacy among customer interfaces. In order to support routing privacy, Provider Edge (PE) routers maintain multiple forwarding table instances, with each forwarding table instance containing routes for one or more Virtual Private Networks (VPN). Service providers (SP) assign customer interfaces to these VPN specific routing table instances. In doing so, the SP assigns the customer interface to a VPN. The SP assures VPN customers that all VPN traffic will remain within the VPN. Conversely, the SP assures VPN customers that VPN interfaces will never receive datagrams originating outside of the VPN. In order to provide these assurances, the SP must configure its PE routers correctly. If the SP assigns a customer interface to the wrong forwarding table instance, 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 authentication mechanism. VPN customers could use the CE-based authentication mechanism to protect themselves against 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. In order to support authentication, each VPN site sends the PE router that supports it a magic cookie. In many cases, the Customer Edge (CE) router originates the magic cookie. In configurations where the SP manages the CE, the customer can designate another device contained by the VPN site as the magic cookie originator. Having received the magic cookie, the PE router sends an authentication request to a server that the customer controls. The query identifies the PE router, VPN, and interface. It also contains the magic cookie. If the authentication server explicitly rejects the authentication request, the PE router terminates the authentication process. Therefore, the PE router will neither accept traffic from the CE nor send traffic to it. If the authentication server explicitly accepts the authentication request or fails to respond, the PE router joins the CE to the VPN. At this point, the PE will accept traffic from the CE and forward traffic to the CE. It will also accept routes from the CE and distribute them throughout the provider network. Having proceeded to this phase of the authentication process, the PE router distributes the magic cookie 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 receives a magic cookie that it cannot authenticate, it issues an alarm requesting operator intervention. The CE 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 magic cookie information to the CE until it has received a magic cookie from the customer site that the CE supports. Note also that the authentication process does not rely upon the availability of an authentication server. In fact, authentication server deployment is optional. Some customers may choose not to deploy an authentication server and rely entirely upon authentication by CE routers. The magic cookie approach described by this document contains four components. These are 1) Customer-to-PE signaling, 2) PE-to- authentication server signaling, 3) PE-to-PE signaling and 4) 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. Motivation Currently, PPVPN 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 an 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 authentication mechanism, described herein, informs Customer A of the VPN breach. It provides immediate and automatic notification. Customers who seek to prevent accidental misconfiguration of the provider network should deploy the authentication server described above. Customers who merely require post-hoc notification of accidental misconfiguration need not deploy the authentication server. The CE-to-CE authentication 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. 6. Customer-to-PE Signaling In order to support CE-based authentication, each VPN site must send one or more magic cookies to the PE router that supports it. In many cases, the CE will originate the magic cookie. In configurations where the SP manages the CE, the customer may designate another device contained by the VPN site as the magic cookie originator. If the device that originates the magic cookie also maintains a BGP peering session with the PE, the originating device can piggyback magic cookie information on this BGP peering session. Section 8 of this document describes an extended BGP community attribute that supports this purpose. Section 10 of this document describes a new UDP-based protocol that also can be used to propagate magic cookies from customer equipment to PE. This protocol can be used in any VPN configuration, including the configuration described above. 7. PE-to-Authentication Server Signaling Having received the magic cookie, the PE router sends an authentication request to a server that the customer controls. The authentication request identifies the PE router and specifies the magic cookie. If the authentication server explicitly rejects the authentication request, the PE router terminates the authentication process. Therefore, the PE router will neither accept traffic from the CE nor send traffic to it. If the authentication server explicitly accepts the authentication request or fails to respond, the PE router joins the CE to the VPN. At this point, the PE will accept traffic from the CE and forward traffic to the CE. It will also accept routes from the CE and distribute them throughout the provider network. Section 10 of this document describes a new UDP-based protocol that the PE can use to communicate with the authentication server. 8. PE-to-PE Signaling In order to support CE-based authentication, the PE router must not activate routes to destinations that are contained by a directly connected VPN site until it has received a magic cookie from the VPN site. When the PE has received a magic cookie and attempted to contact the customer's authentication server, it will activate those routes and advertise them to its iBGP peers. (That is, the PE will advertise 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 magic cookie to each BGP update. To support this purpose, this document defines a new transitive extended community [EXTBGP] called CE-to-CE Authentication Token. This community uses the format of the Opaque extended community. The low-order octet of the Type field of the CE-to-CE Authentication Token is TBD (to be assigned by the IANA). The 6 octets of the Value field carries the magic cookie. If the provider network does not use BGP to distribute VPN routes among PE routers, it can use the UDP-based protocol described in Section 10 of this document to distributed magic cookies to remote PE routers. 9. PE-to-CE Signaling Previous sections of this document describe how the PE router acquires a magic cookie to be associated with each route that is active in its forwarding table. Section 6 describes how the PE acquires magic cookies from directly connected VPN sites. Section 8 describes how the PE acquires magic cookies from other PE routers. In order to support CE-based authentication, the PE router must relay these magic cookies to directly connected CE routers. If the PE and CE routers maintain a BGP peering session with one another, the PE can use this BGP peering session to send magic cookies to the CE. Section 8 of this document describes a BGP extended community attribute that supports this purpose. Section 10 of this document describes a new UDP-based protocol that also can be used to propagate magic cookies from PE to CE. This protocol can be used in any VPN configuration, including the configuration described above. The PE must relay every magic cookie that it has acquired regarding a VPN to each CE router that participates in the VPN. When the PE router receives a new magic cookie, it must relay it to the appropriate CE routers immediately. Furthermore, the PE router MUST not reveal any magic cookie information to CE routers that are contained by sites from which a magic cookie has not yet been received. 10. VPN Cookie Propagtion Protocol The VPN Cookie Propagtion Protocol is used to distribute magic cookie information. It supports the following message types: ANNOUNCEMENT ACCEPT REJECT The CE routers can send the ANNOUNCEMENT message to PE routers. PE routers can send the ANNOUNCEMENT message to the authentication server, to each other, and to CE routers. The authentication server sends an ACCEPT message to the PE router in order to accept a magic cookie that it has received. It sends a REJECT message to the PE router in order to reject a magic cookie. The authentication server may not send ANNOUNCEMENT messages. PE router and CE routers may not send ACCEPT messages or REJECT messages. 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 | Message Type | AuType | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic Cookie (Octets 1-4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic Cookie (Octets 5-6) | Reserved (must be zero) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 The Version field is equal to 1. The Message Type field may contain the following values: ANNOUNCEMENT 1 ACCEPT 2 REJECT 3 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 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 Cookie Propagtion Protocol establishes soft state between PE and CE routers. ANNOUNCEMENTS expire automatically upon expiration of a configurable timer. Therefore PE and CE routers must repeat ANNOUNCEMENT messages periodically. By default, ANNOUNCEMENTS expire in 60 minutes, and should be refreshed every 20 minutes. However, the PE router does not need to submit a magic cookie to the authentication server multiple times. It submits the magic cookie to the authentication one time, as soon as the magic cookie is acquired from the customer site. 11. Configurability SPs can deploy the authentication mechanisms described above globally or on a per-VPN basis. In either case, a particular VPN site within the authentication domain may not be capable of announcing a magic cookie to the PE that supports it. In this case, the SP can configure the PE router so that it will permit that particular CE router to join the authentication enabled VPN. The PE router will associate a null cookie (value 0x000000000000) with the VPN site that the CE supports. The PE router will distribute this null cookie into the VPN as if it had been announced by the CE device. 12. Security Considerations If VPN customer receives a magic cookie that it cannot authenticate, the VPN customer should contact his/her SP immediately. The VPN customer should also consider changing its magic cookie value, as the SP may have revealed that value to an unauthorized party. 13. 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. IANA will also assign a new UDP port number to the VPN Cookie Propagation Protocol, described in Section 10. 14. Acknowledgements Thanks to Beth Alwin, Eduard Metz, Richard Morgan and Benson Schliesser for their comments on this draft. 15. Normative References [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 [EXTBGP], "BGP Extended Communities Attribute", Ramachandra, S., Tappan, D., Rekhter, Y., June 2001, draft-ietf-idr-bgp-ext- communities-02.txt 16. 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 Eric C. Rosen Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824 Email: erosen@cisco.com Robert Raszuk Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824 Email: raszuk@cisco.com Dan Tappan Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA 01824 Email: tappan@cisco.com 17. 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.