Internet Draft Internet Engineering Task Force Juha Heinanen INTERNET DRAFT Telia Finland, Inc. Expires June 1998 December 1997 VPN support for MPLS <draft-heinanen-mpls-vpn-00.txt> 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 document discusses the need to include support for Virtual Private Networks in MPLS and gives a high-level description on how it can be accomplished. 1. Introduction The Framework for MPLS document [1] contains a long list of benefits that MPLS has as compared to conventional router backbones. For some reason it doesn't include easy support for Virtual Private Networks (VPNs) as one of them. Either VPN support is one of the best kept secrets of the MPLS design team or the authors of the framework document have not considered VPN support as an issue worth mentioning. Intranets are one of the fast growing ways to deploy the TCP/IP protocol suite. In order to provide Intranet services to its (best paying) customers, ISPs must be able to address the problems of security and use of non-unique, private IP addresses [2]. It turns Heinanen VPN Support for MPLS [Page 1] INTERNET DRAFT December, 1997 out that MPLS, due to its Layer 2, virtual circuit nature, provides a simple and efficient solution to these important problems. In conventional router backbones, IP packets are forwarded based on destination IP addresses, which must be unique within the backbone. It would not help to have a separate forwarding table for each VPN, since there is no VPN identifier in the IP packet header that could be used to select the correct forwarding table. MPLS backbone routers, on the other hand, can benefit from a separate routing table per VPN, since the tables are not used to forward IP packets, but to control label distribution. In MPLS backbones it is enough that the destination addresses are unique at the ingress LSRs, which attach the labels to the IP packets. This is the key observation that allows efficient implementation of VPNs in the MPLS environment. The following sections discuss various ways to support VPNs over an MPLS backbone. It is assumed that customer VPN sites communicate with the MPLS backbone either using static routes and LDP or BGP and that within the MPLS backbone either OSPF and LDP or IBGP are used to distribute the reachability and label binding information. 2. Virtual Private Networks (VPNs) In this document the term VPN is used to denote a set of customer sites that connect to the MPLS backbone and form a Closed User Group (CUG). A site may advertise a set of "streams" [3] to the other members of a CUG. This allows the other CUG members (and only them) to send IP packets to those streams. The advertised streams need only be unique within the CUG(s) to which the site belongs to. A site can at the same time be a member of more than one CUG and also be connected to the public Internet. In the latter case, the site advertises (some of) its streams without associating them with any CUG. The public Internet can thus be considered to be a special CUG that does not have any CUG identification. CUGs are identified within MPLS backbones using unique CUG identifiers. A CUG identifier can be constructed, for example, by appending an integer that uniquely identifies a CUG with a single MPLS backbone to an IP address owned by that backbone. Between a customer site and an MPLS backbone, a CUG can be identified using a CUG index, which is an integer that uniquely distinguishes the CUG among all CUGs defined over that link. 3. Distribution of VPN bindings to and from the MPLS backbone When a customer site is connected to an MPLS backbone, the corresponding interface of the backbone LSR is configured with a list Heinanen VPN Support for MPLS [Page 2] INTERNET DRAFT December, 1997 of CUG identifiers that correspond to the CUGs that the customer site belongs to and with a mapping that describes the correspondence between these CUG identifiers and the CUG indexes used over the link between the customer LSR and the backbone LSR. IP routing between the customer site and the MPLS backbone is assumed to be based either on static routes or BGP. If static routes are used, then the Label Distribution Protocol (LDP) [3] needs to be turned on between the customer LSR and the backbone LSR for advertisement of the label bindings. In order to support VPNs, the LDP advertisement message need to be extended with the CUG index so that the two LSRs know which VPN an advertisement belongs to. Since the LDP advertisements also carry stream information, manual configuration of static routes in the two LSRs would not be necessarily needed. If BGP is used between the customer site and the MPLS backbone, then the label bindings are included in BGP advertisements by extending BGP with label and CUG index attributes. The LDP would thus not need to be turned on between the customer LSR and the backbone LSR. When the above configuration tasks have been completed, the customer LSR and backbone LSR use either LDP or BGP to inform each other what streams are available for each VPN and what labels have been bound to them. The backbone LSR checks that the customer site really is a member of the VPN before it accepts a label binding from the customer LSR. Correspondingly, before a backbone LSR distributes a label binding to a customer LSR, it checks to see that the customer site is really configured to belong to the same VPN as the advertised label binding. If the customer site belongs to only one VPN, it should not be bothered with the knowledge of the VPNs. In that case, the only VPN is configured as the default VPN to the corresponding interface of the backbone LSR and the two LSRs don't include a CUG index in their advertisements to each other. 4. Distribution of VPN bindings within the MPLS backbone When a backbone LSR learns a label binding from a customer site, it must somehow make the stream (and a corresponding label binding) known to the other CUG members. This chapter covers the cases where either OSPF and LDP or IBGP is used to distribute the label bindings. If the MPLS backbone is using OSPF and LDP to distribute the routing information and label bindings, the backbone LSR that learns a binding from a customer LSR injects the stream together with the Heinanen VPN Support for MPLS [Page 3] INTERNET DRAFT December, 1997 corresponding VPN identifier to its OSPF process. The VPN identifier allows the OSPF process to construct for each VPN its own routing table. This is needed, because the VPNs may use overlapping, private IP addresses. How the VPN identifier is associated with the stream in the OSPF advertisement is left for further study. One possibility is to use the Opaque LSA option [4]. In addition to injecting the stream to its OSPF process, the backbone LSR also advertises a corresponding label binding to its peers within the MPLS backbone. This advertisement is otherwise normal except that also the CUG identifier is included in the advertisement message. If the MPLS backbone is using IBGP to distribute the label bindings, then it suffices that a backbone LSR that learned a binding from a customer LSR injects the binding together with the CUG identifier to its IBGP process. This requires that BGP is extended with two attributes: one for the CUG identifier and one for the label. The details of these extensions are left for further study. 5. Security considerations As shown in this document, MPLS can be used to implement secure VPNs over a single MPLS backbone where the VPNs are fully isolated from each other in terms of both visibility and packet forwarding. The security is accomplished by manually associating a set of unique CUG identifiers to the customer interfaces of the backbone LSRs. The CUG identifiers limit the distribution of both reachability and label information. If a customer site has not received a label for a particular destination, it has no means to send packets to that destination provided that the LSRs assign the labels so that they are unique per interface, not per LSR. Manual configuration of the CUG identifiers is always subject to human error. However, configuration of a single CUG identifier once per interface is a much simpler process than configuration of a list of IP address prefixes, since the latter need to be modified each time a new customer site is added to or removed from the VPN. 6. Summary This document has argued that VPN support should be an essential part of the MPLS protocol. Easy and efficient support for VPNs is seen as the killer application for MPLS without which the whole MPLS effort is hard to justify. It is therefore suggested that the MPLS working group incorporates VPN support in its current work plan. Heinanen VPN Support for MPLS [Page 4] INTERNET DRAFT December, 1997 References [1] Callon, R., et al, "A Framework for Multiprotocol Label Switching". draft-ietf-mpls-framework-02.txt. [2] Rekhter, Y., et al, "Address Allocation for Private Internets". RFC 1918, Feb 1996. [3] Feldman, Nancy, et al, "LDP Specification". draft-feldman-ldp- spec-00.txt. [4] Coltun, Rob, "The OSPF Opaque LSA Option". draft-ietf-ospf- opaque-02.txt. Acknowledgements I would like to thank Rob Coltun for listening to my initial ideas and Yakov Rekhter for pointing out the importance of IBGP. Author Information Juha Heinanen Telia Finland, Inc. Myyrmaentie 2 01600 VANTAA Finland Phone +358 303 944 808 Email jh@telia.fi Heinanen VPN Support for MPLS [Page 5]