idnits 2.17.1 draft-ietf-lisp-threats-09.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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 8, 2014) is 3664 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** 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 (-09) exists of draft-ietf-lisp-ddt-01 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-05 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). 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: October 10, 2014 Telecom ParisTech 6 O. Bonaventure 7 Universite catholique de Louvain 8 April 8, 2014 10 LISP Threats Analysis 11 draft-ietf-lisp-threats-09.txt 13 Abstract 15 This document proposes a threat analysis of the Locator/Identifier 16 Separation Protocol (LISP) if deployed in the Internet. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on October 10, 2014. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. On-path Attackers . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Off-Path Attackers: Reference Environment . . . . . . . . . . 3 55 4. Attack vectors . . . . . . . . . . . . . . . . . . . . . . . . 5 56 4.1. Configured EID-to-RLOC mappings . . . . . . . . . . . . . 6 57 4.2. EID-to-RLOC Cache . . . . . . . . . . . . . . . . . . . . 6 58 4.3. Attacks using the data-plane . . . . . . . . . . . . . . . 7 59 4.3.1. Attacks not leveraging on the LISP header . . . . . . 7 60 4.3.2. Attacks leveraging on the LISP header . . . . . . . . 8 61 4.4. Attacks using the control-plane . . . . . . . . . . . . . 11 62 4.4.1. Attacks with Map-Request messages . . . . . . . . . . 11 63 4.4.2. Attacks with Map-Reply messages . . . . . . . . . . . 12 64 4.4.3. Attacks with Map-Register messages . . . . . . . . . . 13 65 4.4.4. Attacks with Map-Notify messages . . . . . . . . . . . 14 66 5. Attack categories . . . . . . . . . . . . . . . . . . . . . . 14 67 5.1. Intrusion . . . . . . . . . . . . . . . . . . . . . . . . 14 68 5.1.1. Description . . . . . . . . . . . . . . . . . . . . . 14 69 5.1.2. Vectors . . . . . . . . . . . . . . . . . . . . . . . 14 70 5.2. Denial of Service (DoS) . . . . . . . . . . . . . . . . . 14 71 5.2.1. Description . . . . . . . . . . . . . . . . . . . . . 14 72 5.2.2. Vectors . . . . . . . . . . . . . . . . . . . . . . . 14 73 5.3. Subversion . . . . . . . . . . . . . . . . . . . . . . . . 15 74 5.3.1. Description . . . . . . . . . . . . . . . . . . . . . 15 75 5.3.2. Vectors . . . . . . . . . . . . . . . . . . . . . . . 15 76 6. Note on Privacy . . . . . . . . . . . . . . . . . . . . . . . 16 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 79 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 82 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 83 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 18 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 86 1. Introduction 88 The Locator/ID Separation Protocol (LISP) is specified in [RFC6830]. 89 The present document assess the potential security threats identified 90 in the LISP specifications if LISP is deployed in the Internet (i.e., 91 a public non-trustable environment). 93 The document is composed of two main parts: the first discussing the 94 techniques that can be used by attackers to succeed attacks based on 95 the LISP protocol and architecture; the second discussing the main 96 categories of attacks and how to construct them. 98 This document does not consider all the possible uses of LISP as 99 discussed in [RFC6830] and [I-D.ietf-lisp-deployment]. The document 100 focuses on LISP unicast, including as well LISP Interworking 101 [RFC6832], LISP-MS [RFC6833], and LISP Map-Versioning [RFC6834]. The 102 reading of these documents is a prerequisite for understanding the 103 present document. 105 This document assumes a generic IP service and does not discuss the 106 difference, from a security viewpoint, between using IPv4 or IPv6. 108 2. On-path Attackers 110 On-path attackers are attackers that are able to capture and modify 111 all the packets exchanged between an Ingress Tunnel Router (ITR) and 112 an Egress Tunnel Router (ETR). To cope with such an attacker, 113 cryptographic techniques such as those used by IPSec ([RFC4301]) are 114 required. As with IP, LISP relies on higher layer cryptography to 115 secure packet payloads from on path attacks, so this document does 116 not consider on-path attackers. 118 Similarly, a time-shifted attack is an attack where the attacker is 119 temporarily on the path between two communicating hosts. While it is 120 on-path, the attacker sends specially crafted packets or modifies 121 packets exchanged by the communicating hosts in order to disturb the 122 packet flow (e.g., by performing a man in the middle attack). An 123 important issue for time-shifted attacks is the duration of the 124 attack once the attacker has left the path between the two 125 communicating hosts. This documents does not consider time-shifted 126 attacks. 128 3. Off-Path Attackers: Reference Environment 130 The reference environment shown in the figure below is considered 131 throughout this document. There are two hosts attached to LISP 132 routers: HA and HB. HA is attached to the two LISP xTRs LR1 and LR2, 133 which in turn are attached to two different ISPs. HB is attached to 134 the two LISP xTRs LR3 and LR4. HA and HB are the EIDs of the two 135 hosts. LR1, LR2, LR3, and LR4 are the RLOCs of the xTRs. PxTR is a 136 proxy xTR and MR/MS plays the roles of Map Server and/or Map 137 Resolver. 139 +-----+ 140 | HA | 141 +-----+ 142 | EID: HA 143 | 144 ----------------- 145 | | 146 +-----+ +-----+ 147 | LR1 | | LR2 | 148 +-----+ +-----+ 149 | | 150 | | 151 +-----+ +-----+ 152 |ISP1 | |ISP2 | 153 +-----+ +-----+ 154 | | 155 +------+ +----------------+ +-----+ 156 | PxTR |-----| |-----| SA | 157 +------+ | | +-----+ 158 | Internet | 159 +-------+ | | +-----+ 160 | MR/MS |----| |-----| NSA | 161 +-------+ +----------------+ +-----+ 162 | | 163 +-----+ +-----+ 164 | LR3 | | LR4 | 165 +-----+ +-----+ 166 | | 167 ------------------- 168 | 169 | EID: HB 170 +-----+ 171 | HB | 172 +-----+ 174 Figure 1: Reference Network 176 We consider two off-path attackers with different capabilities: 178 SA is an off-path attacker that is able to send spoofed packets, 179 i.e., packets with a different source IP address than its 180 assigned IP address. SA stands for Spoofing Attacker. To 181 perform some of the attacks described in this document SA needs 182 to be in a non-LISP site. 184 NSA is an off-path attacker that is only able to send packets whose 185 source address is its assigned IP address. NSA stands for Non 186 Spoofing Attacker. 188 It should be noted that with LISP, packet spoofing is slightly 189 different than in the current Internet. Generally the term "spoofed 190 packet" indicates a packet containing a source IP address that is not 191 the one of the actual originator of the packet. Since LISP uses 192 encapsulation, the spoofed address could be in the outer header as 193 well as in the inner header, this translates in two types of 194 spoofing: 196 EID Spoofing: the originator of the packet puts in it a spoofed EID. 197 The packet will be normally encapsulated by the ITR of the site 198 (or a PITR if the source site is not LISP enabled). 200 RLOC Spoofing: the originator of the packet generates directly a 201 LISP-encapsulated packet with a spoofed source RLOC. 203 Note that the two types of spoofing are not mutually exclusive, 204 rather all combinations are possible and could be used to perform 205 different kind of attacks. 207 In the reference environment, both SA and NSA attackers are capable 208 of sending LISP encapsulated data packets and LISP control packets. 209 This means that SA is able to perform both RLOC and EID spoofing 210 while NSA can only perform EID spoofing. They may also send other 211 types of IP packets such as ICMP messages. We assume that both 212 attackers can query the LISP mapping system (e.g., through a public 213 Map Resolver) to obtain the mappings for both HA and HB. 215 4. Attack vectors 217 This section presents techniques that can be used by attackers to 218 succeed attacks leveraging the LISP protocol and architecture. This 219 section focuses on the techniques while Section 5 presents the 220 attacks that can be succeeded while using these techniques. 222 4.1. Configured EID-to-RLOC mappings 224 Each xTR maintains a set of configured mappings related to the EID- 225 Prefixes that are "behind" the xTR [RFC6830]. Where "behind" means 226 that at least one of the xTR's globally visible IP addresses is a 227 RLOC for those EID-Prefixes. 229 As these mappings are determined by configuration. This means that 230 the only way to attack this data structure is by gaining privileged 231 access to the xTR. As such, it is out of the scope of LISP to 232 propose any mechanism to protect routers and, hence, it is no further 233 analyzed in this document. 235 4.2. EID-to-RLOC Cache 237 The EID-to-RLOC Cache (also called the Map-Cache) is the data 238 structure that stores a copy of the mappings retrieved from a remote 239 ETR's mapping via the LISP control-plane. Attacks against this data 240 structure could happen either when the mappings are first installed 241 in the cache or by corrupting (poisoning) the mappings already 242 present in the cache. 244 Cache poisoning attacks are used to alter (any combination of) the 245 following parts of the mappings installed in the EID-to-RLOC Cache: 247 o EID prefix 249 o RLOC list 251 o RLOC priority 253 o RLOC weight 255 o RLOC reachability 257 o Mapping TTL 259 o Mapping version 261 o Mapping Instance ID 263 Cache poisoning attacks can be performed by attackers from the 264 outside of the attacked LISP network but also directly from the 265 inside. As a matter of fact, end-hosts behind an ITR can use the 266 data-plane to overflow the ITR's EID-to-RLOC Cache by sending packets 267 to non-popular EID prefixes (similar to scan attack but with a 268 different goal). In such a scenario the ITR may evict popular (in- 269 use) entries from the map-cache disrupting the normal operation of 270 the network by forcing cache miss [Florin13]. 272 4.3. Attacks using the data-plane 274 The data-plane is constituted of the operations of encapsulation, 275 decapsulation, and forwarding as well as the content of the EID-to- 276 RLOC Cache and configured EID-to-RLOC mappings as specified in the 277 original LISP document ([RFC6830]). 279 4.3.1. Attacks not leveraging on the LISP header 281 An attacker can inject packets into flows without using the LISP 282 header, i.e., with the N, L, E, V, and I bits ([RFC6830]). 284 Taking notation of the reference environment (Figure 1), to inject a 285 packet in the HA->HB flow, a spoofing off-path attacker (SA) could 286 send a LISP encapsulated packet whose source is set to LR1 or LR2 and 287 destination LR3 or LR4. The packet will reach HB as if the packet 288 was sent by host HA. This is not different from today's Internet 289 where a spoofing off-path attacker may inject data packets in any 290 flow. A non-spoofing off-path attacker (NSA) could only send a 291 packet whose source address is set to its assigned IP address. The 292 destination address of the encapsulated packet could be LR3 or LR4. 294 4.3.1.1. Gleaning Attacks 296 In order to reduce the time required to obtain a mapping, [RFC6830] 297 proposes the gleaning mechanism that allows an ITR to learn a mapping 298 from the LISP data encapsulated packets and the Map-Request packets 299 that it receives. LISP data encapsulated packet contains a source 300 RLOC, destination RLOC, source EID and destination EID. When an ITR 301 receives a data encapsulated packet coming from a source EID for 302 which it does not already know a mapping, it may insert the mapping 303 between the source RLOC and the source EID in its EID-to-RLOC Cache. 304 Gleaning could also be used when an ITR receives a Map-Request as the 305 Map-Request also contains a source EID address and a source RLOC. 306 Once a gleaned entry has been added to the EID-to-RLOC cache, the 307 LISP ITR sends a Map-Request to retrieve the mapping for the gleaned 308 EID from the mapping system. [RFC6830] recommends storing the 309 gleaned entries for only a few seconds. 311 An attacker can send LISP encapsulated packets to host HB with host 312 HA's EID and if the xTRs that serve host HB do not store a mapping 313 for host HA at that time. The xTR will store the gleaned entry and 314 use it to return the packets sent by host HB. In parallel, the ETR 315 will send a Map-Request to retrieve the mapping for HA but until the 316 reception of the Map-Reply, host HB will exchange packets with the 317 attacker instead of HA. 319 Similarly, if an off-path attacker knows that hosts HA and HB that 320 resides in different sites will exchange information at a given time 321 the attacker could send to LR1 (resp. LR3) a LISP data encapsulated 322 packet whose source RLOC is its IP address and contains an IP packet 323 whose source is set to HB (resp. HA). The attacker chooses a packet 324 that will not trigger an answer, for example the last part of a 325 fragmented packet. Upon reception of these packets, LR1 and LR3 326 install gleaned entries that point to the attacker. If host HA is 327 willing to establish a flow with host HB at that time, the packets 328 that they exchange will pass through the attacker as long as the 329 gleaned entry is active on the xTRs. 331 By itself, an attack made solely using gleaning cannot last long, 332 however it should be noted that with current network capacities, a 333 large amount of packets might be exchanged during even a small 334 fraction of time. 336 4.3.1.2. Threats concerning Interworking 338 [RFC6832] defines Proxy-ITR and Proxy-ETR network elements to allow 339 LISP and non-LISP sites to communicate. The Proxy-ITR has 340 functionality similar to the ITR, however, its main purpose is to 341 encapsulate packets arriving from the DFZ in order to reach LISP 342 sites. A Proxy-ETR has functionality similar to the ETR, however, 343 its main purpose is to inject de-encapsulated packets in the DFZ in 344 order to reach non-LISP Sites from LISP sites. As a PITR (resp. 345 PETR) is a particular case of ITR (resp. ETR), it is subject to same 346 attacks than ITRs (resp. ETR). 348 PxTRs can be targeted by attacks aiming to influence traffic between 349 LISP and non-LISP sites but also to launch relay attacks. 351 It is worth to notice that when PITR and PETR functions are 352 separated, attacks targeting nodes that collocate PITR and PETR 353 functionality are ineffective. 355 4.3.2. Attacks leveraging on the LISP header 357 The main LISP document [RFC6830] defines several flags that modify 358 the interpretation of the LISP header in data packets. In this 359 section, we discuss how an off-path attacker could exploit this LISP 360 header. 362 4.3.2.1. Attacks using the Locator Status Bits 364 When the L bit is set to 1, it indicates that the second 32-bits 365 longword of the LISP header contains the Locator Status Bits. In 366 this field, each bit position reflects the status of one of the RLOCs 367 mapped to the source EID found in the encapsulated packet. In 368 particular, a packet with the L bit set and all Locator Status Bits 369 set to zero indicates that none of the locators of the encapsulated 370 source EID are reachable. The reaction of a LISP ETR that receives 371 such a packet is not clearly described in [RFC6830]. 373 An attacker can send a data packet with the L bit set to 1 and some 374 or all Locator Status Bits set to zero. Therefore, by blindly 375 trusting the Locator Status Bits communication going on can be 376 altered or forced to go through a particular set of locators. 378 4.3.2.2. Attacks using the Map-Version bit 380 The optional Map-Version bit is used to indicate whether the low- 381 order 24 bits of the first 32 bits longword of the LISP header 382 contain a Source and Destination Map-Version. When a LISP ETR 383 receives a LISP encapsulated packet with the Map-Version bit set to 384 1, the following actions are taken: 386 o It compares the Destination Map-Version found in the header with 387 the current version of its own configured EID-to-RLOC mapping, for 388 the destination EID found in the encapsulated packet. If the 389 received Destination Map-Version is smaller (i.e., older) than the 390 current version, the ETR should apply the SMR procedure described 391 in [RFC6830] and send a Map-Request with the SMR bit set. 393 o If a mapping exists in the EID-to-RLOC Cache for the source EID, 394 then it compares the Map-Version of that entry with the Source 395 Map-Version found in the header of the packet. If the stored 396 mapping is older (i.e., the Map-Version is smaller) than the 397 source version of the LISP encapsulated packet, the xTR should 398 send a Map-Request for the source EID. 400 An off-path attacker could use the Map-Version bit to force an ETR to 401 send Map-Request messages. The attacker could retrieve the current 402 source and destination Map-Version for both HA and HB. Based on this 403 information, it could send a spoofed packet with an older Source Map- 404 Version or Destination Map-Version. If the size of the Map-Request 405 message is larger than the size of the smallest LISP-encapsulated 406 packet that could trigger such a message, this could lead to 407 amplification attacks (see Section 4.4.1) so that more bandwidth is 408 consumed on the target (because of the larger packets) than the 409 bandwidth necessary at the attacker side. 411 4.3.2.3. Attacks using the Nonce-Present and the Echo-Nonce bits 413 The Nonce-Present and Echo-Nonce bits are used when verifying the 414 reachability of a remote ETR. Assume that LR3 wants to verify that 415 LR1 receives the packets that it sends. LR3 can set the Echo-Nonce 416 and the Nonce-Present bits in LISP data encapsulated packets and 417 include a random nonce in these packets. Upon reception of these 418 packets, LR1 will store the nonce sent by LR3 and echo it when it 419 returns LISP encapsulated data packets to LR3. 421 A spoofing off-path attacker (SA) could interfere with this 422 reachability test by sending two different types of packets: 424 1. LISP data encapsulated packets with the Nonce-Present bit set and 425 a random nonce and the appropriate source and destination RLOCs. 427 2. LISP data encapsulated packets with the Nonce-Present and the 428 Echo-Nonce bits both set and the appropriate source and 429 destination RLOCs. These packets will force the receiving ETR to 430 store the received nonce and echo it in the LISP encapsulated 431 packets that it sends. 433 The first type of packet should not cause any major problem to ITRs. 434 As the reachability test uses a 24 bits nonce, it is unlikely that an 435 off-path attacker could send a single packet that causes an ITR to 436 believe that the ETR it is testing is reachable while in reality it 437 is not reachable. To increase the success likelihood of such attack, 438 the attacker should create a massive amount of packets carrying all 439 possible nonce values. 441 The second type of packet could be exploited to attack the nonce- 442 based reachability test. Consider a spoofing off-path attacker (SA) 443 that sends a continuous flow of spoofed LISP data encapsulated 444 packets that contain the Nonce-Present and the Echo-Nonce bit and 445 each packet contains a different random nonce. The ETR that receives 446 such packets will continuously change the nonce that it returns to 447 the remote ITR. If the remote ITR starts a nonce-reachability test, 448 this test may fail because the ETR has received a spoofed LISP data 449 encapsulated packet with a different random nonce and never echoes 450 the real nonce. In this case the ITR will consider the ETR not 451 reachable. The success of this test depends on the ratio between the 452 amount of packets sent by the legitimate ITR and the spoofing off- 453 path attacker (SA). 455 4.3.2.4. Attacks using the Instance ID bits 457 LISP allows to carry in its header a 24-bits value called "Instance 458 ID" and used on the ITR to indicate which local Instance ID has been 459 used for encapsulation, while on the ETR can be used to select the 460 forwarding table used for forwarding the decapsulated packet. 462 The Instance ID increases exposure to attacks ([RFC6169]) as if an 463 off-path attacker can randomly guess a valid Instance ID value to get 464 access to network that might not been accessible in normal 465 conditions. However, such attacks target end-systems, which is out 466 of the scope of this document. 468 4.4. Attacks using the control-plane 470 In this section, we discuss the different types of attacks that could 471 occur when an off-path attacker sends control-plane packets. We 472 focus on the packets that are sent directly to the ETR and do not 473 analyze the particularities of the different LISP indexing sub- 474 system. 476 4.4.1. Attacks with Map-Request messages 478 An off-path attacker could send Map-Request packets to a victim ETR. 479 In theory, a Map-Request packet is only used to solicit an answer and 480 as such it should not lead to security problems. However, the LISP 481 specification [RFC6830] contains several particularities that could 482 be exploited by an off-path attacker. 484 The first possible exploitation is the RLOC record P bit. The RLOC 485 record P bit is used to probe the reachability of remote ETRs. In 486 our reference environment, LR3 could probe the reachability of LR1 by 487 sending a Map-Request with the RLOC record P bit set. LR1 would 488 reply by sending a Map-Reply message with the RLOC record P bit set 489 and the same nonce as in the Map-Request message. 491 A spoofing off-path attacker (SA) could use the RLOC record P bit to 492 force a victim ETR to send a Map-Reply to the spoofed source address 493 of the Map-Request message. As the Map-Reply can be larger than the 494 Map-Request message, there is a risk of amplification attack. Map- 495 Requests are usually smaller than a hundred bytes while the maximum 496 size of a Map-Reply (without considering any MTU constrain) can be 497 above 1 MB, largely bigger than the message sent by the attacker. 498 These numbers are however theoretical values not considering 499 transport layer limitations and it is more likely that the reply will 500 contain only one record with at most a dozen of locators, limiting so 501 the amplification factor. 503 Similarly, if a non-spoofing off-path attacker (NSA) sends a Map- 504 Request with the RLOC record P bit set, it will receive a Map-Reply 505 with the RLOC record P bit set. 507 An amplification attack could be launched by a spoofing off-path 508 attacker (SA) as follows. Consider an attacker SA and EID-Prefix 509 192.0.2.0/24 and a victim ITR, SA could send spoofed Map-Request 510 messages whose source EID addresses are all the addresses inside 511 192.0.2.0/24 and source RLOC address is the victim ITR. Upon 512 reception of these Map-Request messages, the ETR would send large 513 Map-Reply messages, for each of the addresses back to the victim ITR. 515 The Map-Request message may also contain the SMR bit. Upon reception 516 of a Map-Request message with the SMR bit, an ETR must return to the 517 source of the Map-Request message a Map-Request message to retrieve 518 the corresponding mapping. Note that according to [RFC6830] the SMR- 519 triggered Map-Request might be sent through the mapping system, 520 depending on the number of RLOCs in the locators set. This raises 521 similar problems as the RLOC record P bit discussed above except that 522 as the Map-Request messages are smaller than Map-Reply messages, the 523 risk of amplification attacks is reduced. This is not true anymore 524 if the ETR append to the Map-Request messages its own Map-Records. 525 This mechanism is meant to reduce the delay in mapping distribution 526 since mapping information is provided in the Map-Request message. 528 Furthermore, appending Map-Records to Map-Request messages allows an 529 off-path attacker to generate a (spoofed or not) Map-Request message 530 and include in the Map-Reply portion of the message mapping for EID 531 prefixes that it does not serve. 533 Moreover, attackers can use Map Resolver and/or Map Server network 534 elements to perform relay attacks. Indeed, on the one hand, a Map 535 Resolver is used to dispatch Map-Request to the mapping system and, 536 on the other hand, a Map Server is used to dispatch Map-Requests 537 coming from the mapping system to ETRs that are authoritative for the 538 EID in the Map-Request. 540 4.4.2. Attacks with Map-Reply messages 542 In this section we analyze the attacks that could occur when an off- 543 path attacker sends directly Map-Reply messages to ETRs without using 544 one of the proposed LISP mapping systems. 546 There are two different types of Map-Reply messages: 548 Positive Map-Reply: These messages contain a Map-Record binding an 549 EID-Prefix to one or more RLOCs. 551 Negative Map-Reply: These messages contain a Map-Record for an EID- 552 Prefix with an empty locator-set and specifying an action, 553 which may be either Drop, natively forward, or Send Map- 554 Request. 556 Positive Map-Reply messages are used to map EID-Prefixes onto RLOCs. 557 Negative Map-Reply messages are used to indicate non-LISP prefixes. 558 ITRs can, if needed, be configured to send all traffic destined for 559 non-LISP prefixes to a Proxy-ETR. 561 Most of the security of the Map-Reply messages depends on the 64 bits 562 nonce that is included in a Map-Request and returned in the Map- 563 Reply. If an ETR does not accept Map-Reply messages with an invalid 564 nonce, the risk of attack is acceptable given the size of the nonce 565 (64 bits). However, the nonce only confirms that the Map-Reply 566 received was sent in response to a Map-Request sent, it does not 567 validate the contents of that Map-Reply. 569 In addition, an attacker could perform EID-to-RLOC Cache overflow 570 attack by de-aggregating (i.e., splitting an EID prefix into 571 artificially smaller EID prefixes) either positive or negative 572 mappings. 574 In presence of malicious ETRs, overclaiming attacks are possible. 575 Such an attack happens when and ETR replies to a legitimate Map- 576 Request message it received with a Map-Reply message that contains an 577 EID-Prefix that is larger than the prefix owned by the site that 578 encompasses the EID of the Map-Request. For instance if the prefix 579 owned by the site is 192.0.2.0/25 but the Map-Reply contains a 580 mapping for 192.0.2.0/24, then the mapping will influence packets 581 destined to other EIDs than the one the LISP site has authority on. 583 A malicious ETR might also fragment its configured EID-to-RLOC 584 mappings so that ITR's might have to install much more mappings than 585 really necessary. This attack is called de-aggregation attack. 587 4.4.3. Attacks with Map-Register messages 589 Map-Register messages are sent by ETRs to indicate to the mapping 590 system the EID prefixes associated to them. The Map-Register message 591 provides an EID prefix and the list of ETRs that are able to provide 592 Map-Replies for the EID covered by the EID prefix. 594 As Map-Register messages are protected by an authentication 595 mechanism, only a compromised ETR can register itself to its 596 allocated Map Server. 598 A compromised ETR can perform an overclaiming attack in order to 599 influence the route followed by Map-Requests for EIDs outside the 600 scope of its legitimate EID prefix. 602 A compromised ETR can also perform a deaggregation attack in order to 603 register more EID prefixes than necessary to its Map Servers. 605 Similarly, a compromised Map Server can accept invalid registration 606 or advertise invalid EID prefix to the indexing sub-system. 608 4.4.4. Attacks with Map-Notify messages 610 Map-Notify messages are sent by a Map Server to an ETR to acknowledge 611 the good reception and processing of a Map-Register message. 613 A compromised ETR using EID that it is not authoritative for can send 614 a Map-Register with the M-bit set and a spoofed source address to 615 force the Map Server to send a Map-Notify message to the spoofed 616 address and then succeed a relay attack. Similarly to the pair Map- 617 Request/Map-Reply, the pair Map-Register/Map-Notify is protected by a 618 nonce making it hard for an attacker to inject a falsified 619 notification to an ETR to make this ETR believe that the registration 620 succeeded while it has not. 622 5. Attack categories 624 5.1. Intrusion 626 5.1.1. Description 628 With an intrusion attack an attacker gains remote access to some 629 resources (e.g., a host, a router, or a network) that are normally 630 denied to her. 632 5.1.2. Vectors 634 Intrusion attacks can be mounted using: 636 o Spoofing EID or RLOCs 638 o Instance ID bits 640 5.2. Denial of Service (DoS) 642 5.2.1. Description 644 A Denial of Service (DoS) attack aims at disrupting a specific 645 targeted service either by exhausting the resources of the victim up 646 to the point that it is not able to provide a reliable service to 647 legit traffic and/or systems or by exploiting vulnerabilities to make 648 the targeted service unable to operate properly. 650 5.2.2. Vectors 652 Denial of Service attacks can be mounted using 653 o Gleaning 655 o Interworking 657 o Locator Status Bits 659 o Map-Version bit 661 o Nonce-Present and Echo-Nonce bits 663 o Map-Request message 665 o Map-Reply message 667 o Map-Register message 669 o Map-Notify message 671 5.3. Subversion 673 5.3.1. Description 675 With subversion an attacker can gain access (e.g., using 676 eavesdropping or impersonation) to restricted or sensitive 677 information such as passwords, session tokens, or any other 678 confidential information. This type of attack is usually carried out 679 in a way such that the target does not even notice the attack. When 680 the attacker is positioned on the path of the target traffic, it is 681 called a Man-in-the-Middle attack. However, this is not a 682 requirement to carry out and eavesdropping attack. Indeed the 683 attacker might be able, for instance through an intrusion attack on a 684 weaker system, either to duplicate or even re-direct the traffic, in 685 both cases having access to the raw packets. 687 5.3.2. Vectors 689 Subversion attacks can be mounted using 691 o Gleaning 693 o Locator Status Bits 695 o Nonce-Present and the Echo-Nonce bits 697 o Map-Request messages 699 o Map-Reply messages 701 6. Note on Privacy 703 As presented by [RFC6973], universal privacy considerations are 704 impossible to establish as the privacy definition may vary from one 705 to another. As a consequence, this document does not aim at 706 identifying privacy issues related to the LISP protocol but it is 707 necessary to highlight that security threats identified in this 708 document could play a role in privacy threats as defined in section 5 709 of [RFC6973]. 711 7. IANA Considerations 713 This document makes no request to IANA. 715 8. Security Considerations 717 This document is devoted to threat analysis of the Locator/Identifier 718 Separation Protocol and is then a piece of choice to understand the 719 security risks at stake while deploying LISP in non-trustable 720 environment. 722 The purpose of this document is not to provide recommendations to 723 protect against attacks, however most of threats can be prevented 724 with careful deployment and configuration (e.g., filter) and also by 725 applying the general rules in security that consist in activating 726 only features that are necessary in the deployment and verifying the 727 validity of the information obtained from third parties. More 728 detailed recommendations are given in [Saucez13]. 730 The control-plane is probably the most critical part of LISP from a 731 security viewpoint and it is worth to notice that the specifications 732 already offer authentication mechanism for Map-Register messages 733 ([RFC6833]) and that [I-D.ietf-lisp-sec] and [I-D.ietf-lisp-ddt] are 734 clearly going in the direction of a secure control-plane. 736 9. Acknowledgments 738 This document builds upon the draft of Marcelo Bagnulo 739 ([I-D.bagnulo-lisp-threat]), where the flooding attack and the 740 reference environment were first described. 742 The authors would like to thank Ronald Bonica, Albert Cabellos, Noel 743 Chiappa, Florin Coras, Vina Ermagan, Dino Farinacci, Stephen Farrell, 744 Joel Halpern, Emily Hiltzik, Darrel Lewis, Edward Lopez, Fabio Maino, 745 Terry Manderson, and Jeff Wheeler for their comments. 747 This work has been partially supported by the INFSO-ICT-216372 748 TRILOGY Project (www.trilogy-project.org). 750 The work of Luigi Iannone has been partially supported by the ANR-13- 751 INFR-0009 LISP-Lab Project (www.lisp-lab.org) and the EIT KIC ICT- 752 Labs SOFNETS Project. 754 10. References 756 10.1. Normative References 758 [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security 759 Concerns with IP Tunneling", RFC 6169, April 2011. 761 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 762 Locator/ID Separation Protocol (LISP)", RFC 6830, 763 January 2013. 765 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 766 "Interworking between Locator/ID Separation Protocol 767 (LISP) and Non-LISP Sites", RFC 6832, January 2013. 769 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 770 Protocol (LISP) Map-Server Interface", RFC 6833, 771 January 2013. 773 [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID 774 Separation Protocol (LISP) Map-Versioning", RFC 6834, 775 January 2013. 777 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 778 Morris, J., Hansen, M., and R. Smith, "Privacy 779 Considerations for Internet Protocols", RFC 6973, 780 July 2013. 782 10.2. Informative References 784 [Florin13] 785 Coras, F., Domingo-Pascual, J., Lewis, D., and A. 786 Cabellos-Aparicio, "An Analytical Model for Loc/ID 787 Mappings Caches", Technical Report. arXiv:1312.1378v2, 788 2013, . 790 [I-D.bagnulo-lisp-threat] 791 Bagnulo, M., "Preliminary LISP Threat Analysis", 792 draft-bagnulo-lisp-threat-01 (work in progress), 793 July 2007. 795 [I-D.ietf-lisp-ddt] 796 Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP 797 Delegated Database Tree", draft-ietf-lisp-ddt-01 (work in 798 progress), March 2013. 800 [I-D.ietf-lisp-deployment] 801 Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- 802 Pascual, J., and D. Lewis, "LISP Network Element 803 Deployment Considerations", draft-ietf-lisp-deployment-12 804 (work in progress), January 2014. 806 [I-D.ietf-lisp-sec] 807 Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D., 808 and O. Bonaventure, "LISP-Security (LISP-SEC)", 809 draft-ietf-lisp-sec-05 (work in progress), October 2013. 811 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 812 Internet Protocol", RFC 4301, December 2005. 814 [Saucez13] 815 Saucez, D., Iannone, L., and O. Bonaventure, "The Map-and- 816 Encap Locator/Identifier separation paradigm: a Security 817 Analysis", Solutions for Sustaining Scalability in 818 Internet Growth, IGI Global, 2013. 820 Appendix A. Document Change Log 822 o Version 09 Posted March 2014. 824 * Updated document according to the review of A. Cabellos. 826 o Version 08 Posted October 2013. 828 * Addition of a privacy consideration note. 830 * Editorial changes 832 o Version 07 Posted October 2013. 834 * This version is updated according to the thorough review made 835 during October 2013 LISP WG interim meeting. 837 * Brief recommendations put in the security consideration 838 section. 840 * Editorial changes 842 o Version 06 Posted October 2013. 844 * Complete restructuration, temporary version to be used at 845 October 2013 interim meeting. 847 o Version 05 Posted August 2013. 849 * Removal of severity levels to become a short recommendation to 850 reduce the risk of the discussed threat. 852 o Version 04 Posted February 2013. 854 * Clear statement that the document compares threats of public 855 LISP deployments with threats in the current Internet 856 architecture. 858 * Addition of a severity level discussion at the end of each 859 section. 861 * Addressed comments from V. Ermagan and D. Lewis' reviews. 863 * Updated References. 865 * Further editorial polishing. 867 o Version 03 Posted October 2012. 869 * Dropped Reference to RFC 2119 notation because it is not 870 actually used in the document. 872 * Deleted future plans section. 874 * Updated References 876 * Deleted/Modified sentences referring to the early status of the 877 LISP WG and documents at the time of writing early versions of 878 the document. 880 * Further editorial polishing. 882 * Fixed all ID nits. 884 o Version 02 Posted September 2012. 886 * Added a new attack that combines overclaiming and de- 887 aggregation (see Section 4.4.2). 889 * Editorial polishing. 891 o Version 01 Posted February 2012. 893 * Added discussion on LISP-DDT. 895 o Version 00 Posted July 2011. 897 * Added discussion on LISP-MS>. 899 * Added discussion on Instance ID in Section 4.3.2. 901 * Editorial polishing of the whole document. 903 * Added "Change Log" appendix to keep track of main changes. 905 * Renamed "draft-saucez-lisp-security-03.txt. 907 Authors' Addresses 909 Damien Saucez 910 INRIA 911 2004 route des Lucioles BP 93 912 06902 Sophia Antipolis Cedex 913 France 915 Email: damien.saucez@inria.fr 917 Luigi Iannone 918 Telecom ParisTech 919 23, Avenue d'Italie, CS 51327 920 75214 PARIS Cedex 13 921 France 923 Email: luigi.iannone@telecom-paristech.fr 925 Olivier Bonaventure 926 Universite catholique de Louvain 927 Place St. Barbe 2 928 Louvain la Neuve 929 Belgium 931 Email: olivier.bonaventure@uclouvain.be