Internet Draft An extended IP VPN Architecture November 1998 VPN BOF L. Casey Internet Draft Nortel Networks Expiration Date: May 1999 November 1998 An extended IP VPN Architecture Status of this Memo 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 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." 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), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This Internet Draft extends the framework for IP VPN's, as, for example, described by Heinanen et al.[1] and Gleeson et al [2], to include the concept of VPN Areas. VPN areas relate to the scoping of the mechanisms (membership dissemination, tunneling etc.) used to provide IP VPN service. VPN areas are a partitioning of the shared service provider's network. In general, all sites within a VPN area are one tunneled hop from each other, but multiple tunneled hops will be required for traffic between sites served by different VPN areas. Two reasons why Service Providers might partition their IP network into areas in support of VPN's are to achieve scalability, and to match administrative domain. VPN areas also Casey [Page 1] Internet Draft An extended IP VPN Architecture November 1998 facilitate the use of different IP VPN mechanisms in different parts of the network. There are multiple proposals for tunnel technology and discovery mechanisms for IP VPN's. The VPN area concept allows them to co-exist in one provider's network as well as smoothing migration to new mechanisms. This draft also examines the impact that VPN areas have on the IP VPN framework mechanisms described in [2]. The conclusion reached is that the best mechanism for intra-VPN reachability dissemination is a full routing protocol run by Virtual Routers. Table of Contents 1 Introduction 3 1.1 IP VPNs 3 1.2 IP VPN generic operations 4 1.3 VPN areas 4 1.4 Outline 5 1.5 Terminology and abbreviations 5 2 VPN Areas and VPN Border Routers 6 2.1 Motivation 6 2.2 VPN Border Routers - VBR's 8 2.2.1Types of VBR 9 3 Configuring VPN areas 10 3.1 Setting VPN-area scopes. 10 3.2 The VR mechansism 10 3.2.1Gateway VBR Forwarding Behavior 10 3.2.2Constructing and Maintaining Forwarding Tables 11 3.3 VPN-ID scope 12 4 Operation of multi-VPN area IP VPN's 12 4.1 VPN membership configuration and dissemination 12 4.1.1Automating gateway VBR configuration 13 4.2 Tunnel establishment 13 4.3 Stub Link Reachability information 14 4.4 Intra VPN reachability information 14 4.5 Summary of new IP VPN Configuration 15 5 Summary and Benefits of extended IP VPN's 15 5.1 Summary 15 5.2 Provider value to the enterprise 16 5.3 Provider network protection 17 5.4 VPN Isolation 17 5.5 Engineerable 17 5.6 Scaling Factors 17 6. Security Considerations 18 6.1 User Data Privacy 18 6.2 Service Provider Security 19 7. Intellectual Property Considerations 19 8. References 20 9. Author's Address 20 Casey [Page 2] Internet Draft An extended IP VPN Architecture November 1998 1.Introduction 1.1 IP VPNs An IP Virtual Private Network (IP VPN) is a service, offered by a (service) provider to an enterprise customer. An IP VPN interconnects geographically dispersed enterprise IP networks over the provider's shared network facilities. The general goal of a VPN is to offer equivalent privacy and performance to leased line interconnectivity while realizing substantial deployment efficiencies because the network infrastructure is shared by many enterprises. In this draft we use the term "provider" to cover the public carrier, network operator or ISP, or consortiums thereof, who operate the shared network infrastructure and offer the IP VPN service. We call the shared network structure the base network of the VPN. In [1] and [2], Heinanen and Gleeson et al. provide a definition of a service, which they call an Virtual Private Routed Network (VPRN) service. A quick summary of the properties of VPRN service are: 1) data privacy 2) address isolation 3) intra VPN routing 4) implemented on IP based base networks The first two of these properties are general to all VPN's. It is the third of these properties, intra VPN routing, that makes a VPN specifically an IP VPN. An IP VPN service includes the routing of enterprise IP traffic by the provider, steering it over the wide area based upon its IP destination address. Benefits of using an IP VPN service include simplified configuration of enterprise edge routers [2], and exploiting the ubiquity of IP service for access to enterprise sites. This draft does not assume the fourth property of VPRN's listed above. While base networks based upon IP have unrivalled geographical extent, one intent of introducing the VPN area concept is to allow an IP VPN service to be supported over a concatenated mixture of diverse base networks. In [2] two other types of VPN that use an IP based network infrastructure are also described. Virtual Private Dial Networks (VPDN's) offer, in effect, a PPP transport service. In a Virtual Private LAN Segment (VPLS) service, the provider offers a wide area Casey [Page 3] Internet Draft An extended IP VPN Architecture November 1998 emulation of a LAN segment, which may support multiple enterprise network protocols. While this draft does not consider the implementation of either of these services, it does consider how a provider might augment an IP VPN service with VPDN or VPLS service (see sec 2.2.1). 1.2 IP VPN generic operations There are a number of generic operations that need to be performed in order to provide IP VPN service. 1) VPN membership discovery is the process by which provider nodes learn of the other nodes serving the same VPN. 2) Tunnel establishment is the process of providing private paths across the base network for each enterprise customer's data. 3) Offering an IP Service means that the provider's network must interact with the enterprise customer's routing regime. The stub link reachability information exchange is the operation where nodes in the enterprise network exchange reachability information with nodes in the provider's network. 4) The provider nodes serving a particular VPN need to propagate the individual site reachability information to each other, so that they can route the enterprise packets across the providers network. This is the Intra VPN reachability exchange. [1] and [2] list a plethora of choices of mechanism to implement the IP VPN operations. This Internet Draft assumes that reader is familiar with [1] and/or [2]. Consideration of base networks other than IP expands the set of choices even further. For a particular IP VPN to be deployed each of these choices have to be nailed down. This is a problem as IP VPN technology is immature today. The market is likely to see different choices deployed in different networks. A major motivation for introducing the concept of VPN areas is to define how an IP VPN can be constructed to operate over a mixture of base network choices, tunneling mechanism choices and VPN generic operation mechanism choices. 1.3 VPN areas VPN Areas are a partitioning of Provider's network infrastructure. Within a VPN Area the various VPN mechanisms (base network, tunneling, VPN membership discovery etc.) are the same. Between VPN areas the VPN mechanisms can be different. One Casey [Page 4] Internet Draft An extended IP VPN Architecture November 1998 goal of VPN areas is to allow an IP VPN Service Provider to partition his base network based upon IP VPN implementation choices. For example, an Service Provider may have MPLS in the backbone part of his network but not in all regional networks. He can operate a MPLS based IP VPN area in the backbone, as described in this draft, while using other forms of IP VPN technology (e.g. IP over LANE VLAN's) in the regional VPN areas. The VPN area concept facilitates migration of VPN technologies. It can also be used to reflect VPN service scoping rules into the network, even when the same VPN mechanisms are deployed in all areas. Service scoping can be based upon administrative boundaries or can be introduced to address scaling problems. 1.4 Outline The purpose of this Internet draft is to introduce and motivate the concept of VPN areas and to show how the VPN generic operations can be extended to multi VPN area networks. Section 2 of this Internet Draft starts with the motivations for deploying VPN areas. The concept of a VPN edge device is generalized to VPN Border Router (VBR). Not only are VBR's interposed between enterprise sites and the providers network but they can also be situated between, and straddle, VPN areas. Section 3 looks at how VPN areas might be configured and at the scoping of VPN-ID's. As well, it introduces the Virtual Router (VR) mechanism as the most straightforward way of managing the forwarding of traffic between VPN areas. Building on this, section 4 examines at how the operations of an IP VPN are modified when there are multiple VPN areas. In particular, the VPN membership discovery operation and the intra VPN reachability exchange mechanism are impacted. For multi-VPN deployments, this Internet Draft advocates the use of full routing protocols for the exchange of intra VPN reachability information. Section 5 summarizes the properties of multi-VPN area IP VPN's and Section 6 addresses security considerations. 1.5 Terminology and abbreviations In addition to the terminology of [1] and [2] the following terms are introduced Base network The provider's network upon which an IP VPN service is built Peer VR's VR's that serve the same IP VPN within the same VPN area. Casey [Page 5] Internet Draft An extended IP VPN Architecture November 1998 Stub link Dedicated IP link between a VBR and an enterprise site VBR VPN Border Router VR Virtual Router. An instantiation in a VBR of a routing process dedicated to, and working within the address space of, an IP VPN VPN Area A partition of the base network. Within a VPN Area the various VPN mechanisms (tunneling, VPN membership discovery etc.) are the same. 2 VPN Areas and VPN Border Routers 2.1 Motivation Just as the original Internet routing protocols were modified to partition networks into areas (OSPF) and Autonomous Systems (BGP), to cater for scalability and administrative boundaries respectively, similar concerns motivate the partitioning of networks that provide IP VPN service. Figure 1 shows a partition of a network into 5 VPN areas. (Note that, for the time being at least, we call all partitions "areas" irrespective of the motivation that lead to their construction). +---------------------------+----------------------------+ / | \ / | \ + | VPN Area 2 + | | | | VPN Area 1 | | | | | | ------+------ | | / \ | | / \ | | / \ | +--------------------+ VPN Area 0 +---------------------+ | \ / | | \ / | | \ / | | ------+------ | | VPN Area 4 | | | | VPN Area 3 | + | + \ | / \ | / +---------------------------+----------------------------+ Figure 1: VPN Area Casey [Page 6] Internet Draft An extended IP VPN Architecture November 1998 One motivation for VPN Areas is to cater for administrative boundaries. While a group of network operators may band together to offer an IP VPN service, each may wish to retain control of what enterprises they serve. Analogous to BGP, they may instigate transit and peering agreements so as to offer a seamless IP VPN service within their combined geographical area of coverage. However, some enterprises may only want IP VPN service in a single VPN area in return, presumably, the operator of that area would provide the service for a lower tariff than a wider scoped service. In addition to being a service scoping mechanism, VPN areas are also a technology scoping mechanism. The VPN area mechanism will allow each of the network operators may operate different base networks, tunnel mechanisms, etc. within their own VPN areas and still provide a homogeneous combined IP VPN Service. Geographic service scoping may also be the motivation for a single provider to introduce VPN areas. For example, a transnational service provider may establish a VPN area in each country served to support charging enterprises more for international traffic than traffic that stays inside the country. QoS Scoping is another motivation for VPN areas. A service provider may wish to offer IP VPN service level agreements relating to delay, packet loss etc., where the parameters are different for different VPN Areas. A particularly important instance of this is where the provider treats his own network as one VPN area and the rest of the Internet as another area. For IP VPN traffic confined to his own network, the provider may be able to offer fairly tight service guarantees, by dint of the technologies employed, network topology and traffic engineering. An enterprise may have some remote sites that it would be impractical to connect directly to the provider's network. The provider can still make these sites part of an IP VPN, by setting up tunnels (probably IPSec) to them over the Internet. There cannot, of course, be any performance guarantees for the traffic traversing the Internet. VPN areas also provide a framework for addressing traffic engineering and scalability concerns. This is elaborated upon in section 5. Finally, a major motivation for VPN areas is that they scope IP VPN implementations. As noted above, to implement an IP VPN service choices have to be made on base network technology, tunnel mechanism, VPN membership dissemination mechanism and Casey [Page 7] Internet Draft An extended IP VPN Architecture November 1998 intra VPN reachability information exchange mechanism. At this stage in IP VPN maturity, there are multiple proposals for each mechanism even for the same base network. E.g. [3],[4],[5],[6] and [7]are differing proposals for MPLS as a base network. 2.2 VPN Border Routers - VBR's A VPN Border Router or VBR is a node at the border of a VPN area. Each VPN area contains both VBR and plain (non-edge) nodes, interconnected by links. All proposals for IP VPN's distinguish the first IP device in the path between the enterprise's network and the provider's shared network. Unfortunately, there is no common term for it. In this draft we use the term edge VBR. In multi-VPN area networks, VBR's also are the gateway devices between VPN areas. VBR's serve as tunnel ingress and egress points for enterprise IP traffic. Figure 2 shows a path between two enterprise sites that traverses two VPN areas. Each VPN area is bordered by VPN's and contains other nodes that operate as part of the base network but are unaware of the IP VPN service because enterprise traffic is tunneled through them. (Note that we use tunnel in a very loose sense here to mean any mechanism that encapsulates enterprise IP packets and carries a demuliplexing identifier with them. VBR's use the demuliplexing identifier to separate out IP packets of the different VPN's. In our loose use of the term, a layer 2 virtual circuit is a tunnel). +----+ +---+ +---+ +---+ +---+ +---+ +---+ +----+ |EntR|----|VBR|---|BNN|--|BNN|---|VBR|---|BNN|---|VBR|----|EntR| +----+ +---+ +---+ +---+ +---+ +---+ +---+ +----+ <-----Tunnel------> <---Tunnel--> <--------VPN Area-------> <---VPN Area----> EntR = Enterprise Router VBR = VPN Border Router Stb = Stub Link BNN = Base Network Node Figure 2: IP VPN Path over 2 VPN Areas Enterprise sites interface to the provider's network over a stub link from an enterprise router (EntR). (Very small sites may not have an enterprise router but, rather, consist of a single LAN subnet, i.e. an Ethernet, with a VBR serving as a default router). Some larger Enterprise sites may be "not so stubby". They may have multiple links, from the same or different enterprise routers, to the same VBR or to different VBR's. [2] contains a discussion on the implications of this. An additional case Casey [Page 8] Internet Draft An extended IP VPN Architecture November 1998 arising from the introduction of VPN areas is when an enterprise site has stub links to VBR's in different VPN areas 2.2.1 Types of VBR One categorization of VBR's is whether they serve a single VPN or multiple VPN's. Exclusive VBR's may be located at the enterprise site or at a POP. Shared VBR's would always be located at a provider POP. Note that a VPN area can contain both shared and exclusive VBR's: it is entirely a provider's choice as to whether he deploys all POP based shared VBR's, customer located exclusive VBR's or a mixture of both. A VBR can fulfill edge, gateway or special functions. Edge VBR: First IP device between enterprise site and the provider's network. It serves one or more sites of one or more enterprises. Gateway VBR: A VBR that are attached to two or more VPN areas. It straddles the VPN areas and is able to forward enterprise traffic between VPN areas. (In general a gateway VBR's will de-encapsulate traffic from the incoming tunnel and re-encapsulate in a tunnel appropriate for the outgoing VPN area. If the two VPN areas share the same VPN mechanisms the de- encapsulation may not be necessary) Special functions include: Internet Attachment: Enterprise access to the Internet may be offered as an extension of IP VPN service and be implemented by a special VBR that has firewall (and, if needed, NAT) functions. VPDN Attachment: Enterprise dial-in users may be connected directly to the IP VPN, instead of terminating on a home gateway at a particular enterprise site. To implement this service, special function VBR's may provide a per enterprise RAS function, or a per enterprise home gateway function. VPLS Interworking: As noted in [2], there are many similarities between Virtual Private LAN Subnet (VPLS) service and IP VPN service. A provider may offer both; in particular some enterprise sites may connect to a VBR over virtual private LAN subnet (or even a real LAN subnet). Minor changes in edge VBR functionality are required to handle this kind of interworking. A VBR need not be dedicated to only one of these functions. We say that a VBR serves a particular VPN if it terminates one or Casey [Page 9] Internet Draft An extended IP VPN Architecture November 1998 more stub links to enterprise sites of that VPN. A gateway VBR that straddles two or more VPN areas serves a particular VPN if it forwards traffic for that VPN between the areas. It is a generally desirable goal that other (internal) nodes in the provider's network are not aware of individual VPN's. 3 Configuring VPN areas This section addresses general configuration issues for IP VPNs that span multiple VPN areas. It considers the necessary uniqueness requirements for VPN-ID's and introduces Virtual Routers as the mechanism for forwarding traffic between VPN areas. 3.1 Setting VPN-area scopes. A Provider or consortium wishing to offer IP VPN service using multiple VPN areas has first to decide on the basis for partitioning their network and then configure VBR's to realize the desired VPN areas. If the basis for VPN areas relates to base network technology then the partitioning process will be straightforward: gateway VBR's will be deployed with separate interfaces to two or more base networks. If the deployment of multiple VPN areas is being driven by scalability or administrative domain concerns, and if the base network is common to all the VPN areas, then particular care will be needed in configuring the interfaces of gateway VBR's. An interface's type or network address will not be enough to determine which VPN area it participates in. Introducing a VPN- area Identifier to facilitate configuring gateway VBR's is an area for further study. 3.2 The VR mechansism Isolation of the IP addresses within a VPN is equivalent to each VPN having its own independent IP Address space. Thus, we talk about the address space of enterprise E1 being independent from address space E2 (enterprise E2's address space). When the base network is an IP network, one needs to be particularly clear when talking about an IP address as to what address space it is part of: that of the base network or that of an enterprise IP network. 3.2.1 Gateway VBR Forwarding Behavior Gateway VBR's are going to serve large numbers of VPN. Within each VBR there needs to be an instance of a forwarding table for each IP VPN supported by that VBR. The forwarding control process operates in the enterprise address space. When packets arrives at a gateway VBR the VBR will select the correct Casey [Page 10] Internet Draft An extended IP VPN Architecture November 1998 forwarding table based upon the identity of the incoming tunnel. The forwarding table will determine on what tunnel packets should be sent out (suitably encapsulated for the tunnel selected). 3.2.2 Constructing and Maintaining Forwarding Tables There has been basically two approaches advocated for dynamically constructing and maintaining forwarding tables in IP VPN's. [4] advocates that the Intra VPN reachability information be piggy backed on routing exchanges taking place in the base network, while [3] and [6] advocate the use of virtual routers. A virtual router (VR) is simply a forwarding control process in a VBR, dedicated to one IP VPN. It participates directly in routing information exchanges with other VR's dedicated to the same VPN, over tunnels of that VPN. The routing exchanges relate only to the IP address space of the enterprise customer. The routing regime used can be specific to individual VPN's (e.g. small one might use RIP, while larger ones use OSPF). Notes on VR's: 1) Static/default routing (i.e. administratively configured forwarding tables) is considered an acceptable routing regime, particularly appropriate for small VPN's. 2) The VR definition implies every link interface (stub or tunnel end point) or the VR itself has an IP address in the enterprise address space. 3) A VR may use different routing protocols on each of its interfaces. It could end up exchanging routing information with all of a customer's enterprise routers (e.g. if the entire enterprise intranet was one OSPF area). Alternatively the routing regime on stub links could be isolated to just the edge VBR and the attached Enterprise edge router, see [2]. 4) When the tunnel topology within a VPN area is a full mesh a VR sees the VR's of all other VBR's in its VPN area as neighbors. From the perspective of the IP VPN routing, all its VR's in a VPN area are a single hop from each other. VR's in different VPN areas are two or more hops away. Because we want to support an arbitrary topology and interconnect of VPN-areas, our preference is to use virtual routers as the mechanism for constructing and maintaining forwarding tables in VBR's. However the power of the VPN area concept is such that, within one IP VPN service, it would permit one VPN area to piggyback intra VPN reachability information on base network routing exchanges and another area to use virtual Casey [Page 11] Internet Draft An extended IP VPN Architecture November 1998 routers. It should be noted though, that piggybacking may require modifying routing protocols and that there are scoping issues to address (see [2] again), while VR's run their routing protocols unmodified and secure. 3.3 VPN-ID scope There are two different reasons why an IP VPN needs to be identified. The first of these relates to the administrative identification an IP VPN service instantiation provided for an enterprise. Generally speaking, it is desirable that this identification be globally unique – we call it the global VPN- ID. A global VPN ID will be 32 bits or more in size, see [2]. (Strictly speaking, this form of VPN-ID needs only to be unique within the provider or group of carriers offering IP VPN service but given the propensity of providers to merge it is wise to make it globally unique. The other use of a VPN-ID is in the VPN membership dissemination operation. Typically, this form of VPN-ID, which we call the local VPN-ID, has only to be unique within a VPN area. There have been several proposals, [3][6], that this be a 16 bit quantity. To facilitate re-engineering of VPN areas we propose that all 16 bit VPN-ID's be unique within an AS. (Prepending the AS number to a local VPN-ID of the first provider of a particular IP VPN service instance is one way to generate a 32 bit global VPN-ID). 4 Operation of multi-VPN area IP VPN's Section 1.2 outlined a number of generic operations that need to be performed before an IP VPN can forward IP traffic between enterprise sites. This section examines how these operations are affected by the introduction of VPN areas. 4.1 VPN membership configuration and dissemination A provider whose base network spans multiple VPN areas will need to scope the IP VPN service offered a particular enterprise: will it be confined to a single area or span multiple VPN areas? Spanning multiple VPN areas is enabled by configuring VR's for the new IP VPN in gateway VBR's. These VR's will be informed of the routing regime they are to participate in and they will need a router number and/or IP address assignment from the enterprise IP space. If, as should be done, there is to be chain of trust between the VR's dedicated to the VPN then appropriate credentials have also to be administered. Finally, the VR will be configured with a local VPN-ID for use in each VPN area in which it is configured to operate. Casey [Page 12] Internet Draft An extended IP VPN Architecture November 1998 Once this configuration has been done, the gateway VBR is able to participate in the VPN membership dissemination process with the other VBR's in each of the VPN areas to which it is attached. The VPN membership dissemination mechanism may be different in each VPN area. Nevertheless, the end result is that each VR dedicated to a particular VPN (i.e. assigned the same VPN-ID) has enough information to establish tunnels to its peer VR's in each of the VPN areas to which it is attached. 4.1.1 Automating gateway VBR configuration At this stage in developing the VPN area concept, it is assumed that the provider will use the required configuration of gateway VBR's both as a policy mechanism (to scope a service) and as a traffic engineering mechanism (splitting the load of multiple VPN's over multiple gateway VBR's). The general automation of the process is for further study. One special case stands out though: a simple topology of a two level hierarchy of a core and stub VPN areas. Each gateway VBR between stub and core could cache the VPN membership announcements that it receives on its stub side and relay them over the core. If there were a matching VPN-ID from another gateway VBR then both would initiate a VR, and establish a tunnel between them. The new VRs would also announce their presence on the stub network to complete the VPN tunnel connectivity. 4.2 Tunnel establishment In this proposal, tunnels are only established between VR's within a VPN area. A different tunneling mechanism choice may be in effect in each VPN area, depending on the base network. See [1] to [7] for some of the VPN membership dissemination mechanisms and tunnel establishment mechanisms that could be used. As an example, in one VPN area tunnels may be realized by GRE over an IP base network, and in another tunnels may be realized by ATM SVC's over an ATM base network. In general, traffic travelling between VPN areas is forwarded at the IP layer by VR's in gateway VBR's. However, for individual base network/tunnel mechanisms, it may be possible to establish tunnels right through VBR's. [6] provides an example of how this could be done using the MPLS label distribution protocol for MPLS tunnels and VPN areas corresponding to MPLS domains. In the preceding, we have also assumed that within a VPN area all VR's (for a particular VPN) are fully meshed connected by tunnels. All enterprise traffic travels across VPN area in a single tunnel hop. One of the advantages of VR's is that this assumption can be relaxed, since the VR's are capable of Casey [Page 13] Internet Draft An extended IP VPN Architecture November 1998 exchanging routing information and calculating next (tunnel) hops. Of course, establishing an arbitrary tunnel topology within a VPN area would require administrative intervention. 4.3 Stub Link Reachability information The existence of multiple VPN areas should not be directly visible to the enterprise edge routers, nor should it affect mechanism for exchanging reachability information between a (VR in an) edge VBR and the enterprise site. As noted in [2] it is beneficial for the protocol used to exchange of reachability information across a stub link to be simple, and for it to be alterable on an enterprise site by enterprise site basis. However, VPN areas enable more complex stub link connectivities, such as multiple links from an enterprise site to different VPN areas. For "not so stubby" site connectivity, VBR's will have to push routing hop information to the enterprise routers if loops and sub optimal forwarding are to be avoided. The most general mechanism for a VBR to learn the set of address prefixes that reachable over its stub links, and for the enterprise site to learn what addresses it should forward over which stub link, is a full routing protocol. Our position is that, with the common exception of sites connected by a single stub link and not having routing backdoors (see [2]), enterprise edge routers and the VPN VR's should participate in the same routing regime. 4.4 Intra VPN reachability information VR's dedicated to each IP VPN exchange routing information exchanges with each other across the entire scope of the IP VPN, i.e. across multiple VPN areas. The routing exchanges relate only to the IP address space of the enterprise customer. The routing information will typically be exchanged over the same tunnels between VR's used to carry enterprise traffic. The routing regime used can be specific to individual VPN's (e.g. small one might use RIP, while larger ones might use use OSPF). Each VPN area may have a different mechanism for the dissemination of VPN membership. In general, the existence of new sites for a VPN is propagated only to the VBR's within an VPN area. However, other VBR's will learn the reachability information for the new site through the routing protocol exchanges of the IP VPN. Information concerning a new enterprise site will reach gateway VBR's using the mechanisms of the VPN area to which the site is newly attached. A VR in the gateway VBR will then convey the new routing information across the VPN area boundary, to all of its neighbors in other VPN areas connected to it. Casey [Page 14] Internet Draft An extended IP VPN Architecture November 1998 4.5 Summary of new IP VPN Configuration This section reviews the processes that bring an new IP VPN into service over a multi-VPN area network. When a enterprise wants to obtain an IP VPN service from a provider the provider must first do some configuration. The provider needs to allocate a VPN-ID and then provision the stub links between enterprise sites and one or more VBR's. The provider must instantiate a VR at each VBR that has new IP VPN stub links terminating on it. This involves assigning the VR an IP address, or router number, out of the enterprises address space, and assigning IP addresses for each stub link terminating on the VR. In a fully flexible system the VR could be configured to run separate routing regimes on each stub link, and another one for the tunnels to peer VR's. The VR would all need to be instructed on how I should import information between routing regimes. The choice of routing regime to be used for stub links will probably have been spelt out in an SLA. For example, an enterprise with one large corporate site and a modest number of smaller satellite sites, each with its own /24 subnet, might use static/default routing for all satellite site stub link interfaces. RIP could be used between all VR's and between the large corporate site and the VR(s) to which it is connected. Assuming the IP VPN service scope is multiple VPN areas, the provider must choose which gateway VBR's will be used and then instantiate VR's on them. One this configuration has been performed and the VR's serving the new IP VPN are in place, automatic tunnel establishment can proceed in each VPN area. This results in tunnel meshes within VPN areas and the provider chosen connectivity between areas. Assuming that the chosen intra VPN routing protocol links permits auto-discovery of routers, then each of VR's can establish a neighbor relationship with its peers and then exchange enterprise routing information. After this, the VR's are able to forward enterprise traffic between all sites in the VPN. 5 Summary and Benefits of extended IP VPN's 5.1 Summary This Internet Draft presents an extended IP VPN architecture. The concept of VPN areas is introduced as a partitioning of the service provider's base network. The definition of a provider edge device is extended to that of a VPN Border Router (VBR). As well as interposing between an enterprise site and the core of Casey [Page 15] Internet Draft An extended IP VPN Architecture November 1998 the provider's network, a VBR may straddle two or more VPN areas. In the former usage a VBR is called an edge VBR while in the latter usage it is a gateway VBR. Specialized VBR's may also interface to modem pools for provider network support for dial- in user access to the enterprise networks and firewalls for network access to the Internet. Two of the reasons why Service Providers might partition their IP network into area's in support of VPN's are to achieve scalability and to match administrative areas. VPN areas also facilitate the use of different IP VPN technologies in different parts of the network. There are multiple proposals for tunnel technology and discovery mechanisms for IP VPN's. The VPN area concept allows them to co-exist in one provider's network and smoothes migration to new mechanisms. VBR's that serve multiple VPN's have been described as supporting multiple virtual routers (VR's). Each VR participates in the routing regime of a single IP VPN, and is responsible for forwarding packets for that VPN within the VBR. The solution provides the following benefits: 5.2 Provider value to the enterprise The provider provides IP service within its own network. Specifically enterprise packets are routed at VBR's within the carrier network. This reduces the capabilities needed of enterprise edge routers. CPE based tunneled implementations of VPN's confine packets to travel on tunnels between enterprise routers. This requires the enterprise router to support multiple tunnel interfaces. In very large VPN's the number of tunnel interfaces may tax the capacity of the enterprise router. Often though, even for small VPN's, the topology of tunnels is compromised, from a mesh to a hub and spoke system. Sub optimal routing is the usual result, with undesirable "hairpinning" of packets over costly "last mile" links at the hub. The use of specialized VBR's, as described in section 2.2.1, permits the enterprise to outsource to the provider more of the IP network services it needs, saving both capital and operational costs. There are also potential traffic savings on the "last mile" links to the sites that would otherwise host home gateways and Internet firewalls. Traffic to or from the external networks will travel straight from or to the destination site, rather than be hairpinned through a hosting site. Casey [Page 16] Internet Draft An extended IP VPN Architecture November 1998 5.3 Provider network protection VR's protect the provider's base network from the customer enterprise networks, particularly if the base network is an IP network. Enterprise routers do not communicate any routing information with the provider's internal routers. Thus, the carrier's networks can be protected from many kinds of damage, deliberate or accidental, that can occur in shared IP networks. (Of course, if the carrier runs a public IP service over the same network that is supporting the VPN's, then there is no protection from the public IP network users). Other VPN realizations require the difficult to manage BSP-4 routers be deployed between customer and carrier to provide (imperfect) isolation. 5.4 VPN Isolation With tunnel connected VR's as the forwarding mechanism, an enterprise has complete freedom in choice of IP addressing schemes and can choose VPN routing protocols independent of other enterprises. Non tunnel based implementations of VPN's over IP networks require customers to use unique, registered, IP addresses. However, such addresses are in short supply and increasingly difficult to come by, so many customers want to use private IP addresses in their enterprise networks. Further, enterprise Topology changes (route flapping) in one VPN network is transparent to other enterprises' VPN's. VR's provide separation of fate. 5.5 Engineerable VPN areas and gateway VBR's provide a basis for traffic engineering to be applied to IP VPN's. The load of different VPNs can be allocated to different VBR's. This can be looked upon as a form of loose explicit routing. However it is superior to IP's loose source routing in several respects: 1) If the routing regime being used for intra VPN routing supports "equal cost path routing" then there can be load sharing within a VPN through multiple gateways VBR's. 2) Multiple gateway VBRs provide automatic resilience. 3) While packets are in tunnels (i.e. they are encapsulated), they don't have to carry the expensive to process source route headers. 5.6 Scaling Factors Few types of base network can support an unlimited number of tunnels. For example, if the tunnel mechanism is Virtual Casey [Page 17] Internet Draft An extended IP VPN Architecture November 1998 Circuits on a base Frame Relay network the total number of tunnels will depend of the number of DLCI's that can be supported on shared Frame Relay links. Judicious use of VPN areas can reduce the number of tunnels needed, permitting the support of more VPN's, serving more sites. Scalability concerns also arise in the exchange of reachability information for VPN's. Simple reachability exchange mechanisms do not scale to cover large VPN's with potentially more than a single stub link per enterprise site. VR's address this by using full routing protocols for reachability information exchange. Also having a positive impact on scaling is the fact that VPN areas significantly reduce the number of peers with which VR's exchange intra VPN reachability information. This allows VBR's to support more VPN's with less routing packet exchange overhead. On the negative side gateway VBR's may become bottlenecks. However, this problem can be engineered away, since different VPN's can be assigned to different gateway VBR's. The resulting spreading of the load through multiple gateway VBR's will actually be an improvement over many single area realizations. Connectivity between geographic regions tends to be more sparse that connectivity within a region. Without traffic engineering, the base network routing regime of a single area VPN that spanned regions, might send all traffic between two regions through one router and/or over one link. 6.Security Considerations One of the major functions of a VPN is to provide both data privacy and addressing privacy for multiple customers over a shared network infrastructure. At the same time, the provider of the shared network infrastructure needs assurance that it can not be compromised by a customer, to the detriment of the provider or other customers. 6.1 User Data Privacy A Service Provider may choose to deploy VBR's, each with a single VR, at a customer's enterprise premise, or they may deploy VBR's with multiple VR's at a Service Provider location. In both cases, the only traffic that will enter a customers premise is that of the customer's VPN. This is ensured by the isolation of VR's within a VBR (i.e. no traffic passes between them) and the use of tunnels dedicated to single VPN's. Casey [Page 18] Internet Draft An extended IP VPN Architecture November 1998 There is a threat from an intruder setting up a fake VBR and persuading genuine VR's to send it traffic. This is little different from threats today from hackers setting up routers that advertise false routes. Solutions involve having network nodes only exchange information with other network nodes that are part of a chain of trust. VBR to VBR or VR to VR authentication must be part of a full solution. As provided here, there is no necessary confidentiality of enterprise data from the Service Provider. I.e. enterprise data is kept separate from other enterprises and is not readily available to hackers, but the provider the Service Provider has full access to the content of packets. An Enterprise that wants to assure total confidentiality of its data must encrypt it. End to end encryption will ensure total confidentiality over the entire enterprise intranet. If the enterprise is not are worried about internal threats, but perceives the service provider as a threat then encryption should be performed on all traffic crossing the WAN interface (i.e. before it reaches the providers VBR). 6.2 Service Provider Security Keeping user traffic in tunnels is the best way to ensure the service provider's network is not compromised. While the VR's participating in a particular IP VPN share IP address space with the customer, the customer has no visibility of the IP addresses used in the Service Providers base network. The service provider's network is transparent to users. Even if a hacker within an Enterprise knows some router address inside a service provider's network, it can't be reached. Packets will either be forwarded to an enterprise node that happens to have the same address, or dropped, because the VR's don't have forwarding entries for it. The VR mechanism can actually provide extra security for service providers whose base network is part of the Internet. They can configure an IP VPN at all of their nodes that isolates all of their legitimate management traffic from general user traffic. VPN areas can also be used to enhance security. They provide a mechanism to partition responsibilities in the provision of IP VPN service, as well as internal boundaries where policies can be enforced and auditing performed. 7.Intellectual Property Considerations Nortel Networks may seek patent or other intellectual property protection for some or all of the technologies disclosed in this Casey [Page 19] Internet Draft An extended IP VPN Architecture November 1998 document. If any standards arising from this document are, or become, protected by one or more patents assigned to Nortel Networks, Nortel Networks intends to disclose those patents and license them on reasonable and non-discriminatory terms. 8.References [1] Heinanen, et. al, "MPLS Mappings of Generic VPN Mechanisms", , August 1998. [2] Gleeson et al. "A Framework for IP Based Virtual Private Networks", [3] Muthukrishnan and Malis, "Core IP VPN Architecture", , Oct 1998. [4] Heinanen et al., "VPN support with MPLS", , March 1998. [5] Jameiseson et al., "MPLS VPN Architecture", , Aug 1998. [6] Casey et al., "IP VPN Realization using MPLS Tunnels", , Oct 1998. [7] Li, "CPE based VPN's using MPLS", , Oct 1998. 9.Author's Address Liam Casey Nortel Networks. PO Box 3511 Station C Ottawa ON K1Y 4H7 Canada EMail: liam@nortelnetworks.com Casey [Page 20]