idnits 2.17.1 draft-ietf-lisp-impact-05.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 20, 2015) is 3079 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-lisp-threats-13 ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) ** Obsolete normative reference: RFC 6833 (Obsoleted by RFC 9301) ** Obsolete normative reference: RFC 6834 (Obsoleted by RFC 9302) == Outdated reference: A later version (-04) exists of draft-farinacci-lisp-signal-free-multicast-03 == Outdated reference: A later version (-12) exists of draft-farinacci-lisp-te-09 == Outdated reference: A later version (-10) exists of draft-ietf-lisp-crypto-02 == Outdated reference: A later version (-09) exists of draft-ietf-lisp-ddt-03 == Outdated reference: A later version (-22) exists of draft-ietf-lisp-lcaf-11 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-09 == Outdated reference: A later version (-16) exists of draft-meyer-lisp-mn-13 Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Saucez 3 Internet-Draft INRIA 4 Intended status: Informational L. Iannone 5 Expires: May 23, 2016 Telecom ParisTech 6 A. Cabellos 7 F. Coras 8 Technical University of 9 Catalonia 10 November 20, 2015 12 LISP Impact 13 draft-ietf-lisp-impact-05.txt 15 Abstract 17 The Locator/Identifier Separation Protocol (LISP) aims at improving 18 the Internet routing scalability properties by leveraging on three 19 principles: address role separation, encapsulation, and mapping. In 20 this document, based on implementation work, deployment experiences, 21 and theoretical studies, we discuss the impact that the deployment of 22 LISP can have on both the routing infrastructure and the end-user. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 23, 2016. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. LISP in a nutshell . . . . . . . . . . . . . . . . . . . . . . 3 60 3. LISP for scaling the Internet Routing Architecture . . . . . . 4 61 4. Beyond scaling the Internet Routing Architecture . . . . . . . 6 62 4.1. Traffic engineering . . . . . . . . . . . . . . . . . . . 7 63 4.2. LISP for IPv6 Co-existence . . . . . . . . . . . . . . . . 8 64 4.3. Inter-domain multicast . . . . . . . . . . . . . . . . . . 9 65 5. Impact of LISP on operations and business models . . . . . . . 9 66 5.1. Impact on non-LISP traffic and sites . . . . . . . . . . . 10 67 5.2. Impact on LISP traffic and sites . . . . . . . . . . . . . 10 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 70 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 73 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 76 1. Introduction 78 The Locator/Identifier Separation Protocol (LISP) relies on three 79 principles to improve the scalability properties of Internet routing: 80 address role separation, encapsulation, and mapping. When invented, 81 LISP was targeted at solving the Internet routing scaling problem 82 ([RFC4984]). There have now been years of implementations and 83 experiments examining the impact and open questions of using LISP to 84 improve inter-domain routing scalability. Experience has shown that 85 because LISP utilizes mapping and encapsulation technologies, it can 86 be deployed and used for purposes that go beyond routing scalability. 87 For example, LISP provides a mean for a LISP site to precisely 88 control its inter-domain outgoing and incoming traffic, with the 89 possibility to apply different policies to different domains 90 exchanging traffic with it. LISP can also be used to ease the 91 transition from IPv4 to IPv6 as it allows the transport of IPv4 over 92 IPv6 or IPv6 over IPv4. Furthermore, LISP also supports inter-domain 93 multicast. 95 Leveraging on implementation and deployment experience, as well as 96 research work, this document describes, at a high level, the impacts 97 and open questions still seen in LISP. This information is 98 particularly useful for considering future approaches and to support 99 further experimentation to clarify some large open questions (e.g. 100 around the operations). LISP utilizes a tunnel-based data plane and 101 a distributed control plane. LISP requires some new functionalities, 102 such as reachability mechanisms. Being more than a simple 103 encapsulation technology and as a new technology, until even more 104 deployment experience is gained, some open questions, related to LISP 105 deployment and operations, remain. As an encapsulation technology, 106 there may be concerns on reduced Maximum Transmission Unit (MTU) size 107 in some deployments. An important impact of LISP is on network 108 operations related to resiliency and troubleshooting. As LISP relies 109 on cached mappings and on encapsulation, resiliency during failures 110 and troubleshooting may be more difficult. Also, the use of 111 encapsulation may make failure detection and recovery slower and it 112 will require more coordination than with a single, non-encapsulated, 113 routing domain solution. 115 2. LISP in a nutshell 117 The Locator/Identifier Separation Protocol (LISP) relies on three 118 principles: address role separation, encapsulation, and mapping. 120 The address space is divided into two sets that have different 121 semantic meanings: the Routing Locators (RLOCs) and the Endpoint 122 Identifiers (EIDs). RLOCs are addresses typically assigned from the 123 Provider Aggregatable (PA) address space. The EIDs are attributed to 124 the nodes in the edge networks, by a block of contiguous addresses, 125 which are typically Provider Independent (PI). To limit the 126 scalability problem, LISP only requires the PA routes towards the 127 RLOCs to be announced in the Provider infrastructure. Whereas, for 128 non-LISP deployments the EIDs need as well to be propagated. 130 LISP routers are used at the boundary between the EID and the RLOC 131 spaces. Routers used to exit the EID space (towards the Provider 132 domain) are called Ingress Tunnel Router (ITRs) and those used to 133 enter the EID space (from the Provider domain) are called the Egress 134 Tunnel Routers (ETRs). When a host sends a packet to a remote 135 destination, it sends it as in the non-LISP Internet. The packet 136 arrives at the border of its site at an ITR. Because EIDs are not 137 routable on the Internet, the packet is encapsulated with the source 138 address set to the ITR RLOC and the destination address set to the 139 ETR RLOC. The encapsulated packet is then forwarded in the Provider 140 domain until it reaches the selected ETR. The ETR de-encapsulates 141 the packet and forwards it to its final destination. The acronym xTR 142 for Ingress/Egress tunnel router is used for a router playing these 143 two roles. 145 The correspondence between EIDs and RLOCs is given by the mappings. 146 When an ITR needs to find ETR RLOCs that serve an EID, it queries a 147 mapping system. With the LISP Canonical Address Format (LCAF) 148 [I-D.ietf-lisp-lcaf], LISP is not restricted to the Internet Protocol 149 for the EID addresses. With LCAF, any address type can be used as 150 EID (the address is only the key for the mapping lookup). LISP can 151 transport, for example, Ethernet frames over the Internet. 153 An introduction to LISP can be found in [RFC7215]. The LISP 154 specifications are given in [RFC6830], [RFC6833], 155 [I-D.ietf-lisp-ddt], [RFC6836], [RFC6832], [RFC6834]. 157 3. LISP for scaling the Internet Routing Architecture 159 The original goal of LISP was to improve the scalability properties 160 of the Internet routing architecture. LISP utilizes traffic 161 engineering and stub AS prefixes (not announced anymore in the DFZ), 162 so that routing tables are smaller and more stable (i.e., they 163 experience less churn). Furthermore, at the edge of the network, 164 information necessary to forward packets (i.e., the mappings) is 165 obtained on demand using a pull model (whereas the current Internet 166 BGP model uses a push model). Therefore, the scalability of edge 167 networks is less dependent on the Internet's size and more related to 168 its traffic matrix. This scaling improvement has been proven by 169 several studies (see below). The research studies cited hereafter 170 are based on the following assumptions: 172 o EID-to-RLOC mappings follow the same prefix size as the current 173 BGP routing infrastructure (current PI addresses only); 175 o EIDs are used only at the stub ASes, not in the transit ASes; 177 o the RLOCs of an EID prefix are deployed at the edge between the 178 stubs owning the EID prefix and the providers, allocating the 179 RLOCs in a Provider Aggregetable (PA) mode. 181 The above assumptions are inline with [RFC7215] and current LISP 182 deployments. It is recognized these assumptions may change in the 183 longer term. [KIF13] and [CDLC] explore different EDI prefix space 184 sizes, and still show results that are consistent and equivalent to 185 the above assumptions. 187 Quoitin et al. [QIdLB07] show that the separation between locator 188 and identifier roles at the network level improves the routing 189 scalability by reducing the Routing Information Base (RIB) size (up 190 to one order of magnitude) and increases path diversity and thus the 191 traffic engineering capabilities. [IB07] and [KIF13] show, based on 192 real Internet traffic traces, that the number of mapping entries that 193 must be handled by an ITR of a network with up to 20,000 users is 194 limited to few tens of thousands; that the signaling traffic (i.e., 195 Map-Request/Map-Reply packets) is in the same order of magnitude 196 similar to DNS requests/reply traffic; and that the encapsulation 197 overhead, while not negligible, is very limited (in the order of few 198 percentage points of the total traffic volume). 200 Previous studies consider the case of a timer-based cache eviction 201 policy (i.e., mappings are deleted from the cache upon timeout), 202 while [CDLC] has a more general approach based on the Least Recently 203 Used (LRU) eviction policy, proposing an analytic model for the EID- 204 to-RLOC cache size when prefix-level traffic has a stationary 205 generating process. The model shows that miss rate can be accurately 206 predicted from the EID-to-RLOC cache size and a small set of easily 207 measurable traffic parameters. The model was validated using four 208 one-day-long packet traces collected at egress points of a campus 209 network and an academic exchange point considering EID-prefixes as 210 being of the same size as BGP prefixes. Consequently, operators can 211 provision the EID-to-RLOC cache of their ITRs according to the miss 212 rate they want to achieve for their given traffic. 214 Results in [CDLC] indicate that for a given target miss-ratio, the 215 size of the cache depends only on the parameters of the popularity 216 distribution, being independent of the number of users (the size of 217 the LISP site) and the number of destinations (the size of the EID- 218 prefix space). Assuming that the popularity distribution remains 219 constant, this means that as the number of users and the number of 220 destinations grow, the cache size needed to obtain a given miss rate 221 remains constant O(1). 223 LISP usually populates its EID-to-RLOC cache in a pull mode which 224 means that mappings are retrieved on demand by the ITR. The main 225 advantage of this mode is that the EID-to-RLOC cache size only 226 depends on the traffic characteristics at the ITR and is independent 227 of the size of the Provider domain. This benefit comes at the cost 228 of some delay to transmit the packets that do not hit an entry in the 229 cache (for which a mapping has to be learned). This delay is bound 230 by the time necessary to retrieve the mapping from the mapping 231 system. Moreover, similarly to a push model (e.g., BGP), the pull 232 model induces signaling messages that correspond to the retrieval of 233 mappings upon cache miss. The difference being that the signaling 234 load only depends on the traffic at the ITR and is not triggered by 235 external events such as in BGP. [CDLC] shows that the miss rate is a 236 function of the EID-to-RLOC cache size and traffic generation process 237 and [CDLC], [SDIB08], and [SDIB08] show from traffic traces that, in 238 practice, the cache miss rate, and thus the signaling rate, remain 239 low. 241 4. Beyond scaling the Internet Routing Architecture 243 LISP is more than just a scalability solution, it is also a tool to 244 provide both incoming and outgoing traffic engineering ([S11], 245 [I-D.farinacci-lisp-te]), it can be used as an IPv6 transition at the 246 routing level, and it can be used for inter-domain multicast 247 ([RFC6831], [I-D.coras-lisp-re]). Also, LISP has been identified for 248 use to support devices' Internet mobility ([I-D.meyer-lisp-mn]) and 249 to support virtual machines' mobility in data centers and multi- 250 tenant VPNs. These last two uses are not discussed further as they 251 are out of the scope of the current LISP Working Group charter. 253 A key advantage of the LISP architecture is that it facilitates 254 routing in environments where there is little to no correlation 255 between network endpoints and topological location. In service 256 provider environments, this application is needed in a range of 257 consumer use cases which require an inline anchor to deliver a 258 service to a subscribers. Inline anchors provide one of three types 259 of capabilities: 261 o enable mobility of subscriber end points 263 o enable chaining of middle-box functions and services 264 o enable seamless scale-out of functions 266 Without LISP, the approach commonly used by operators is to aggregate 267 service anchors in custom built boxes. This limits deployments as 268 end-points only can move on the same mobile gateway, functions can be 269 chained only if traffic traverses the same wire or the same DPI box, 270 and capacity can scale out only if traffic fans out to/from a 271 specific load balancer. 273 With LISP, service providers are able to distribute, virtualize, and 274 instantiate subscriber-service anchors anywhere in the network. 275 Typical use cases for virtualized inline anchors and network 276 functions include: Distributed Mobility and Virtualized Evolved 277 Packet Core (vEPC), Virtualized Customer Premise Equipment or vCPE, 278 where functionality previously anchored at a customer premises is now 279 dynamically allocated in-network, Virtualized SGi LAN, Virtual IMS 280 and Virtual SBC, etc. 282 ConteXtream ([ConteXtream]) has been deploying map-assisted overlay 283 networks since 2006, first with a proprietary solution, then evolving 284 to standard LISP. The solution has been deployed in production in 285 three tier-1 operators spanning hundreds of millions of subscribers. 286 Map assisted overlays had been primarily used to map subscriber flows 287 to services resources dynamically based on profiles and conditions. 288 Specifically it has been used to map mobile subscribers to value- 289 added/optimization services, broadband subscribes to telephony 290 services, and fixed-mobile subscribers to BNG (Broadband Network 291 Gateway) functions and Internet access services. The LISP map- 292 assisted overlay architecture is used to optimally resolve subscriber 293 to services to functions to instances to IP overlay aggregation 294 locations, just in time, per flow. 296 4.1. Traffic engineering 298 In the current (non-LISP)routing infrastructure, addresses used by 299 stub networks are globally routable and the routing system 300 distributes the routes to reach these stubs. With LISP, the EID 301 prefixes of a LISP site are not routable in the DFZ, mappings are 302 needed in order to determine the list of LISP routers to contact to 303 forward packets. This difference is significant for two reasons. 304 First, packets are not forwarded to a site but to a specific router. 305 Second, a site can control the entry points for its traffic by 306 controlling its mappings. 308 For traffic engineering purposes, a mapping associates an EID prefix 309 to a list of RLOCs. Each RLOC is annotated with a priority and a 310 weight. When there are several RLOCs, the ITR selects the one with 311 the highest priority and sends the encapsulated packet to this RLOC. 313 If several RLOCs with the highest priority exist, then the traffic is 314 balanced proportionally to their weight among such RLOCs. Traffic 315 engineering in LISP thus allows the mapping owner to have a fine- 316 grained control on the primary and backup path for its incoming and 317 outgoing packets use. In addition, it can share the load among its 318 links. An example of the use of such a feature is described by 319 Saucez et al. [SDIB08], showing how to use LISP to direct different 320 types of traffic on different links having different capacity. 322 Traffic engineering in LISP goes one step further. As every Map- 323 Request contains the Source EID Address of the packet that caused a 324 cache miss and triggered the Map-Request. It is thus possible for a 325 mapping owner to differentiate the answer (Map-Reply) it gives to 326 Map-Requests based on the requester. This functionality is not 327 available today with BGP because a domain cannot control exactly the 328 routes that will be received by domains that are not in the direct 329 neighborhood. 331 4.2. LISP for IPv6 Co-existence 333 The LISP encapsulation mechanism is designed to support any 334 combination of locators and identifiers address family. It is then 335 possible to bind IPv6 EIDs with IPv4 RLOCs and vice-versa. This 336 allows transporting IPv6 packets over an IPv4 network (or IPv4 337 packets over an IPv6 network), making LISP a valuable mechanism to 338 ease the transition to IPv6. 340 An example is the case of the network infrastructure of a datacenter 341 being IPv4-only while dual-stack front-end load balancers are used. 342 In this scenario, LISP can be used to provide IPv6 access to servers 343 even though the network and the servers only support IPv4. Assuming 344 that the datacenter's ISP offers IPv6 connectivity, the datacenter 345 only needs to deploy one (or more) xTR(s) at its border with the ISP 346 and one (or more) xTR(s) directly connected to the load balancers. 347 The xTR(s) at the ISP's border tunnels IPv6 packets over IPv4 to the 348 xTR(s) directly attached to the load balancer. The load balancer's 349 xTR de-encapsulates the packets and forwards them to the load 350 balancer, which act as proxies, translating each IPv6 packet into an 351 IPv4. IPv4 packets are then sent to the appropriate servers. 352 Similarly, when the server's response arrives at the load balancer, 353 the packet is translated back into an IPv6 packet and forwarded to 354 its xTR(s), which in turn will tunnel it back, over the IPv4-only 355 infrastructure, to an xTR connected to the ISP. The packet is then 356 de-encapsulated and forwarded to the ISP natively in IPv6. 358 4.3. Inter-domain multicast 360 LISP has native support for multicast [RFC6831]. From the data-plane 361 perspective, at a multicast enabled xTR, an EID sourced multicast 362 packet is encapsulated in another multicast packet and subsequently 363 forwarded in a RLOC-level distribution tree. Therefore, xTRs must 364 participate in both EID and RLOC level distribution trees. Control- 365 plane wise, since group addresses have no topological significance 366 they need not to be mapped. It is worth noting that, to properly 367 function, LISP-Multicast requires that inter-domain multicast be 368 available. 370 LISP Replication Engineering (RE) ([I-D.coras-lisp-re], [CDM12]) 371 leverage LISP messages ([I-D.farinacci-lisp-mr-signaling]) for 372 multicast state distribution to construct xTR based inter-domain 373 multicast distribution trees when inter-domain multicast support is 374 not available. Simulations of three different management strategies 375 for low latency content delivery show that such overlays can support 376 thousands of member xTRs, hundreds of thousands of end-hosts and 377 deliver content at latencies close to unicast ones ([CDM12]). It was 378 also observed that high client churn has a limited impact on 379 performance and management overhead. 381 Similarly to LISP-RE, Signal-Free LISP Multicast 382 ([I-D.farinacci-lisp-signal-free-multicast]) can be used when the 383 core network does not provide multicast support. But instead of 384 using signaling to build inter-domain multicast trees, signal-free 385 exclusively leverages the map-server for multicast state storage and 386 distribution. As a result, the source ITR generally performs head- 387 end replication but it might be also used to emulate LISP-RE 388 distribution trees. 390 5. Impact of LISP on operations and business models 392 Numerous implementation efforts ([IOSNXOS], [OpenLISP], [LISPmob], 393 [LISPClick], [LISPcp], and [LISPfritz]) have been made to assess the 394 specifications and, additionally, interoperability tests ([Was09]) 395 have been successful. A world-wide large deployment in the 396 international lisp4.net testbed, which is currently composed of nodes 397 running at least three different implementations, will allow us to 398 learn further operational aspects related to LISP. 400 The following sections distinguish the impact of LISP on LISP sites 401 from the impact on non-LISP sites. 403 5.1. Impact on non-LISP traffic and sites 405 LISP has no impact on traffic which has neither LISP origin nor LISP 406 destination. However, LISP can have a significant impact on traffic 407 between a LISP site and a non-LISP site. Traffic between a non-LISP 408 site and a LISP site are subject to the same issues as those observed 409 for LISP-to-LISP traffic but also have issues specific to the 410 transition mechanism that allows the LISP site to exchange packets 411 with a non-LISP site ([RFC6832], [RFC7215]). 413 The transition requires setup of proxy tunnel routers (PxTRs). 414 Proxies cause what is referred to as path stretch (i.e., a 415 lengthening of the path compared to the topological shortest-path) 416 and make troubleshooting harder. There are still questions related 417 to PxTRs that need to be answered: 419 o Where to deploy PxTRs? The placement in the topology has an 420 important impact on the path stretch. 422 o How many PxTRs? The number of PxTR has a direct impact on the 423 load and the impact of the failure of a PxTR on the traffic. 425 o What part of the EID space? Will all the PxTRs be proxies for the 426 whole EID space or will it be segmented between different PxTRs? 428 o Who operates PxTRs? An important question to answer is related to 429 the entities that will deploy PxTRs, how will they manage their 430 additional CAPEX/OPEX costs associated with PxTRs? How will the 431 traffic be carried with respect to security and privacy? 433 A PxTR will also normally advertise in BGP the EID prefix for which 434 they are proxy. However, if proxies are managed by different 435 entities, they will belong to different ASes. In this case, we need 436 to be sure that this will not cause MOAS (Multi-Origin AS) issues 437 that could negatively influence routing. Moreover, it is important 438 to ensure that the way EID prefixes will be de-aggregated by the 439 proxies will remain reasonable so as not to contribute to BGP 440 scalability issues. 442 5.2. Impact on LISP traffic and sites 444 LISP is a protocol based on the map-and-encap paradigm which has the 445 positive impacts that we have summarized in the above sections. 446 However, LISP also has impacts on operations: 448 MTU issue: as LISP uses encapsulation, the MTU is reduced, this has 449 implications on potentially all of the traffic. However, in 450 practice, on the lisp4.net network, no major issue due to the 451 MTU has been observed. This is probably due to the fact that 452 current end-host stacks are well designed to deal with the 453 problem of MTU. 455 Resiliency issue: the advantage of flexibility and control offered 456 by the Locator/ID separation comes at the cost of increasing 457 the complexity of the reachability detection. Indeed, 458 identifiers are not directly routable and have to be mapped to 459 locators but a locator may be unreachable while others are 460 still reachable. This is an important problem for any tunnel- 461 based solution. In the current Internet, packets are forwarded 462 independently of the border router of the network meaning that, 463 in case of the failure of a border router, another one can be 464 used. With LISP, the destination RLOC specifically designates 465 one particular ETR, hence if this ETR fails, the traffic is 466 dropped, even though other ETRs are available for the 467 destination site. Another resiliency issue is linked to the 468 fact that mappings are learned on demand. When an ITR fails, 469 all its traffic is redirected to other ITRs that might not have 470 the mappings requested by the redirected traffic. Existing 471 studies ([SKI12], [SD12]) show, based on measurements and 472 traffic traces, that failure of ITRs and RLOC are infrequent 473 but that when such failure happens, a critical number of 474 packets can be dropped. Unfortunately, the current techniques 475 for LISP resiliency, based on monitoring or probing are not 476 rapid enough (failure recovery on the order of a few seconds). 477 To tackle this issue [I-D.bonaventure-lisp-preserve] and 478 [I-D.saucez-lisp-itr-graceful] propose techniques based on 479 local failure detection and recovery. 481 Middle boxes/filters: because of increasingly common use of 482 encryption as a response to pervasive monitoring ([RFC7258]), 483 with LISP providing the option to encrypt traffic between xTRs 484 ([I-D.ietf-lisp-crypto]), middle boxes are increasingly likely 485 to be unable to understand encapsulated traffic, which can 486 cause them to drop legitimate packets. In addition, LISP 487 allows triangular or even rectangular routing, so it is 488 difficult to maintain a correct state even if the middle box 489 understands LISP. Finally, filtering may also have problems 490 because they may think only one host is generating the traffic 491 (the ITR), as long as it is not de-encapsulated. To deal with 492 LISP encapsulation, LISP aware firewalls that inspect inner 493 LISP packets are proposed [lispfirewall]. 495 Troubleshooting/debugging: the major issue which LISP 496 experimentation has shown is the difficulty of troubleshooting. 497 When there is a problem in the network, it is hard to pin-point 498 the reason as the operator only has a partial view of the 499 network. The operator can see what is in its EID-to-RLOC 500 cache/database, and can try to obtain what is potentially 501 elsewhere by querying the Map Resolvers, but the knowledge 502 remains partial. On top of that, ICMP packets only carry the 503 first few tens of bytes of the original packet, which means 504 that when an ICMP arrives at the ITR, it might not contain 505 enough information to allow correct troubleshooting. 506 Deployment in the beta network has shown that LISP+ALT 507 ([RFC6836]) was not easy to maintain and control ([CCR13]), 508 which explains the migration to LISP-DDT ([I-D.ietf-lisp-ddt]), 509 based on a massively distributed and hierarchical approach 510 ([CCR13]). 512 Business/Operational-related: Iannone et al. [IL10] have shown that 513 there are economical incentives to migrate to LISP, however, 514 some questions remain. For example, how will the EIDs be 515 allocated to allow aggregation and hence scalability of the 516 mapping system? Who will operate the mapping system 517 infrastructure and for what benefits? What if several 518 operators run different mapping systems? How will they 519 interoperate or share mapping information? 521 Reachability: The overhead related to RLOC reachability mechanisms 522 is not known. 524 6. IANA Considerations 526 This document makes no request to the IANA. 528 7. Security Considerations 530 A thorough security and threats analysis of the LISP protocol is 531 carried out in details in [I-D.ietf-lisp-threats]. Like for other 532 Internet technologies, also for LISP most of threats can be mitigated 533 using Best Current Practice, meaning with careful deployment an 534 configuration (e.g., filter) and also by activating only features 535 that are really necessary in the deployment and verifying all the 536 information obtained from third parties. Unless gleaning (Section 6 537 of [RFC6836] and Section3.1 of [I-D.ietf-lisp-threats]) features are 538 used, the LISP data-plane shows the same level of security as other 539 IP-over-IP technologies. From a security perspective, the control- 540 plane remains the critical part of the LISP architecture. To 541 mitigate the threats on the mapping system, authentication should be 542 used for all control plane messages. The current specification 543 ([RFC6836], [I-D.ietf-lisp-sec]) defines security mechanisms which 544 can reduce threats in open network environments. The LISP 545 specification defines a generic authentication data field for control 546 plane messages ([RFC6836]) which could be used for a general 547 authentication mechanisms for the LISP control-plane while staying 548 backward compatible. 550 8. Acknowledgments 552 Thanks to Deborah Brungard, Ben Campbell, Spencer Dawkins, Stephen 553 Farrel, Kathleen Moriarty, Hilarie Orman, and Wassim Haddad for their 554 thorough reviews, comments, and suggestions. 556 The people that contributed to this document are Alia Atlas, Sharon 557 Barkai, Vince Fuller, Joel Halpern, Terry Manderson, Gregg Schudel, 558 Ron Bonica, and Ross Callon. 560 The work of Luigi Iannone has been partially supported by the ANR-13- 561 INFR-0009 LISP-Lab Project (www.lisp-lab.org). 563 9. References 565 9.1. Normative References 567 [I-D.ietf-lisp-threats] 568 Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats 569 Analysis", draft-ietf-lisp-threats-13 (work in progress), 570 August 2015. 572 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 573 Locator/ID Separation Protocol (LISP)", RFC 6830, 574 DOI 10.17487/RFC6830, January 2013, 575 . 577 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 578 Locator/ID Separation Protocol (LISP) for Multicast 579 Environments", RFC 6831, DOI 10.17487/RFC6831, 580 January 2013, . 582 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 583 "Interworking between Locator/ID Separation Protocol 584 (LISP) and Non-LISP Sites", RFC 6832, DOI 10.17487/ 585 RFC6832, January 2013, 586 . 588 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 589 Protocol (LISP) Map-Server Interface", RFC 6833, 590 DOI 10.17487/RFC6833, January 2013, 591 . 593 [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID 594 Separation Protocol (LISP) Map-Versioning", RFC 6834, 595 DOI 10.17487/RFC6834, January 2013, 596 . 598 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 599 "Locator/ID Separation Protocol Alternative Logical 600 Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, 601 January 2013, . 603 [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- 604 Pascual, J., and D. Lewis, "Locator/Identifier Separation 605 Protocol (LISP) Network Element Deployment 606 Considerations", RFC 7215, DOI 10.17487/RFC7215, 607 April 2014, . 609 9.2. Informative References 611 [CCR13] Saucez, D., Iannone, L., and B. Donnet, "A First 612 Measurement Look at the Deployment and Evolution of the 613 Locator/ID Separation Protocol", ACM SIGCOMM Computer 614 Communication Review. Vol. 43, N. 2., April 2013. 616 [CDLC] Coras, F., Domingo, J., Lewis, D., and A. Cabellos, "An 617 Analytical Model for Loc/ID Mappings Caches", IEEE 618 Transactions on Networking, 2014. 620 [CDM12] Coras, F., Domingo-Pascual, J., Maino, F., Farinacci, D., 621 and A. Cabellos-Aparicio, "Lcast: Software-defined Inter- 622 Domain Multicast", Elsevier Computer Networks, July 2014. 624 [ConteXtream] 625 ConteXtream Software Company, "SDN and NFV solutions for 626 carrier networks. (Further details on LISP only through 627 private inquiry.)", http://www.contextream.com. 629 [I-D.bonaventure-lisp-preserve] 630 Bonaventure, O., Francois, P., and D. Saucez, "Preserving 631 the reachability of LISP ETRs in case of failures", 632 draft-bonaventure-lisp-preserve-00 (work in progress), 633 July 2009. 635 [I-D.coras-lisp-re] 636 Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J., 637 Maino, F., and D. Farinacci, "LISP Replication 638 Engineering", draft-coras-lisp-re-08 (work in progress), 639 November 2015. 641 [I-D.farinacci-lisp-mr-signaling] 642 Farinacci, D. and M. Napierala, "LISP Control-Plane 643 Multicast Signaling", draft-farinacci-lisp-mr-signaling-06 644 (work in progress), February 2015. 646 [I-D.farinacci-lisp-signal-free-multicast] 647 Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", 648 draft-farinacci-lisp-signal-free-multicast-03 (work in 649 progress), June 2015. 651 [I-D.farinacci-lisp-te] 652 Farinacci, D., Kowal, M., and P. Lahiri, "LISP Traffic 653 Engineering Use-Cases", draft-farinacci-lisp-te-09 (work 654 in progress), September 2015. 656 [I-D.ietf-lisp-crypto] 657 Farinacci, D. and B. Weis, "LISP Data-Plane 658 Confidentiality", draft-ietf-lisp-crypto-02 (work in 659 progress), September 2015. 661 [I-D.ietf-lisp-ddt] 662 Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP 663 Delegated Database Tree", draft-ietf-lisp-ddt-03 (work in 664 progress), April 2015. 666 [I-D.ietf-lisp-lcaf] 667 Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 668 Address Format (LCAF)", draft-ietf-lisp-lcaf-11 (work in 669 progress), September 2015. 671 [I-D.ietf-lisp-sec] 672 Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. 673 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-09 674 (work in progress), October 2015. 676 [I-D.meyer-lisp-mn] 677 Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP 678 Mobile Node", draft-meyer-lisp-mn-13 (work in progress), 679 July 2015. 681 [I-D.saucez-lisp-itr-graceful] 682 Saucez, D., Bonaventure, O., Iannone, L., and C. Filsfils, 683 "LISP ITR Graceful Restart", 684 draft-saucez-lisp-itr-graceful-03 (work in progress), 685 December 2013. 687 [IB07] Iannone, L. and O. Bonaventure, "On the cost of caching 688 locator/id mappings", In Proc. ACM CoNEXT 2007, 689 December 2007. 691 [IL10] Iannone, L. and T. Leva, "Modeling the economics of Loc/ID 692 Separation for the Future Internet", Book Chapter, 693 Towards the Future Internet - Emerging Trends from the 694 European Research, IOS Press, May 2010. 696 [IOSNXOS] Cisco Systems Inc., "Locator/ID Separation Protocol 697 (LISP)", http://lisp4.cisco.com, 2013. 699 [KIF13] Kim, J., Iannone, L., and A. Feldmann, "Caching Locator/ID 700 Mappings: Scalability Analysis and Implications", 701 Elsevier Computer Networks Journal, March 2013. 703 [LISPClick] 704 Saucez, D. and V. Nguyen, "LISP-Click: A Click 705 implementation of the Locator/ID Separation Protocol", 706 1st Symposium on Click Modular Router, 2009, 707 November 2009. 709 [LISPcp] "The lip6-lisp Project", https://github.com/lip6-lisp/, 710 2014. 712 [LISPfritz] 713 "Unsere FRITZ!Box-Produkte", 714 http://avm.de/produkte/fritzbox/, 2014. 716 [LISPmob] "An open-source LISP implementation for Linux, Android and 717 OpenWRT", http://lispmob.org, 2015. 719 [OpenLISP] 720 "The OpenLISP Project", http://www.openlisp.org, 2013. 722 [QIdLB07] Quoitin, B., Iannone, L., de Launois, C., and O. 723 Bonaventure, "Evaluating the benefits of the locator/ 724 identifier separation", In Proc. ACM MobiArch 2007, 725 May 2007. 727 [RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report 728 from the IAB Workshop on Routing and Addressing", 729 RFC 4984, DOI 10.17487/RFC4984, September 2007, 730 . 732 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 733 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, 734 May 2014, . 736 [S11] Saucez, D., "Mechanisms for Interdomain Traffic 737 Engineering with LISP", PhD Thesis, Universite catholique 738 de Louvain, 2011, October 2011. 740 [SD12] Saucez, D. and B. Donnet, "On the Dynamics of Locators in 741 LISP", In Proc. IFIP Networking 2012, May 2012. 743 [SDIB08] Saucez, D., Donnet, B., Iannone, L., and O. Bonaventure, 744 "Interdomain Traffic Engineering in a Locator/Identifier 745 Separation Context", In Proc. of Internet Network 746 Management Workshop, 2008, October 2008. 748 [SKI12] Saucez, D., Kim, J., Iannone, L., Bonaventure, O., and C. 749 Filsfils, "A Local Approach to Fast Failure Recovery of 750 LISP Ingress Tunnel Routers", In Proc. IFIP Networking 751 2012, May 2012. 753 [Was09] Wasserman, M., "LISP Interoperability Testing", IETF 76, 754 LISP WG presentation, 2009., November 2009. 756 [lispfirewall] 757 "LISP and Zone-Based Firewalls Integration and 758 Interoperability", http://www.cisco.com/c/en/us/td/docs/ 759 ios-xml/ios/sec_data_zbf/configuration/xe-3s/ 760 sec-data-zbf-xe-book/sec-zbf-lisp-inner-pac-insp.html, 761 2014. 763 Authors' Addresses 765 Damien Saucez 766 INRIA 767 2004 route des Lucioles BP 93 768 06902 Sophia Antipolis Cedex 769 France 771 Email: damien.saucez@inria.fr 772 Luigi Iannone 773 Telecom ParisTech 774 23, Avenue d'Italie, CS 51327 775 75214 PARIS Cedex 13 776 France 778 Email: ggx@gigix.net 780 Albert Cabellos 781 Technical University of Catalonia 782 C/Jordi Girona, s/n 783 08034 Barcelona 784 Spain 786 Email: acabello@ac.upc.edu 788 Florin Coras 789 Technical University of Catalonia 790 C/Jordi Girona, s/n 791 08034 Barcelona 792 Spain 794 Email: fcoras@ac.upc.edu