Network Working Group H. Ould-Brahim Internet Draft B. Gleeson draft-ouldbrahim-vpn-vr-00.txt Nortel Networks Expiration Date: September 2000 March 2000 Network based IP VPN Architecture Using Virtual Routers Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. 1. Abstract This draft describes a network based IP VPN architecture with no assumption on the backbone transport technology used and no assumption on the routing protocol used. The architecture is based on the virtual router concept, which provides separate routing, forwarding, and quality of service per VPN basis. For scalability purposes, we introduce the concept of virtual connection gateway (VCG) for backbone connectivity to all virtual routers configured on a single service provider node. 2. Conventions used in this document ARP Address Resolution Protocol Ould-Brahim, et. al 1 Network based IP VPN Architecture September 2000 CPE Customer Premises Equipment LER Label Edge Router LSR Label Switch Router LSP Label Switched Path QoS Quality of Service SPE Service Provider Edge Node VCG Virtual Connection Gateway VPID Virtual Private Identifier VR Virtual Router 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 [2]. 3. Introduction Several solutions have been put forward to achieve different levels of network privacy when building VPNs across a shared public backbone. Most of these solutions require separate per VPN forwarding capabilities and make use of IP or LSP tunnels across the backbone [4], [8], and [10]. This document describes a network based IP VPN solution without the need for any routing protocol extension and is not restricted to a given type of backbone technology used. The architecture is based on the virtual router concept, which offers separate routing, forwarding, and quality of service per VPN basis. Virtual routers use the same mechanisms as physical routers and are easy to deploy, operate, and troubleshoot. For scalability purposes, we introduce a particular virtual router called "Virtual Connection Gateway" (VCG) used for backbone connectivity to all virtual routers configured on a single service provider node. The VCG allows virtual routers not to be involved in the routing across the backbone. Any routing protocol can be used at the virtual router and the VCG levels. VPN routing information is exchanged between VPN sites through IP tunnels. No assumption is made on the tunnel technology used (the tunnels can be IPSec, IP in IP, GRE, L2TP, or MPLS tunnels). 4. Requirements Flexibility No specific extensions needed for the routing protocols, and no restriction on the type of routing protocols used. The architecture should allow VPN address overlapping. Security Ould-Brahim, et al. March 2000 2 Network based IP VPN Architecture September 2000 The architecture should accommodate different levels of security. Any tunneling mechanism can be used. The addressing used within the VPN can be unrelated to that used to route the tunneled packets across the backbone. Backbone Technology Independence The VPN service should operate independently of the core network infrastructure. Backbone independence allows for smooth migration from one transport technology to another with minimal disruption to the VPN services. Quality of Service per VPN basis Quality of service can be configured per VPN basis. The architecture should be flexible to accommodate a wide range of QoS models. Scalability The architecture should accommodate different sizes of VPNs. The addition of new VPN sites should not impact both existing backbone configuration and existing VPNs configured on the service provider node. Management It should be easy to configure, deploy, operate, and troubleshoot each VPN. The architecture should support backdoor links between VPN sites. Traffic can be directed to the backdoor link, or injected via the ISP edge node with the flexibility of using both the ISP access, and the backdoor link as internal or external paths [4]. 5. Architecture Building Blocks A network based IP VPN consists of providing site-to-site private connectivity across a service provider core-networking infrastructure. A virtual private network is composed of multiple VPN sites attached to private CPE networks. The CPE device (e.g., a router) is connected to a service provider edge node (SPE). The SPE provides to the CPE, routing and forwarding capabilities across the backbone. The underlying backbone technology can be an ATM network. +------+ | | VPN-A(site 1)---| CPE | | | +------+ | +----------+ | SPE node | +----------+ | Ould-Brahim, et al. March 2000 3 Network based IP VPN Architecture September 2000 -------------------- ( Backbone ) -------------------- | | +----------+ +----------+ | SPE node | | SPE node | +----------+ +----------+ | | +-------+ +-------+ VPN-A (site 2)--| CPE | | CPE |-- VPN-A(site 3) +-------+ +-------+ Figure 1: IP VPN connectivity with three sites The private CPE network where the VPN sites are attached to accesses the SPE node by connecting to a virtual router over an access link which can be ATM virtual circuit, or PPP connection. Routing tables associated with each virtual router define the site-to-site connectivity for that enterprise VPN. 5.1 Backbone In general the backbone is a shared network infrastructure, which represents: (a) A layer-2 ATM network, (b) An overlay layer-3 network, possibly on top of an existing layer-2 network, (c) An MPLS network, using IP routing and label forwarding mechanism (with possible layer-2 technology used in the MPLS core). In this architecture, no assumption is made on the backbone technology supported. The backbone can be built from different transport technologies. 5.2 Virtual Router A virtual router (VR) is an emulation of a physical router at the software and hardware levels. Virtual routers have independent IP routing and forwarding tables and they are isolated from each other. This means that a VPN's IP addressing space can overlap with another VPN's address space. The IP addresses need only be unique within a VPN domain. A virtual router has two main functions: 1. Constructing routing tables describing the paths between VPN sites using any routing protocols (e.g., OSPF, RIP, or BGP-4). Ould-Brahim, et al. March 2000 4 Network based IP VPN Architecture September 2000 2. Forwarding or switching packets to the next hop within the VPN domain. From the user point of view, a virtual router provides the same functionality as a physical router. Many virtual routers can coexist on the same SPE node. From the CPE point of view, the SPE node performs the functions of many routers, forwarding packets to the correct destination, while isolating each VPN's traffic in the same manner that individual routers do. Separate router capabilities provide each CPE link with the appearance of a dedicated router that guarantees isolation from other VPN traffic while running on shared switching and transmission resources. Virtual private networks are created by interconnecting VRs across the backbone. The network administrator assigns a virtual router at every SPE where the sites attaches to the CPE network. Virtual routers belonging to the same IP VPN domain must have the same Virtual Private Identifier (VPID). The VPIds provide VPN membership between VRs, and are used only for administrative purposes. To the CPE access device, the virtual router appears as a neighbor router in the CPE network, to which it sends all traffic for non-local VPN destinations. Each CPE access device must learn the set of destinations reachable through its connection to the virtual router on the SPE node; this may be as simple as a default route. Virtual routers participating in a single VPN domain are responsible for learning and disseminating reachability information among themselves. 5.3 Virtual Connection Gateway The virtual connection gateway (VCG) is a virtual router that connects multiple VRs (configured on a single SPE node) to the backbone. The VCG connects each SPE node to a shared backbone infrastructure. VCGs can be deployed over ATM, IP, and MPLS networks. Since the VCG allows the aggregation of layer 2 connections over the network core, backbone configuration remains unaffected as the SPE network administrator adds new virtual routers, and therefore new VPN sites. The relationship between the VRs and the VCG is an overlay relationship. Each VCG on a SPE node can connect to other SPE nodes through its own core technology. By using multiple VCGs the core network administrator can migrate its backbone from one core technology to another with minimal disruption to VPN services. The VCG aggregates traffic from the CPE virtual routers and provides a single outbound connectivity into the backbone for all individual VPN traffic on that node. 5.4 Tunneling Two VPN endpoints are connected through the use of IP tunnels. The tunnel appears to private CPE networks as a point-to-point link. Ould-Brahim, et al. March 2000 5 Network based IP VPN Architecture September 2000 Traffic sent through the tunnel, and forwarded by the VCG is opaque to the underlying backbone technology used. Any tunneling mechanism can be used (e.g., Generic Routing Encapsulation (GRE) [5], Layer 2 Tunneling Protocol (L2TP) [13], IPSec [6], and MPLS). Each tunnel endpoint has two addresses: one public (or SPE based) address, and one private (or VPN based) address. The public address resides on the virtual carrier gateway, and the private address resides on the virtual router. The public tunnel address must be unique across the network but the private tunnel addresses can overlap between different VPNs. 6. Topology A typical IP VPN configuration consists of connecting all virtual routers to a single VCG on an SPE node (see figure 2). Each virtual router is configured to support one VPN at a given time (although the VR might be configured to support many). Each VCG is connected to the backbone through either ATM virtual circuit, PPP, or MPLS. +-----+ +-----+ +-----+ |VPN-A| |VPN-B| |VPN-C| |site1| |site1| |site1| +-----+ +-----+ +-----+ | | | |200.1.1.1/24 | | +--|-------------|------|-----+ | +-----+ +------+ +-----+ | /------|-|VR-A | | VR-B | |VR-C | | / /----|-+-----+ +------+ +-----+ | VPN-A / / | |10.1.1.1/24 | | | tunnel / / | | +------------------+ | | / / | -| VCG |- | / / | +------------------+ | / / +------------|----------------+ | | | | ------------------------|--------\ | ----------------- |2nd | ( ) |tunnel | /---------( Backbone )--------\ for VPN-A | | ----------------- | | | | | | | +-|----------------+ +--------+ +--|--------------------+ | | +------+ | | | | |+--------------+ | | | | VCG |----- | | Router | | || VCG |-- | | | +------+ | | | | | |+--------------+ | | | | |20.1.1.1/24| | +--------+ | | |30.1.1.1/24| | | |+-----+ +------+| | | |+----+ +-----+|+----+| ||VR-A | |VR-B |/ | | ||VR-A| |VR-B |/|VR-C|| |+-----+ +------+ | +-----+ |+----+ +-----+ +----+| | |200.1.1.2/24 | +------------------+ |VPN-C| | |200.1.1.3/24| | | |site2| +-|------------|----|---+ Ould-Brahim, et al. March 2000 6 Network based IP VPN Architecture September 2000 | | +-----+ | | | +-----+ +-----+ +-----+ +-----+ +-----+ |VPN-A| |VPN-B| |VPN-A| |VPN-B| |VR-C | |site2| |site2| |site3| |site3| |site3| +-----+ +-----+ +-----+ +-----+ +-----+ Figure 2: Network topology with three VPNs VPN sites are tunneled through the use of IP tunnels. The administrator configures the source address of the point-to-point IP tunnel on all virtual routers in the same VPN. The source endpoint of the IP tunnel stretches across the virtual router to the VCG on each SPE node. The virtual router performs encapsulation at the ingress, and the VCG performs de-encapsulation at the egress of the remote endpoint tunnel. 7. Addressing The addressing used within the backbone may have no relation to the addressing used by each VR connected to each local VPN. Different VRs can use the same addresses as long as they belong to different VPNs. One possible mechanism to provide mapping between private and public addresses for the tunnel endpoints is to use static ARP. In this case, the administrator creates a static ARP table for each VPN, and defines a mapping between public and private addresses for the tunnel endpoints. The static ARP table provides address resolution between destination endpoints public address (that is, the VCG on the destination SPE node) and its private address (that is, the virtual router to which the endpoint belongs). 8. Route Distribution between VRs within a VPN Virtual routers can run any routing protocol on their local VPN domain. Both static routes and dynamic routing protocols such as RIP, OSPF, and BGP-4 can be used. VPN sites exchange routing information through the IP tunnels over the backbone. Virtual routers export through any IGP the routing information learned from CPE devices to the routing protocol used over the tunnel (be it RIP, OSPF, or BGP-4) at the virtual router level. If a backdoor link is used between private CPE networks running any IGP over this link, then by adjusting the backdoor link costs appropriately, the SPE path can be favored for forwarding VPN traffic. In this model, the backdoor link can be used as a backup link in case the SPE path fails. 9. Route Distribution between VCGs Ould-Brahim, et al. March 2000 7 Network based IP VPN Architecture September 2000 Because no assumption is made on the backbone, the VCGs can also use any routing protocol to exchange routing information in the backbone. 10. Quality of Service The architecture adapts to different quality of service mechanisms to ensure site-to-site quality of service preservation per VPN. Packets received from a VPN site can receive differentiated services treatment at the virtual router level, which directly impacts what egress backbone link to use. In this case the virtual router may classify and police the packets per VPN at the ingress links, and the VCG may forward the packet based on differentiated services code points carried by the packet. This model allows separate quality of service engineering of the VPNs and the backbone. 11. Scalability Although discussed throughout this document, two levels of scalability need to be addressed: (a) Scaling in the backbone. (b) Scaling at the SPE edge node. Scaling in the backbone depends on many factors, which can be the type of transport technology used, the number of VPN sites configured, the number of tunnels used, the tunnel technology used (whether authentication and encryption mechanisms are used or not). For a network based VPN solution, it is desirable to simplify the deployment and configuration of different VPNs with several sites sharing the same geographical location. Virtual routers allow multiple private CPE networks to connect to a single service provider node. Scaling on the SPE node depends also on many factors related to the type of platform used, the resource capacity of the device (in terms of memory and CPU), the operating system used, etc. One advantage of the ability to contain the VPN address space, and the VPN routing and forwarding capabilities within the virtual router entity is the possibility to distribute node system resources per VPN basis. An example of such distribution is to apply different scheduling mechanisms for processing each VPN activity within the SPE node. This distribution contributes in establishing a wide range of priority schemes among VPNs not just at the packet or routing protocol levels. 12. Backbone Migration During backbone technology migration, the impact to VPNs can range from service degradation to complete loss of connectivity. By using separate routing infrastructure on the backbone, it is possible to migrate each VPN to the new transport technology one at a time. One Ould-Brahim, et al. March 2000 8 Network based IP VPN Architecture September 2000 approach is use a second VCG per SPE node and to migrate each service provider node separately from the SPE. When the new connections between the VRs and the new VCG are established, all VPNs will then be redirected to the new VCG for packet forwarding. As an example for migrating to an MPLS network, a second VCG will be configured and deployed as an LER. LSPs are then configured (or signaled). The LSP tunnels are operational once the VRs are connected to the new VCG. Each VR is connected to the new VCG one at a time. This approach is particularly useful for VPNs requiring high service availability, and VPNs requiring no major reconfiguration when the backbone is migrated. +---------+ | | +----+ +---------+ +-----+ | +----+ | | | | |VR-A |\ | | |----|SPN | +----+ | +-----+ \ | | | /| |-----| | | | \+-----+ |SPN | / +----+ |VCG | +----+ +----+--->| VCG |----| | / ---| | |VR-C| |VR-B| /+-----+ | |/ / +----+ +----+ +----+ | +----+ / | | | / +-----+ | / / | +----+ +----+/ | VCG | +---+/ +---+ | |VR-A| |VR-C| | LER |--|LSR|-------|SPN| | +----+ +----+ +-----+ +---+ +---+ | | | | | +---+ / +---------+ +---------+ \|LSR|/ +---+ / \ +----+ +----+ +----|VCG |----|VCG |--------+ | |LER | --+----+ | | +----+ / | \ | | / | \ | | +----+ +----+ +----+ | +----|VR-A|--|VR-B|--|VR-C|--+ +----+ +----+ +----+ Figure 3: Backbone migration to MPLS 13. Security Considerations 13.1 Data Security Different levels of data security may be implemented within the VPN service provider backbone. Depending on the backbone deployment scenarios, strong security mechanisms may not be necessary (such as Ould-Brahim, et al. March 2000 9 Network based IP VPN Architecture September 2000 IPSec) particularly for backbones under a single service provider administration, or for backbones using direct ATM connections. VPN Service provider can enforce different security levels before entering the backbone tunnels. Indeed, one solution is to apply authentication and firewall processing before the virtual router intercepts the packets. In this situation, encapsulation techniques such as those provided by IP in IP [9] and GRE [5] may be sufficient at the backbone level. 13.2 Routing Security A routing table per VPN provides additional level of security with respect to address manipulation inside the SPE node. Any routing configuration is done within the context of a virtual router. Separate per VPN routing infrastructure provides an extra level of security against address leaking due to the fact that forwarding tables are generated by the routing infrastructure corresponding to one virtual router, and therefore one VPN. 14. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. 3 Fox B., et al, "Virtual Private Networks Identifier", RFC 2685, September 1999. 4 Gleeson, B., et al., "A Framework for IP Based Virtual Private Networks", RFC 2764, February 2000. 5 Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994. 6 Kent S., Atkinson R., "Security Architecture for the Internet Protocol", RFC2401, November 1998. 7 Jamoussi, B., et al, "Constraint-based LSP Setup using LDP", Work in Progress. 8 Muthukrishnan, K., Malis, A., "Core MPLS IP VPN Architecture", Work in Progress. 9 Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. 10 Rosen E., et al, "BGP/MPLS VPNs", RFC 2547, March 1999. Ould-Brahim, et al. March 2000 10 Network based IP VPN Architecture September 2000 11 Sumimoto, J., et al, "MPLS VPN Interworking", Work in Progress. 12 Thayer, R., et al, "IP Security Document Roadmap", RFC 2411, November 1998. 13 Townsley, W., et al, "Layer Two Tunneling Protocol L2TP", RFC 2661, August 1999. 15. Acknowledgments The authors would like to acknowledge the following individuals for their helpful comments and suggestions: Scott Larrigan, Bilel Jamoussi, David Hudson, David Drynan, Ru Wadasinghe, Greg Wright, Peter Ashwood-Smith, Can Aysan, and Martin Pepin. 16. Author's Addresses Hamid Ould-Brahim Nortel Networks P O Box 3511 Station C Ottawa, ON K1Y 4H7 Canada Phone: +1 (613) 765 3418 Email: hbrahim@nortelnetworks.com Bryan Gleeson Nortel Networks 4500 Great America Parkway Santa Clara CA 95054 USA Phone: +1 (408) 548 3711 Email: bgleeson@shastanets.com Ould-Brahim, et al. March 2000 11 Network based IP VPN Architecture September 2000 Full Copyright Statement "Copyright (C) The Internet Society (date). 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 implmentation 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 Ould-Brahim, et al. March 2000 12