Internet DRAFT - draft-freitas-bellagamba-lisp-hybrid-cloud-usecase

draft-freitas-bellagamba-lisp-hybrid-cloud-usecase







LISP                                                          S. Freitas
Internet-Draft                                             P. Bellagamba
Intended status: Informational                               Y. Hertoghs
Expires: August 16, 2014                                   Cisco Systems
                                                       February 12, 2014


              Using LISP for Secure Hybrid Cloud Extension
         draft-freitas-bellagamba-lisp-hybrid-cloud-usecase-00

Abstract

   The purpose of this draft is to document how the Locator/Identifier
   Separation Protocol (LISP) can be used to enable a secure layer
   3-based Hybrid Cloud, which is a composition of two or more distinct
   cloud infrastructures that remain unique entities, but are bound
   together to enable data and application portability.

   It describes how LISP, in combination with IPsec, can be implemented
   on a virtualized router that is deployed on a public cloud and on the
   enterprise Data Center to enable cloud bursting, workload migration,
   rapid provision of new applications in the cloud and disaster
   recovery use cases.  This draft covers how LISP allows virtual
   machines (VMs) to be moved to the cloud without requiring changes to
   the VMs IP and/or MAC-address.

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]

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 16, 2014.



Freitas, et al.          Expires August 16, 2014                [Page 1]

Internet-Draft         LISP Hybrid Cloud Use Case          February 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
   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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  LISP-Enabled Secure Hybrid Cloud Diagram  . . . . . . . . . .   4
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Deploying LISP for Secure Hybrid Cloud Extension  . . . . . .   6
   5.  Deployment Considerations . . . . . . . . . . . . . . . . . .   7
     5.1.  Requirements on the underlying network  . . . . . . . . .   7
     5.2.  Routing Considerations  . . . . . . . . . . . . . . . . .   8
       5.2.1.  RLOC Advertisement  . . . . . . . . . . . . . . . . .   8
       5.2.2.  LISP Stretched Subnets Advertisement  . . . . . . . .   8
       5.2.3.  Traffic symmetry  . . . . . . . . . . . . . . . . . .   8
     5.3.  No changes to Virtual or Physical Servers . . . . . . . .   8
     5.4.  Integration with other network services . . . . . . . . .   9
       5.4.1.  WAN acceleration  . . . . . . . . . . . . . . . . . .   9
       5.4.2.  Firewalls . . . . . . . . . . . . . . . . . . . . . .   9
   6.  Communication (flow) examples . . . . . . . . . . . . . . . .   9
     6.1.  LISP-enabled Intra subnet communication between the
           Enterprise and the Cloud  . . . . . . . . . . . . . . . .  10
     6.2.  Communication from non-LISP Enabled Remote Sites to the
           Enterprise and to the Cloud . . . . . . . . . . . . . . .  10
     6.3.  Communication from enterprise local LISP enabled subnet
           to the Cloud LISP enabled subnet  . . . . . . . . . . . .  11
     6.4.  Communication from enterprise local non-LISP enabled
           subnet to the cloud LISP enabled subnet . . . . . . . . .  11
     6.5.  Communication from LISP Enabled Subnets to non-LISP
           Enabled Subnets . . . . . . . . . . . . . . . . . . . . .  11
     6.6.  Communication between non-LISP enabled subnets  . . . . .  11
     6.7.  Inter-Subnet communication between servers in the Cloud .  11
     6.8.  Communication from LISP Enabled Remote Sites to the
           Enterprise and to the Cloud . . . . . . . . . . . . . . .  11
   7.  Performance and Scalability Considerations  . . . . . . . . .  12
   8.  Management and Automation Considerations  . . . . . . . . . .  12



Freitas, et al.          Expires August 16, 2014                [Page 2]

Internet-Draft         LISP Hybrid Cloud Use Case          February 2014


   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  12
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  12
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  13
     12.2.  Informative References . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   Many enterprises are pursuing an hybrid cloud computing strategy
   within the next three years.  Some of the use cases for Hybrid Cloud
   are automated on-demand compute capacity (cloud bursting), split
   application architectures, workload migration, rapid provision of new
   applications in the cloud, and disaster recovery.

   One common requirement from enterprises that wish to move to a Hybrid
   Cloud is the ability to migrate the servers to the Cloud without
   making any changes to them.  In particular, server administrators
   would like to avoid changing the server's IP address, subnet mask and
   default gateway configurations.  Also, enterprises would like to
   adopt their own IP addressing scheme in the cloud and not been
   limited by the addressing scheme of the cloud provider
   infrastructure.

   Locator/Identifier Separation Protocol (LISP) [RFC6830] can be used
   to address those requirements.  LISP separates location and identity,
   thus allowing the enterprise to migrate or create new servers on the
   cloud with the same IP address (server's identity), subnet mask, and
   default gateway configurations then the one used inside their own
   private data centers.  LISP will update the EID-to-RLOC mapping of
   the server to reflect the new location that, in this this example, is
   moved to the cloud.  No changes are required to the end systems,
   users or servers, as the mapping between identity (server's IP
   address) and location (enterprise DC or public cloud) is handled by
   LISP, transparently to the users trying to reach the server.

   LISP operates as an overlay, encapsulating the original packet from
   the server into an UDP packet along with an additional outer IPvN
   header, which holds the source and destination RLOCs.  This allows
   the server administrators to address the server in the cloud
   according to their own IP addressing scheme, independent of the cloud
   provider's addressing structure.

   Another important property of LISP that is relevant to enable a
   Secure Hybrid Cloud extension is that it enables IP portability to
   the cloud by routing (layer 3) to the right location where the server




Freitas, et al.          Expires August 16, 2014                [Page 3]

Internet-Draft         LISP Hybrid Cloud Use Case          February 2014


   is.  This provides total isolation of broadcast (Layer 2) domains
   between the Enterprise and the Public Cloud.

   Non-LISP enabled sites communicates to the servers moved to the cloud
   via the enterprise data center (DC), where LISP is also deployed.
   The solution proposed in this draft does not require LISP to be
   enabled globally, but can be deployed by enabling LISP on just the
   enterprise DC and the public cloud, with minimal impact on the
   operations of both the DC and the cloud.

   The optional deployment of LISP at individual user's site, provides
   data path optimization, as the LISP-encapsulated traffic is routed
   directly to the public cloud or the DC, depending on the server
   location.

   The LISP service is provided in the network, to any virtual machine,
   independently of the hypervisor type used in the enterprise or the
   public cloud provider.  In fact, the hypervisor type used on the
   enterprise and on the cloud infrastructure can be different.  LISP
   works with any VM in the public cloud without the need to modify the
   VM configuration before migration.

   LISP is deployed in virtualized routers in the cloud, and can be
   deployed in either physical or virtual router in the enterprise DC.
   The LISP-enabled router deployed within the enterprise DC does not
   need to be the default gateway for the local servers (physical and
   VMs).

   The communication between the LISP-enabled router deployed within the
   enterprise DC and within the public cloud SHOULD be secured by an
   IPsec (Internet Protocol Security (IPsec)) tunnel.  LISP encapsulated
   traffic is protected with an IPsec tunnel, that can provide data
   origin authentication, integrity protection, anti-reply protection
   and confidentiality between the cloud and the enterprise.

   The LISP-enabled Hybrid Cloud solution allows Intra-Subnet
   communication regardless of the location of the server.  This means
   that communication between two servers located on the same subnet can
   happen even when one server is located at the enterprise DC and
   another server is located at the cloud.  Inter-subnet communication
   is also supported.

2.  LISP-Enabled Secure Hybrid Cloud Diagram

   This diagram illustrates the use case described in this draft.






Freitas, et al.          Expires August 16, 2014                [Page 4]

Internet-Draft         LISP Hybrid Cloud Use Case          February 2014


   Users' end-devices, typically located at non-LISP sites, are
   connected to the enterprise WAN to access servers located either at
   the enterprise DC or at the public cloud.

   The enterprise DC hosts some of the servers, and has a PxTR deployed
   attached to the subnets which host mobile servers.

   The PxTR (PxTR-1) deployed within the enterprise DC is configured
   with an IPsec tunnel towards the cloud's xTR (xTR-2).

   Some servers have been moved to the cloud and an xTR is deployed
   within the cloud to allow IP mobility between the enterprise DC and
   the public cloud.

     Enterprise DC                                         Public Cloud
 |---------------------|                              |--------------------|
 |                     |       .--..--. .--. ..       |                    |
 |                     |     (    '           '.--.   |                    |
 |                     |   .-.'   Internet        '   |                    |
 | Server -------PxTR-1|===(=====IPsec Tunnel=====)===|== ====xTR-2 --VM 1 |
 |   A        |        |   (                      '-' |                    |
 |            |        |    (._.'--'._.'.-._.'.-._)   |--------------------|
 | Server -- Router 2  |
 |   B                 |\     .--..--. .--. ..
 |---------------------| \  (    '           '.--.
                         .-.'        L3          '
                        (         Underlay       )
                         (          (WAN)      '-'
                          ._.'--'._.'.-._.'.-._)
                            //
                        +---+---+
                  .--.-.|Router1|'.-.
                 (      +---+---+   )
                (                __.
              ..'  Non-LISP Site )
             (             .'-'
               '--'._.'.    )\
                /       '--'  \
            '--------'   '--------'
            :  End   :   :  End   :
            : Device :   : Device :
            :   1    :   :   2    :
            '--------'   '--------'


                                 Figure 1





Freitas, et al.          Expires August 16, 2014                [Page 5]

Internet-Draft         LISP Hybrid Cloud Use Case          February 2014


3.  Terminology

   Hybrid Cloud = A composition of two or more clouds (private,
   community or public) that remain unique entities but are bound
   together, offering the benefits of multiple deployment models.

   LISP-enabled virtualized router = A virtual machine / appliance that
   supports Routing and LISP functions, including Host Mobility.

   The terms Ingress Tunnel Router (ITR) and Egress Tunnel Router (ETR)
   are defined in [RFC6830]

   The terms Proxy-ITR (PITR) and Proxy-ETR (PETR) are defined in
   [RFC6832]

4.  Deploying LISP for Secure Hybrid Cloud Extension

   As represented in Figure 1, LISP routers are deployed at both the
   enterprise DC (PxTR-1) and the public cloud (xTR-2).

   At the enterprise DC, PxTR-1 does not need to be the default gateway
   for the local servers (physical and VMs), but it MUST be directly
   connected to the subnet where IP mobility will be provided.  PxTR-1
   MUST have an interface (physical or virtual sub-interface) connected
   to the same subnet of the servers that are eligible for moving.  This
   allows the LISP router to detect the servers and to provide IP
   mobility for this subnet.  PxTR-1 can detect server's EIDs by various
   way, including listening to ARPs that may be sent by the servers, for
   example during boot up time, or by initiating traffic (ICMP requests)
   to the servers.  PxTR-1 MUST perform both proxy-itr and proxy-etr
   functions, so that non- LISP enabled sites can reach the servers
   moved to the cloud via the enterprise data center.  Since PxTR-1 is
   not the default gateway and is not on the regular data path (i.e. the
   data path before there is any migration to the cloud), we refer to
   the deployment of LISP in the enterprise DC as non-intrusive.  To
   redirect traffic from the enterprise data center to the cloud, the
   PxTR utilizes Proxy-ARP for both Intra-Subnet and Inter-Subnet
   communication.

   The map-resolver (MR) and map-server (MS) functions can be enabled on
   either PxTR-1 in the enterprise DC, or xTR-2 running within the
   cloud.  By enabling the MS/MR functions on one of the LISP routers
   used to provide the hybrid cloud extension, the solution can be
   deployed without adding other infrastructure at the cloud provider or
   at the enterprise.

   Within the cloud, the LISP-enabled virtualized router (xTR-2) MUST be
   the default gateway for the Virtual Machines on those subnets that



Freitas, et al.          Expires August 16, 2014                [Page 6]

Internet-Draft         LISP Hybrid Cloud Use Case          February 2014


   require IP mobility. xTR-2 MUST be configured as a LISP ITR and ETR
   node so that it can perform LISP encapsulation and de-encapsulation
   of the packets coming from or going to the VMs located within the
   cloud.  Whenever a route to the destination is not found on xTR-2
   routing table, xTR-2 must route that traffic via PxTR-1 (at the
   enterprise DC).  This function is useful to ensure that the traffic
   flow is symmetric between non-LISP enabled sites and the cloud, and
   MUST be used when there are firewalls or other stateful devices
   located at the enterprise data center. xTR-2, being the default
   gateway on the cloud, can detect servers' EIDs (Endpoint IDentifiers)
   by listening to ARPs that may be sent by the server themselves.  For
   example during boot up time, or whenever the host needs to
   communicate outside its subnet, because the host will ARP or send the
   packet towards its default gateway xTR-2.  To support Intra-subnet
   communication between the cloud and the enterprise, xTR-2 attracts
   traffic local to the cloud using proxy-arp.  Whenever a VM on the
   cloud ARPs for another IP located on the same subnet, the xTR will
   respond to this ARP request (proxy-arp) unless it has detected that
   the EID is local to the cloud .

5.  Deployment Considerations

   This section will cover what needs to be considered for a successful
   deployment of a LISP-Enabled Secure Hybrid Cloud.

5.1.  Requirements on the underlying network

   The network at the enterprise DC and the network within the cloud
   MUST allow the flooding of ARP packets within the subnets (i.e. VLAN,
   or similar Layer 2 technologies) where IP mobility is required.  The
   reason for this requirement is that the xTR deployed within the cloud
   or the PxTR deployed within the enterprise DC uses Proxy-ARP to
   attract traffic to themselves to enable intra-subnet communication.
   For example, when a server within the enterprise DC wants to
   communicate with a server that is located within the cloud within the
   same subnet, the server within the enterprise DC will ARP for the IP
   address of the server that has moved to the cloud, in this case this
   ARP request MUST be flooded on the broadcast domain (i.e. VLAN) such
   that the LISP enabled router within the enterprise DC can respond to
   this request with its own MAC (proxy-ARP) so that traffic to a server
   moved to the cloud is then sent to the router located within the
   enterprise DC which then performs LISP encapsulation and send the
   traffic to the RLOC of the xTR located on the cloud.  The same
   process happens on the reverse direction when traffic is returned
   from the cloud to the enterprise DC.






Freitas, et al.          Expires August 16, 2014                [Page 7]

Internet-Draft         LISP Hybrid Cloud Use Case          February 2014


5.2.  Routing Considerations

   Deploying LISP for Secure Hybrid Cloud extension requires routing
   considerations related with: (1) RLOC advertisement, (2)
   advertisement of LISP enabled subnets to enable communication from
   non-LISP sites, and (3) traffic symmetry.

5.2.1.  RLOC Advertisement

   The RLOCs used on the LISP enabled routers at the enterprise DC and
   at the cloud MUST be reciprocally reachable via the IPsec tunnel that
   connects the enterprise DC to the cloud.  Those RLOCs SHOULD belong
   to the private IP address space controlled by the enterprise.  This
   keeps the LISP deployment independent from both the cloud and the
   enterprise infrastructures.  Reachability information for those RLOCs
   SHOULD be announced via the dynamic routing protocol of choice (IGP
   or EGP) used on top of the IPsec tunnel connecting the enterprise to
   the cloud.  In alternative, if preferred, static routing COULD be
   used as well.

5.2.2.  LISP Stretched Subnets Advertisement

   The subnets that are going to be stretched from the enterprise to the
   cloud already exist within the enterprise data center.  Those subnets
   SHOULD already be advertised towards the enterprise WAN by the
   existing routing protocol.  This ensures that non-LISP remote sites
   have a route to the LISP-enabled subnets via the enterprise data
   center, where PxTR-1 attracts all the traffic directed to the subnets
   that have been "stretched" to the cloud.

5.2.3.  Traffic symmetry

   For the cases where there are stateful devices (i.e. Firewalls, Load
   balancers) located within the enterprise data center, traffic
   symmetry is mandatory.  To achieve that, as described in the LISP
   Stretched Subnets Advertisement section, traffic is first attracted
   to the enterprise and then tunneled to the cloud.  On the return from
   the cloud, the iTR MUST ensures that the traffic towards non-LISP
   sites is first returned to the PeTR at the enterprise DC.

5.3.  No changes to Virtual or Physical Servers

   The network-based solution described in this draft, deployed with
   LISP routers at the enterprise DC and at the cloud, does not require
   changes to the servers (physical or virtual).  Neither to those that
   are eligible for mobility, nor to those that are not eligible for
   mobility.




Freitas, et al.          Expires August 16, 2014                [Page 8]

Internet-Draft         LISP Hybrid Cloud Use Case          February 2014


5.4.  Integration with other network services

   Although not the focus of this draft, it's important to consider that
   enterprises may have some network services, like firewalls or WAN
   acceleration devices that SHOULD be integrated as part of a holistic
   Hybrid Cloud solution.  LISP SHOULD not prevent the integration of
   such services.

5.4.1.  WAN acceleration

   It may be desirable by an enterprise to accelerate traffic from the
   enterprise DC to the cloud.  WAN acceleration SHOULD happen before
   the traffic is LISP and IPsec encapsulated.  Defining all the options
   for how the WAN acceleration device is inserted within the traffic
   flow is outside the scope of this draft.  However, one approach that
   may be supported by the routers used on the enterprise and on the
   cloud, is to have the LISP-enabled router redirect the traffic to the
   WAN acceleration device(s) before the traffic is LISP and IPsec
   encapsulated.

5.4.2.  Firewalls

   Within enterprise data centers, firewalls can be implemented at
   several points of the network.  The section "Traffic Symmetry" covers
   how this solution works when there are firewalls located within the
   enterprise data center.

   At the cloud, the LISP-enabled virtualized router (xTR-2 in Figure 1)
   is the default gateway for the servers VMs.  In order to simplify the
   deployment xTR-2 SHOULD also function as a firewall for the servers
   located at the cloud. xTR-2 SHOULD secure communication between
   subnets located at the cloud, and communication from the cloud to the
   enterprise or the Internet.

6.  Communication (flow) examples

   This section will explain the detailed communication flows referring
   to the diagram shown in Figure 1

   PxTR-1, at the enterprise LISP site, is placed "on a stick", meaning
   that it does not need to be the default gateway, and its interaction
   with the local infrastructure is based on Proxy-ARP.  PxTR-1 proxy-
   replies on behalf of all non-local servers, inserting its own MAC
   address for any EID that is not locally detected.  PxTR-1 can be
   either a physical router, or a virtual appliance.  To be able to
   manage not only locally sourced traffic, but also traffic coming from
   the WAN, PxTR -1 is enabled as a PiTR.  To be able to receive back
   traffic from the cloud and deliver it to the WAN, PxTR-1 is also set-



Freitas, et al.          Expires August 16, 2014                [Page 9]

Internet-Draft         LISP Hybrid Cloud Use Case          February 2014


   up as a PeTR.  In summary this node is a PxTR regarding its role for
   handling LISP traffic.

   At the Cloud LISP site, xTR-2 is a standard xTR for the locally
   attached subnets. xTR-2 is the default gateway for the extended
   subnets. xTR-2 is playing the role of eTR for the flow coming from
   the enterprise site, and acts as an iTR for the flow going back to
   the enterprise site.  For any destination that is not known by the
   xTR, the iTR encapsulates the traffic to the RLOC of the PeTR
   specified, in this case the PeTR specified is PxTR-1 deployed at the
   enterprise site.

6.1.  LISP-enabled Intra subnet communication between the Enterprise and
      the Cloud

   Server A at the enterprise site sends an ARP request for the IP
   address of VM-1 that it wants to communicate with, in order to find
   the MAC address.  PxTR-1, which is on a stick, replies with its own
   MAC address (proxy-arp) as VM-1 is not detected locally.  Traffic is
   then sent to PxTR-1, after which it will issue a Map-Request to the
   MS to find the location of VM-1.  Finally it will encapsulate the
   traffic towards xTR-2 at the Cloud site as VM-1 is identified in the
   Map-server as belonging to that site.  Traffic is then delivered
   towards the cloud-attached subnet.

   On the return path, the flow is handled in a symmetrical reverse way
   compared to the inbound one just described above.

6.2.  Communication from non-LISP Enabled Remote Sites to the Enterprise
      and to the Cloud

   Traffic from End Device 1 or 2, which are located at a remote site
   that is not LISP enabled, is naturally attracted toward the
   enterprise DC by IP routing.  Whenever reaching the Enterprise site,
   it is crossing the site's security and other services to reach the
   local subnet that is supposed to host the destination server VM-1.
   When the local default gateway sends an ARP to find VM-1, PxTR-1
   responds to this ARP using the Proxy-ARP function as described above.
   Traffic is sent LISP-encapsulated to the Cloud site where it is
   delivered to VM-1.

   xTR-2, which is the default gateway for VM-1, handles the return
   traffic that is sent by VM-1.  As this traffic is not intended to a
   LISP site, (i.e.it is targeted to End Device 1 or 2), xTR-2 sends the
   traffic to the PeTR configured on it (PxTR-1).






Freitas, et al.          Expires August 16, 2014               [Page 10]

Internet-Draft         LISP Hybrid Cloud Use Case          February 2014


6.3.  Communication from enterprise local LISP enabled subnet to the
      Cloud LISP enabled subnet

   Traffic originated from a LISP enabled subnet (from Server B),
   intended to another LISP enabled subnet extended to the cloud (to
   VM-1) will first reach the local gateway (Router 2) and then will be
   routed locally to the extended subnet where PxTR-1 will respond to
   the ARP issued by Router 2.  On the return path, the traffic will hit
   xTR-2, which is the default gateway, and then be routed by LISP
   towards the Enterprise site.

6.4.  Communication from enterprise local non-LISP enabled subnet to the
      cloud LISP enabled subnet

   In this case, traffic will first reach the default gateway (Router
   2), from which it will follow the same path than the traffic
   originated from a remote site.  The PxTR function will be used in
   both directions.

6.5.  Communication from LISP Enabled Subnets to non-LISP Enabled
      Subnets

   When traffic is sourced from a LISP enabled subnet at the enterprise
   site (Server A or B) towards a non-LISP enabled subnet at the cloud
   site, standard routing will take effect.

   For the return traffic, xTR-2 will send it back to PxTR-1 as LISP
   encapsulated traffic.

6.6.  Communication between non-LISP enabled subnets

   In this case, the traffic will be routed using plain IP routing and
   LISP is not involved.

   The return traffic also uses plain IP routing, and LISP is not
   involved.

6.7.  Inter-Subnet communication between servers in the Cloud

   In the cloud itself, xTR-2 can locally route traffic between local
   subnets as it is the cloud site default gateway.

6.8.  Communication from LISP Enabled Remote Sites to the Enterprise and
      to the Cloud

   All above considerations of traffic flows are assuming that the only
   LISP enabled devices are PxTR-1 and xTR-2.




Freitas, et al.          Expires August 16, 2014               [Page 11]

Internet-Draft         LISP Hybrid Cloud Use Case          February 2014


   If one remote site need to access directly a non-LISP enabled
   resource in the cloud, meaning a subnet that is strictly local to the
   cloud, then pure routing can be used.

   If a remote site needs path optimization to directly reach the
   servers that are part of a LISP stretched subnet at the cloud site,
   LISP can be enabled on this remote site.  An xTR deployed on this
   remote site would consult the map-server to receive the correct
   location of the server.

7.  Performance and Scalability Considerations

   TBD.

8.  Management and Automation Considerations

   TBD.

9.  Acknowledgements

   The authors would like to thanks Michael Nolan and Fabio Maino for
   their review, and Fabio Maino for his encouragement to develop this
   draft.

10.  IANA Considerations

   This memo includes no request to IANA.

11.  Security Considerations

   The connection from the enterprise to the public cloud provider is
   usually done over the internet, although it may happen via a
   dedicated private circuit on some cases.  This draft strongly
   suggests that an IPsec tunnel SHOULD be established between the
   enterprise and the cloud provider and that the data sent within this
   tunnel SHOULD be encrypted.

   The IPsec tunnel SHOULD be established between the LISP-enabled
   routers located on the enterprise and on the cloud.  By establishing
   the IPsec tunnels and ensuring that the RLOC from the routers are
   reachable via those IPsec tunnels then the LISP encapsulated traffic
   between the enterprise and the cloud will also be encrypted as it
   will flow over the IPsec tunnels.

   Also see [I-D.ietf-lisp-sec] for a list of security considerations
   for LISP.





Freitas, et al.          Expires August 16, 2014               [Page 12]

Internet-Draft         LISP Hybrid Cloud Use Case          February 2014


12.  References

12.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

12.2.  Informative References

   [I-D.ietf-lisp-sec]
              Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D.,
              and O. Bonaventure, "LISP-Security (LISP-SEC)", draft-
              ietf-lisp-sec-05 (work in progress), October 2013.

   [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.

Authors' Addresses

   Santiago Freitas
   Cisco Systems
   New Square Park, Bedfont Lakes
   Feltham  TW14 8HA
   UK

   Phone: +44 20 8824 8429
   Email: safreita@cisco.com


   Patrice Bellagamba
   Cisco Systems
   L'Atlantis, 11, Rue Camille Desmoulins
   Issy Les Moulineaux  92782
   France

   Phone: +33 15 804 6235
   Email: pbellaga@cisco.com









Freitas, et al.          Expires August 16, 2014               [Page 13]

Internet-Draft         LISP Hybrid Cloud Use Case          February 2014


   Yves Hertoghs
   Cisco Systems
   De Kleetlaan 6a
   Diegem  1831
   BE

   Email: yhertogh@cisco.com












































Freitas, et al.          Expires August 16, 2014               [Page 14]