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