Internet DRAFT - draft-shen-lisp-multiprovider-vpn
draft-shen-lisp-multiprovider-vpn
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]
