Network Working Group D. Lewis Internet-Draft G. Schudel Intended status: Experimental Cisco Systems, Inc. Expires: August 18, 2014 February 14, 2014 LISP Virtual Private Networks (VPNs) draft-lewis-lisp-vpns-00.txt Abstract This document describes the use of the Locator/ID Separation Protocol (LISP) to create Virtual Private Networks (VPNs). LISP is used to provide segmentation in both the LISP data plane and control plane. These IP based VPNs can be created over the top of the Internet or other VPN protocols, and can be implemented by Enterprise or Service Provider type networks. The goal of these VPNs is to leverage the characteristics of LISP - routing scalability, simply expressed Ingress site TE Policy, IP Address Family traversal, and mobility, in ways that provide value to network operators. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on August 18, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Lewis & Schudel Expires August 18, 2014 [Page 1] Internet-Draft LISP Virtual Private Networks (VPNs) February 2014 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 3. Virtualizing LISP . . . . . . . . . . . . . . . . . . . . . . 4 3.1. The LISP IID in the Data Plane . . . . . . . . . . . . . 4 3.2. The LISP IID in the Control Plane . . . . . . . . . . . . 4 3.3. Locator Network Segmentation . . . . . . . . . . . . . . 4 4. LISP VPN Network Elements . . . . . . . . . . . . . . . . . . 5 5. Types of LISP VPNs . . . . . . . . . . . . . . . . . . . . . 5 6. Enterprise VPNs . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Internet based Enterprise LISP VPN Example . . . . . . . 6 6.2. MPLS-VPN based Enterprise LISP VPN Example . . . . . . . 6 7. Service Provider LISP VPNs . . . . . . . . . . . . . . . . . 6 7.1. MPLS VPNs and LISP CE based VPNs, from the SP perspective 6 7.2. Service Provider Internet based LISP VPN Example . . . . 7 7.3. Service Provider MPLS-VPN based LISP VPN Example . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8.1. LISP VPNs and IPSec . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 11.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction Network virtualization create multiple, logically separated topologies across one common physical infrastructure. Virtual Routing and Forwarding (VRF) containers are used to create multiple instances of Layer 3 routing tables virtualization (segmentation) at the device level. Data Plane Forwarding VRF table separation is maintained across network paths using either single-hop path segmentation (hop-by-hop) such as 802.1q VLANs or VPI/VCI PW. Traditional multi-hop mechanisms include MPLS and GRE tunnels. Control plane segmentation is key to allowing sites to use overlapping network prefixes in these logically separate topologies. MPLS+BGP (ref RFC 2547) is an example of this control plane segmentation. LISP creates two namespaces - End-Site-Identifier (EID) namespace and the Routing Locators (RLOC) namespace. The LISP Mapping System maps Lewis & Schudel Expires August 18, 2014 [Page 2] Internet-Draft LISP Virtual Private Networks (VPNs) February 2014 the EID to a RLOC. LISP can be used for virtual networking in both name spaces, and the LISP Mapping System can be used to Map Virtualized EID Networks to RLOC Networks. That is, either or both namespace can be virtualized. When the EID namespace is segmented, a LISP Instance-ID (IID) is encoded in both the data plane and in the control plane to provide segmentation and to disambiguate overlapping EID Prefixes. The allows multiple VRFs to 'share' a common Routing Locator network while maintaining prefix segmentation. This flexible approach to LISP virtualization, combined with LISP's innate capabilities of simple TE policy expression, address family traversal, and mobility, have several implications for the use and creation of Overlay Networks. An Enterprise using a LISP VPN it can virtualize, under the same control plane, a coherent overlay network in its campus, its branches, its Data Centers and its external 'cloud' based services. A LISP VPN can be built with a partial mesh of Tunnel Routers that do not have direct reachability to each other's RLOCs. One example of non globally reachable RLOC namespace is the IPv4 Internet and the IPv6 Internet. Without some intervening mechanism, individual sites connected to one, but not both of these two networks could not directly communicate with each other. The same situation can occur for Locator networks of the same address family, as in the case where there are two separate MPLS VPNs acting as Locator Namespaces. When data path security is needed, LISP virtualization can be combined with IPSec to provide data path confidentiality, integrity, origin authentication and anti-replay protection. In general, LISP VPNs can be instantiated either by Enterprises or by Service Providers. When implemented by Enterprise networks, the functions of LISP Tunnel Routers (xTRs) and the LISP Mapping System are enabled on Customer Edge (CE) devices use IP transport (either the internet or a private IP network (e.g. an MPLS-BGP VPN), to create a common underlay for the LISP Overlay to use. When LISP VPNs are implemented by a Service Provider, the xTR function may be enabled on either the Provider Edge (PE)or the CE devices, and the LISP Mapping system may be enabled on either one of those devices or dedicated to a devices somewhere in the Service Provider network with IP connectivity to those data plane devices. 2. Definition of Terms For definitions of other terms, notably Map-Request, Map-Reply, Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR), please consult the LISP specification [RFC6830]. Lewis & Schudel Expires August 18, 2014 [Page 3] Internet-Draft LISP Virtual Private Networks (VPNs) February 2014 3. Virtualizing LISP A LISP VPN is a collection of LISP Sites building an Overlay Network. These sites share a common control plane, the LISP Mapping System. The members of this VPN also share common RLOC connectivity, whether it be the Internet or a private IP network. VPNs must be allowed to have overlapping address space. We need to disambiguate this space in both the control and data plane. The LISP Instance ID (IID) is used to provide a VPN wide unique identifier. The LISP Instance ID is a 24 bit unstructured namespace that identifies a LISP VPN. The tuple of EID Prefix and IID is referred to as an Extended EID (XEID) (ref DDT draft). The LISP IID is used in the data plane of the LISP header (ref RFC 6830), as well as in the LISP control plane (ref LCAF). 3.1. The LISP IID in the Data Plane A LISP xTR will map, by configuration, the LISP Instance ID to a given VRF in its EID namespace. The purpose of the LISP IID in the LISP header is to allow an xTR to identify which VPN the packet belongs to when encapsulating or decapsulating LISP packets. the EID. For example, on receipt of a packet a LISP ETR will deliver the decapsulated data to the proper VRF. The use of multiple IIDs on a single site xTR, each mapped to a different EID VRF allows for multiplexing of VPNs over a Locator network. 3.2. The LISP IID in the Control Plane In the LISP Mapping Server, LISP sites are identified by a set of EID Prefixes, an authentication key, and an LISP IID. 3.3. Locator Network Segmentation This document has so far discussed virtualizing the LISP EID namespace, and communication between xTRs and the LISP Mapping System. Implicit in this communication requirement is a network between these devices. LISP VPNs do not require this network connectivity to be in the "default" VRF, just that a a given LISP Site and its Mapping System be interconnected via a common VRF. LISP xTRs may have connectivity to each other via multiple distinct VRFs, as in the case where the LISP VPN is being used to create an Overlay with multiple MPLS-VPN Service Providers being used as the transport. Lewis & Schudel Expires August 18, 2014 [Page 4] Internet-Draft LISP Virtual Private Networks (VPNs) February 2014 4. LISP VPN Network Elements In general LISP VPNs are built from the network elements described in RFC 6830 and RFC 6832. This document describes a new way to use the Re-Encapsulating Tunnel Router in RFC 6830. This LISP VPNs are comprised of the following major network elements: CE routers acting as XTRs. Each customer site is deployed as one or more LISP xTR devices, and include single-home or multi-home designs, using any access media that provides Internet (IPv4 or IPv6) underlay connectivity. The site xTR configuration includes only the LISP EID space that the site is authoritative for and that it registers into the LISP Mapping System, and the RLOC addressing and ingress TE policy desired by the site. To reach other xTRs in the VPN, the xTR is only required to have simple, default routing to its next hop in the address family of the RLOC space. A virtualized LISP Mapping System. The Mapping system is configured with per customer and per site information, including the IID of the VPN(s), the EID Prefixes allowed to be registered, and the authentication key(s) of the LISP sites, and optionally the specific Locators that are allowed to be registered. Optionally, LISP Proxy Tunnel Routers. VPN services also need to be able to offer non-LISP to LISP interworking for Internet connectivity or for migration to the LISP VPN from other technologies. Optionally, LISP Re-encapsulating Tunnel Routers. If LISP VPN services require LISP to LISP interworking across disconnected locator spaces, for example to connect LISP sites attached solely to the IPv4 Internet with those that are solely attached to the IPv6 Internet, then the SP also deploys a number of Re-encapsulating Tunnel Routers to act as a gateway in the data plane that joins these disjointed locator networks. - IPSec infrastructure. (More text needed here) 5. Types of LISP VPNs In general, LISP VPNs can be instantiated either by Enterprises or by Service Providers. When deployed by Enterprises, the functions of LISP Tunnel Routers (xTRs) and the LISP Mapping System are enabled on Customer Edge (CE) devices use IP transport (either the internet or a private IP network (e.g. an MPLS-VPN), to create a common underlay for the LISP Overlay to use. When LISP is used a Service Provider, the xTR function may be enabled on either the Provider Edge or the Customer Edge devices, and the LISP Mapping system may be enabled on Lewis & Schudel Expires August 18, 2014 [Page 5] Internet-Draft LISP Virtual Private Networks (VPNs) February 2014 either one of these dedicated devices, or deployed elsewhere in the Service Provider network that shares IP connectivity with those data plane devices. 6. Enterprise VPNs When implementing VPNs via LISP, enterprises create an Overlay which may be independent of their network Service Provider. These VPNs allow for edge virtualization to take place over a common core, as well as allow for simplified multihoming, address family traversal, ip multicast over unicast services, and support for other LISP use cases like Mobility. 6.1. Internet based Enterprise LISP VPN Example Example of an Enterprise LISP VPN using internet underlay. (Example to be added) 6.2. MPLS-VPN based Enterprise LISP VPN Example Example of an Enterprise LISP VPN using MPLS underlay (Example to be added) 7. Service Provider LISP VPNs This section provides two examples of LISP VPNs being used by network Service Providers. These two are not exhaustive examples, and could themselves be combined by Serve Providers wanting to deploy a unified Overlay VPN with multiple types (Internet, Mobile, or Private) of Underlay networks. The first example is a CE based VPN using the Internet as an underlay. The second example is a CE based VPN using an MPLS-BGP VPN as an underlay. 7.1. MPLS VPNs and LISP CE based VPNs, from the SP perspective When LISP and MPLS VPNs are used in conjunction, there are some potential benefits to the services and scalability of the SPs MPLS VPN. The Service provider would see a reduction in the number of routes on their PEs. When LISP runs as an overlay, all customer prefixes which are typically injected into eBGP and imported into the customer VRF are no longer required. The LISP Mapping system is instead used to provide the level of indirection resolution for end to end connectivity. The only prefixes that are required in the PE VRFs are the point-to-point PE-CE link prefixes connecting all customer sites to the MPLS core. Lewis & Schudel Expires August 18, 2014 [Page 6] Internet-Draft LISP Virtual Private Networks (VPNs) February 2014 A reduction in the numbers of VRFs on their PEs. When LISP is run on the customer CE routers, sub-customer virtualization can be handled at the EID level and only a single MPLS VPN is required to segment traffic across the MPLS core. Thus, a global reduction in the number of PE VRFs can be achieved and allowing the SP to more efficiently operate the network. Consistant network layer services across MPLS NNI networks. LISP VPNs can be used to provide, as an example, address family traversal over the top of an NNI VPN that does not support IPv6. The SP would deploy a LISP Proxy Tunnel Router at their ASBR to the partner, and then customer IPv6 traffic would be encapsulated into IPv4 at the primary provider's edge into LISP and delivered to the IPv4 Locators of the partner provider's CE. 7.2. Service Provider Internet based LISP VPN Example This example describes an SP offering an Internet based VPN service offering using LISP VPNs. (Example to be added) 7.3. Service Provider MPLS-VPN based LISP VPN Example This example describes an MPLS VPN provider using LISP to create an Overlay to their MPLS VPN service offering. (Example to be added) 8. Security Considerations LISP [RFC 6830] incorporates many security mechanisms as part of the mapping database service when using control-plane procedures for obtaining EID-to-RLOC mappings. In general, data plane mechanisms are not of primary concern for general Internet use-case. However, when LISP VPNs are deployed, several additional security mechanisms and considerations must be addressed. Data plane traffic uses the LISP instance-id (IID) header field for segmentation. in-flight modifications of this IID value could result in violations to the tenant segmentation provided by the IID. Protection against this attack can be achieved by using the integrity protection mechanisms afforded by IPSec, with or without encryption depending on users' confidentiality requirements (see below). Re-encapsulating Tunnel Routers which bridge LISP-to-LISP domains that use disconnected locator spaces do have access to the LISP Mapping system and control plane components. Thus, RTRs should not need specialized security mechanism beyond those already in place for LISP VPNs. Lewis & Schudel Expires August 18, 2014 [Page 7] Internet-Draft LISP Virtual Private Networks (VPNs) February 2014 8.1. LISP VPNs and IPSec When LISP VPNs are created over the Public Internet, there may be a requirement for a VPN to provide data path confidentiality, integrity, origin authentication and anti-replay protection. When implementing IPSec in a LISP VPN, an operator has two broad choices. The operator can either apply the IPSec functions to the Routing Locator or the EID. When applying IPSec to the routing locator header, the IPSec encryption policy is applied to the routing locator header of LISP, the order of operation is (1) LISP e encapsulation, and then (2) IPSec encryption. In this case, the encryption policy must be designed to match LISP outer header source/destination attributes. It should be noted that this form of encapsulation provides confidentiality to the IID and the EID address space, that may be a security requirement for certain users. When applying IPSec to the EID header, the IPSec encryption policy is applied to the EID header of LISP, the order of operation is (1) IPSec encryption, and then (2) LISP encapsulation. In this case, the encryption policy must be designed to match EID header source/ destination attributes. Various key exchange mechanisms can be used to provision the tunnel endpoints with appropriate key material. The use of group key management mechanisms such as GDOI [ RFC6407] introduces a substantial simplification in terms of operation and use of encryption resources at the xTRs, given the role of a key server that "pushes" group key updates to the members of a VPN that share the same encryption key material. When GDOI encryption methods are used, positioning the Key Server infrastructure within its own EID network can provide substantial benefit. Architecturally, this allows the Key Server to be reachable via LISP from "all" CE devices (xTRs). This is advantageous from a security perspective, because the KS can be isolated from general routing, and is not reachable (and thus attackable) from any of the XTRs that constitute the VPN. 9. Acknowledgments Thanks goes to Dino Farinacci, Dave Meyer, Vince Fuller, Isidor Kouvolus, Jesper Skrivner, Fabio Maino, Vina Ermagan, and other members of the community who have been working on implementing and deploying LISP VPNs. Lewis & Schudel Expires August 18, 2014 [Page 8] Internet-Draft LISP Virtual Private Networks (VPNs) February 2014 10. IANA Considerations This document creates no new requirements on IANA namespaces [RFC5226]. 11. References 11.1. Normative References [I-D.ietf-lisp-ddt] Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP Delegated Database Tree", draft-ietf-lisp-ddt-01 (work in progress), March 2013. [I-D.ietf-lisp-lcaf] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format (LCAF)", draft-ietf-lisp-lcaf-04 (work in progress), January 2014. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, January 2013. [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites", RFC 6832, January 2013. [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation Protocol (LISP) Map-Server Interface", RFC 6833, January 2013. 11.2. Informative References [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006. [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap", RFC 6071, February 2011. [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of Interpretation", RFC 6407, October 2011. Lewis & Schudel Expires August 18, 2014 [Page 9] Internet-Draft LISP Virtual Private Networks (VPNs) February 2014 Authors' Addresses Darrel Lewis Cisco Systems, Inc. Email: darlewis@cisco.com Gregg Schudel Cisco Systems, Inc. Email: gschudel@cisco.com Lewis & Schudel Expires August 18, 2014 [Page 10]