[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/