idnits 2.17.1 draft-ietf-lisp-threats-10.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 (July 4, 2014) is 3582 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-06 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: January 5, 2015 Telecom ParisTech 6 O. Bonaventure 7 Universite catholique de Louvain 8 July 4, 2014 10 LISP Threats Analysis 11 draft-ietf-lisp-threats-10.txt 13 Abstract 15 This document proposes a threat analysis of the Locator/Identifier 16 Separation Protocol (LISP). 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 January 5, 2015. 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. Threat model . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.1. Attacker modes of operation . . . . . . . . . . . . . . . 4 55 2.1.1. On-path attackers vs. Off-path attackers . . . . . . . 4 56 2.1.2. Internal attackers vs. External attackers . . . . . . 4 57 2.1.3. Live attackers vs. Time-shifted attackers . . . . . . 4 58 2.1.4. Control-plane attackers vs. Data-plane attackers . . . 5 59 2.1.5. Cross mode attackers . . . . . . . . . . . . . . . . . 5 60 2.2. Threat categories . . . . . . . . . . . . . . . . . . . . 5 61 2.2.1. Replay attack . . . . . . . . . . . . . . . . . . . . 5 62 2.2.2. Packet manipulation . . . . . . . . . . . . . . . . . 5 63 2.2.3. Packet interception and suppression . . . . . . . . . 6 64 2.2.4. Spoofing . . . . . . . . . . . . . . . . . . . . . . . 6 65 2.2.5. Rogue attack . . . . . . . . . . . . . . . . . . . . . 6 66 2.2.6. Denial of Service (DoS) attack . . . . . . . . . . . . 7 67 2.2.7. Performance attack . . . . . . . . . . . . . . . . . . 7 68 2.2.8. Intrusion attack . . . . . . . . . . . . . . . . . . . 7 69 2.2.9. Amplification attack . . . . . . . . . . . . . . . . . 7 70 2.2.10. Multi-category attacks . . . . . . . . . . . . . . . . 7 71 3. Attack vectors . . . . . . . . . . . . . . . . . . . . . . . . 7 72 3.1. Gleaning . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 3.2. Locator Status Bits . . . . . . . . . . . . . . . . . . . 9 74 3.3. Map-Version . . . . . . . . . . . . . . . . . . . . . . . 9 75 3.4. Echo-Nonce algorithm . . . . . . . . . . . . . . . . . . . 10 76 3.5. Instance ID . . . . . . . . . . . . . . . . . . . . . . . 11 77 3.6. Interworking . . . . . . . . . . . . . . . . . . . . . . . 11 78 3.7. Map-Request messages . . . . . . . . . . . . . . . . . . . 12 79 3.8. Map-Reply messages . . . . . . . . . . . . . . . . . . . . 13 80 3.9. Map-Register messages . . . . . . . . . . . . . . . . . . 14 81 3.10. Map-Notify messages . . . . . . . . . . . . . . . . . . . 14 82 4. Note on Privacy . . . . . . . . . . . . . . . . . . . . . . . 14 83 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 85 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 87 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 88 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 89 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 17 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 92 1. Introduction 94 The Locator/ID Separation Protocol (LISP) is specified in [RFC6830]. 95 The present document assess the potential security threats identified 96 in the LISP specifications if LISP is deployed in the Internet (i.e., 97 a public non-trustable environment). 99 The document is composed of three main parts: the first defines the 100 general threat model that attackers can follow to mount attacks. The 101 second describing the techniques based on the LISP protocol and 102 architecture that attackers can use to construct attacks. The third 103 discussing general solutions to protect the LISP protocol and 104 architecture from attacks. 106 This document does not consider all the possible uses of LISP as 107 discussed in [RFC6830] and [RFC7215]. The document focuses on LISP 108 unicast, including as well LISP Interworking [RFC6832], LISP-MS 109 [RFC6833], and LISP Map-Versioning [RFC6834]. The reading of these 110 documents is a prerequisite for understanding the present document. 112 This document assumes a generic IP service and does not discuss the 113 difference, from a security viewpoint, between using IPv4 or IPv6. 115 2. Threat model 117 This document assumes that attackers can be located anywhere in the 118 Internet (either in LISP sites or outside LISP sites) and that 119 attacks can be mounted either by a single attacker or by the 120 collusion of several attackers. 122 An attacker is a malicious entity that performs the action of 123 attacking a target in a network where LISP is (partially) deployed by 124 leveraging the LISP protocol and/or architecture. 126 An attack is the action of performing an illegitimate action on a 127 target in a network where LISP is (partially) deployed. 129 The target of an attack is the entity (i.e., a device connected to 130 the network or a network) that is aimed to undergo the consequences 131 of an attack. Other entities can potentially undergo side effects of 132 an attack, even though they are not directly targeted by the attack. 133 The target of an attack can be selected specifically, i.e., a 134 particular entity, or arbitrarily, i.e., any entity. Finally, an 135 attacker can aim at attacking one or several targets with a single 136 attack. 138 Section 2.1 specifies the different modes of operation that attackers 139 can follow to mount attacks and Section 2.2 specifies the different 140 categories of attacks that attackers can build. 142 2.1. Attacker modes of operation 144 Attackers can be classified according to the following four modes of 145 operation, i.e., the temporal and spacial locality of the attacker. 147 2.1.1. On-path attackers vs. Off-path attackers 149 On-path attackers, also known as Men-in-the-Middle, are able to 150 intercept and modify packets between legitimate communicating 151 entities. On-path attackers are located either directly on the 152 normal communication path (either by gaining access to a node on the 153 path or by placing themselves directly on the path) or outside the 154 location path but manage to deviate or gain a copy of packets sent 155 between the communication entities. On-path attackers hence mount 156 their attacks by modifying packets initially sent legitimately 157 between communication entities. 159 An attacker is called off-path attacker if it does not have access to 160 packets exchanged during the communication or if there is no 161 communication. To succeed their attacks, off-path attackers must 162 hence generate packets and inject them in the network. 164 2.1.2. Internal attackers vs. External attackers 166 An internal attacker launches its attack from a node located within a 167 legitimate LISP site. Such an attacker is either a legitimate node 168 of the site or it exploits a vulnerability to gain access to a 169 legitimate node in the site. Because of their location, internal 170 attackers are trusted by the site they are in. 172 On the contrary, an external attacker launches its attacks from the 173 outside of a legitimate LISP site. 175 2.1.3. Live attackers vs. Time-shifted attackers 177 A live attacker mounts attacks for which it must remain connected as 178 long as the attack is mounted. In other words, the attacker must 179 remain active for the whole duration of the attack. Consequently, 180 the attack ends as soon as the attacker (or the used attack vector) 181 is neutralized. 183 On the contrary, a time-shifted attacker mounts attacks that remain 184 active after it disconnects from the Internet. 186 2.1.4. Control-plane attackers vs. Data-plane attackers 188 A control-plane attacker mounts its attack by using control-plane 189 functionalities, typically the mapping system. 191 A data-plane attacker mounts its attack by using data-plane 192 functionalities. 194 As there is no strict delimitation between the control-plane and the 195 data-plane, an attacker can operate in the control-plane (resp. data- 196 plane) to mount attacks targeting the data-plane (resp. control- 197 plane) or keep the attacked and targeted planes at the same layer 198 (i.e., from control-plane to control-plane or from data-plane to 199 data-plane). 201 2.1.5. Cross mode attackers 203 The attacker modes of operation are not mutually exclusive and hence 204 attackers can combine them to mount attacks. 206 For example, an attacker can launch an attack using the control-plane 207 directly from within a LISP site to which it got temporary access 208 (i.e., internal + control-plane attacker) to create a vulnerability 209 on its target and later on (i.e., time-shifted + external attacker) 210 mount an attack on the data plane (i.e., data-plane attacker) that 211 leverages the vulnerability. 213 2.2. Threat categories 215 Attacks can be classified according to the nine following categories. 217 2.2.1. Replay attack 219 A replay attack happens when an attacker retransmits at a later time, 220 and without modifying it, a packet (or a sequence of packets) that 221 has already been transmitted. 223 2.2.2. Packet manipulation 225 A packet manipulation attack happens when an attacker receives a 226 packet, modifies the packet (i.e., changes some information contained 227 in the packet) and finally transmits the packet to its final 228 destination that can be the initial destination of the packet or 229 another one. 231 2.2.3. Packet interception and suppression 233 In a packet interception and suppression attack, the attacker 234 captures the packet and drops it before it can reach its final 235 destination. 237 2.2.4. Spoofing 239 With a spoofing attack, the attacker injects packets in the network 240 pretending being another node. Spoofing attacks are made by forging 241 source addresses in packets. 243 It should be noted that with LISP, packet spoofing is similar to any 244 other existing tunneling technology currently deployed in the 245 Internet. Generally the term "spoofed packet" indicates a packet 246 containing a source IP address that is not the one of the actual 247 originator of the packet. Hence, since LISP uses encapsulation, the 248 spoofed address could be in the outer header as well as in the inner 249 header, this translates in two types of spoofing. 251 Inner address spoofing: the attacker uses encapsulation and uses a 252 spoofed source address in the inner packet. In case of data- 253 plane LISP encapsulation, that corresponds to spoof the source 254 EID address of the encapsulated packet. 256 Outer address spoofing: the attacker does not use encapsulation and 257 spoofs the source address of the packet. 259 Note that the two types of spoofing are not mutually exclusive, 260 rather all combinations are possible and could be used to perform 261 different kind of attacks. For example, an attacker not in a LISP 262 site can generate a packet with a forged source IP address (i.e., 263 outer address spoofing) and forward it to a LISP destination. The 264 packet is then eventually encapsulated by a PITR so that once 265 encapsulated the attack corresponds to a inner address spoofing. One 266 can also imagine an attacker forging a packet with encapsulation 267 where both inner an outer source addresses are spoofed. 269 It is important to notice that the combination of inner and outer 270 spoofing makes the identification of the attacker complex as the 271 packet may not contain information that permits to detect the origin 272 of the attack. 274 2.2.5. Rogue attack 276 In a rogue attack the attacker manages to appear as a legitimate 277 source of information, without faking its identity (as opposed to a 278 spoofing attacker). 280 2.2.6. Denial of Service (DoS) attack 282 A Denial of Service (DoS) attack aims at disrupting a specific 283 targeted service to make it unable to operate properly. 285 2.2.7. Performance attack 287 A performance attacks aims at exploiting computational resources 288 (e.g., memory, processor) of a targeted node so to make it unable to 289 operate properly. 291 2.2.8. Intrusion attack 293 In an intrusion attack the attacker gains remote access to a resource 294 (e.g., a host, a router, or a network) or information that it 295 normally doesn't have access to. Intrusion attacks can lead to 296 privacy leakages. 298 2.2.9. Amplification attack 300 In an amplification attack, the traffic generated by the target of 301 the attack in response to the attack is larger than the traffic that 302 the attacker must generate. 304 2.2.10. Multi-category attacks 306 Attacks categories are not mutually exclusive and any combination can 307 be used to perform specific attacks. 309 For example, one can mount a rogue attack to perform a performance 310 attack starving the memory of an ITR resulting in a DoS on the ITR. 312 3. Attack vectors 314 This section presents techniques that can be used by attackers to 315 succeed attacks leveraging the LISP protocol and/or architecture. 317 3.1. Gleaning 319 To reduce the time required to obtain a mapping, the optional 320 gleaning mechanism allows an xTR to directly learn a mapping from the 321 LISP data encapsulated packets and the Map-Request packets that it 322 receives. LISP encapsulated data packets contain a source RLOC, 323 destination RLOC, source EID and destination EID. When an xTR 324 receives an encapsulated data packet coming from a source EID for 325 which it does not already know a mapping, it may insert the mapping 326 between the source RLOC and the source EID in its EID-to-RLOC Cache. 328 The same technique can be used when an xTR receives a Map-Request as 329 the Map-Request also contains a source EID address and a source RLOC. 330 Once a gleaned entry has been added to the EID-to-RLOC cache, the xTR 331 sends a Map-Request to retrieve the actual mapping for the gleaned 332 EID from the mapping system. 334 If a packet injected by an off-path attacker and with a spoofed inner 335 address is gleaned by an xTR then the attacker may divert the traffic 336 meant to be delivered to the spoofed EID as long as the gleaned entry 337 is used by the xTR. This attack can be used as part of replay, 338 packet manipulation, packet interception and suppression, or DoS 339 attacks as the packets are sent to the attacker. 341 If the packet sent by the attacker contains a spoofed outer address 342 instead of a spoofed inner address then it can succeed a DoS or a 343 performance attack as the traffic normally destined to the attacker 344 will be redirected to the spoofed source RLOC. Such traffic may 345 overload the owner of the spoofed source RLOC, preventing it from 346 operating properly. 348 If the packet injected uses both inner and outer spoofing, the 349 attacker can succeed a spoofing, a performance, or an amplification 350 attack as traffic normally destined to the spoofed EID address will 351 be sent to the spoofed RLOC address. If the attacked LISP site also 352 generates traffic to the spoofed EID address, such traffic may have a 353 positive amplification factor. 355 A gleaning attack does not only impact the data-plane but can also 356 have repercussions on the control-plane as a Map-Request is sent 357 after the creation of a gleaned entry. The attacker can then succeed 358 DoS and performance attacks on the control-plane. For example, if an 359 attacker sends a packet for each address of a prefix not yet cached 360 in the EID-to-RLOC cache of an xTR, the xTR will potentially send a 361 Map-Request for each such packet until the mapping is installed which 362 leads to an over-utilisation of the control-plane as each packet 363 generates a control-plane event. For succeeding this example, the 364 attacker may not need to use spoofing. 366 Gleaning attacks are fundamentally involving a time-shifted mode of 367 operation as the attack may last as long as the gleaned entry is kept 368 by the targeted xTR. Nevertheless, [RFC6830] recommends to store the 369 gleaned entries for only a few seconds which limits the duration of 370 the attack. 372 Gleaning attacks always involve external data-plane attackers but 373 results in attacks on either the control-plane or data-plane. 375 It is worth to notice that the outer spoofed address does not need to 376 be the RLOC of a LISP site an may be any address. 378 3.2. Locator Status Bits 380 When the L bit is set to 1, it indicates that the second 32-bits 381 longword of the LISP header contains the Locator Status Bits. In 382 this field, each bit position reflects the status of one of the RLOCs 383 mapped to the source EID found in the encapsulated packet. The 384 reaction of a LISP xTR that receives such a packet is left as 385 operational choice in [RFC6830]. 387 When an attacker sends a LISP encapsulated packet with a crafted LSB 388 to an xTR, it can influence the xTR's choice of the locators for the 389 prefix associated to the source EID. In case of an off-path 390 attacker, the attacker must inject a forged packet in the network 391 with a spoofed inner address. An on-path attacker can manipulate the 392 LSB of legitimate packets passing through it and hence does not need 393 to use spoofing. Instead of manipulating the LSB field, an on-path 394 attacker can also obtain the same result of injecting packets with 395 invalid LSB values by replaying packets. 397 The LSB field can be leveraged to succeed a DoS attack by either 398 declaring all RLOCs as unreachable (all LSB set to 0), or by 399 concentrating all the traffic to one RLOC (e.g., all but one LSB set 400 to 0) and hence overloading the RLOC concentrating all the traffic 401 from the xTR, or by forcing packets to be sent to RLOCs that are 402 actually not reachable (e.g., invert LSB values). 404 The LSB field can also be used to mount a replay, a packet 405 manipulation, or a packet interception and suppression attack. 406 Indeed, if the attacker manages to be on the path between the xTR and 407 one of the RLOCs specified in the mapping, forcing packets to go via 408 that RLOC implies that the attacker will gain access to the packets. 410 Attacks using the LSB are fundamentally involving a time-shifted mode 411 of operation as the attack may last as long as the reachability 412 information gathered from the LSB is used by the xTR to decide the 413 RLOCs to be used. 415 3.3. Map-Version 417 When the Map-Version bit is set to 1, it indicates that the low-order 418 24 bits of the first 32 bits longword of the LISP header contain a 419 Source and Destination Map-Version. When a LISP xTR receives a LISP 420 encapsulated packet with the Map-Version bit set to 1, the following 421 actions are taken: 423 o It compares the Destination Map-Version found in the header with 424 the current version of its own configured EID-to-RLOC mapping, for 425 the destination EID found in the encapsulated packet. If the 426 received Destination Map-Version is smaller (i.e., older) than the 427 current version, the ETR should apply the SMR procedure described 428 in [RFC6830] and send a Map-Request with the SMR bit set. 430 o If a mapping exists in the EID-to-RLOC Cache for the source EID, 431 then it compares the Map-Version of that entry with the Source 432 Map-Version found in the header of the packet. If the stored 433 mapping is older (i.e., the Map-Version is smaller) than the 434 source version of the LISP encapsulated packet, the xTR should 435 send a Map-Request for the source EID. 437 A cross-mode attacker can use the Map-Version bit to mount a DoS 438 attack, an amplification attack, or a spoofing attack. For instance 439 if the mapping cached at the xTR is outdated, the xTR will send a 440 Map-Request to retrieve the new mapping which can yield to a DoS 441 attack (by excess of signalling traffic) or an amplification attack 442 if the data-plane packet sent by the attacker is smaller than the 443 control-plane packets sent in response to the attacker's packet. 444 With a spoofing attack and if the xTR considers that the spoofed ITR 445 has an outdated mapping, it will send an SMR to the spoofed ITR which 446 can result in performance, amplification, or DoS attack as well. 448 Map-Version attackers are inherently cross mode as the Map-Version is 449 a method to put control information in the data-plane. Moreover, 450 this vector involves live attackers. Nevertheless, on-path attackers 451 do not take specific advantage over off-path attackers. 453 3.4. Echo-Nonce algorithm 455 The Nonce-Present and Echo-Nonce bits are used to verifying the 456 reachability of an xTR. An testing xTR sets the Echo-Nonce and the 457 Nonce-Present bits in LISP data encapsulated packets and include a 458 random nonce in the LISP header of packets. Upon reception of these 459 packets, the tested xTR stores the nonce and echo it whenever it 460 returns a LISP encapsulated data packets to the testing xTR. The 461 reception of the echoed nonce confirms that the tested xTR is 462 reachable. 464 An attacker can interfere with the reachability test by sending two 465 different types of packets: 467 1. LISP data encapsulated packets with the Nonce-Present bit set and 468 a random nonce. Such packets are normally used in response to a 469 reachability test. 471 2. LISP data encapsulated packets with the Nonce-Present and the 472 Echo-Nonce bits both set. These packets will force the receiving 473 ETR to store the received nonce and echo it in the LISP 474 encapsulated packets that it sends. These packets are normally 475 used as trigger for a reachability test. 477 The first type of packets is used to make xTRs think that an other 478 xTR is reachable while it is not. It is hence a way to mount a DoS 479 attack (i.e., the ITR will send its packet to a non-reachable ETR 480 while it should use another one). 482 The second type of packets could be exploited to attack the nonce- 483 based reachability test. If the attacker sends a continuous flow of 484 packets that each have a different random nonce, the ETR that 485 receives such packets will continuously change the nonce that it 486 returns to the remote ITR, which can yield to a performance attack. 487 If the remote ITR tries a nonce-reachability test, this test may fail 488 because the ETR may echo an invalid nonce. This hence yields to a 489 DoS attack. 491 In the case of an on-path attacker, a packet manipulation attack is 492 necessary to mount the attack. To mount such an attack, an off-path 493 attacker must mount an outer address spoofing attack. 495 3.5. Instance ID 497 LISP allows to carry in its header a 24-bits value called Instance ID 498 and used on the ITR to indicate which local Instance ID has been used 499 for encapsulation, while on the ETR the instance ID decides the 500 forwarding table to use to forward the decapsulated packet in the 501 LISP site. 503 An attacker (either a control-plane or data-plane attacker) can use 504 the instance ID functionality to mount an intrusion attack. 506 3.6. Interworking 508 [RFC6832] defines Proxy-ITR and Proxy-ETR network elements to allow 509 LISP and non-LISP sites to communicate. The Proxy-ITR has 510 functionality similar to the ITR, however, its main purpose is to 511 encapsulate packets arriving from the DFZ in order to reach LISP 512 sites. A Proxy-ETR has functionality similar to the ETR, however, 513 its main purpose is to inject de-encapsulated packets in the DFZ in 514 order to reach non-LISP Sites from LISP sites. As a PITR (resp. 515 PETR) is a particular case of ITR (resp. ETR), it is subject to same 516 attacks than ITRs (resp. ETR). 518 As any other system relying on proxies, LISP interworking can be used 519 by attackers to hide their exact origin in the network. 521 3.7. Map-Request messages 523 A control-plane off-path attacker can exploit Map-Request messages to 524 mount DoS, performance, or amplification attacks. By sending Map- 525 Request messages at high rate, the attacker can overload nodes 526 involved in the mapping system. For instance sending Map-Requests at 527 high rate can considerably increase the state maintained in a Map- 528 Resolver or consume CPU cycles on ETRs that have to process the Map- 529 Request packets they receive in their slow path (i.e., performance or 530 DoS attack). When the Map-Reply packet is larger than the Map- 531 Request sent by the attacker, that yields to an amplification attack. 532 The attacker can combine the attack with a spoofing attack to 533 overload the node to which the spoofed address is actually attached. 535 It is worth to notice that if the attacker sets the P bit in the Map- 536 Request, it is legitimate the send the Map-Request directly to the 537 ETR instead of passing through the mapping system. 539 The SMR bit can be used to mount a variant of these attacks. 541 For efficiency reasons, Map-Records can be appended to Map-Request 542 messages. When an xTR receives a Map-Request with appended Map- 543 Records, it does the same operations as for the other Map-Request 544 messages and is so subject to the same attacks. However, it also 545 installs in its EID-to-RLOC cache the Map-Records contained in the 546 Map-Request. An attacker can then use this vector to force the 547 installation of mappings in its target xTR. Consequently, the EID- 548 to-RLOC cache of the xTR is polluted by potentially forged mappings 549 allowing the attacker to mount any of the attacks categorized in 550 Section 2.2 (see Section 3.8 for more details). It is worth to 551 mention that the attacker does not need to forge the mappings present 552 in the Map-Request to succeed a performance or DoS attack. Indeed, 553 if the attacker owns a large enough EID prefix it can de-aggregate it 554 in many small prefixes, each corresponding to another mapping and it 555 them in the xTR cache by the mean of the Map-Request. 557 Moreover, attackers can use Map Resolver and/or Map Server network 558 elements to relay its attacks and hide the origin of the attack. 559 Indeed, on the one hand, a Map Resolver is used to dispatch Map- 560 Request to the mapping system and, on the other hand, a Map Server is 561 used to dispatch Map-Requests coming from the mapping system to ETRs 562 that are authoritative for the EID in the Map-Request. 564 3.8. Map-Reply messages 566 Most of the security of the Map-Reply messages depends on the 64 bits 567 nonce that is included in a Map-Request and returned in the Map- 568 Reply. If an ETR does not accept Map-Reply messages with an invalid 569 nonce, the risk of attack is limited given the size of the nonce (64 570 bits). Nevertheless, the nonce only confirms that the Map-Reply 571 received was sent in response to a Map-Request sent, it does not 572 validate the contents of that Map-Reply. 574 If an attacker manages to send a valid (i.e., in response to a Map- 575 Request and with the correct nonce) Map-Reply to an ITR, then it can 576 perform any of the attack categorised in Section 2.2 as it can inject 577 forged mappings directly in the ITR EID-to-RLOC cache. For instance, 578 if the mapping injected to the ITR points to the address of a node 579 controlled by the attacker, it can mount replay, packet manipulation, 580 packet interception and suppression, or DoS attacks as it will 581 receive every packet destined to a destination lying in the EID 582 prefix of the injected mapping. In addition, the attacker can inject 583 plethora of mappings in the ITR to mount an performance attack by 584 filling up the EID-to-RLOC cache of the ITR. If the attacker can 585 also mount an amplification attack as soon as the ITR has to send a 586 lot of packets to the EIDs matching the injected mapping. In this 587 case, the RLOC address associated to the mapping is the address of 588 the real target of the attacker and all the traffic of the ITR will 589 be sent to the target which means that with one single packet the 590 attacker may generate very high traffic towards its final target. 592 If the attacker is a valid ETR in the system it can mount a rogue 593 attack if it uses prefixes over-claiming. In such a scenario, the 594 attacker ETR replies to a legitimate Map-Request message it received 595 with a Map-Reply message that contains an EID-Prefix that is larger 596 than the prefix owned by the attacker. For instance if the owned 597 prefix is 192.0.2.0/25 but the Map-Reply contains a mapping for 598 192.0.2.0/24, then the mapping will influence packets destined to 599 other EIDs than the one attacker has authority on. With such 600 technique, the attacker can mount the attacks presented above as it 601 can (partially) control the mappings installed on its target ITR. To 602 force its target ITR to send a Map-Request, nothing prevents the 603 attacker to initiate some communication with the ITR. This method is 604 particularly interesting for internal attackers that want to control 605 the mappings installed in their site. To that aim, they simply have 606 to collude with an external attacker ready to over-claim prefixes on 607 behalf of the internal attacker. 609 It is worth to notice that when the Map-Reply is in response to a 610 Map-Request sent via the mapping system (i.e., not send directly from 611 the ITR to an ETR), the attacker does not need to use a spoofing 612 attack to succeed its attack as by design the source IP address of a 613 Map-Reply is not known in advance by the ITR. 615 Map-Request and Map-Reply messages are at the mercy of any type of 616 attackers, on-path or off-path but also external or internal 617 attackers. Also, even though they are control message, they can be 618 leveraged by data-plane attackers. As the decision of removing 619 mappings is based on the TTL indicated in the mapping, time-shifted 620 attackers can take benefit of injecting forged mappings as well. 622 3.9. Map-Register messages 624 Map-Register messages are sent by ETRs to indicate to the mapping 625 system the EID prefixes associated to them. The Map-Register message 626 provides an EID prefix and the list of ETRs that are able to provide 627 Map-Replies for the EID covered by the EID prefix. 629 As Map-Register messages are protected by an authentication 630 mechanism, only a compromised ETR can register itself to its 631 allocated Map Server. 633 A compromised ETR can over-claim the prefix it owns in order to 634 influence the route followed by Map-Requests for EIDs outside the 635 scope of its legitimate EID prefix (see Section 3.8 for the list of 636 attacks opened by over-claiming). 638 A compromised ETR can also de-aggregate its EID prefix in order to 639 register more EID prefixes than necessary to its Map Servers (see 640 Section 3.7 for the impact of de-aggregation of prefixes by an 641 attacker). 643 Similarly, a compromised Map Server can accept invalid registration 644 or advertise invalid EID prefix to the mapping system. 646 3.10. Map-Notify messages 648 Map-Notify messages are sent by a Map Server to an ETR to acknowledge 649 the good reception and processing of a Map-Register message. 651 Similarly to the pair Map-Request/Map-Reply, the pair Map-Register/ 652 Map-Notify is protected by a nonce making it hard for an attacker to 653 inject a falsified notification to an ETR to make this ETR believe 654 that the registration succeeded while it has not. 656 4. Note on Privacy 658 As presented by [RFC6973], universal privacy considerations are 659 impossible to establish as the privacy definition may vary from one 660 to another. As a consequence, this document does not aim at 661 identifying privacy issues related to the LISP protocol but it is 662 necessary to highlight that security threats identified in this 663 document could play a role in privacy threats as defined in section 5 664 of [RFC6973]. 666 Note, however, that like public deployments of any other control 667 plane protocol, in an Internet deployment mappings are public and 668 hence provide information about the infrastructure and reachability 669 of LISP sites (i.e., the addresses of the edge routers). 671 5. IANA Considerations 673 This document makes no request to IANA. 675 6. Security Considerations 677 This document is devoted to threat analysis of the Locator/Identifier 678 Separation Protocol and is then a piece of choice to understand the 679 security risks at stake while deploying LISP in non-trustable 680 environment. 682 The purpose of this document is not to provide recommendations to 683 protect against attacks, however most of threats can be prevented 684 with careful deployment and configuration (e.g., filter) and also by 685 applying the general rules in security that consist in activating 686 only features that are necessary in the deployment and verifying the 687 validity of the information obtained from third parties. More 688 detailed recommendations are given in [Saucez13]. 690 The control-plane is probably the most critical part of LISP from a 691 security viewpoint and it is worth to notice that the specifications 692 already offer authentication mechanism for Map-Register messages 693 ([RFC6833]) and that [I-D.ietf-lisp-sec] and [I-D.ietf-lisp-ddt] are 694 clearly going in the direction of a secure control-plane. 696 7. Acknowledgments 698 This document builds upon the draft of Marcelo Bagnulo 699 ([I-D.bagnulo-lisp-threat]), where the flooding attack and the 700 reference environment were first described. 702 The authors would like to thank Ronald Bonica, Albert Cabellos, Ross 703 Callon, Noel Chiappa, Florin Coras, Vina Ermagan, Dino Farinacci, 704 Stephen Farrell, Joel Halpern, Emily Hiltzik, Darrel Lewis, Edward 705 Lopez, Fabio Maino, Terry Manderson, and Jeff Wheeler for their 706 comments. 708 This work has been partially supported by the INFSO-ICT-216372 709 TRILOGY Project (www.trilogy-project.org). 711 The work of Luigi Iannone has been partially supported by the ANR-13- 712 INFR-0009 LISP-Lab Project (www.lisp-lab.org) and the EIT KIC ICT- 713 Labs SOFNETS Project. 715 8. References 717 8.1. Normative References 719 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 720 Locator/ID Separation Protocol (LISP)", RFC 6830, 721 January 2013. 723 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 724 "Interworking between Locator/ID Separation Protocol 725 (LISP) and Non-LISP Sites", RFC 6832, January 2013. 727 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 728 Protocol (LISP) Map-Server Interface", RFC 6833, 729 January 2013. 731 [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID 732 Separation Protocol (LISP) Map-Versioning", RFC 6834, 733 January 2013. 735 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 736 Morris, J., Hansen, M., and R. Smith, "Privacy 737 Considerations for Internet Protocols", RFC 6973, 738 July 2013. 740 8.2. Informative References 742 [I-D.bagnulo-lisp-threat] 743 Bagnulo, M., "Preliminary LISP Threat Analysis", 744 draft-bagnulo-lisp-threat-01 (work in progress), 745 July 2007. 747 [I-D.ietf-lisp-ddt] 748 Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP 749 Delegated Database Tree", draft-ietf-lisp-ddt-01 (work in 750 progress), March 2013. 752 [I-D.ietf-lisp-sec] 753 Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. 754 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-06 755 (work in progress), April 2014. 757 [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- 758 Pascual, J., and D. Lewis, "Locator/Identifier Separation 759 Protocol (LISP) Network Element Deployment 760 Considerations", RFC 7215, April 2014. 762 [Saucez13] 763 Saucez, D., Iannone, L., and O. Bonaventure, "The Map-and- 764 Encap Locator/Identifier separation paradigm: a Security 765 Analysis", Solutions for Sustaining Scalability in 766 Internet Growth, IGI Global, 2013. 768 Appendix A. Document Change Log 770 o Version 10 Posted July 2014. 772 * Document completely remodeled according to the discussions on 773 the mailing list in the thread 774 http://www.ietf.org/mail-archive/web/lisp/current/msg05206.html 775 and to address comments from Ronald Bonica and Ross Callon. 777 o Version 09 Posted March 2014. 779 * Updated document according to the review of A. Cabellos. 781 o Version 08 Posted October 2013. 783 * Addition of a privacy consideration note. 785 * Editorial changes 787 o Version 07 Posted October 2013. 789 * This version is updated according to the thorough review made 790 during October 2013 LISP WG interim meeting. 792 * Brief recommendations put in the security consideration 793 section. 795 * Editorial changes 797 o Version 06 Posted October 2013. 799 * Complete restructuration, temporary version to be used at 800 October 2013 interim meeting. 802 o Version 05 Posted August 2013. 804 * Removal of severity levels to become a short recommendation to 805 reduce the risk of the discussed threat. 807 o Version 04 Posted February 2013. 809 * Clear statement that the document compares threats of public 810 LISP deployments with threats in the current Internet 811 architecture. 813 * Addition of a severity level discussion at the end of each 814 section. 816 * Addressed comments from V. Ermagan and D. Lewis' reviews. 818 * Updated References. 820 * Further editorial polishing. 822 o Version 03 Posted October 2012. 824 * Dropped Reference to RFC 2119 notation because it is not 825 actually used in the document. 827 * Deleted future plans section. 829 * Updated References 831 * Deleted/Modified sentences referring to the early status of the 832 LISP WG and documents at the time of writing early versions of 833 the document. 835 * Further editorial polishing. 837 * Fixed all ID nits. 839 o Version 02 Posted September 2012. 841 * Added a new attack that combines over-claiming and de- 842 aggregation (see Section 3.8). 844 * Editorial polishing. 846 o Version 01 Posted February 2012. 848 * Added discussion on LISP-DDT. 850 o Version 00 Posted July 2011. 852 * Added discussion on LISP-MS>. 854 * Added discussion on Instance ID. 856 * Editorial polishing of the whole document. 858 * Added "Change Log" appendix to keep track of main changes. 860 * Renamed "draft-saucez-lisp-security-03.txt. 862 Authors' Addresses 864 Damien Saucez 865 INRIA 866 2004 route des Lucioles BP 93 867 06902 Sophia Antipolis Cedex 868 France 870 Email: damien.saucez@inria.fr 872 Luigi Iannone 873 Telecom ParisTech 874 23, Avenue d'Italie, CS 51327 875 75214 PARIS Cedex 13 876 France 878 Email: luigi.iannone@telecom-paristech.fr 880 Olivier Bonaventure 881 Universite catholique de Louvain 882 Place St. Barbe 2 883 Louvain la Neuve 884 Belgium 886 Email: olivier.bonaventure@uclouvain.be