idnits 2.17.00 (12 Aug 2021) /tmp/idnits24052/draft-freitasbellagamba-lisp-hybrid-cloud-use-case-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 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. -- The document date (February 20, 2014) is 3012 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-25) exists of draft-ietf-lisp-sec-05 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LISP S. Freitas 3 Internet-Draft P. Bellagamba 4 Intended status: Informational Y. Hertoghs 5 Expires: August 24, 2014 Cisco Systems 6 February 20, 2014 8 Using LISP for Secure Hybrid Cloud Extension 9 draft-freitasbellagamba-lisp-hybrid-cloud-use-case-00 11 Abstract 13 The purpose of this draft is to document how the Locator/Identifier 14 Separation Protocol (LISP) can be used to enable a secure layer 15 3-based Hybrid Cloud, which is a composition of two or more distinct 16 cloud infrastructures that remain unique entities, but are bound 17 together to enable data and application portability. 19 It describes how LISP, in combination with IPsec, can be implemented 20 on a virtualized router that is deployed on a public cloud and on the 21 enterprise Data Center to enable cloud bursting, workload migration, 22 rapid provision of new applications in the cloud and disaster 23 recovery use cases. This draft covers how LISP allows virtual 24 machines (VMs) to be moved to the cloud without requiring changes to 25 the VMs IP and/or MAC-address. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119] 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on August 24, 2014. 50 Copyright Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. LISP-Enabled Secure Hybrid Cloud Diagram . . . . . . . . . . 4 69 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 4. Deploying LISP for Secure Hybrid Cloud Extension . . . . . . 6 71 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 7 72 5.1. Requirements on the underlying network . . . . . . . . . 7 73 5.2. Routing Considerations . . . . . . . . . . . . . . . . . 8 74 5.2.1. RLOC Advertisement . . . . . . . . . . . . . . . . . 8 75 5.2.2. LISP Stretched Subnets Advertisement . . . . . . . . 8 76 5.2.3. Traffic symmetry . . . . . . . . . . . . . . . . . . 8 77 5.3. No changes to Virtual or Physical Servers . . . . . . . . 8 78 5.4. Integration with other network services . . . . . . . . . 9 79 5.4.1. WAN acceleration . . . . . . . . . . . . . . . . . . 9 80 5.4.2. Firewalls . . . . . . . . . . . . . . . . . . . . . . 9 81 6. Communication (flow) examples . . . . . . . . . . . . . . . . 9 82 6.1. LISP-enabled Intra subnet communication between the 83 Enterprise and the Cloud . . . . . . . . . . . . . . . . 10 84 6.2. Communication from non-LISP Enabled Remote Sites to the 85 Enterprise and to the Cloud . . . . . . . . . . . . . . . 10 86 6.3. Communication from enterprise local LISP enabled subnet 87 to the Cloud LISP enabled subnet . . . . . . . . . . . . 11 88 6.4. Communication from enterprise local non-LISP enabled 89 subnet to the cloud LISP enabled subnet . . . . . . . . . 11 90 6.5. Communication from LISP Enabled Subnets to non-LISP 91 Enabled Subnets . . . . . . . . . . . . . . . . . . . . . 11 92 6.6. Communication between non-LISP enabled subnets . . . . . 11 93 6.7. Inter-Subnet communication between servers in the Cloud . 11 94 6.8. Communication from LISP Enabled Remote Sites to the 95 Enterprise and to the Cloud . . . . . . . . . . . . . . . 11 96 7. Performance and Scalability Considerations . . . . . . . . . 12 97 8. Management and Automation Considerations . . . . . . . . . . 12 98 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 99 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 100 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 101 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 102 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 103 12.2. Informative References . . . . . . . . . . . . . . . . . 13 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 106 1. Introduction 108 Many enterprises are pursuing an hybrid cloud computing strategy 109 within the next three years. Some of the use cases for Hybrid Cloud 110 are automated on-demand compute capacity (cloud bursting), split 111 application architectures, workload migration, rapid provision of new 112 applications in the cloud, and disaster recovery. 114 One common requirement from enterprises that wish to move to a Hybrid 115 Cloud is the ability to migrate the servers to the Cloud without 116 making any changes to them. In particular, server administrators 117 would like to avoid changing the server's IP address, subnet mask and 118 default gateway configurations. Also, enterprises would like to 119 adopt their own IP addressing scheme in the cloud and not been 120 limited by the addressing scheme of the cloud provider 121 infrastructure. 123 Locator/Identifier Separation Protocol (LISP) [RFC6830] can be used 124 to address those requirements. LISP separates location and identity, 125 thus allowing the enterprise to migrate or create new servers on the 126 cloud with the same IP address (server's identity), subnet mask, and 127 default gateway configurations then the one used inside their own 128 private data centers. LISP will update the EID-to-RLOC mapping of 129 the server to reflect the new location that, in this this example, is 130 moved to the cloud. No changes are required to the end systems, 131 users or servers, as the mapping between identity (server's IP 132 address) and location (enterprise DC or public cloud) is handled by 133 LISP, transparently to the users trying to reach the server. 135 LISP operates as an overlay, encapsulating the original packet from 136 the server into an UDP packet along with an additional outer IPvN 137 header, which holds the source and destination RLOCs. This allows 138 the server administrators to address the server in the cloud 139 according to their own IP addressing scheme, independent of the cloud 140 provider's addressing structure. 142 Another important property of LISP that is relevant to enable a 143 Secure Hybrid Cloud extension is that it enables IP portability to 144 the cloud by routing (layer 3) to the right location where the server 145 is. This provides total isolation of broadcast (Layer 2) domains 146 between the Enterprise and the Public Cloud. 148 Non-LISP enabled sites communicates to the servers moved to the cloud 149 via the enterprise data center (DC), where LISP is also deployed. 150 The solution proposed in this draft does not require LISP to be 151 enabled globally, but can be deployed by enabling LISP on just the 152 enterprise DC and the public cloud, with minimal impact on the 153 operations of both the DC and the cloud. 155 The optional deployment of LISP at individual user's site, provides 156 data path optimization, as the LISP-encapsulated traffic is routed 157 directly to the public cloud or the DC, depending on the server 158 location. 160 The LISP service is provided in the network, to any virtual machine, 161 independently of the hypervisor type used in the enterprise or the 162 public cloud provider. In fact, the hypervisor type used on the 163 enterprise and on the cloud infrastructure can be different. LISP 164 works with any VM in the public cloud without the need to modify the 165 VM configuration before migration. 167 LISP is deployed in virtualized routers in the cloud, and can be 168 deployed in either physical or virtual router in the enterprise DC. 169 The LISP-enabled router deployed within the enterprise DC does not 170 need to be the default gateway for the local servers (physical and 171 VMs). 173 The communication between the LISP-enabled router deployed within the 174 enterprise DC and within the public cloud SHOULD be secured by an 175 IPsec (Internet Protocol Security (IPsec)) tunnel. LISP encapsulated 176 traffic is protected with an IPsec tunnel, that can provide data 177 origin authentication, integrity protection, anti-reply protection 178 and confidentiality between the cloud and the enterprise. 180 The LISP-enabled Hybrid Cloud solution allows Intra-Subnet 181 communication regardless of the location of the server. This means 182 that communication between two servers located on the same subnet can 183 happen even when one server is located at the enterprise DC and 184 another server is located at the cloud. Inter-subnet communication 185 is also supported. 187 2. LISP-Enabled Secure Hybrid Cloud Diagram 189 This diagram illustrates the use case described in this draft. 191 Users' end-devices, typically located at non-LISP sites, are 192 connected to the enterprise WAN to access servers located either at 193 the enterprise DC or at the public cloud. 195 The enterprise DC hosts some of the servers, and has a PxTR deployed 196 attached to the subnets which host mobile servers. 198 The PxTR (PxTR-1) deployed within the enterprise DC is configured 199 with an IPsec tunnel towards the cloud's xTR (xTR-2). 201 Some servers have been moved to the cloud and an xTR is deployed 202 within the cloud to allow IP mobility between the enterprise DC and 203 the public cloud. 205 Enterprise DC Public Cloud 206 |---------------------| |--------------------| 207 | | .--..--. .--. .. | | 208 | | ( ' '.--. | | 209 | | .-.' Internet ' | | 210 | Server -------PxTR-1|===(=====IPsec Tunnel=====)===|== ====xTR-2 --VM 1 | 211 | A | | ( '-' | | 212 | | | (._.'--'._.'.-._.'.-._) |--------------------| 213 | Server -- Router 2 | 214 | B |\ .--..--. .--. .. 215 |---------------------| \ ( ' '.--. 216 .-.' L3 ' 217 ( Underlay ) 218 ( (WAN) '-' 219 ._.'--'._.'.-._.'.-._) 220 // 221 +---+---+ 222 .--.-.|Router1|'.-. 223 ( +---+---+ ) 224 ( __. 225 ..' Non-LISP Site ) 226 ( .'-' 227 '--'._.'. )\ 228 / '--' \ 229 '--------' '--------' 230 : End : : End : 231 : Device : : Device : 232 : 1 : : 2 : 233 '--------' '--------' 235 Figure 1 237 3. Terminology 239 Hybrid Cloud = A composition of two or more clouds (private, 240 community or public) that remain unique entities but are bound 241 together, offering the benefits of multiple deployment models. 243 LISP-enabled virtualized router = A virtual machine / appliance that 244 supports Routing and LISP functions, including Host Mobility. 246 The terms Ingress Tunnel Router (ITR) and Egress Tunnel Router (ETR) 247 are defined in [RFC6830] 249 The terms Proxy-ITR (PITR) and Proxy-ETR (PETR) are defined in 250 [RFC6832] 252 4. Deploying LISP for Secure Hybrid Cloud Extension 254 As represented in Figure 1, LISP routers are deployed at both the 255 enterprise DC (PxTR-1) and the public cloud (xTR-2). 257 At the enterprise DC, PxTR-1 does not need to be the default gateway 258 for the local servers (physical and VMs), but it MUST be directly 259 connected to the subnet where IP mobility will be provided. PxTR-1 260 MUST have an interface (physical or virtual sub-interface) connected 261 to the same subnet of the servers that are eligible for moving. This 262 allows the LISP router to detect the servers and to provide IP 263 mobility for this subnet. PxTR-1 can detect server's EIDs by various 264 way, including listening to ARPs that may be sent by the servers, for 265 example during boot up time, or by initiating traffic (ICMP requests) 266 to the servers. PxTR-1 MUST perform both proxy-itr and proxy-etr 267 functions, so that non- LISP enabled sites can reach the servers 268 moved to the cloud via the enterprise data center. Since PxTR-1 is 269 not the default gateway and is not on the regular data path (i.e. the 270 data path before there is any migration to the cloud), we refer to 271 the deployment of LISP in the enterprise DC as non-intrusive. To 272 redirect traffic from the enterprise data center to the cloud, the 273 PxTR utilizes Proxy-ARP for both Intra-Subnet and Inter-Subnet 274 communication. 276 The map-resolver (MR) and map-server (MS) functions can be enabled on 277 either PxTR-1 in the enterprise DC, or xTR-2 running within the 278 cloud. By enabling the MS/MR functions on one of the LISP routers 279 used to provide the hybrid cloud extension, the solution can be 280 deployed without adding other infrastructure at the cloud provider or 281 at the enterprise. 283 Within the cloud, the LISP-enabled virtualized router (xTR-2) MUST be 284 the default gateway for the Virtual Machines on those subnets that 285 require IP mobility. xTR-2 MUST be configured as a LISP ITR and ETR 286 node so that it can perform LISP encapsulation and de-encapsulation 287 of the packets coming from or going to the VMs located within the 288 cloud. Whenever a route to the destination is not found on xTR-2 289 routing table, xTR-2 must route that traffic via PxTR-1 (at the 290 enterprise DC). This function is useful to ensure that the traffic 291 flow is symmetric between non-LISP enabled sites and the cloud, and 292 MUST be used when there are firewalls or other stateful devices 293 located at the enterprise data center. xTR-2, being the default 294 gateway on the cloud, can detect servers' EIDs (Endpoint IDentifiers) 295 by listening to ARPs that may be sent by the server themselves. For 296 example during boot up time, or whenever the host needs to 297 communicate outside its subnet, because the host will ARP or send the 298 packet towards its default gateway xTR-2. To support Intra-subnet 299 communication between the cloud and the enterprise, xTR-2 attracts 300 traffic local to the cloud using proxy-arp. Whenever a VM on the 301 cloud ARPs for another IP located on the same subnet, the xTR will 302 respond to this ARP request (proxy-arp) unless it has detected that 303 the EID is local to the cloud . 305 5. Deployment Considerations 307 This section will cover what needs to be considered for a successful 308 deployment of a LISP-Enabled Secure Hybrid Cloud. 310 5.1. Requirements on the underlying network 312 The network at the enterprise DC and the network within the cloud 313 MUST allow the flooding of ARP packets within the subnets (i.e. VLAN, 314 or similar Layer 2 technologies) where IP mobility is required. The 315 reason for this requirement is that the xTR deployed within the cloud 316 or the PxTR deployed within the enterprise DC uses Proxy-ARP to 317 attract traffic to themselves to enable intra-subnet communication. 318 For example, when a server within the enterprise DC wants to 319 communicate with a server that is located within the cloud within the 320 same subnet, the server within the enterprise DC will ARP for the IP 321 address of the server that has moved to the cloud, in this case this 322 ARP request MUST be flooded on the broadcast domain (i.e. VLAN) such 323 that the LISP enabled router within the enterprise DC can respond to 324 this request with its own MAC (proxy-ARP) so that traffic to a server 325 moved to the cloud is then sent to the router located within the 326 enterprise DC which then performs LISP encapsulation and send the 327 traffic to the RLOC of the xTR located on the cloud. The same 328 process happens on the reverse direction when traffic is returned 329 from the cloud to the enterprise DC. 331 5.2. Routing Considerations 333 Deploying LISP for Secure Hybrid Cloud extension requires routing 334 considerations related with: (1) RLOC advertisement, (2) 335 advertisement of LISP enabled subnets to enable communication from 336 non-LISP sites, and (3) traffic symmetry. 338 5.2.1. RLOC Advertisement 340 The RLOCs used on the LISP enabled routers at the enterprise DC and 341 at the cloud MUST be reciprocally reachable via the IPsec tunnel that 342 connects the enterprise DC to the cloud. Those RLOCs SHOULD belong 343 to the private IP address space controlled by the enterprise. This 344 keeps the LISP deployment independent from both the cloud and the 345 enterprise infrastructures. Reachability information for those RLOCs 346 SHOULD be announced via the dynamic routing protocol of choice (IGP 347 or EGP) used on top of the IPsec tunnel connecting the enterprise to 348 the cloud. In alternative, if preferred, static routing COULD be 349 used as well. 351 5.2.2. LISP Stretched Subnets Advertisement 353 The subnets that are going to be stretched from the enterprise to the 354 cloud already exist within the enterprise data center. Those subnets 355 SHOULD already be advertised towards the enterprise WAN by the 356 existing routing protocol. This ensures that non-LISP remote sites 357 have a route to the LISP-enabled subnets via the enterprise data 358 center, where PxTR-1 attracts all the traffic directed to the subnets 359 that have been "stretched" to the cloud. 361 5.2.3. Traffic symmetry 363 For the cases where there are stateful devices (i.e. Firewalls, Load 364 balancers) located within the enterprise data center, traffic 365 symmetry is mandatory. To achieve that, as described in the LISP 366 Stretched Subnets Advertisement section, traffic is first attracted 367 to the enterprise and then tunneled to the cloud. On the return from 368 the cloud, the iTR MUST ensures that the traffic towards non-LISP 369 sites is first returned to the PeTR at the enterprise DC. 371 5.3. No changes to Virtual or Physical Servers 373 The network-based solution described in this draft, deployed with 374 LISP routers at the enterprise DC and at the cloud, does not require 375 changes to the servers (physical or virtual). Neither to those that 376 are eligible for mobility, nor to those that are not eligible for 377 mobility. 379 5.4. Integration with other network services 381 Although not the focus of this draft, it's important to consider that 382 enterprises may have some network services, like firewalls or WAN 383 acceleration devices that SHOULD be integrated as part of a holistic 384 Hybrid Cloud solution. LISP SHOULD not prevent the integration of 385 such services. 387 5.4.1. WAN acceleration 389 It may be desirable by an enterprise to accelerate traffic from the 390 enterprise DC to the cloud. WAN acceleration SHOULD happen before 391 the traffic is LISP and IPsec encapsulated. Defining all the options 392 for how the WAN acceleration device is inserted within the traffic 393 flow is outside the scope of this draft. However, one approach that 394 may be supported by the routers used on the enterprise and on the 395 cloud, is to have the LISP-enabled router redirect the traffic to the 396 WAN acceleration device(s) before the traffic is LISP and IPsec 397 encapsulated. 399 5.4.2. Firewalls 401 Within enterprise data centers, firewalls can be implemented at 402 several points of the network. The section "Traffic Symmetry" covers 403 how this solution works when there are firewalls located within the 404 enterprise data center. 406 At the cloud, the LISP-enabled virtualized router (xTR-2 in Figure 1) 407 is the default gateway for the servers VMs. In order to simplify the 408 deployment xTR-2 SHOULD also function as a firewall for the servers 409 located at the cloud. xTR-2 SHOULD secure communication between 410 subnets located at the cloud, and communication from the cloud to the 411 enterprise or the Internet. 413 6. Communication (flow) examples 415 This section will explain the detailed communication flows referring 416 to the diagram shown in Figure 1 418 PxTR-1, at the enterprise LISP site, is placed "on a stick", meaning 419 that it does not need to be the default gateway, and its interaction 420 with the local infrastructure is based on Proxy-ARP. PxTR-1 proxy- 421 replies on behalf of all non-local servers, inserting its own MAC 422 address for any EID that is not locally detected. PxTR-1 can be 423 either a physical router, or a virtual appliance. To be able to 424 manage not only locally sourced traffic, but also traffic coming from 425 the WAN, PxTR -1 is enabled as a PiTR. To be able to receive back 426 traffic from the cloud and deliver it to the WAN, PxTR-1 is also set- 427 up as a PeTR. In summary this node is a PxTR regarding its role for 428 handling LISP traffic. 430 At the Cloud LISP site, xTR-2 is a standard xTR for the locally 431 attached subnets. xTR-2 is the default gateway for the extended 432 subnets. xTR-2 is playing the role of eTR for the flow coming from 433 the enterprise site, and acts as an iTR for the flow going back to 434 the enterprise site. For any destination that is not known by the 435 xTR, the iTR encapsulates the traffic to the RLOC of the PeTR 436 specified, in this case the PeTR specified is PxTR-1 deployed at the 437 enterprise site. 439 6.1. LISP-enabled Intra subnet communication between the Enterprise and 440 the Cloud 442 Server A at the enterprise site sends an ARP request for the IP 443 address of VM-1 that it wants to communicate with, in order to find 444 the MAC address. PxTR-1, which is on a stick, replies with its own 445 MAC address (proxy-arp) as VM-1 is not detected locally. Traffic is 446 then sent to PxTR-1, after which it will issue a Map-Request to the 447 MS to find the location of VM-1. Finally it will encapsulate the 448 traffic towards xTR-2 at the Cloud site as VM-1 is identified in the 449 Map-server as belonging to that site. Traffic is then delivered 450 towards the cloud-attached subnet. 452 On the return path, the flow is handled in a symmetrical reverse way 453 compared to the inbound one just described above. 455 6.2. Communication from non-LISP Enabled Remote Sites to the Enterprise 456 and to the Cloud 458 Traffic from End Device 1 or 2, which are located at a remote site 459 that is not LISP enabled, is naturally attracted toward the 460 enterprise DC by IP routing. Whenever reaching the Enterprise site, 461 it is crossing the site's security and other services to reach the 462 local subnet that is supposed to host the destination server VM-1. 463 When the local default gateway sends an ARP to find VM-1, PxTR-1 464 responds to this ARP using the Proxy-ARP function as described above. 465 Traffic is sent LISP-encapsulated to the Cloud site where it is 466 delivered to VM-1. 468 xTR-2, which is the default gateway for VM-1, handles the return 469 traffic that is sent by VM-1. As this traffic is not intended to a 470 LISP site, (i.e.it is targeted to End Device 1 or 2), xTR-2 sends the 471 traffic to the PeTR configured on it (PxTR-1). 473 6.3. Communication from enterprise local LISP enabled subnet to the 474 Cloud LISP enabled subnet 476 Traffic originated from a LISP enabled subnet (from Server B), 477 intended to another LISP enabled subnet extended to the cloud (to 478 VM-1) will first reach the local gateway (Router 2) and then will be 479 routed locally to the extended subnet where PxTR-1 will respond to 480 the ARP issued by Router 2. On the return path, the traffic will hit 481 xTR-2, which is the default gateway, and then be routed by LISP 482 towards the Enterprise site. 484 6.4. Communication from enterprise local non-LISP enabled subnet to the 485 cloud LISP enabled subnet 487 In this case, traffic will first reach the default gateway (Router 488 2), from which it will follow the same path than the traffic 489 originated from a remote site. The PxTR function will be used in 490 both directions. 492 6.5. Communication from LISP Enabled Subnets to non-LISP Enabled 493 Subnets 495 When traffic is sourced from a LISP enabled subnet at the enterprise 496 site (Server A or B) towards a non-LISP enabled subnet at the cloud 497 site, standard routing will take effect. 499 For the return traffic, xTR-2 will send it back to PxTR-1 as LISP 500 encapsulated traffic. 502 6.6. Communication between non-LISP enabled subnets 504 In this case, the traffic will be routed using plain IP routing and 505 LISP is not involved. 507 The return traffic also uses plain IP routing, and LISP is not 508 involved. 510 6.7. Inter-Subnet communication between servers in the Cloud 512 In the cloud itself, xTR-2 can locally route traffic between local 513 subnets as it is the cloud site default gateway. 515 6.8. Communication from LISP Enabled Remote Sites to the Enterprise and 516 to the Cloud 518 All above considerations of traffic flows are assuming that the only 519 LISP enabled devices are PxTR-1 and xTR-2. 521 If one remote site need to access directly a non-LISP enabled 522 resource in the cloud, meaning a subnet that is strictly local to the 523 cloud, then pure routing can be used. 525 If a remote site needs path optimization to directly reach the 526 servers that are part of a LISP stretched subnet at the cloud site, 527 LISP can be enabled on this remote site. An xTR deployed on this 528 remote site would consult the map-server to receive the correct 529 location of the server. 531 7. Performance and Scalability Considerations 533 TBD. 535 8. Management and Automation Considerations 537 TBD. 539 9. Acknowledgements 541 The authors would like to thanks Michael Nolan and Fabio Maino for 542 their review, and Fabio Maino for his encouragement to develop this 543 draft. 545 10. IANA Considerations 547 This memo includes no request to IANA. 549 11. Security Considerations 551 The connection from the enterprise to the public cloud provider is 552 usually done over the internet, although it may happen via a 553 dedicated private circuit on some cases. This draft strongly 554 suggests that an IPsec tunnel SHOULD be established between the 555 enterprise and the cloud provider and that the data sent within this 556 tunnel SHOULD be encrypted. 558 The IPsec tunnel SHOULD be established between the LISP-enabled 559 routers located on the enterprise and on the cloud. By establishing 560 the IPsec tunnels and ensuring that the RLOC from the routers are 561 reachable via those IPsec tunnels then the LISP encapsulated traffic 562 between the enterprise and the cloud will also be encrypted as it 563 will flow over the IPsec tunnels. 565 Also see [I-D.ietf-lisp-sec] for a list of security considerations 566 for LISP. 568 12. References 570 12.1. Normative References 572 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 573 Requirement Levels", BCP 14, RFC 2119, March 1997. 575 12.2. Informative References 577 [I-D.ietf-lisp-sec] 578 Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D., 579 and O. Bonaventure, "LISP-Security (LISP-SEC)", draft- 580 ietf-lisp-sec-05 (work in progress), October 2013. 582 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 583 Locator/ID Separation Protocol (LISP)", RFC 6830, January 584 2013. 586 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 587 "Interworking between Locator/ID Separation Protocol 588 (LISP) and Non-LISP Sites", RFC 6832, January 2013. 590 Authors' Addresses 592 Santiago Freitas 593 Cisco Systems 594 New Square Park, Bedfont Lakes 595 Feltham TW14 8HA 596 UK 598 Phone: +44 20 8824 8429 599 Email: safreita@cisco.com 601 Patrice Bellagamba 602 Cisco Systems 603 L'Atlantis, 11, Rue Camille Desmoulins 604 Issy Les Moulineaux 92782 605 France 607 Phone: +33 15 804 6235 608 Email: pbellaga@cisco.com 609 Yves Hertoghs 610 Cisco Systems 611 De Kleetlaan 6a 612 Diegem 1831 613 BE 615 Email: yhertogh@cisco.com