Internet Engineering Task Force N. Shen Internet-Draft Cisco Systems Intended status: Experimental D. Farinacci Expires: January 21, 2015 lispers.net July 20, 2014 LISP Multi-Provider VPN Use-Cases draft-shen-lisp-multiprovider-vpn-00 Abstract This document describes how LISP sites communicate with each other in a VPN when there are multiple mapping database systems administered by multiple providers. The detail of VPN segmentation across mapping databases will be provided. 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 January 21, 2015. 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 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. Shen & Farinacci Expires January 21, 2015 [Page 1] Internet-Draft LISP Multi-Provider VPN Use-Cases July 2014 Table of Contents 1. Requirements Language . . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. LISP Mapping Database System . . . . . . . . . . . . . . . . 5 6. LISP Packet Flow . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Packet from Site1 to Site2 . . . . . . . . . . . . . . . 7 6.2. Packet from Site1 to Site3 . . . . . . . . . . . . . . . 7 6.3. Packet from Site1 to Site4 . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . 8 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 8 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Introduction This document describes how the Locator/Identifier Separation Protocol (LISP) [RFC6830] is used for Multi-Provider LISP VPN where the providers maintain their own local LISP mapping databases, and their own security and crypto mechanisms within the provider's LISP network. Each provider will have a number of Gateway Tunnel Routers (GTR) to send and receive LISP encapsulated packets to and from the other provider. Those Gateway Tunnel Routers behave the same as the Re-Encapsulating Tunnel Routers (RTRs) on traffic engineered LISP paths. Special security mechanisms between a pair of GTRs from two providers can be enforced, such as firewall and IPSec encryption can be applied over this Multi-Provider LISP overlay tunnel. This specification will define how an Explicit Locator Path (ELP) [LISP-LCAF] can be used for an ITR to encapsulate an Multi-Provider VPN packet to its own Gateway Tunnel Router (GTR), then to the peering provider's Gateway Tunnel Router (GTR), and finally to the peering provider's ETR. This specification will examine how each provider's GTR can interface with its own local LISP mapping database system and allow the instance-ID allocated to sites of one provider can be different from the instance-ID allocated to sites in the other providers. This allows policy and control to be contained within Shen & Farinacci Expires January 21, 2015 [Page 2] Internet-Draft LISP Multi-Provider VPN Use-Cases July 2014 each provider while allowing segmented connectivity across providers with secure LISP overlay. 3. Definition of Terms Mapping Service Provider (MSP): A LISP control-plane network provider which maintains its own LISP mapping database system. LISP Provider Network: Is a delivery network that administers its own mapping database acting as an MSP as well as managing a set of GTRs so multi-provider VPNs can be provided. Re-Encapsulating Tunnel Router (RTR): An RTR is a router that acts as an ETR (or PETR) by decapsulating packets where the destination address in the "outer" IP header is one of its own RLOCs. Then acts as an ITR (or PITR) by making a decision where to encapsulate the packet based on the next locator in the ELP towards the final destination ETR. Gateway Tunnel Router (GTR): An GTR is a router serves as a gateway re-encapsulating tunnel router (RTR) on the edge of the provider's LISP network. It services as an ETR for one LISP network for sending out the packet to the other provider, and as an ITR for the another LISP network when receiving a packet from the other provider. Re-Encapsulating Tunnels: Re-Encapsulating tunneling occurs when an RTR acts as an ETR and then an ITR on a given packet. As an ETR it removes a LISP header, then acts as an ITR to prepend another LISP header. Doing this allows a packet to be re- routed by the re-encapsulating router without adding the overhead of additional tunnel headers. Any references to tunnels in this specification refers to dynamic encapsulating tunnels and they are never statically configured. When using multiple mapping database systems, care must be taken to not create re-encapsulation loops through misconfiguration. 4. Overview A packet that is sourced by an EID which is destined for an EID travels across a core network based on the locators that ITR uses as the outer source and destination addresses towards a given ETR. If the Mapping Service Provider (MSP) the ITR uses to obtain the destination ETR's locator address can be a local mapping database or one deployed on globally on the Internet. Shen & Farinacci Expires January 21, 2015 [Page 3] Internet-Draft LISP Multi-Provider VPN Use-Cases July 2014 In a LISP Provider Network, the security mechanism is usually applied with the LISP tunneled packets within a single administrative organization. When two LISP Provider Networks need to communicate with each other, it is undesirable to have xTRs belong to two organizations to simply exchange the crypto keys. This specification proposes the solution to have the xTRs setup normal LISP overlay to the local GTR, and to have both GTRs of peering LISP Provider Networks to share common crypto keys if needed, and use the LISP re- encapsulation tunnels to have the Multi-Provider VPN packets traffic engineered among two providers without compromising the security aspect of the VPNs and simplify the Multi-Provider secure VPN management. (Mapping DB 1) (Mapping DB 2) Source site (-----------} {-----------) Destination Site ( LISP } { LISP ) +-------+ ( Provider1 } { Provider2 ) +---------+ | \ ( Network } { Network ) / | | seid / ITR ---(---> . --> } { --> . ----)---> ETR deid / | | siid / || ( | } { ^ ) ^^ \ diid | | / || ( | } { | ) || \ | +------+ || ( v } { | ) || +-------+ || ( GTR1 ======> GTR2 ) || || ( ^^ } { || ) || || (--------||-} {-||--------) || || || || || ================= ================== Secure LISP Tunnel Secure LISP Tunnel Typical Multi-Provider Secure VPN Data Path from ITR to ETR This diagram shows the packet flow from Provider1's network into the Provider2's network, and the other direction is logically the same. Although this diagram only showing one pair of GTRs between two providers, but in general, there can be a number of GTRs to be deployed on each side to either load share or for Multi-Provider VPN traffic engineering purposes. The policy agreed upon both providers decides which EIDs/IIDs to be exported to the other provider's mapping database. The ETR in Provider2 network registers the destination EID/IID into its own mapping system (Mapping DB 2); base on the Multi-Provider VPN policies, Provider2 network will provide the VPN mapping information along with the gateway Tunnel Router (GTR2) hop address to Provider1. Shen & Farinacci Expires January 21, 2015 [Page 4] Internet-Draft LISP Multi-Provider VPN Use-Cases July 2014 Provider1 will provision the Gateway Tunnel Router (GTR1) to register the Multi-Provider VPN LISP mapping into its own mapping database along with the ELP to list the GTR1 and GTR2 as hops. An AS Number [LISP-LCAF] can be part of the EID mapping entry to clearly define the mapping is an Multi-Provider LISP entry and belong to which MSP network. Other usages of this AS Number includes to detect the LISP mapping system looping and to facilitate multi- provider LISP VPN trouble-shooting. 5. LISP Mapping Database System For sites attached to LISP Provider Networks to communicate with one another in a VPN, we assume the EID space is unique, while the IID space is maintained individually by each LISP Provider Network and there is no coordination among providers on the LISP IIDs. The Multi-Provider VPN mapping entries are registered into its own mapping database by the GTRs. Take an example to illustrate the mapping database systems in the Multi-Provider LISP VPN. In this instance, we have 4 LISP sites that want to be part of the same VPN. There are 3 LISP Provider Networks each which manage their own LISP mapping database systems. Each provider allocates IIDs to their local LISP sites and there is no IID space coordination among the MSPs. Shen & Farinacci Expires January 21, 2015 [Page 5] Internet-Draft LISP Multi-Provider VPN Use-Cases July 2014 AS 65512 AS 65513 10.1.0.0/16 (-----------} {-----------) +-----+ ( LISP } { LISP ) 11.1.0.0/16 |Site1 \ ( ProviderA } { ProviderB ) +------+ | xTR ( Network } { Network ) / Site3 | |IID 1 / +-----(--- . --+ } { +-- . ----)---- xTR | +-----+ ( | } { | ) \ IID 2 | ( | } { | ) +------+ +-----+ ( | } { | ) |Site2 \ ( GTR-A GTR-B ) | xTR ---{--- . --+ }. . . .{ } |IID 1 / (-----------} . . {-----------) +-----+ . . 10.2.0.0/16 . {-- GTR-C --) 12.1.0.0/16 { | ) +------+ { | ) / Site4 | { . ----)---- xTR | { ) \ IID 1 | { LISP ) +------+ { ProviderC ) { Network } {-----------) AS 65514 Four Multi-Provider LISP VPN sites from three LISP Providers In above diagram, there are three LISP Provider Networks and four LISP sites to be provisioned within the same Multi-Provider VPN. MSP A has two LISP sites with the same IID, and with prefix 10.1.0.0/16 in Site1 and 10.2.0.0/16 in Site2, IID 1; The MSP B has one site with IID 2 with prefix 11.1.0.0/16 in Site3 and the MSP C has one site with IID 1 with prefix 12.1.0.0/16 in Site4. The GTR-A, GTR-B and GTR-C are the re-encapsulation tunnel routers to facilitate Multi- Provider VPN communication among the three MSPs. In ProviderA's mapping database (registered by GTR-A): (IID1, 11.1.0.0/16) -> ELP: [GTR-A, (IID2, GTR-B)] [IID1, 12.1.0.0/16) -> ELP: [GTR-A, (IID1, GTR-C)] In ProviderB's mapping database (registered by GTR-B): (IID2, 10.1.0.0/16) -> ELP: [GTR-B, (IID1, GTR-A)] [IID2, 10.2.0.0/16) -> ELP: [GTR-B, (IID1, GTR-A)] [IID2, 12.1.0.0/16) -> ELP: [GTR-B, (IID1, GTR-C)] Shen & Farinacci Expires January 21, 2015 [Page 6] Internet-Draft LISP Multi-Provider VPN Use-Cases July 2014 In ProviderC's mapping database (registered by GTR-C): (IID2, 10.1.0.0/16) -> ELP: [GTR-C, (IID1, GTR-A)] [IID2, 10.2.0.0/16) -> ELP: [GTR-C, (IID1, GTR-A)] [IID2, 11.1.0.0/16) -> ELP: [GTR-C, (IID2, GTR-B)] 6. LISP Packet Flow Using the same example as in the previous section, this section shows how the VPN packet flow operations either within the same LISP Provider Network sites as well as sites across LISP Provider Networks. 6.1. Packet from Site1 to Site2 This packet flow from 10.1 network to 10.2 network is within the same LISP Provider Network uses the traditional LISP-VPN mechanism [LISP-VPN]. Each ETR registers the site (IID1, eid-prefix) with ProviderA's mapping database. The xTR at Site1 sends the Map- Requests for(IID1, eid) to mapping database, and encapsulates the packet direct to the xTR at Site2. 6.2. Packet from Site1 to Site3 This is the Multi-Provider VPN case. The xTR at Site1 of 10.1 sends a Map-Request for (IID1, 11.1.1.1) to its local LISP mapping database. The returned result will be (IID1, 11.1.0.0/16) with ELP of [GTR-A, (IID2, GTR-B)]. The xTR at Site1 encapsulates to GTR-A with the IID1 in the LISP header. The GTR-A does a lookup on (IID1, 11.1.1.1) in its local mapping database (same as the xTRs) and it will use the second node in the ELP list. The GTR-A encapsulates the packet to GTR-B with IID2 in the LISP header. GTR-B decapsulates and looks up the (IID2, 11.1.1.1) in MSP B's local mapping database, and the RLOC of TR at Site3 is returned. The GTR-B encapsulates the packet to that RLOC. The xTR on Site3 decapsulates the packet and sends the packet to the host of 11.1.1.1. 6.3. Packet from Site1 to Site4 The operation is almost identical as the above sub-section except for that the IIDs between the two sites are the same. Thus there is no IID change during the packet hops across LISP Provider Networks. 7. Security Considerations This specification allows provider's VPN to communicate with each other in a secure fashion. The LISP tunnel from ITR to GTR1 and from GTR2 to ETR may use their own encryption mechanisms with each Shen & Farinacci Expires January 21, 2015 [Page 7] Internet-Draft LISP Multi-Provider VPN Use-Cases July 2014 provider. There can be cases one provider uses encryption for the LISP overlay while the other provider does not. Also whether or not to use the encryption over the tunnel between the GTR1 and GTR2 depends on the data sensitivity and the underlining network. The GTRs MAY choose to drop the packet if the local security policy does not match Multi-Provider VPN packet attributes. 8. IANA Considerations At this time there are no requests for IANA. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, January 2013. 9.2. Informative References [LISP-LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format", draft-ietf-lisp-lcaf-06 (work in progress), 2014. [LISP-VPN] Lewis, D. and G. Schudel, "LISP Virtual Private Networks (VPNs)", draft-ietf-lisp-vpns-00 (work in progress), 2014. [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. Appendix A. Acknowledgments TBD. Appendix B. Document Change Log Initial draft posted on July 2014. Shen & Farinacci Expires January 21, 2015 [Page 8] Internet-Draft LISP Multi-Provider VPN Use-Cases July 2014 Authors' Addresses Naiming Shen Cisco Systems San Jose, California USA Email: naiming@cisco.com Dino Farinacci lispers.net San Jose, California USA Phone: 408-718-2001 Email: farinacci@gmail.com Shen & Farinacci Expires January 21, 2015 [Page 9]