idnits 2.17.1 draft-ietf-lisp-threats-11.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 (December 30, 2014) is 3395 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-02 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-07 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: July 3, 2015 Telecom ParisTech 6 O. Bonaventure 7 Universite catholique de Louvain 8 December 30, 2014 10 LISP Threats Analysis 11 draft-ietf-lisp-threats-11.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 July 3, 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Threat model . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.1. Attacker's Operation Modes . . . . . . . . . . . . . . . 3 55 2.1.1. On-path vs. Off-path Attackers . . . . . . . . . . . 4 56 2.1.2. Internal vs. External Attackers . . . . . . . . . . . 4 57 2.1.3. Live vs. Time-shifted attackers . . . . . . . . . . . 4 58 2.1.4. Control-plane vs. Data-plane attackers . . . . . . . 4 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 . . . . . . . . . 5 64 2.2.4. Spoofing . . . . . . . . . . . . . . . . . . . . . . 5 65 2.2.5. Rogue attack . . . . . . . . . . . . . . . . . . . . 6 66 2.2.6. Denial of Service (DoS) attack . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 12 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 mitigation techniques and general solutions to protect the 104 LISP protocol and 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's Operation Modes 144 Attackers can be classified according to the following four modes of 145 operation, i.e., the temporal and spacial diversity of the attacker. 147 2.1.1. On-path 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 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 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 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 complete isolation between the control-plane and the 195 data-plane, an attacker can operate in the control-plane (resp. 196 data-plane) to mount attacks targeting the data-plane (resp. 197 control-plane) or keep the attacked and targeted planes at the same 198 layer (i.e., from control-plane to control-plane or from data-plane 199 to 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 a 229 different 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. In case of data-plane 258 LISP encapsulation, that corresponds to spoof the source RLOC 259 address of the encapsulated packet. 261 Note that the two types of spoofing are not mutually exclusive, 262 rather all combinations are possible and could be used to perform 263 different kind of attacks. For example, an attacker outside a LISP 264 site can generate a packet with a forged source IP address (i.e., 265 outer address spoofing) and forward it to a LISP destination. The 266 packet is then eventually encapsulated by a PITR so that once 267 encapsulated the attack corresponds to a inner address spoofing. One 268 can also imagine an attacker forging a packet with encapsulation 269 where both inner an outer source addresses are spoofed. 271 It is important to notice that the combination of inner and outer 272 spoofing makes the identification of the attacker complex as the 273 packet may not contain information that allows to detect the origin 274 of the attack. 276 2.2.5. Rogue attack 278 In a rogue attack the attacker manages to appear as a legitimate 279 source of information, without faking its identity (as opposed to a 280 spoofing attacker). 282 2.2.6. Denial of Service (DoS) attack 284 A Denial of Service (DoS) attack aims at disrupting a specific 285 targeted service to make it unable to operate properly. 287 2.2.7. Performance attack 289 A performance attacks aims at exploiting computational resources 290 (e.g., memory, processor) of a targeted node so to make it unable to 291 operate properly. 293 2.2.8. Intrusion attack 295 In an intrusion attack the attacker gains remote access to a resource 296 (e.g., a host, a router, or a network) or information that it 297 normally doesn't have access to. Intrusion attacks can lead to 298 privacy leakages. 300 2.2.9. Amplification attack 302 In an amplification attack, the traffic generated by the target of 303 the attack in response to the attack is larger than the traffic that 304 the attacker must generate. 306 2.2.10. Multi-category attacks 308 Attacks categories are not mutually exclusive and any combination can 309 be used to perform specific attacks. 311 For example, one can mount a rogue attack to perform a performance 312 attack starving the memory of an ITR resulting in a DoS on the ITR. 314 3. Attack vectors 316 This section presents techniques that can be used by attackers to 317 succeed attacks leveraging the LISP protocol and/or architecture. 319 3.1. Gleaning 321 To reduce the time required to obtain a mapping, the optional 322 gleaning mechanism allows an xTR to directly learn a mapping from the 323 LISP data encapsulated packets and the Map-Request packets that it 324 receives. LISP encapsulated data packets contain a source RLOC, 325 destination RLOC, source EID and destination EID. When an xTR 326 receives an encapsulated data packet coming from a source EID for 327 which it does not already know a mapping, it may insert the mapping 328 between the source RLOC and the source EID in its EID-to-RLOC Cache. 329 The same technique can be used when an xTR receives a Map-Request as 330 the Map-Request also contains a source EID address and a source RLOC. 331 Once a gleaned entry has been added to the EID-to-RLOC cache, the xTR 332 sends a Map-Request to retrieve the actual mapping for the gleaned 333 EID from the mapping system. 335 If a packet injected by an off-path attacker and with a spoofed inner 336 address is gleaned by an xTR then the attacker may divert the traffic 337 meant to be delivered to the spoofed EID as long as the gleaned entry 338 is used by the xTR. This attack can be used as part of replay, 339 packet manipulation, packet interception and suppression, or DoS 340 attacks as the packets are sent to the attacker. 342 If the packet sent by the attacker contains a spoofed outer address 343 instead of a spoofed inner address then it can succeed a DoS or a 344 performance attack as the traffic normally destined to the attacker 345 will be redirected to the spoofed source RLOC. Such traffic may 346 overload the owner of the spoofed source RLOC, preventing it from 347 operating properly. 349 If the packet injected uses both inner and outer spoofing, the 350 attacker can succeed a spoofing, a performance, or an amplification 351 attack as traffic normally destined to the spoofed EID address will 352 be sent to the spoofed RLOC address. If the attacked LISP site also 353 generates traffic to the spoofed EID address, such traffic may have a 354 positive amplification factor. 356 A gleaning attack does not only impact the data-plane but can also 357 have repercussions on the control-plane as a Map-Request is sent 358 after the creation of a gleaned entry. The attacker can then succeed 359 DoS and performance attacks on the control-plane. For example, if an 360 attacker sends a packet for each address of a prefix not yet cached 361 in the EID-to-RLOC cache of an xTR, the xTR will potentially send a 362 Map-Request for each such packet until the mapping is installed which 363 leads to an over-utilisation of the control-plane as each packet 364 generates a control-plane event. For succeeding this example, the 365 attacker may not need to use spoofing. 367 Gleaning attacks are fundamentally involving a time-shifted mode of 368 operation as the attack may last as long as the gleaned entry is kept 369 by the targeted xTR. RFC 6830 [RFC6830] recommends to store the 370 gleaned entries for only a few seconds which limits the duration of 371 the attack. 373 Gleaning attacks always involve external data-plane attackers but 374 results in attacks on either the control-plane or data-plane. 376 It is worth to notice that the outer spoofed address does not need to 377 be the RLOC of a LISP site an may be any address. 379 3.2. Locator Status Bits 381 When the L bit in the LISP header is set to 1, it indicates that the 382 second 32-bits longword of the LISP header contains the Locator 383 Status Bits. In this field, each bit position reflects the status of 384 one of the RLOCs mapped to the source EID found in the encapsulated 385 packet. The reaction of a LISP xTR that receives such a packet is 386 left as operational choice in [RFC6830]. 388 When an attacker sends a LISP encapsulated packet with a crafted LSB 389 to an xTR, it can influence the xTR's choice of the locators for the 390 prefix associated to the source EID. In case of an off-path 391 attacker, the attacker must inject a forged packet in the network 392 with a spoofed inner address. An on-path attacker can manipulate the 393 LSB of legitimate packets passing through it and hence does not need 394 to use spoofing. Instead of manipulating the LSB field, an on-path 395 attacker can also obtain the same result of injecting packets with 396 invalid LSB values by replaying packets. 398 The LSB field can be leveraged to succeed a DoS attack by either 399 declaring all RLOCs as unreachable (all LSB set to 0), or by 400 concentrating all the traffic to one RLOC (e.g., all but one LSB set 401 to 0) and hence overloading the RLOC concentrating all the traffic 402 from the xTR, or by forcing packets to be sent to RLOCs that are 403 actually not reachable (e.g., invert LSB values). 405 The LSB field can also be used to mount a replay, a packet 406 manipulation, or a packet interception and suppression attack. 407 Indeed, if the attacker manages to be on the path between the xTR and 408 one of the RLOCs specified in the mapping, forcing packets to go via 409 that RLOC implies that the attacker will gain access to the packets. 411 Attacks using the LSB are fundamentally involving a time-shifted mode 412 of operation as the attack may last as long as the reachability 413 information gathered from the LSB is used by the xTR to decide the 414 RLOCs to be used. 416 3.3. Map-Version 418 When the Map-Version bit of the LISP header is set to 1, it indicates 419 that the low-order 24 bits of the first 32 bits longword of the LISP 420 header contain a Source and Destination Map-Version. When a LISP xTR 421 receives a LISP encapsulated packet with the Map-Version bit set to 422 1, the following actions are taken: 424 o It compares the Destination Map-Version found in the header with 425 the current version of its own configured EID-to-RLOC mapping, for 426 the destination EID found in the encapsulated packet. If the 427 received Destination Map-Version is smaller (i.e., older) than the 428 current version, the ETR should apply the SMR procedure described 429 in [RFC6830] and send a Map-Request with the SMR bit set. 431 o If a mapping exists in the EID-to-RLOC Cache for the source EID, 432 then it compares the Map-Version of that entry with the Source 433 Map-Version found in the header of the packet. If the stored 434 mapping is older (i.e., the Map-Version is smaller) than the 435 source version of the LISP encapsulated packet, the xTR should 436 send a Map-Request for the source EID. 438 A cross-mode attacker can use the Map-Version bit to mount a DoS 439 attack, an amplification attack, or a spoofing attack. For instance 440 if the mapping cached at the xTR is outdated, the xTR will send a 441 Map-Request to retrieve the new mapping which can yield to a DoS 442 attack (by excess of signalling traffic) or an amplification attack 443 if the data-plane packet sent by the attacker is smaller than the 444 control-plane packets sent in response to the attacker's packet. 445 With a spoofing attack and if the xTR considers that the spoofed ITR 446 has an outdated mapping, it will send an SMR to the spoofed ITR which 447 can result in performance, amplification, or DoS attack as well. 449 Map-Version attackers are inherently cross mode as the Map-Version is 450 a method to put control information in the data-plane. Moreover, 451 this vector involves live attackers. Nevertheless, on-path attackers 452 do not take specific advantage over off-path attackers. 454 3.4. Echo-Nonce 456 The Nonce-Present and Echo-Nonce bits in the LISP header are used to 457 verify the reachability of an xTR. A testing xTR sets the Echo-Nonce 458 and the Nonce-Present bits in LISP data encapsulated packets and 459 include a random nonce in the LISP header of packets. Upon reception 460 of these packets, the tested xTR stores the nonce and echo it 461 whenever it returns a LISP encapsulated data packets to the testing 462 xTR. The reception of the echoed nonce confirms that the tested xTR 463 is reachable. 465 An attacker can interfere with the reachability test by sending two 466 different types of packets: 468 1. LISP data encapsulated packets with the Nonce-Present bit set and 469 a random nonce. Such packets are normally used in response to a 470 reachability test. 472 2. LISP data encapsulated packets with the Nonce-Present and the 473 Echo-Nonce bits both set. These packets will force the receiving 474 ETR to store the received nonce and echo it in the LISP 475 encapsulated packets that it sends. These packets are normally 476 used as trigger for a reachability test. 478 The first type of packets is used to make xTRs think that an other 479 xTR is reachable while it is not. It is hence a way to mount a DoS 480 attack (i.e., the ITR will send its packet to a non-reachable ETR 481 while it should use another one). 483 The second type of packets could be exploited to attack the nonce- 484 based reachability test. If the attacker sends a continuous flow of 485 packets that each have a different random nonce, the ETR that 486 receives such packets will continuously change the nonce that it 487 returns to the remote ITR, which can yield to a performance attack. 488 If the remote ITR tries a nonce-reachability test, this test may fail 489 because the ETR may echo an invalid nonce. This hence yields to a 490 DoS attack. 492 In the case of an on-path attacker, a packet manipulation attack is 493 necessary to mount the attack. To mount such an attack, an off-path 494 attacker must mount an outer address spoofing attack. 496 3.5. Instance ID 498 LISP allows to carry in its header a 24-bits value called Instance ID 499 and used on the ITR to indicate which local Instance ID has been used 500 for encapsulation, while on the ETR the instance ID decides the 501 forwarding table to use to forward the decapsulated packet in the 502 LISP site. 504 An attacker (either a control-plane or data-plane attacker) can use 505 the instance ID functionality to mount an intrusion attack. 507 3.6. Interworking 509 [RFC6832] defines Proxy-ITR and Proxy-ETR network elements to allow 510 LISP and non-LISP sites to communicate. The Proxy-ITR has 511 functionality similar to the ITR, however, its main purpose is to 512 encapsulate packets arriving from the DFZ in order to reach LISP 513 sites. A Proxy-ETR has functionality similar to the ETR, however, 514 its main purpose is to inject de-encapsulated packets in the DFZ in 515 order to reach non-LISP Sites from LISP sites. As a PITR (resp. 516 PETR) is a particular case of ITR (resp. ETR), it is subject to same 517 attacks than ITRs (resp. ETR). 519 As any other system relying on proxies, LISP interworking can be used 520 by attackers to hide their exact origin in the network. 522 3.7. Map-Request messages 524 A control-plane off-path attacker can exploit Map-Request messages to 525 mount DoS, performance, or amplification attacks. By sending Map- 526 Request messages at high rate, the attacker can overload nodes 527 involved in the mapping system. For instance sending Map-Requests at 528 high rate can considerably increase the state maintained in a Map- 529 Resolver or consume CPU cycles on ETRs that have to process the Map- 530 Request packets they receive in their slow path (i.e., performance or 531 DoS attack). When the Map-Reply packet is larger than the Map- 532 Request sent by the attacker, that yields to an amplification attack. 533 The attacker can combine the attack with a spoofing attack to 534 overload the node to which the spoofed address is actually attached. 536 It is worth to notice that if the attacker sets the P bit (Probe Bit) 537 in the Map-Request, it is legitimate the send the Map-Request 538 directly to the ETR instead of passing through the mapping system. 540 The SMR bit can be used to mount a variant of these attacks. 542 For efficiency reasons, Map-Records can be appended to Map-Request 543 messages. When an xTR receives a Map-Request with appended Map- 544 Records, it does the same operations as for the other Map-Request 545 messages and is so subject to the same attacks. However, it also 546 installs in its EID-to-RLOC cache the Map-Records contained in the 547 Map-Request. An attacker can then use this vector to force the 548 installation of mappings in its target xTR. Consequently, the EID- 549 to-RLOC cache of the xTR is polluted by potentially forged mappings 550 allowing the attacker to mount any of the attacks categorized in 551 Section 2.2 (see Section 3.8 for more details). It is worth to 552 mention that the attacker does not need to forge the mappings present 553 in the Map-Request to succeed a performance or DoS attack. Indeed, 554 if the attacker owns a large enough EID prefix it can de-aggregate it 555 in many small prefixes, each corresponding to another mapping and it 556 installs them in the xTR cache by mean of the Map-Request. 558 Moreover, attackers can use Map Resolver and/or Map Server network 559 elements to relay its attacks and hide the origin of the attack. 560 Indeed, on the one hand, a Map Resolver is used to dispatch Map- 561 Request to the mapping system and, on the other hand, a Map Server is 562 used to dispatch Map-Requests coming from the mapping system to ETRs 563 that are authoritative for the EID in the Map-Request. 565 3.8. Map-Reply messages 567 Most of the security of the Map-Reply messages depends on the 64 bits 568 nonce that is included in a Map-Request and returned in the Map- 569 Reply. If an ETR does not accept Map-Reply messages with an invalid 570 nonce, the risk of attack is limited given the size of the nonce (64 571 bits). Nevertheless, the nonce only confirms that the Map-Reply 572 received was sent in response to a Map-Request sent, it does not 573 validate the contents of that Map-Reply. 575 If an attacker manages to send a valid (i.e., in response to a Map- 576 Request and with the correct nonce) Map-Reply to an ITR, then it can 577 perform any of the attack categorised in Section 2.2 as it can inject 578 forged mappings directly in the ITR EID-to-RLOC cache. For instance, 579 if the mapping injected to the ITR points to the address of a node 580 controlled by the attacker, it can mount replay, packet manipulation, 581 packet interception and suppression, or DoS attacks as it will 582 receive every packet destined to a destination lying in the EID 583 prefix of the injected mapping. In addition, the attacker can inject 584 plethora of mappings in the ITR to mount a performance attack by 585 filling up the EID-to-RLOC cache of the ITR. If the attacker can 586 also mount an amplification attack as soon as the ITR has to send a 587 lot of packets to the EIDs matching the injected mapping. In this 588 case, the RLOC address associated to the mapping is the address of 589 the real target of the attacker and all the traffic of the ITR will 590 be sent to the target which means that with one single packet the 591 attacker may generate very high traffic towards its final target. 593 If the attacker is a valid ETR in the system it can mount a rogue 594 attack if it uses prefixes over-claiming. In such a scenario, the 595 attacker ETR replies to a legitimate Map-Request message it received 596 with a Map-Reply message that contains an EID-Prefix that is larger 597 than the prefix owned by the attacker. For instance if the owned 598 prefix is 192.0.2.0/25 but the Map-Reply contains a mapping for 599 192.0.2.0/24, then the mapping will influence packets destined to 600 other EIDs than the one attacker has authority on. With such 601 technique, the attacker can mount the attacks presented above as it 602 can (partially) control the mappings installed on its target ITR. To 603 force its target ITR to send a Map-Request, nothing prevents the 604 attacker to initiate some communication with the ITR. This method 605 can be used by internal attackers that want to control the mappings 606 installed in their site. To that aim, they simply have to collude 607 with an external attacker ready to over-claim prefixes on behalf of 608 the internal attacker. 610 It is worth to notice that when the Map-Reply is in response to a 611 Map-Request sent via the mapping system (i.e., not send directly from 612 the ITR to an ETR), the attacker does not need to use a spoofing 613 attack to succeed its attack as by design the source IP address of a 614 Map-Reply is not known in advance by the ITR. 616 Map-Request and Map-Reply messages are exposed to any type of 617 attackers, on-path or off-path but also external or internal 618 attackers. Also, even though they are control message, they can be 619 leveraged by data-plane attackers. As the decision of removing 620 mappings is based on the TTL indicated in the mapping, time-shifted 621 attackers can take benefit of injecting forged mappings as well. 623 3.9. Map-Register messages 625 Map-Register messages are sent by ETRs to Map Servers to indicate to 626 the mapping system the EID prefixes associated to them. The Map- 627 Register message provides an EID prefix and the list of ETRs that are 628 able to provide Map-Replies for the EID covered by the EID prefix. 630 As Map-Register messages are protected by an authentication 631 mechanism, only a compromised ETR can register itself to its 632 allocated Map Server. 634 A compromised ETR can over-claim the prefix it owns in order to 635 influence the route followed by Map-Requests for EIDs outside the 636 scope of its legitimate EID prefix (see Section 3.8 for the list of 637 over-claiming attacks). 639 A compromised ETR can also de-aggregate its EID prefix in order to 640 register more EID prefixes than necessary to its Map Servers (see 641 Section 3.7 for the impact of de-aggregation of prefixes by an 642 attacker). 644 Similarly, a compromised Map Server can accept invalid registration 645 or advertise invalid EID prefix to the mapping system. 647 3.10. Map-Notify messages 649 Map-Notify messages are sent by a Map Server to an ETR to acknowledge 650 the good reception and processing of a Map-Register message. 652 Similarly to the pair Map-Request/Map-Reply, the pair Map-Register/ 653 Map-Notify is protected by a nonce making it hard for an attacker to 654 inject a falsified notification to an ETR to make this ETR believe 655 that the registration succeeded while it has not. 657 4. Note on Privacy 659 As presented by [RFC6973], universal privacy considerations are 660 impossible to establish as the privacy definition may vary from one 661 to another. As a consequence, this document does not aim at 662 identifying privacy issues related to the LISP protocol but it is 663 necessary to highlight that security threats identified in this 664 document could play a role in privacy threats as defined in section 5 665 of [RFC6973]. 667 Note, however, that like public deployments of any other control 668 plane protocol, in an Internet deployment mappings are public and 669 hence provide information about the infrastructure and reachability 670 of LISP sites (i.e., the addresses of the edge routers). 672 5. IANA Considerations 674 This document makes no request to IANA. 676 6. Security Considerations 678 This document is devoted to threat analysis of the Locator/Identifier 679 Separation Protocol and is then a piece of choice to understand the 680 security risks at stake while deploying LISP in non-trustable 681 environment. 683 The purpose of this document is not to provide recommendations to 684 protect against attacks, however most of threats can be prevented 685 with careful deployment and configuration (e.g., filter) and also by 686 applying the general rules in security that consist in activating 687 only features that are necessary in the deployment and verifying the 688 validity of the information obtained from third parties. More 689 detailed recommendations are given in [Saucez13]. 691 The control-plane is probably the most critical part of LISP from a 692 security viewpoint and it is worth to notice that the specifications 693 already offer authentication mechanism for Map-Register messages 694 ([RFC6833]) and that [I-D.ietf-lisp-sec] and [I-D.ietf-lisp-ddt] are 695 clearly going in the direction of a secure control-plane. 697 7. Acknowledgments 699 This document builds upon the draft of Marcelo Bagnulo 700 ([I-D.bagnulo-lisp-threat]), where the flooding attack and the 701 reference environment were first described. 703 The authors would like to thank Ronald Bonica, Albert Cabellos, Ross 704 Callon, Noel Chiappa, Florin Coras, Vina Ermagan, Dino Farinacci, 705 Stephen Farrell, Joel Halpern, Emily Hiltzik, Darrel Lewis, Edward 706 Lopez, Fabio Maino, Terry Manderson, and Jeff Wheeler for their 707 comments. 709 This work has been partially supported by the INFSO-ICT-216372 710 TRILOGY Project (www.trilogy-project.org). 712 The work of Luigi Iannone has been partially supported by the ANR- 713 13-INFR-0009 LISP-Lab Project (www.lisp-lab.org) and the EIT KIC ICT- 714 Labs SOFNETS Project. 716 8. References 718 8.1. Normative References 720 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 721 Locator/ID Separation Protocol (LISP)", RFC 6830, January 722 2013. 724 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 725 "Interworking between Locator/ID Separation Protocol 726 (LISP) and Non-LISP Sites", RFC 6832, January 2013. 728 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 729 Protocol (LISP) Map-Server Interface", RFC 6833, January 730 2013. 732 [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID 733 Separation Protocol (LISP) Map-Versioning", RFC 6834, 734 January 2013. 736 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 737 Morris, J., Hansen, M., and R. Smith, "Privacy 738 Considerations for Internet Protocols", RFC 6973, July 739 2013. 741 8.2. Informative References 743 [I-D.bagnulo-lisp-threat] 744 Bagnulo, M., "Preliminary LISP Threat Analysis", draft- 745 bagnulo-lisp-threat-01 (work in progress), 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-02 (work in 750 progress), October 2014. 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-07 755 (work in progress), October 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 11 Posted December 2014. 772 * Editorial polishing. Clarifications added in few points. 774 o Version 10 Posted July 2014. 776 * Document completely remodeled according to the discussions on 777 the mailing list in the thread http://www.ietf.org/mail- 778 archive/web/lisp/current/msg05206.html and to address comments 779 from Ronald Bonica and Ross Callon. 781 o Version 09 Posted March 2014. 783 * Updated document according to the review of A. Cabellos. 785 o Version 08 Posted October 2013. 787 * Addition of a privacy consideration note. 789 * Editorial changes 791 o Version 07 Posted October 2013. 793 * This version is updated according to the thorough review made 794 during October 2013 LISP WG interim meeting. 796 * Brief recommendations put in the security consideration 797 section. 799 * Editorial changes 801 o Version 06 Posted October 2013. 803 * Complete restructuration, temporary version to be used at 804 October 2013 interim meeting. 806 o Version 05 Posted August 2013. 808 * Removal of severity levels to become a short recommendation to 809 reduce the risk of the discussed threat. 811 o Version 04 Posted February 2013. 813 * Clear statement that the document compares threats of public 814 LISP deployments with threats in the current Internet 815 architecture. 817 * Addition of a severity level discussion at the end of each 818 section. 820 * Addressed comments from V. Ermagan and D. Lewis' reviews. 822 * Updated References. 824 * Further editorial polishing. 826 o Version 03 Posted October 2012. 828 * Dropped Reference to RFC 2119 notation because it is not 829 actually used in the document. 831 * Deleted future plans section. 833 * Updated References 835 * Deleted/Modified sentences referring to the early status of the 836 LISP WG and documents at the time of writing early versions of 837 the document. 839 * Further editorial polishing. 841 * Fixed all ID nits. 843 o Version 02 Posted September 2012. 845 * Added a new attack that combines over-claiming and de- 846 aggregation (see Section 3.8). 848 * Editorial polishing. 850 o Version 01 Posted February 2012. 852 * Added discussion on LISP-DDT. 854 o Version 00 Posted July 2011. 856 * Added discussion on LISP-MS>. 858 * Added discussion on Instance ID. 860 * Editorial polishing of the whole document. 862 * Added "Change Log" appendix to keep track of main changes. 864 * Renamed "draft-saucez-lisp-security-03.txt. 866 Authors' Addresses 868 Damien Saucez 869 INRIA 870 2004 route des Lucioles BP 93 871 06902 Sophia Antipolis Cedex 872 France 874 Email: damien.saucez@inria.fr 876 Luigi Iannone 877 Telecom ParisTech 878 23, Avenue d'Italie, CS 51327 879 75214 PARIS Cedex 13 880 France 882 Email: luigi.iannone@telecom-paristech.fr 884 Olivier Bonaventure 885 Universite catholique de Louvain 886 Place St. Barbe 2 887 Louvain la Neuve 888 Belgium 890 Email: olivier.bonaventure@uclouvain.be