Internet Draft MPLS Working Group Juha Heinanen Internet Engineering Task Force Telia Finland, Inc. INTERNET DRAFT Bryan Gleeson, Arthur Lin Expires February 1998 Shasta Networks, Inc. MPLS Mappings of Generic VPN Mechanisms <draft-heinanen-generic-vpn-mpls-00.txt> 1. 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 view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 2. Abstract This document describes a set of generic mechanisms which can be used to set up network based Virtual Private Networks (VPN) across IP networks. In particular, it describes how these mechanisms can be mapped into a network running the Multi-Protocol Label Switching (MPLS) specification. The mechanisms described, however, can apply to any type of IP network running various forms of IP tunneling mechanisms, and are not solely restricted to MPLS networks. This Draft serves to introduce these generic mechanisms, which are part of the broader VPN framework which will be described more fully in forthcoming Drafts. 3. Introduction An earlier Draft [Heinanen] proposed a number of mechanisms for Virtual Private Network (VPN) support in networks running the Multi- Protocol Label Switching (MPLS) specification [Callon]. Heinanen, et al. [Page 1] INTERNET DRAFT MPLS Mappings of Generic VPN Mechanisms August, 1998 Subsequently, it was noted that most of the mechanisms proposed in that Draft are subsets of generic VPN mechanisms, and can also apply to current IP networks. Hence this Draft first discusses these generic mechanisms and shows how these may be applied in general IP networks. In particular, these can be applied in IP networks not running any major new protocol, such as MPLS, which may facilitate roll- out of VPN services on current IP networks, prior to the possible future deployment of MPLS. Subsequently, the Draft also discusses how these mechanisms can be applied to MPLS networks in particular. As with the earlier Draft, this Draft is intended to serve as a framework, highlighting areas for more detailed specification. Neither has enough detail to allow for interoperable implementations. Hence more work is required to finalize a specification for VPN support, both on MPLS networks and on current networks. A future Internet Draft will propose a more general VPN framework and specific areas for future specification so as to allow more general interoperable VPN solutions. 4. VPN Definition and Scope A VPN can be succinctly defined as the emulation of a private wide area network (WAN) facility using IP facilities (including the public Internet, or private IP backbones). There are a wide variety of VPN types, corresponding to the very wide variety of WAN facilities that are currently defined. Future Drafts will discuss the full range of possible VPN types, but the particular type of VPN specifically discussed in this Draft can be described as a 'virtual private routed network' (VPRN), in which a customer with multiple geographically dispersed sites wishes to connect each of these sites together into a private network. Such networks are routinely built today using, for instance, frame relay links and/or leased lines between the routers at each pair of sites, or, more likely, given the cost of such links, by star wiring each site to a single central site. A VPRN emulates such a network using dedicated IP links. The nature of the connectivity of these sites is discussed further below, but for the moment it can be assumed that it is desired that each of these sites be logically meshed to each other site, since there is less cost assumed with full meshing in a virtual IP network, than in cases where physical resources (e.g. Frame Relay DLCI, or a leased line) must be allocated for each connected pair of sites. This yields optimal routing, since it precludes the need for traffic between two sites to traverse through a third. VPNs of various sorts are today routinely implemented using a Heinanen, et al. [Page 2] INTERNET DRAFT MPLS Mappings of Generic VPN Mechanisms August, 1998 combination of host applications and customer premises equipment (CPE) routers. The mechanisms discussed in both this Draft and its predecessor, however, apply specifically only to the class of 'network based VPNs', where the operation of the VPN is outsourced to an Internet service provider (ISP), and is implemented on network as opposed to CPE equipment. There is significant interest in such solutions both by customers seeking to reduce support costs and by ISPs seeking new revenue sources. The network based focus allows the use of particular mechanisms which may lead to highly efficient and cost effective VPRN solutions. However such mechanisms also leverage tools (e.g. piggybacking on routing protocols) which are accessible only to ISPs and which are unlikely to be made available to any customer, or even hosted on ISP owned and operated CPE, due to the problems of coordinating joint management of the CPE gear by both the ISP and the customer. Hence, it is assumed that each customer site CPE router connects to an ISP edge router through one or more dedicated point-to-point stub links (e.g. leased lines, ATM or Frame Relay connections); the VPRN mechanisms discussed below will operate on each of these ISP edge routers, in order to route traffic received across a stub link to the appropriate destination customer site across its stub link. In particular, the edge router will hide all VPRN topology information from the CPE routers, hence significantly simplifying the operation of the CPE. Note that a single ISP edge router could terminate multiple stub links belonging to the same VPRN. The means by which traffic is routed between such local interfaces is outside the scope of standardization, per se, though obviously these would leverage many of the same routing and forwarding mechanisms used for communication with remote VPN sites. In such a scenario, a VPN connecting each of these sites must generally meet a number of minimum requirements, which arise from the need to essentially emulate the facilities that customers expect from a leased line facility, and which, hence, they also generally expect from any emulation of such a facility. While there are a number of such requirements, three are of particular concern to this Draft: A. Support for Disjoint Address Spaces: The addressing used within the VPRN may have no relation to the addressing of the ISP, or ISPs, across which the VPRN may operate. In particular, the former may also be non-unique, private IP addressing [Rekhter1]. B. Support for Intra-VPN routing: Heinanen, et al. [Page 3] INTERNET DRAFT MPLS Mappings of Generic VPN Mechanisms August, 1998 Since a VPRN will generally interconnect multiple sites, the VPRN mechanism must implement some mechanism by which intra-VPN traffic can be efficiently routed to the correct destination site within the VPRN. C. Support for Data Security: In general, customers using VPNs require some form of data security, given the general perceptions of the lack of security of IP networks, and particularly that of the Internet. Whether or not this perception is correct, it is one that must be addressed by any VPN implementation. Most recent VPN implementations are converging on the use of IPSec facilities [Kent] for this purpose. Together, these requirements imply that VPRNs must be implemented through some form of IP tunneling mechanism, where the addressing used within the VPRN can be disjoint from that used to route the tunneled packets across the IP backbone. Such tunnels, depending upon their form, can provide some level of intrinsic data security, or this can also be enhanced using other mechanisms (e.g. IPSec). Such tunnels together form an overlay network operating over and across the general Internet backbone, connecting each of the ISP edge routers supporting VPN stub links to each other. Within each of the ISP edge routers, there must be VPN specific IP forwarding mechanisms, to forward packets received across each of the stub links ('ingress' traffic) to the appropriate destination edge router, based upon the address space of the customer's network, and to forward packets received from the core ('egress' traffic) to the appropriate stub link, for cases where an edge router supports multiple stub links belonging to the same VPN (as will be noted below, VPN tunnels can, as a local matter, either terminate on the edge router, or on each stub link; in the former case, a VPN specific forwarding table is needed for egress traffic, in the latter case, it is not). Note also that a single customer site may belong concurrently to multiple VPNs, of various sorts, and/or may wish to transmit traffic both onto one or more VPNs and to the default Internet. The mechanisms needed to do this are outside the scope of this Draft, and are not discussed further. For the purposes of this Draft, it is also assumed that all of the traffic being sent across the VPRN is IP traffic, since the devices implementing the VPRN need to be able to interpret the packet header information to determine the appropriate end-point within the VPRN. However, that procedures discussed here could be readily extended for Multiprotocol transport, either by forming separate VPRNs for each protocol, or by running Multiprotocol routing and forwarding Heinanen, et al. [Page 4] INTERNET DRAFT MPLS Mappings of Generic VPN Mechanisms August, 1998 procedures in each VPN router, and multiplexing multiple protocols across the VPN stub links. IP encapsulation methods could also be used to transport different protocols across IP links. These multiprotocol transport mechanisms are left for further study. 5. Generic VPN Mechanisms ISPs wishing to offer tunnel based VPRN services need to be able to do so with minimal configuration, since this yields the most cost effective solution. The generic VPN mechanisms discussed here apply to the means by which this can be done. The following sections discuss these in detail. 5.1 VPN Membership Information Configuration and Dissemination In order to establish a VPRN, or to insert new customer sites into an established VPRN, the stub links on each edge router from those sites in the particular VPRN must first be configured with the identity of the particular VPRN to which the stub links belong. Note that this first step, of stub link configuration, is unavoidable, since clearly the edge router cannot infer such bindings and hence must be configured with this information. The means by which this is done are outside the scope of this Draft, but a management information base (MIB) allowing for bindings between local stub links and VPN identities may be one obvious solution. Thereafter, each edge router must learn either the identity of, or, at least, the router to, each other edge router supporting other stub links in that particular VPRN. Implicit in the latter is the notion that there exists some mechanism by which the configured edge routers can then use this edge router and/or stub link identity information to subsequently set up the appropriate tunnels between them; this is discussed further below. In order to configure each stub link with the identity of the VPN to which it belongs, some form of VPN identifier is required; the scope of uniqueness of this identifier is a function of its usage, which is related to how VPRN membership is disseminated. This problem, of VPRN member dissemination between participating edge routers, can be solved in a variety of ways: A. Directory Lookup: The members of a particular VPRN, that is, at a minimum, the identity of the edge routers supporting stub links in the VPRN, and possibly also the identity of each of the stub links, could be configured into a directory, which edge routers could query, using some defined Heinanen, et al. [Page 5] INTERNET DRAFT MPLS Mappings of Generic VPN Mechanisms August, 1998 mechanism (e.g. LDAP), upon configuration of their local stub interfaces and VPN identifier. The latter, in this case, need only be unique within the scope of the directory. This mechanism allows for authorization checking prior to disseminating VPRN membership information, which may be desirable where VPRNs span multiple administrative domains. In such a case, directory to directory protocol mechanisms could also be used to propagate authorized VPRN membership information between the directory systems of the multiple administrative domains. There would also need to be some form of database synchronization mechanism (e.g. triggered or regular polling of the directory by edge routers, or active pushing of update information to the edge routers by the directory) in order for all edge routers to learn the identity of newly configured sites inserted into an active VPRN. B. Explicit Management Configuration: A VPRN Management Information Base (MIB) could be defined which would allow a central management system to configure each edge router with the identities of each other participating edge router and possibly also the identity of each of the stub links. Similar mechanisms could also be used, as noted above, to configure the VPN bindings of the local stub links on the edge router. The scope of the VPN identifier in this case is related to the scope of the management system. Note that this mechanism allows the management station to impose strict authorization control; on the other hand, it may be more difficult to configure edge routers outside the scope of the management system. The management configuration model can also be considered a subset of the directory method, in that the (management) directories could use MIBs to push VPRN membership information to the participating edge routers, either subsequent to, or as part of, the local stub link configuration process. C. Piggybacking in Routing Protocols: VPRN membership information could be piggybacked into the routing protocols run by each edge router, since this is an efficient means of automatically propagating information throughout the network to other participating edge routers. Specifically, each route advertisement by each edge router could include, at the minimum, the set of VPN identifiers associated with each edge router, and adequate information to allow other edge routers to determine the identity of, and/or, the route to, the particular edge router. Other edge routers would examine received route advertisements to determine if any Heinanen, et al. [Page 6] INTERNET DRAFT MPLS Mappings of Generic VPN Mechanisms August, 1998 contained information relevant to a supported (i.e. configured) VPRN; this determination could be done by looking for a VPN identifier matching a locally configured VPN. The nature of the piggybacked information, and related issues, such as scoping, and the means by which the nodes advertising particular VPN memberships will be identified, will generally be a function both of the routing protocol and of the nature of the underlying transport, and is discussed further below. The advantage of this last scheme is that it allows for very efficient information dissemination, particularly across multiple routing domains (e.g. across different autonomous systems/ISPs) but it does require that all nodes in the path, and not just the participating edge routers, be able to accept such modified route advertisements. Significant administrative complexity may also be required to configure scoping mechanisms so as to both permit and constrain the dissemination of the piggybacked advertisements. Furthermore, unless some security mechanism is used for routing updates so as to permit only all relevant edge routers to read the piggybacked advertisements, this scheme generally implies a trust model where all routers in the path must perforce be authorized to know this information. Depending upon the nature of the routing protocol, piggybacking may also require intermediate routers, particularly autonomous system (AS) border routers, to cache such advertisements and potentially also re-distribute them between multiple routing protocols. Each of the schemes described above have merit in particular situations. The earlier Draft [Heinanen] discussed the last scheme only, and that is further spelled out below, but the other two schemes may also offer important practical advantages. In particular, note that, in practice, there will almost always be some directory or management system which will maintain VPN membership information, since, as noted above, the binding of VPNs to stub links must be configured, hence, presumably, such information would be obtained from, and stored within, some database. Hence the additional steps to facilitate the configuration of such information into edge routers, and/or, facilitate edge router access to such information, may not be excessively onerous. These methods will be discussed in greater detail in forthcoming Drafts. 5.1.1 VPN Identifier A principal benefit of the router piggybacking model is that it allows for simple dissemination of VPN membership information across multiple ASs. This implies the need for a VPN identifier than can be Heinanen, et al. [Page 7] INTERNET DRAFT MPLS Mappings of Generic VPN Mechanisms August, 1998 unique across multiple ASs. To that end, [Heinanen] proposed a globally unique VPN identifier (note that such an identifier may be useful for VPN types other than only VPRNs) made up of the concatenation of an AS number, and a label assigned by the AS administrator which is locally unique within the particular AS. It is proposed that this be adopted as the VPN identifier, with the further stipulation that the VPN ID be coded as a four octet BGP Communities Attribute [Chandra], made up a two octet AS number and a 2 octet, unstructured integer VPN number, to allow for sufficient numbers of VPNs per AS. The specific details of this proposed format are for future clarification. Note that where a VPN crosses multiple ASs, then there must be some administrative mechanisms to coordinate VPN ID assignment e.g. through the notion of a 'home AS' for a particular VPN, which is used in the VPN ID of that VPN. A VPN ID coded as proposed could also be easily piggybacked in BGP, and could also be easily specified within BGP policy filters in AS border routers for scoping and administrative purposes. For the remainder of the discussion, it is assumed that the VPN identifier will be as so described. 5.2 Tunneling Mechanisms Once VPRN membership information has been disseminated, the tunnels comprising the VPRN can be constructed. While this can be done through manual configuration, this is clearly not likely to be a scalable solution, given the o(n^2) problem of meshed links. As such, tunnel set up should use some form of signaling protocol which would allow two nodes to construct a tunnel to each other knowing only each other's identity. Note also that there are some tunneling mechanisms which allow for multiple disjoint calls or sessions within the same tunnel - in such a 'shared tunnel' case, the signaling protocol could also be used to assign a call within an existing tunnel between two edge routers for a new VPN between them. There are two specific cases of interest networks running MPLS, and current networks not running MPLS. These are discussed separately. 5.2.1 MPLS Networks As noted in [Heinanen], MPLS can be considered to be a form of IP tunneling, since the labels of MPLS packets allow for routing decisions to be decoupled from the addressing information of the packets themselves. MPLS label distribution mechanisms can be used to Heinanen, et al. [Page 8] INTERNET DRAFT MPLS Mappings of Generic VPN Mechanisms August, 1998 associate specific sets of MPLS labels with particular VPRN address prefixes supported on particular egress points (i.e. stub links of edge routers) and hence allow other edge routers to explicitly label and route traffic to particular VPRN stub links. The exact relationship of the various MPLS labels and the particular VPN to which they are bound is a function of whether or not the CPE edge routers participate or do not participate in MPLS with the ISP edge routers. These cases are discussed in greater detail below. The principal attraction of MPLS as a tunneling mechanism is that it may require less processing within each edge router than alternative tunneling mechanisms. This is also a function of the fact that data security within a MPLS network is implicit in the explicit label binding, much as with a connection oriented network, such as Frame Relay. This may hence lessen customer concerns about data security and hence require less processor intensive security mechanisms (e.g. IPSec). As discussed below, however, such implicit mechanisms address only some of the potential security concerns of customers. 5.2.2 Non-MPLS Networks For non-MPLS networks, VPNs in general require the use of an explicit IP tunneling mechanism. There are numerous IP tunneling mechanisms, including IP/IP [Simpson], GRE tunnels [Hanks], L2TP [Valencia] and IPSec [Kent]. Each of these allow for opaque transport of IP packets, with routing disjoint from the address fields of the encapsulated packets. Additional processing is required in edge routers for the use of any of these protocols, with some (e.g. IPSec) mandating significant processing capabilities. On the other hand, such tunneling protocols can provide significantly more comprehensive data security capabilities than the implicit security of MPLS. It is the case, however, that none of the protocols listed above were originally designed to support VPNs of the type under consideration. As such, none provide all of the mechanisms likely to be needed for VPN applications. In particular, only L2TP and IPSec can be considered to have any form of signaling protocol (the L2TP control protocol, and the Internet Key Exchange protocol [Harkins], respectively) which could potentially be used to automate the process of tunnel set up. Furthermore, none of these tunneling protocols have support today for multicast (other than source replication), whereas MPLS does have such support, though the application of MPLS mechanisms to multicast transport within VPNs is not yet fully defined, and requires further study. Given however, the current paucity of operational networks running MPLS, there is likely to be significant value in fully defining a VPN Heinanen, et al. [Page 9] INTERNET DRAFT MPLS Mappings of Generic VPN Mechanisms August, 1998 tunneling mechanism which could be deployed in current networks. It may also be possible to readily extend other IP tunneling protocols to incorporate support for multicast. Subsequent Drafts will address these issues. 5.3 Stub Link Reachability Information There must be mechanisms to allow ISP edge routers to determine the set of VPN addresses and address prefixes reachable at each stub link connecting to the edge router. There are a number of means by which this can be done: A. Routing Protocol Instance: A routing protocol can be run between the CPE edge router and the ISP edge router to exchange reachability information. Note that this routing exchange is asymmetrical since the CPE router views the ISP edge router as the default path into the VPN. Any suitable routing protocol could be used to exchange routing information between the CPE and ISP edge routers. It should be noted that the only function of this protocol is indeed to exchange reachability information, not to discover topology, since, by definition, there is only a single, point-to-point (logical) link between the CPE router and the ISP edge router, with the latter then discovering (and hiding) the VPN topology. Likely protocols for this purpose include RIPv2, OSPF [Moy] and BGP-4 [Rekhter2]. Note that even if the same protocol is used between the CPE and ISP edge routers, and from the ISP edge routers into the core, these will be two quite distinct routing instantiations. If the ISP edge router uses routing protocol piggybacking to disseminate VPN membership and reachability information across the core, then it may redistribute suitably labeled routes from the CPE routing instantiation to the core routing instantiation (but never the other way round). There is no requirement that the same protocol, or even the same CPE reachability information gathering mechanism, be run between each CPE router and associated edge router in a particular VPRN, since this is purely local matter. Note that if a particular customer site concurrently belongs to multiple VPNs (or wishes to concurrently communicate with both a VPN and the Internet), then the ISP edge router must have some means of unambiguously mapping stub link address prefixes to particular VPNs. This could be done either by ensuring (and appropriately configuring the ISP edge router to know) that particular disjoint address prefixes are mapped into separate VPNs, or by tagging the routing advertisements from the CPE edge router with the appropriate VPN Heinanen, et al. [Page 10] INTERNET DRAFT MPLS Mappings of Generic VPN Mechanisms August, 1998 identifier. In the case of MPLS, as discussed below, different MPLS labels would be used to differentiate the disjoint prefixes assigned to particular VPNs. In any case, some administrative procedure would be required for this coordination. B. Configuration: The reachability information across each stub link could be manually configured, which may be appropriate if the set of addresses or prefixes is small and static. C. ISP Administered Addresses: The set of addresses used by each stub site could be administered and allocated by the ISP, which may be appropriate for very small sites with little network administration resources. In such a case the ISP edge router could determine these addresses by proxying for the particular address administration mechanism (e.g. DHCP). Note that in this case it would be the responsibility of the ISP to ensure that each site in the VPN received a disjoint address space. D. MPLS Label Distribution Protocol: In cases where the CPE edge router runs MPLS, the MPLS LDP could be extended to convey the set of prefixes at each stub site, together with the appropriate labeling information. While LDP is not generally considered a routing protocol per se, it may be useful to extend it for this particular constrained scenario. This is for further study. 5.4 Intra-VPN Reachability Information Once an edge router has determined the set of prefixes associated with each of its stub links, then this information must be disseminated to each other edge router in the VPRN. Note also that there is an implicit requirement that the set of reachable addresses within the VPRN be locally unique that is, each VPRN stub link (not performing load sharing) maintain an address space disjoint from any other, so as to permit unambiguous routing. In practical terms, it is also generally desirable, though not required, that this address space be well partitioned i.e. specific, disjoint address prefixes per stub link, so as to preclude the need to maintain and disseminate large numbers of host routes. The intra-VPN reachability information dissemination can be solved in a number of ways, some of which include the following: Heinanen, et al. [Page 11] INTERNET DRAFT MPLS Mappings of Generic VPN Mechanisms August, 1998 A. Directory Lookup: Along with VPN membership information, a central directory could maintain a listing of the address prefixes associated with each end point. Such information could be obtained by the server through protocol interactions with each edge router. Note that the same directory synchronization issues discussed above would apply in this case. B. Explicit Configuration: The address spaces associated with each edge router could be explicitly configured into each other router. This is clearly a non-scalable solution, and also raises the question of how the management system learns such information in the first place. C. Local Intra-VPRN Routing Instantiations: In this approach, each edge router runs an instantiation of a routing protocol (a 'virtual router') per VPRN, running across the VPRN tunnels to each peer edge router, to disseminate intra-VPRN reachability information. The intra-VPN routing advertisements could be distinguished from normal tunnel data packets either by being addressed directly to the peer edge router, or by a tunnel specific mechanism. Note that this intra-VPRN routing protocol need have no relationship with the routing protocols operated by the ISPs in the path. Specifically, the intra- VPRN routing protocol operates as an overlay over the IP backbone, and, given the very simple meshed topology of the VPRN, could be a very simple protocol, such as RIPv2 [Malkin], at least unless the VPRN spans a very large number of edge routers. Since the intra-VPN routing protocol runs as an overlay, it is also wholly transparent to any intermediate routers, and to any edge routers not within the VPRN. This also implies that such routing information can also remain opaque to such routers, which may be a necessary security requirements in some cases. D. Link Reachability Protocol Each edge router could run a link reachability protocol - for instance, some variation of the MPLS LDP - across the tunnel to each peer edge router in the VPRN, carrying the VPN ID and the reachability information of each VPRN running across the tunnel between the two edge routers. Such a protocol would need to be specified, and would require aspects of current routing protocols such as hello protocols, and re-transmit timers and/or positive acknowledgements. However, such an approach may reduce the Heinanen, et al. [Page 12] INTERNET DRAFT MPLS Mappings of Generic VPN Mechanisms August, 1998 processing burden of running routing protocol instantiations per VPRN, and may be of particular benefit where a shared tunnel mechanism is used to connect a set of edge routers supporting multiple VPRNs. E. Piggybacking in Routing Protocols: As with VPN membership, the set of address prefixes associated with each stub interface could also be piggybacked into the routing advertisements from each edge router and propagated through the network. Other edge routers would extract this information from received route advertisements in the same way as they would obtain the VPRN membership information (which, in this case, is implicit in the identification of the source of each route advertisement). Note that this scheme may require, depending upon the nature of the routing protocols involved, that intermediate routers e.g. border routers cache intra-VPRN routing information in order to propagate it further. This also has implications for the trust model, and for the level of security possible for intra-VPRN routing information. Note that in any of the cases discussed above, an edge router has the option of disseminating its stub link prefixes in a manner so as to permit tunneling from remote edge routers directly to the egress stub links. Alternatively, it could disseminate the information so as to associate all such prefixes with the edge router, rather than with specific stub links. In this case, the edge router would need to implement a VPN specific forwarding mechanism for egress traffic, to determine the correct egress stub link. The advantage of this is that it may significantly reduce the number of distinct tunnels or tunnel label information which need to be constructed and maintained. Note that this choice is purely a local manner and is not visible to remote edge routers. The earlier Draft [Heinanen] discussed the last scheme only, and that is further spelled out below. A number of vendors have already announced, however, their intention to support variants of the virtual router scheme, which is also less disruptive to currently deployed routing protocols. As such, this scheme merits further investigation and will be addressed in future Drafts. 6. Routing Protocol Piggybacking As noted above, routing protocol piggybacking could be used to carry VPN membership information alone, or also VPN reachability information. The means by which this is done, and the nature of the piggyback information, is a function both of the particular routing protocol, and of the underlying network mechanism. The particular Heinanen, et al. [Page 13] INTERNET DRAFT MPLS Mappings of Generic VPN Mechanisms August, 1998 cases of OSPF and BGP-4 are discussed below. 6.1 OSPF OSPF is often used as an intra-AS routing protocol, and hence may be a required candidate for routing protocol piggybacking. One means by which VPN membership and reachability information could be piggybacked is through the use of the proposed OSPF opaque LSA [Coltun]. The exact details of how such a piggybacking advertisement might be coded are for further study. In particular, it may prove to be the case that opaque LSAs could be well suited for piggybacking VPN membership information, but not VPN reachability information, since opaque LSAs, at least as currently defined, are attributes of, not indexes into, reachability information. Using them in the latter manner, which would be required to piggyback VPN reachability information, may break some existing OSPF implementations. Opaque LSAs do, however, have a well defined scoping mechanism, that, at least within an AS, allows for control over the extent of dissemination of a VPN advertisement. Note also that as a link state protocol OSPF advertisements always allow for the identification of the source of an advertisement. However, each router in the OSPF network, and not only edge routers, will also need to examine received advertisements, and explicitly ignore piggybacked VPN advertisements, unless configured to be a VPN terminator (i.e. edge router). 6.2 BGP-4 There are a number of potential mechanisms by which VPN information could be piggybacked into BGP-4, including the Multiprotocol Extensions attribute [Bates] or the BGP communities attribute. In the case where VPN reachability information is piggybacked, each VPN address prefix could be encoded as Network Layer Reachability Information (NLRI) and bound to the VPN identifier as a community attribute, if the VPN ID has the format proposed previously. Note that in cases where it was desired only to advertise VPN membership information, then advertising each VPN prefix may be onerous and undesirable, but there is no specific mechanism in BGP-4, as yet, to advertise anything other than NLRI. In the case where this is done on an MPLS network, then the advertisement would carry each VPN prefix, together with the MPLS label(s) to be used to send packets to that stub link. As noted above, these labels, as a purely local matter, could identify either the route to each stub link, or only to the edge router itself, which would then use its own forwarding mechanisms for egress packets. Heinanen, et al. [Page 14] INTERNET DRAFT MPLS Mappings of Generic VPN Mechanisms August, 1998 Since there is already defined a particular mechanism for carrying MPLS labels in BGP-4 using the Multiprotocol Extensions field [Rekhter3], this would suggest that this mechanism should be generalized for the purpose also of conveying VPN information; hence it is proposed that that Draft be amended for this purpose. The use of BGP-4 for VPN piggybacking is more complex in cases where this is done on non-MPLS networks. In such a case, the piggybacked advertisements must allow for the explicit identification of the source of the advertisement. This is important for tunnel set up in non-MPLS networks, where each edge router needs to know the identity (i.e. IP address) of each of the other edge routers, in order to initiate whatever signaling mechanism may be used for tunnel set-up. At present there is no means by which the original source of a BGP advertisement can be identified once that advertisement is redistributed (e.g. from an intra-AS protocol like OSPF into BGP at a border node, or from an edge router through a border router for distribution outside the original AS). Since VPN support in non-MPLS networks is an important requirement, it is proposed that whatever BGP-4 mechanism is chosen for the purpose of VPN advertisements also be amended to allow for explicit tagging with the IP address of the original source of the advertisement. One possible means by which this could be done may be to associate the VPN ID (coded as a Community Attribute) with the /32 prefix (i.e. IP address) of the edge router supporting the VPN. This issue is for further study. Note that in the case where BGP advertisements are propagated across AS boundaries, then each border router must cache the full set of prefixes and associated label stacks of each advertised VPN. In such a case, further work is also needed to control scoping of BGP piggybacked advertisements. In particular, at AS boundaries, border routers would generally need to be manually configured with VPN route advertisement policies to determine whether such advertisements should be propagated, and, if so, to which peer ASs. In general ASs will also likely automatically reject VPN advertisements received from peer ASs unless specifically configured to pass them. Some administrative mechanism (e.g. manual procedures or some form of directory communication, for instance) would be needed for this purpose. Note also that such scoping policy configurations would be needed not only in each border router of each AS with one or more VPN termination points, but also in each AS in the transit path between them. This last may pose problems if the trust system includes the terminating ASs, but excludes one or more of the transit ASs. These problems expose a particular artifact of router piggybacking - while VPN membership and reachability information is relevant only to the Heinanen, et al. [Page 15] INTERNET DRAFT MPLS Mappings of Generic VPN Mechanisms August, 1998 particular edge routers concerned, router piggybacking necessarily requires also the active participation of all intermediate routers that need to process and propagate such advertisements. This may impose significant burdens on the operation and administration of such intermediate routers, as well as compromising the integrity of the VPNs concerned. 7. MPLS Mappings The earlier Draft [Heinanen] proposed a number of mechanisms for facilitating VPN set up in MPLS networks. As noted above, most of these mechanisms are subsets of more generic VPN mechanisms, and some of the alternate mechanisms described above can also be applied to MPLS networks. There are specific issues with respect to mappings into MPLS networks due to the nature of the particular control and data planes of MPLS. Furthermore, the operation of these data and control planes is a function of whether or not the CPE router also runs MPLS. These cases are considered separately. 7.1 CPE Router Runs MPLS In this case the CPE router and ISP edge router exchange, using one of the mechanisms discussed above, the set of address prefixes associated with that stub site and then, concurrently or subsequently, assign MPLS labels to each such prefix. Note that, as discussed above, the edge router could decide, as a local matter, to assign the same label to each such stub link, or distinct labels to each, depending upon whether or not it wished to explicitly forward egress packets. If a CPE routers belongs concurrently to more than one VPN, then it must label the (disjoint) prefixes of each VPN differently, to allow for unambiguous routing at the edge router. Thereafter, the ISP edge router uses whatever routing and label assignment mechanisms may be used within its network to disseminate the prefixes, tagged with the appropriate VPN ID, and the locally assigned MPLS label, to each other peer Label Switching Router (LSR). In the specific case where BGP-4 is used for piggybacking across the core network, this implies that each edge router and border router in the AS but not the intermediate LSRs - will receive the bindings of VPN IDs, VPN prefixes and associated labels, together with the label needed to forward traffic to the particular edge router from its BGP peers. If border routers were to propagate this information further across the core, they would then push into this label stack, information to identify the explicit tunnel route to the particular border router from its peer border routers. At a terminating edge Heinanen, et al. [Page 16] INTERNET DRAFT MPLS Mappings of Generic VPN Mechanisms August, 1998 router, the edge router would maintain in its VPN specific Label Information Base (LIB), the mappings of particular VPN prefixes to the label stacks associated with each prefix. Note that in this case, edge routers will know, and need know, only the route (i.e. MPLS label stack) to each VPN prefix, and will not know the identity of the edge router through which that prefix is reached. Each edge router may also advertise, using either LDP or a piggybacked routing protocol, a default label to be used by the CPE across its stub links to send data into the VPN, unless this binding was implicit (e.g. all traffic from a stub link only gets sent to one particular VPN). Note that all of these label stacks are disjoint from the labels used for connectivity between the edge and border routers, through the intermediate LSR within the AS MPLS network. This level of intra-AS connectivity is a lower level than the BGP peering level; hence, disjoint MPLS label allocation mechanisms (e.g. LDP following prefix distribution using an intra-AS routing protocol) would be used to determine connectivity to, and the appropriate label stacks for, edge and border router connectivity across the AS. Hence an edge or border router wishing to transmit to a particular VPN stub link would need to first determine the destination VPN prefix, and the VPN label stack associated with that prefix. Subsequently, it would then determine the label switched path (LSP) to the particular destination edge router, push the resultant label stack onto the VPN label and transmit the packet. At the destination edge router, the intra-AS routing label stack would be popped, and the packet sent to the appropriate stub link using either the VPN label, if explicitly tagged, or using a local forwarding mechanism, if not. 7.2 CPE Router Does Not Run MPLS This case would work exactly as described above, except that the ISP edge router would proxy for the CPE router by assigning labels to each CPE prefix. Packets sent to the stub link would be routed as described above, except that at the destination edge router the label stack would be removed and an untagged packet sent to the CPE router. In this case, the edge router would also need some unambiguous means of determining the destination VPN, where a particular stub site supports multiple VPNs. Typically this will require disjoint address spaces in each VPN. Note that in either case that all border routers will need to maintain label mappings for all prefixes associated with each VPN in Heinanen, et al. [Page 17] INTERNET DRAFT MPLS Mappings of Generic VPN Mechanisms August, 1998 the AS. This is a consequence of the fact that BGP can, at present, only advertise routes to particular NLRI prefixes and hence, cannot, as discussed above, advertise only VPN to edge router bindings. It is also, of course, obvious, that such information cannot in any sense be aggregated. 7.3 Use of RSVP in MPLS Networks There have been a number of proposals to use the Resource Reservation Protocol (RSVP) to allocate labels within MPLS networks, either for the purpose of setting up flow specific LSPs [Davie] or for administrating traffic engineered tunnels across multiple ASs, as in the PASTE proposal [Li]. In either case, VPN membership and, perhaps also VPN reachability information, could be carried using such RSVP based label allocation mechanisms, as with the use of the LDP, described above. In particular, in the case of the PASTE proposal, RSVP is used to set up and administer traffic engineered tunnels that span potentially multiple service provider domains, and provide non- default path forwarding. In such a case, router piggybacking may not be possible, and hence RSVP may be the only protocol available in which to piggyback VPN advertisements. This subject is for further study. 8. Security Considerations As noted above, VPN operation on MPLS networks relies upon the implicit security of explicitly labeled LSPs. Unless a particular edge router has been configured for membership into a particular VPN, then no CPE router connected to that edge router should be able to insert traffic into that VPN. Note, however, that this is only true if each edge router in the network, and not just those participating in the VPN, ensures that no CPE router can transmit packets with label information that may cause it to be inserted, at some merge point, into a LSP leading to the labeled VPN. As such, the trust model for MPLS based VPNs must encompass all MPLS edge routers, and not only those participating in the particular VPN. The particular form of data security offered by MPLS based VPNs also does not address other potential security concerns e.g. data snooping, non- repudiation, etc. Such concerns can only be met through more explicit security mechanisms e.g. IPSec. As noted earlier, such mechanisms are required for any tunneling mechanism operating on non-MPLS networks where paths are not explicitly labeled. Note, however, that such security mechanisms - e.g. bilateral IPSec peerings between two edge routers in a VPN - have the advantage that the trust model need only include the relevant edge Heinanen, et al. [Page 18] INTERNET DRAFT MPLS Mappings of Generic VPN Mechanisms August, 1998 routers, and not any of the intermediate routers (or administrative domains). Particular VPN configuration mechanisms have their own security issues. In particular, piggybacking of VPN membership and routing information in routing protocols would potentially expose such information to all intermediate routing nodes. This may be a particular issue where this mechanism is used to distribute VPN information across multiple ASs or ISPs. Mechanisms to address this problem may be worthy of study e.g. the use of encryption and authentication mechanisms to protect such piggybacked information, with the use of key distribution mechanisms to restrict access only to trusted edge routers. 9. Intellectual Property Considerations Cisco Systems has claimed potential intellectual property rights to certain aspects of the mechanisms discussed in the earlier Draft, and referred to here. Refer to [Heinanen] for the specific disclosure notice. The nature, extent and impact of these claims are unknown to the present authors. 10. Acknowledgements Thanks to Tony Li, of Juniper Networks, for his helpful review and feedback and to Anthony Alles, of Shasta Networks, for his assistance in the generation of this Draft. 11. References [Bates] Bates, T. "Multiprotocol Extensions for BGP-4", RFC 2283. [Callon] Callon, R., et al "Multiprotocol Label Switching Architecture", draft-ietf-mpls-arch-02.txt. [Chandra] Chandra, R. and Traina, P. "BGP Communities Attribute", RFC 1998. [Coltun] Coltun, R. "The OSPF Opaque LSA Option", RFC 2370. [Davie] Davie, B., et al - "Use of Label Switching with RSVP", draft-ietf-mpls-rsvp-00.txt [Hanks] Hanks, S., et al "Generic Routing Encapsulation over Ipv4 Networks", RFC 1702. Heinanen, et al. [Page 19] INTERNET DRAFT MPLS Mappings of Generic VPN Mechanisms August, 1998 [Harkins] Harkins, D. and Carrel, D. "The Internet Key Exchange (IKE)", draft-ietf-ipsec-isakmp-oakley-08.txt. [Heinanen] Heinanen, J. and Rosen, E. "VPN Support with MPLS" draft-heinanen-mpls-vpn-01.txt. [Kent] Kent, S. and Atkinson, R. "Security Architecture for the Internet Protocol", draft-ietf-ipsec-arch-sec-06.txt. [Li] Li, T. and Rekhter, Y. - "Provider Architecture for Differentiated Services and Traffic Engineering (PASTE)", draft-li- paste-00.txt. [Malkin] Malkin, G. "RIP Version 2 Carrying Additional Information", RFC 1723. [Moy] Moy, J. "OSPF Version 2", RFC 2328. [Rekhter1] Rekhter, Y., et al "Address Allocation for Private Internets", RFC 1918. [Rekhter2] Rekhter, Y. and Li, T. "A Border Gateway Protocol 4 (BGP-4)", RFC 1771. [Rekhter3] Rekhter, Y. and Rosen, E. "Carrying Label Information in BGP-4", draft-ietf-mpls-bgp4-mpls-00.txt. [Simpson] Simpson, W. "IP in IP Tunneling", RFC 1853. [Valencia], Valencia, A., et al "Layer Two Tunneling Protocol "L2TP"", draft-ietf-pppext-l2tp-11.txt. 11. Author Information Juha Heinanen Telia Finland, Inc. Myyrmaentie 2 01600 VANTAA Finland Tel: +358 303 944 808 Email: jh@telia.fi Bryan Gleeson Shasta Networks 249 Humboldt Court Sunnyvale CA 94089-1300 USA Tel: +1 (408) 548 3711 Heinanen, et al. [Page 20] INTERNET DRAFT MPLS Mappings of Generic VPN Mechanisms August, 1998 Email: bgleeson@shastanets.com Arthur Lin Shasta Networks 249 Humboldt Court Sunnyvale CA 94089-1300 USA Tel: +1 (408) 548 3788 Email: alin@shastanets.com Heinanen, et al. [Page 21]