idnits 2.17.1 draft-ietf-lisp-threats-13.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 (August 26, 2015) is 3166 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-03 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-08 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: February 27, 2016 Telecom ParisTech 6 O. Bonaventure 7 Universite catholique de Louvain 8 August 26, 2015 10 LISP Threats Analysis 11 draft-ietf-lisp-threats-13.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 February 27, 2016. 35 Copyright Notice 37 Copyright (c) 2015 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's Operation Modes . . . . . . . . . . . . . . . . 4 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 . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 3.2. Locator Status Bits . . . . . . . . . . . . . . . . . . . 9 74 3.3. Map-Version . . . . . . . . . . . . . . . . . . . . . . . 10 75 3.4. Routing Locator Reachability . . . . . . . . . . . . . . . 10 76 3.5. Instance ID . . . . . . . . . . . . . . . . . . . . . . . 11 77 3.6. Interworking . . . . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . 15 82 4. Note on Privacy . . . . . . . . . . . . . . . . . . . . . . . 15 83 5. Threats Mitigation . . . . . . . . . . . . . . . . . . . . . . 15 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 86 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 88 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 89 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 90 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 18 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 93 1. Introduction 95 The Locator/ID Separation Protocol (LISP) is specified in [RFC6830]. 96 The present document assess the potential security threats identified 97 in the LISP specifications if LISP is deployed in the Internet (i.e., 98 a public non-trustable environment). 100 The document is composed of three main parts: the first defines the 101 general threat model that attackers can follow to mount attacks. The 102 second describes the techniques based on the LISP protocol and 103 architecture that attackers can use to construct attacks. The third 104 discusses mitigation techniques and general solutions to protect the 105 LISP protocol and architecture from attacks. 107 This document does not consider all the possible uses of LISP as 108 discussed in [RFC6830] and [RFC7215]. The document focuses on LISP 109 unicast, including as well LISP Interworking [RFC6832], LISP-MS 110 [RFC6833], and LISP Map-Versioning [RFC6834]. The reading of these 111 documents is a prerequisite for understanding the present document. 113 This document assumes a generic IP service and does not discuss the 114 difference, from a security viewpoint, between using IPv4 or IPv6. 116 2. Threat model 118 This document assumes that attackers can be located anywhere in the 119 Internet (either in LISP sites or outside LISP sites) and that 120 attacks can be mounted either by a single attacker or by the 121 collusion of several attackers. 123 An attacker is a malicious entity that performs the action of 124 attacking a target in a network where LISP is (partially) deployed by 125 leveraging the LISP protocol and/or architecture. 127 An attack is the action of performing an illegitimate action on a 128 target in a network where LISP is (partially) deployed. 130 The target of an attack is the entity (i.e., a device connected to 131 the network or a network) that is aimed to undergo the consequences 132 of an attack. Other entities can potentially undergo side effects of 133 an attack, even though they are not directly targeted by the attack. 134 The target of an attack can be selected specifically, i.e., a 135 particular entity, or arbitrarily, i.e., any entity. Finally, an 136 attacker can aim at attacking one or several targets with a single 137 attack. 139 Section 2.1 specifies the different modes of operation that attackers 140 can follow to mount attacks and Section 2.2 specifies the different 141 categories of attacks that attackers can build. 143 2.1. Attacker's Operation Modes 145 Attackers can be classified according to the following four modes of 146 operation, i.e., the temporal and spacial diversity of the attacker. 148 2.1.1. On-path vs. Off-path Attackers 150 On-path attackers, also known as Men-in-the-Middle, are able to 151 intercept and modify packets between legitimate communicating 152 entities. On-path attackers are located either directly on the 153 normal communication path (either by gaining access to a node on the 154 path or by placing themselves directly on the path) or outside the 155 location path but manage to deviate (or gain a copy of) packets sent 156 between the communication entities. On-path attackers hence mount 157 their attacks by modifying packets initially sent legitimately 158 between communication entities. 160 An attacker is called off-path attacker if it does not have access to 161 packets exchanged during the communication or if there is no 162 communication. In order for their attacks to succeed, off-path 163 attackers must hence generate packets and inject them in the network. 165 2.1.2. Internal vs. External Attackers 167 An internal attacker launches its attack from a node located within a 168 legitimate LISP site. Such an attacker is either a legitimate node 169 of the site or it exploits a vulnerability to gain access to a 170 legitimate node in the site. Because of their location, internal 171 attackers are trusted by the site they are in. 173 On the contrary, an external attacker launches its attacks from the 174 outside of a legitimate LISP site. 176 2.1.3. Live vs. Time-shifted attackers 178 A live attacker mounts attacks for which it must remain connected as 179 long as the attack is mounted. In other words, the attacker must 180 remain active for the whole duration of the attack. Consequently, 181 the attack ends as soon as the attacker (or the used attack vector) 182 is neutralized. 184 On the contrary, a time-shifted attacker mounts attacks that remain 185 active after it disconnects from the Internet. 187 2.1.4. Control-plane vs. Data-plane attackers 189 A control-plane attacker mounts its attack by using control-plane 190 functionalities, typically the mapping system. 192 A data-plane attacker mounts its attack by using data-plane 193 functionalities. 195 As there is no complete isolation between the control-plane and the 196 data-plane, an attacker can operate in the control-plane (resp. data- 197 plane) to mount attacks targeting the data-plane (resp. control- 198 plane) or keep the attacked and targeted planes at the same layer 199 (i.e., from control-plane to control-plane or from data-plane to 200 data-plane). 202 2.1.5. Cross mode attackers 204 The attacker modes of operation are not mutually exclusive and hence 205 attackers can combine them to mount attacks. 207 For example, an attacker can launch an attack using the control-plane 208 directly from within a LISP site to which it got temporary access 209 (i.e., internal + control-plane attacker) to create a vulnerability 210 on its target and later on (i.e., time-shifted + external attacker) 211 mount an attack on the data plane (i.e., data-plane attacker) that 212 leverages the vulnerability. 214 2.2. Threat categories 216 Attacks can be classified according to the nine following categories. 218 2.2.1. Replay attack 220 A replay attack happens when an attacker retransmits at a later time, 221 and without modifying it, a packet (or a sequence of packets) that 222 has already been transmitted. 224 2.2.2. Packet manipulation 226 A packet manipulation attack happens when an attacker receives a 227 packet, modifies the packet (i.e., changes some information contained 228 in the packet) and finally transmits the packet to its final 229 destination that can be the initial destination of the packet or a 230 different one. 232 2.2.3. Packet interception and suppression 234 In a packet interception and suppression attack, the attacker 235 captures the packet and drops it before it can reach its final 236 destination. 238 2.2.4. Spoofing 240 With a spoofing attack, the attacker injects packets in the network 241 pretending being another node. Spoofing attacks are made by forging 242 source addresses in packets. 244 It should be noted that with LISP, packet spoofing is similar to any 245 other existing tunneling technology currently deployed in the 246 Internet. Generally the term "spoofed packet" indicates a packet 247 containing a source IP address that is not the one of the actual 248 originator of the packet. Hence, since LISP uses encapsulation, the 249 spoofed address could be in the outer header as well as in the inner 250 header, this translates in two types of spoofing. 252 Inner address spoofing: the attacker uses encapsulation and uses a 253 spoofed source address in the inner packet. In case of data- 254 plane LISP encapsulation, that corresponds to spoof the source 255 EID address of the encapsulated packet. 257 Outer address spoofing: the attacker does not use encapsulation and 258 spoofs the source address of the packet. In case of data-plane 259 LISP encapsulation, that corresponds to spoof the source RLOC 260 address of the encapsulated packet. 262 Note that the two types of spoofing are not mutually exclusive, 263 rather all combinations are possible and could be used to perform 264 different kind of attacks. For example, an attacker outside a LISP 265 site can generate a packet with a forged source IP address (i.e., 266 outer address spoofing) and forward it to a LISP destination. The 267 packet is then eventually encapsulated by a PITR so that once 268 encapsulated the attack corresponds to a inner address spoofing. One 269 can also imagine an attacker forging a packet with encapsulation 270 where both inner an outer source addresses are spoofed. 272 It is important to notice that the combination of inner and outer 273 spoofing makes the identification of the attacker complex as the 274 packet may not contain information that allows to detect the origin 275 of the attack. 277 2.2.5. Rogue attack 279 In a rogue attack the attacker manages to appear as a legitimate 280 source of information, without faking its identity (as opposed to a 281 spoofing attacker). 283 2.2.6. Denial of Service (DoS) attack 285 A Denial of Service (DoS) attack aims at disrupting a specific 286 targeted service to make it unable to operate properly. 288 2.2.7. Performance attack 290 A performance attacks aims at exploiting computational resources 291 (e.g., memory, processor) of a targeted node so to make it unable to 292 operate properly. 294 2.2.8. Intrusion attack 296 In an intrusion attack the attacker gains remote access to a resource 297 (e.g., a host, a router, or a network) or information that it 298 normally doesn't have access to. Intrusion attacks can lead to 299 privacy leakages. 301 2.2.9. Amplification attack 303 In an amplification attack, the traffic generated by the target of 304 the attack in response to the attack is larger than the traffic that 305 the attacker must generate. 307 In some cases, the data-plane can be several order of magnitude 308 faster than the control-plane at processing packets. This difference 309 can be exploited to overload the control-plane via the data-plane 310 without overloading the data-plane. 312 2.2.10. Multi-category attacks 314 Attacks categories are not mutually exclusive and any combination can 315 be used to perform specific attacks. 317 For example, one can mount a rogue attack to perform a performance 318 attack starving the memory of an ITR resulting in a DoS on the ITR. 320 3. Attack vectors 322 This section presents techniques that can be used by attackers in 323 order to succeed attacks leveraging the LISP protocol and/or 324 architecture. 326 3.1. Gleaning 328 To reduce the time required to obtain a mapping, the optional 329 gleaning mechanism allows an xTR to directly learn a mapping from the 330 LISP data encapsulated packets and the Map-Request packets that it 331 receives. LISP encapsulated data packets contain a source RLOC, 332 destination RLOC, source EID and destination EID. When an xTR 333 receives an encapsulated data packet coming from a source EID for 334 which it does not already know a mapping, it may insert the mapping 335 between the source RLOC and the source EID in its EID-to-RLOC Cache. 336 The same technique can be used when an xTR receives a Map-Request as 337 the Map-Request also contains a source EID address and a source RLOC. 338 Once a gleaned entry has been added to the EID-to-RLOC cache, the xTR 339 sends a Map-Request to retrieve the actual mapping for the gleaned 340 EID from the mapping system. 342 If a packet injected by an off-path attacker and with a spoofed inner 343 address is gleaned by an xTR then the attacker may divert the traffic 344 meant to be delivered to the spoofed EID as long as the gleaned entry 345 is used by the xTR. This attack can be used as part of replay, 346 packet manipulation, packet interception and suppression, or DoS 347 attacks as the packets are sent to the attacker. 349 If the packet sent by the attacker contains a spoofed outer address 350 instead of a spoofed inner address then it can achieve a DoS or a 351 performance attack as the traffic normally destined to the attacker 352 will be redirected to the spoofed source RLOC. Such traffic may 353 overload the owner of the spoofed source RLOC, preventing it from 354 operating properly. 356 If the packet injected uses both inner and outer spoofing, the 357 attacker can achieve a spoofing, a performance, or an amplification 358 attack as traffic normally destined to the spoofed EID address will 359 be sent to the spoofed RLOC address. If the attacked LISP site also 360 generates traffic to the spoofed EID address, such traffic may have a 361 positive amplification factor. 363 A gleaning attack does not only impact the data-plane but can also 364 have repercussions on the control-plane as a Map-Request is sent 365 after the creation of a gleaned entry. The attacker can then achieve 366 DoS and performance attacks on the control-plane. For example, if an 367 attacker sends a packet for each address of a prefix not yet cached 368 in the EID-to-RLOC cache of an xTR, the xTR will potentially send a 369 Map-Request for each such packet until the mapping is installed which 370 leads to an over-utilisation of the control-plane as each packet 371 generates a control-plane event. In order for this attack to 372 succeed, the attacker may not need to use spoofing. This issue can 373 occur even if gleaning is turned off since whether or not gleaning is 374 used the ITR may need to send a Map-Request in response to incoming 375 packets whose EID is not currently in the cache. 377 Gleaning attacks are fundamentally involving a time-shifted mode of 378 operation as the attack may last as long as the gleaned entry is kept 379 by the targeted xTR. RFC 6830 [RFC6830] recommends to store the 380 gleaned entries for only a few seconds which limits the duration of 381 the attack. 383 Gleaning attacks always involve external data-plane attackers but 384 results in attacks on either the control-plane or data-plane. 386 It is worth to notice that the outer spoofed address does not need to 387 be the RLOC of a LISP site an may be any address. 389 3.2. Locator Status Bits 391 When the L bit in the LISP header is set to 1, it indicates that the 392 second 32-bits longword of the LISP header contains the Locator 393 Status Bits. In this field, each bit position reflects the status of 394 one of the RLOCs mapped to the source EID found in the encapsulated 395 packet. The reaction of a LISP xTR that receives such a packet is 396 left as operational choice in [RFC6830]. 398 When an attacker sends a LISP encapsulated packet with a crafted LSB 399 to an xTR, it can influence the xTR's choice of the locators for the 400 prefix associated to the source EID. In case of an off-path 401 attacker, the attacker must inject a forged packet in the network 402 with a spoofed inner address. An on-path attacker can manipulate the 403 LSB of legitimate packets passing through it and hence does not need 404 to use spoofing. Instead of manipulating the LSB field, an on-path 405 attacker can also obtain the same result of injecting packets with 406 invalid LSB values by replaying packets. 408 The LSB field can be leveraged to mount a DoS attack by either 409 declaring all RLOCs as unreachable (all LSB set to 0), or by 410 concentrating all the traffic to one RLOC (e.g., all but one LSB set 411 to 0) and hence overloading the RLOC concentrating all the traffic 412 from the xTR, or by forcing packets to be sent to RLOCs that are 413 actually not reachable (e.g., invert LSB values). 415 The LSB field can also be used to mount a replay, a packet 416 manipulation, or a packet interception and suppression attack. 417 Indeed, if the attacker manages to be on the path between the xTR and 418 one of the RLOCs specified in the mapping, forcing packets to go via 419 that RLOC implies that the attacker will gain access to the packets. 421 Attacks using the LSB are fundamentally involving a time-shifted mode 422 of operation as the attack may last as long as the reachability 423 information gathered from the LSB is used by the xTR to decide the 424 RLOCs to be used. 426 3.3. Map-Version 428 When the Map-Version bit of the LISP header is set to 1, it indicates 429 that the low-order 24 bits of the first 32 bits longword of the LISP 430 header contain a Source and Destination Map-Version. When a LISP xTR 431 receives a LISP encapsulated packet with the Map-Version bit set to 432 1, the following actions are taken: 434 o It compares the Destination Map-Version found in the header with 435 the current version of its own configured EID-to-RLOC mapping, for 436 the destination EID found in the encapsulated packet. If the 437 received Destination Map-Version is smaller (i.e., older) than the 438 current version, the ETR should apply the SMR procedure described 439 in [RFC6830] and send a Map-Request with the SMR bit set. 441 o If a mapping exists in the EID-to-RLOC Cache for the source EID, 442 then it compares the Map-Version of that entry with the Source 443 Map-Version found in the header of the packet. If the stored 444 mapping is older (i.e., the Map-Version is smaller) than the 445 source version of the LISP encapsulated packet, the xTR should 446 send a Map-Request for the source EID. 448 A cross-mode attacker can use the Map-Version bit to mount a DoS 449 attack, an amplification attack, or a spoofing attack. For instance 450 if the mapping cached at the xTR is outdated, the xTR will send a 451 Map-Request to retrieve the new mapping which can yield to a DoS 452 attack (by excess of signalling traffic) or an amplification attack 453 if the data-plane packet sent by the attacker is smaller, or 454 otherwise uses fewer resources, than the control-plane packets sent 455 in response to the attacker's packet. With a spoofing attack and if 456 the xTR considers that the spoofed ITR has an outdated mapping, it 457 will send an SMR to the spoofed ITR which can result in performance, 458 amplification, or DoS attack as well. 460 Map-Version attackers are inherently cross mode as the Map-Version is 461 a method to put control information in the data-plane. Moreover, 462 this vector involves live attackers. Nevertheless, on-path attackers 463 do not take specific advantage over off-path attackers. 465 3.4. Routing Locator Reachability 467 The Nonce-Present and Echo-Nonce bits in the LISP header are used to 468 verify the reachability of an xTR. A testing xTR sets the Echo-Nonce 469 and the Nonce-Present bits in LISP data encapsulated packets and 470 include a random nonce in the LISP header of packets. Upon reception 471 of these packets, the tested xTR stores the nonce and echo it 472 whenever it returns a LISP encapsulated data packets to the testing 473 xTR. The reception of the echoed nonce confirms that the tested xTR 474 is reachable. 476 An attacker can interfere with the reachability test by sending two 477 different types of packets: 479 1. LISP data encapsulated packets with the Nonce-Present bit set and 480 a random nonce. Such packets are normally used in response to a 481 reachability test. 483 2. LISP data encapsulated packets with the Nonce-Present and the 484 Echo-Nonce bits both set. These packets will force the receiving 485 ETR to store the received nonce and echo it in the LISP 486 encapsulated packets that it sends. These packets are normally 487 used as trigger for a reachability test. 489 The first type of packets is used to make xTRs think that an other 490 xTR is reachable while it is not. It is hence a way to mount a DoS 491 attack (i.e., the ITR will send its packet to a non-reachable ETR 492 while it should use another one). 494 The second type of packets could be exploited to attack the nonce- 495 based reachability test. If the attacker sends a continuous flow of 496 packets that each have a different random nonce, the ETR that 497 receives such packets will continuously change the nonce that it 498 returns to the remote ITR, which can yield to a performance attack. 499 If the remote ITR tries a nonce-reachability test, this test may fail 500 because the ETR may echo an invalid nonce. This hence yields to a 501 DoS attack. 503 In the case of an on-path attacker, a packet manipulation attack is 504 necessary to mount the attack. To mount such an attack, an off-path 505 attacker must mount an outer address spoofing attack. 507 If an xTR chooses to periodically check with active probes the 508 liveness of entries in its EID-to-RLOC cache (as described in section 509 6.3 of [RFC6830]), then this may amplify the attack that caused the 510 insertion of entries being checked. 512 3.5. Instance ID 514 LISP allows to carry in its header a 24-bits value called Instance ID 515 and used on the ITR to indicate which local Instance ID has been used 516 for encapsulation, while on the ETR the instance ID decides the 517 forwarding table to use to forward the decapsulated packet in the 518 LISP site. 520 An attacker (either a control-plane or data-plane attacker) can use 521 the instance ID functionality to mount an intrusion attack. 523 3.6. Interworking 525 [RFC6832] defines Proxy-ITR and Proxy-ETR network elements to allow 526 LISP and non-LISP sites to communicate. The Proxy-ITR has 527 functionality similar to the ITR, however, its main purpose is to 528 encapsulate packets arriving from the DFZ in order to reach LISP 529 sites. A Proxy-ETR has functionality similar to the ETR, however, 530 its main purpose is to inject de-encapsulated packets in the DFZ in 531 order to reach non-LISP Sites from LISP sites. As a PITR (resp. 532 PETR) is a particular case of ITR (resp. ETR), it is subject to same 533 attacks than ITRs (resp. ETR). 535 As any other system relying on proxies, LISP interworking can be used 536 by attackers to hide their exact origin in the network. 538 3.7. Map-Request messages 540 A control-plane off-path attacker can exploit Map-Request messages to 541 mount DoS, performance, or amplification attacks. By sending Map- 542 Request messages at high rate, the attacker can overload nodes 543 involved in the mapping system. For instance sending Map-Requests at 544 high rate can considerably increase the state maintained in a Map- 545 Resolver or consume CPU cycles on ETRs that have to process the Map- 546 Request packets they receive in their slow path (i.e., performance or 547 DoS attack). When the Map-Reply packet is larger than the Map- 548 Request sent by the attacker, that yields to an amplification attack. 549 The attacker can combine the attack with a spoofing attack to 550 overload the node to which the spoofed address is actually attached. 552 It is worth to notice that if the attacker sets the P bit (Probe Bit) 553 in the Map-Request, it is legitimate the send the Map-Request 554 directly to the ETR instead of passing through the mapping system. 556 The SMR bit can be used to mount a variant of these attacks. 558 For efficiency reasons, Map-Records can be appended to Map-Request 559 messages. When an xTR receives a Map-Request with appended Map- 560 Records, it does the same operations as for the other Map-Request 561 messages and is so subject to the same attacks. However, it also 562 installs in its EID-to-RLOC cache the Map-Records contained in the 563 Map-Request. An attacker can then use this vector to force the 564 installation of mappings in its target xTR. Consequently, the EID- 565 to-RLOC cache of the xTR is polluted by potentially forged mappings 566 allowing the attacker to mount any of the attacks categorized in 567 Section 2.2 (see Section 3.8 for more details). It is worth to 568 mention that the attacker does not need to forge the mappings present 569 in the Map-Request to achieve a performance or DoS attack. Indeed, 570 if the attacker owns a large enough EID prefix it can de-aggregate it 571 in many small prefixes, each corresponding to another mapping and it 572 installs them in the xTR cache by mean of the Map-Request. 574 Moreover, attackers can use Map Resolver and/or Map Server network 575 elements to relay its attacks and hide the origin of the attack. 576 Indeed, on the one hand, a Map Resolver is used to dispatch Map- 577 Request to the mapping system and, on the other hand, a Map Server is 578 used to dispatch Map-Requests coming from the mapping system to ETRs 579 that are authoritative for the EID in the Map-Request. 581 3.8. Map-Reply messages 583 Most of the security of the Map-Reply messages depends on the 64 bits 584 nonce that is included in a Map-Request and returned in the Map- 585 Reply. If an ETR does not accept Map-Reply messages with an invalid 586 nonce, the risk of an off-path attack is limited given the size of 587 the nonce (64 bits). Nevertheless, the nonce only confirms that the 588 Map-Reply received was sent in response to a Map-Request sent, it 589 does not validate the contents of that Map-Reply. 591 If an attacker manages to send a valid (i.e., in response to a Map- 592 Request and with the correct nonce) Map-Reply to an ITR, then it can 593 perform any of the attack categorised in Section 2.2 as it can inject 594 forged mappings directly in the ITR EID-to-RLOC cache. For instance, 595 if the mapping injected to the ITR points to the address of a node 596 controlled by the attacker, it can mount replay, packet manipulation, 597 packet interception and suppression, or DoS attacks as it will 598 receive every packet destined to a destination lying in the EID 599 prefix of the injected mapping. In addition, the attacker can inject 600 plethora of mappings in the ITR to mount a performance attack by 601 filling up the EID-to-RLOC cache of the ITR. If the attacker can 602 also mount an amplification attack as soon as the ITR has to send a 603 lot of packets to the EIDs matching the injected mapping. In this 604 case, the RLOC address associated to the mapping is the address of 605 the real target of the attacker and all the traffic of the ITR will 606 be sent to the target which means that with one single packet the 607 attacker may generate very high traffic towards its final target. 609 If the attacker is a valid ETR in the system it can mount a rogue 610 attack if it uses prefixes over-claiming. In such a scenario, the 611 attacker ETR replies to a legitimate Map-Request message it received 612 with a Map-Reply message that contains an EID-Prefix that is larger 613 than the prefix owned by the attacker. For instance if the owned 614 prefix is 192.0.2.0/25 but the Map-Reply contains a mapping for 615 192.0.2.0/24, then the mapping will influence packets destined to 616 other EIDs than the one attacker has authority on. With such 617 technique, the attacker can mount the attacks presented above as it 618 can (partially) control the mappings installed on its target ITR. To 619 force its target ITR to send a Map-Request, nothing prevents the 620 attacker to initiate some communication with the ITR. This method 621 can be used by internal attackers that want to control the mappings 622 installed in their site. To that aim, they simply have to collude 623 with an external attacker ready to over-claim prefixes on behalf of 624 the internal attacker. 626 It is worth to notice that when the Map-Reply is in response to a 627 Map-Request sent via the mapping system (i.e., not send directly from 628 the ITR to an ETR), the attacker does not need to use a spoofing 629 attack to achieve its attack as by design the source IP address of a 630 Map-Reply is not known in advance by the ITR. 632 Map-Request and Map-Reply messages are exposed to any type of 633 attackers, on-path or off-path but also external or internal 634 attackers. Also, even though they are control message, they can be 635 leveraged by data-plane attackers. As the decision of removing 636 mappings is based on the TTL indicated in the mapping, time-shifted 637 attackers can take benefit of injecting forged mappings as well. 639 3.9. Map-Register messages 641 Map-Register messages are sent by ETRs to Map Servers to indicate to 642 the mapping system the EID prefixes associated to them. The Map- 643 Register message provides an EID prefix and the list of ETRs that are 644 able to provide Map-Replies for the EID covered by the EID prefix. 646 As Map-Register messages are protected by an authentication 647 mechanism, only a compromised ETR can register itself to its 648 allocated Map Server. 650 A compromised ETR can over-claim the prefix it owns in order to 651 influence the route followed by Map-Requests for EIDs outside the 652 scope of its legitimate EID prefix (see Section 3.8 for the list of 653 over-claiming attacks). 655 A compromised ETR can also de-aggregate its EID prefix in order to 656 register more EID prefixes than necessary to its Map Servers (see 657 Section 3.7 for the impact of de-aggregation of prefixes by an 658 attacker). 660 Similarly, a compromised Map Server can accept invalid registration 661 or advertise invalid EID prefix to the mapping system. 663 3.10. Map-Notify messages 665 Map-Notify messages are sent by a Map Server to an ETR to acknowledge 666 the good reception and processing of a Map-Register message. 668 Similarly to the pair Map-Request/Map-Reply, the pair Map-Register/ 669 Map-Notify is protected by a nonce making it hard for an attacker to 670 inject a falsified notification to an ETR to make this ETR believe 671 that the registration succeeded while it has not. 673 4. Note on Privacy 675 As presented by [RFC6973], universal privacy considerations are 676 impossible to establish as the privacy definition may vary from one 677 to another. As a consequence, this document does not aim at 678 identifying privacy issues related to the LISP protocol but it is 679 necessary to highlight that security threats identified in this 680 document could play a role in privacy threats as defined in section 5 681 of [RFC6973]. 683 Like public deployments of any other control plane protocols, in an 684 Internet deployment mappings are public and hence provide information 685 about the infrastructure and reachability of LISP sites (i.e., the 686 addresses of the edge routers). Depending upon deployment details, 687 LISP map replies might or might not provide finer grained and more 688 detailed information than is available with currently deployed 689 routing and control protocols. 691 5. Threats Mitigation 693 Most of threats can be mitigated with careful deployment and 694 configuration (e.g., filter) and also by applying the general rules 695 in security that consist in activating only features that are 696 necessary in the deployment and verifying the validity of the 697 information obtained from third parties. 699 The control-plane is the most critical part of LISP from a security 700 viewpoint and it is worth to notice that the specifications already 701 offer authentication mechanism for mappings registration ([RFC6833]) 702 and this mechanism combined with LISP-SEC [I-D.ietf-lisp-sec] 703 strongly mitigates threats in non-trustable environments such as the 704 Internet. Moreover, LISP specifications define an authentication 705 data field for Map-Request messages and Encapsulated Control messages 706 without specifying how to use it [RFC6830]. The presence of this 707 field in the specifications allows to propose a general 708 authentication mechanisms for the LISP control-plane while staying 709 backward compatible. The exact technique still has to be designed 710 and defined. To maximally mitigate the threats on the mapping 711 system, authentication must be used, whenever possible, for both Map- 712 Request and Map-Reply messages and for messages exchanged internally 713 among elements of the mapping system, such as specified in 714 [I-D.ietf-lisp-sec] and [I-D.ietf-lisp-ddt]. 716 Systematically applying filters and rate-limitation, as proposed in 717 [RFC6830], mitigates most of the threats presented in this document. 718 In order to minimise the risk of overloading the control-plane with 719 actions triggered from data-plane events, such actions should be rate 720 limited. 722 Finally, all information opportunistically learned (e.g., with LSB or 723 gleaning) should be used with care until they are verified. For 724 instance, a reachability change learned with LSB should not be used 725 directly to decide the destination RLOC, but instead should trigger a 726 rate-limited reachability test. Similarly, a gleaned entry should be 727 used only for the flow that triggered the gleaning procedure until 728 the gleaned entry has been verified [Trilogy]. 730 6. Security Considerations 732 This entire document is dedicated to threat analysis and mitigation 733 of the Locator/Identifier Separation Protocol, aiming at helping to 734 understand the security risks at stake, and how to mitigate them, 735 while deploying LISP in non-trustable environments. 737 7. IANA Considerations 739 This document makes no request to IANA. 741 8. Acknowledgments 743 This document builds upon the draft of Marcelo Bagnulo 744 ([I-D.bagnulo-lisp-threat]), where the flooding attack and the 745 reference environment were first described. 747 The authors would like to thank Ronald Bonica, Albert Cabellos, Ross 748 Callon, Noel Chiappa, Florin Coras, Vina Ermagan, Dino Farinacci, 749 Stephen Farrell, Joel Halpern, Emily Hiltzik, Darrel Lewis, Edward 750 Lopez, Fabio Maino, Terry Manderson, and Jeff Wheeler for their 751 comments. 753 This work has been partially supported by the INFSO-ICT-216372 754 TRILOGY Project (www.trilogy-project.org). 756 The work of Luigi Iannone has been partially supported by the ANR-13- 757 INFR-0009 LISP-Lab Project (www.lisp-lab.org) and the EIT KIC ICT- 758 Labs SOFNETS Project. 760 9. References 762 9.1. Normative References 764 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 765 Locator/ID Separation Protocol (LISP)", RFC 6830, 766 DOI 10.17487/RFC6830, January 2013, 767 . 769 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 770 "Interworking between Locator/ID Separation Protocol 771 (LISP) and Non-LISP Sites", RFC 6832, DOI 10.17487/ 772 RFC6832, January 2013, 773 . 775 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 776 Protocol (LISP) Map-Server Interface", RFC 6833, 777 DOI 10.17487/RFC6833, January 2013, 778 . 780 [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID 781 Separation Protocol (LISP) Map-Versioning", RFC 6834, 782 DOI 10.17487/RFC6834, January 2013, 783 . 785 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 786 Morris, J., Hansen, M., and R. Smith, "Privacy 787 Considerations for Internet Protocols", RFC 6973, 788 DOI 10.17487/RFC6973, July 2013, 789 . 791 9.2. Informative References 793 [I-D.bagnulo-lisp-threat] 794 Bagnulo, M., "Preliminary LISP Threat Analysis", 795 draft-bagnulo-lisp-threat-01 (work in progress), 796 July 2007. 798 [I-D.ietf-lisp-ddt] 799 Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP 800 Delegated Database Tree", draft-ietf-lisp-ddt-03 (work in 801 progress), April 2015. 803 [I-D.ietf-lisp-sec] 804 Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. 805 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-08 806 (work in progress), April 2015. 808 [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- 809 Pascual, J., and D. Lewis, "Locator/Identifier Separation 810 Protocol (LISP) Network Element Deployment 811 Considerations", RFC 7215, DOI 10.17487/RFC7215, 812 April 2014, . 814 [Trilogy] Saucez, D. and L. Iannone, "How to mitigate the effect of 815 scans on mapping systems", Trilogy Future Internet Summer 816 School., 2009. 818 Appendix A. Document Change Log 820 o Version 13 Posted August 2015. 822 * Keepalive version. 824 o Version 12 Posted March 2015. 826 * Addressed comments by Ross Callon on the mailing list (http:// 827 www.ietf.org/mail-archive/web/lisp/current/msg05829.html). 829 * Addition of a section discussing mitigation techniques for 830 deployments in non-trustable environments. 832 o Version 11 Posted December 2014. 834 * Editorial polishing. Clarifications added in few points. 836 o Version 10 Posted July 2014. 838 * Document completely remodeled according to the discussions on 839 the mailing list in the thread 840 http://www.ietf.org/mail-archive/web/lisp/current/msg05206.html 841 and to address comments from Ronald Bonica and Ross Callon. 843 o Version 09 Posted March 2014. 845 * Updated document according to the review of A. Cabellos. 847 o Version 08 Posted October 2013. 849 * Addition of a privacy consideration note. 851 * Editorial changes 853 o Version 07 Posted October 2013. 855 * This version is updated according to the thorough review made 856 during October 2013 LISP WG interim meeting. 858 * Brief recommendations put in the security consideration 859 section. 861 * Editorial changes 863 o Version 06 Posted October 2013. 865 * Complete restructuration, temporary version to be used at 866 October 2013 interim meeting. 868 o Version 05 Posted August 2013. 870 * Removal of severity levels to become a short recommendation to 871 reduce the risk of the discussed threat. 873 o Version 04 Posted February 2013. 875 * Clear statement that the document compares threats of public 876 LISP deployments with threats in the current Internet 877 architecture. 879 * Addition of a severity level discussion at the end of each 880 section. 882 * Addressed comments from V. Ermagan and D. Lewis' reviews. 884 * Updated References. 886 * Further editorial polishing. 888 o Version 03 Posted October 2012. 890 * Dropped Reference to RFC 2119 notation because it is not 891 actually used in the document. 893 * Deleted future plans section. 895 * Updated References 897 * Deleted/Modified sentences referring to the early status of the 898 LISP WG and documents at the time of writing early versions of 899 the document. 901 * Further editorial polishing. 903 * Fixed all ID nits. 905 o Version 02 Posted September 2012. 907 * Added a new attack that combines over-claiming and de- 908 aggregation (see Section 3.8). 910 * Editorial polishing. 912 o Version 01 Posted February 2012. 914 * Added discussion on LISP-DDT. 916 o Version 00 Posted July 2011. 918 * Added discussion on LISP-MS>. 920 * Added discussion on Instance ID. 922 * Editorial polishing of the whole document. 924 * Added "Change Log" appendix to keep track of main changes. 926 * Renamed "draft-saucez-lisp-security-03.txt. 928 Authors' Addresses 930 Damien Saucez 931 INRIA 932 2004 route des Lucioles BP 93 933 06902 Sophia Antipolis Cedex 934 France 936 Email: damien.saucez@inria.fr 937 Luigi Iannone 938 Telecom ParisTech 939 23, Avenue d'Italie, CS 51327 940 75214 PARIS Cedex 13 941 France 943 Email: ggx@gigix.net 945 Olivier Bonaventure 946 Universite catholique de Louvain 947 Place St. Barbe 2 948 Louvain la Neuve 949 Belgium 951 Email: olivier.bonaventure@uclouvain.be