Network Working Group Tony Li INTERNET DRAFT Juniper Networks CPE based VPNs using MPLS Status This document is an Internet Draft. 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 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 a "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 1.0 Abstract This document describes a proposed architecture for the construction of Virtual Private Networks (VPNs). This proposal differs from [1] and [2] in that the functionality of the VPN is shared by the Customer Premises Equipment (CPE). Multi-Protocol Label Switching (MPLS) is used as a tunneling mechanism across the ISP network. 2.0 Introduction A VPN is a mechanism that allows one or more sites to exchange packets. It differs from traditional Internet connectivity in that: - The address space used by the VPN sites might not be global - The VPN sites require secure communications, possibly including payload privacy and protocol level privacy - Sites might interact with multiple VPNs and with the Internet simultaneously - The ISP might perform traffic engineering on the structure of the VPN to ensure consistent service to the VPN participants This proposal differs from those found in [1] and [2] in that it allows the VPN site to maintain physical security over the cryptographic equipment used to encrypt its data. This security level is likely to be necessary for any site with a serious interest in security. The implication is that a VPN site need not trust the Internet Service Provider (ISP) to ensure data privacy, only to provide data transit. This proposal uses BGP as the primary mechanism for information distribution and assumes that RSVP or LDP is used as the signaling mechanism for the MPLS domain. 3.0 Theory of Operation In this architecture, BGP information is exchanged between the CPE and the ISP's border router so that the CPE can indicate (a) its presence in the network and (b) the set of VPNs that the CPE would like to participate in. This information is possibly (but not necessarily) filtered by the ISP and then passed on to other sites. Sites wishing to connect to the VPN initiate an MPLS label-switched path (LSP) with other members of the VPN. If the creation of the LSP is allowable according to the policies established for the VPN, the connection is established and the sites that initiated the LSP have connectivity through the LSP. Transit service is provided by encapsulating packets in an MPLS tunnel. The ISP is responsible for delivering the packets to the designated site within the network. The ISP is not responsible for providing security for the VPN, but it might provide access control information on the distribution of information about the VPN itself. The specification of the policies for VPN membership and the mechanisms for determining policy compliance are beyond the scope of this document. Because an LSP can be modeled as a (half-duplex) point-to-point link, the topology of the VPN can be a full mesh between sites. Alternately, a sparse topology can be constructed based on the policy established by the CPE. This allows the participants in the VPN to determine the optimal tradeoff between administrative overhead and optimized routing between sites. For scalability reasons, providing VPN services is done at the site level. Individual users wishing to access the VPN must do so through a VPN member site. Users not physically present at a VPN member site may access the VPN by first accessing a VPN member site using a mechanism such as Mobile IP [3]. 4.0 VPN advertisement To advertise membership in the VPN, the CPE uses BGP. The CPE advertises a host route (/32 prefix) in BGP. The address that is advertised is the IP address of the CPE equipment itself. This address is taken from the ISP's address space and can be globally unique. The remainder of the address space within a site can be local, and the CPE can provide NAT functionality to separate the address space of the site from the global Internet and/or the remainder of the VPN. [4] To identify the VPN, each VPN is given a unique identifier. This identifier is a 16-bit number, assigned by the ISP. The CPE advertises this number as part of the BGP communities attribute by advertising a community in which the most significant 16 bits are the ISP's Autonomous System (AS) number and the least significant 16 bits are the VPN identifier. This BGP community number is already allocated to the ISP for local use by the ISP. Additional VPN identifiers can be allocated either by acquiring another AS number or by use of one of the locally scoped communities. The ISP's border router is the first router to receive the VPN advertisement from the CPE. At this point, the ISP can filter or otherwise examine the advertisement to ensure that it complies with the ISP's policies. For example, the ISP might wish to sell VPN services at an extra charge. The ISP could discard VPN advertisements from customers that had not subscribed to the VPN service. Further, if the ISP helps to administer membership in the VPN, the ISP optionally could discard advertised communities that the site did not actually participate in. For VPN advertisements that are accepted by the ISP, BGP naturally propagates them to other BGP speakers attached to the ISP and thus to other CPE devices. Note that the ISP can easily construct policy such that a CPE receives only the BGP advertisements that the ISP selects, such as those from other members of the VPN and the default route. This would avoid having the CPE carry full routing. Further, the ISP can easily filter out VPN advertisements, thus protecting the default-free Internet routing table from the introduction of unnecessary routes. The receiving CPE can authenticate the BGP advertisements that it receives, discarding any that fail the authentication test. 5.0 Establishing LSPs When a CPE receives a VPN advertisement, it can decide to create a VPN connection to the advertiser. The CPE is under no obligation to connect to all possible members of the VPN. The creation of VPN LSPs is a function of the VPN participants and the ISP. For example, a common topology today is a star, in which an enterprise has a central site and many remote sites. In general, the remote sites communicate only with the central site. Thus, it makes sense for the remote sites to establish an LSP only back to the central site rather than forming a full mesh of LSPs between VPN participants. Such a policy could be configured into the remote site's CPE. If a site does decide to initiate a VPN LSP to another VPN participant, it does so by using an MPLS signaling protocol to set up the LSP. Currently, both RSVP and LDP are possible candidate signaling protocols for MPLS. The modifications discussed in this document could reasonably be applied to both protocols. When a site is establishing an LSP, it uses its signaling protocol to indicate that it would like an LSP. It uses the address of the CPE device at the opposite end of the LSP to indicate the destination of the LSP. In addition, the CPE attaches the VPN identifier, a time stamp, and a signature for security purposes. Because the ISP participates in the signaling protocol, it has the ability to filter out setup requests for the VPN that do not coincide with the ISP's policies. This helps to ensure that access to VPN services is enforced at the LSP level. In addition, the ISP has the ability to perform traffic engineering on the LSP setup request. Work on traffic engineering is currently in progress, but it is reasonable to expect that an explicit route could be computed by the ISP's border router and attached to the setup request. This allows the ISP to place VPN traffic on appropriate facilities to ensure appropriate service levels for the VPN. After passing the entry border router, the LSP setup propagates through the ISP's network in a manner similar to any other traffic- engineered LSP. When the LSP setup request is received by the destination CPE, it is again authenticated and can be rejected (using the appropriate signaling protocol mechanisms) if it fails the authentication check or violates the destination CPE's configured policies. If it is accepted, the CPE completes the setup request as it normally would within the signaling protocol. As part of the acknowledgment of the setup, the destination CPE also can attach a series of prefixes to its acknowledgment. These prefixes represent reachability information that the destination CPE allows the originating CPE to reach using that LSP. When the originating CPE system receives the acknowledgment, it can, depending on its configured policies, install the prefixes in its forwarding table and it also can inject those prefixes into its local routing. Note that these prefixes are determined by configuration and do not constitute a routing protocol in and of themselves. No mechanisms are provided here to ensure loop freedom or optimality of route computation for prefixes exchanged using the signaling protocol. Sites wishing to have a routing protocol run on top of the VPN are not precluded by this architecture, but no special provisions are made for (or are required by) such situations. Similarly, multicast can be supported on the VPN by running normal multicast routing protocols across the VPN. 6.0 Acknowledgments The author would like to thank Johna Johnson, Aviva Garrett, and Lisa Bourgeault for her comments and Yakov Rekhter for his generous contributions to this work. 7.0 References [1] J. Heinanen, et. al, "VPN support with MPLS," , March 1998. [2] D. Jamieson, et. al, "MPLS VPN Architecture," , August 1998. [3] C. Perkins, "IP Mobility Support," RFC 2002, October 1996. [4] K. Egevang & P. Francis, "The IP Network Address Translator (NAT)," RFC 1631, May 1994. 8.0 Author's Address Tony Li Juniper Networks, Inc. 385 Ravendale Dr. Mountain View, CA 94043 Email: tli@juniper.net Fax: +1 650 526 8001 Voice: +1 650 526 8006