idnits 2.17.1 draft-ietf-lisp-threats-08.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 (October 21, 2013) is 3841 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'Chu' is defined on line 793, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-tcpm-tcp-security' is defined on line 811, but no explicit reference was found in the text == Unused Reference: 'I-D.saucez-lisp-mapping-security' is defined on line 822, but no explicit reference was found in the text == Unused Reference: 'RFC3704' is defined on line 827, but no explicit reference was found in the text == Unused Reference: 'RFC5386' is defined on line 833, but no explicit reference was found in the text == Unused Reference: 'RFC6480' is defined on line 837, but no explicit reference was found in the text == Unused Reference: 'SAVI' is defined on line 840, but no explicit reference was found in the text == Unused Reference: 'Saucez09' is defined on line 843, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) ** Obsolete normative reference: RFC 6833 (Obsoleted by RFC 9301) ** Obsolete normative reference: RFC 6834 (Obsoleted by RFC 9302) == Outdated reference: A later version (-09) exists of draft-ietf-lisp-ddt-01 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-04 Summary: 3 errors (**), 0 flaws (~~), 11 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: April 24, 2014 Telecom ParisTech 6 O. Bonaventure 7 Universite catholique de Louvain 8 October 21, 2013 10 LISP Threats Analysis 11 draft-ietf-lisp-threats-08.txt 13 Abstract 15 This document proposes a threat analysis of the Locator/Identifier 16 Separation Protocol (LISP) if deployed in the Internet. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 24, 2014. 35 Copyright Notice 37 Copyright (c) 2013 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. On-path Attackers . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Off-Path Attackers: Reference Environment . . . . . . . . . . 4 55 4. Attack vectors . . . . . . . . . . . . . . . . . . . . . . . 5 56 4.1. Configured EID-to-RLOC mappings . . . . . . . . . . . . . 5 57 4.2. EID-to-RLOC Cache . . . . . . . . . . . . . . . . . . . . 6 58 4.3. Attacks using the data-plane . . . . . . . . . . . . . . 6 59 4.3.1. Attacks not leveraging on the LISP header . . . . . . 6 60 4.3.2. Attacks leveraging on the LISP header . . . . . . . . 8 61 4.4. Attacks using the control-plane . . . . . . . . . . . . . 11 62 4.4.1. Attacks with Map-Request messages . . . . . . . . . . 11 63 4.4.2. Attacks with Map-Reply messages . . . . . . . . . . . 12 64 4.4.3. Attacks with Map-Register messages . . . . . . . . . 13 65 4.4.4. Attacks with Map-Notify messages . . . . . . . . . . 14 66 5. Attack categories . . . . . . . . . . . . . . . . . . . . . . 14 67 5.1. Intrusion . . . . . . . . . . . . . . . . . . . . . . . . 14 68 5.1.1. Description . . . . . . . . . . . . . . . . . . . . . 14 69 5.1.2. Vectors . . . . . . . . . . . . . . . . . . . . . . . 14 70 5.2. Denial of Service (DoS) . . . . . . . . . . . . . . . . . 14 71 5.2.1. Description . . . . . . . . . . . . . . . . . . . . . 14 72 5.2.2. Vectors . . . . . . . . . . . . . . . . . . . . . . . 15 73 5.3. Subversion . . . . . . . . . . . . . . . . . . . . . . . 15 74 5.3.1. Description . . . . . . . . . . . . . . . . . . . . . 15 75 5.3.2. Vectors . . . . . . . . . . . . . . . . . . . . . . . 15 76 6. Note on privacy . . . . . . . . . . . . . . . . . . . . . . . 16 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 79 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 82 10.2. Informative References . . . . . . . . . . . . . . . . . 18 83 Appendix A. Document Change Log . . . . . . . . . . . . . . . . 19 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 86 1. Introduction 88 The Locator/ID Separation Protocol (LISP) is defined in [RFC6830]. 89 The present document assesses the security level and identifies 90 security threats in the LISP specification if LISP is deployed in the 91 Internet (i.e., a public non-trustable environment). As a result of 92 the performed analysis, the document discusses the severity of the 93 threats and proposes recommendations to reach the same level of 94 security in LISP than in Internet today (e.g., without LISP). 96 The document is composed of three main parts: the first discussing 97 the LISP data-plane; while the second discussing the LISP control- 98 plane. The final part summarizes the recommendations to prevent the 99 identified threats. 101 The LISP data-plane consists of LISP packet encapsulation, 102 decapsulation, and forwarding and includes the map cache data 103 structures used to perform these operations. 105 The LISP control-plane consists in the mapping distribution system, 106 which can be one of the mapping distribution systems proposed so far 107 (e.g., [RFC6830], [I-D.ietf-lisp-ddt], [RFC6836], [RFC6833], 108 [I-D.meyer-lisp-cons], and [RFC6837]), and the Map-Request, Map- 109 Reply, Map-Register, and Map-Notification messages. 111 This document does not consider all the possible uses of LISP as 112 discussed in [RFC6830]. The document focuses on LISP unicast, 113 including as well LISP Interworking [RFC6832], LISP-MS [RFC6833], and 114 LISP Map-Versioning [RFC6834]. The reading of these documents is a 115 prerequisite for understanding the present document. 117 Unless otherwise stated, the document assumes a generic IP service 118 and does not discuss the difference, from a security viewpoint, 119 between using IPv4 or IPv6. 121 2. On-path Attackers 123 On-path attackers are attackers that are able to capture and modify 124 all the packets exchanged between an Ingress Tunnel Router (ITR) and 125 an Egress Tunnel Router (ETR). To cope with such an attacker, 126 cryptographic techniques such as those used by IPSec ([RFC4301]) are 127 required. As with IP, LISP relies on higher layer cryptography to 128 secure packet payloads from on path attacks, so this document does 129 not consider on-path attackers in this document. 131 Similarly, a time-shifted attack is an attack where the attacker is 132 temporarily on the path between two communicating hosts. While it is 133 on-path, the attacker sends specially crafted packets or modifies 134 packets exchanged by the communicating hosts in order to disturb the 135 packet flow (e.g., by performing a man in the middle attack). An 136 important issue for time-shifted attacks is the duration of the 137 attack once the attacker has left the path between the two 138 communicating hosts. We do not consider time-shifted attacks in this 139 document. 141 3. Off-Path Attackers: Reference Environment 143 The reference environment shown in the figure below is considered 144 throughout this document. There are two hosts attached to LISP 145 routers: HA and HB. HA is attached to the two LISP xTRs LR1 and LR2, 146 which in turn are attached to two different ISPs. HB is attached to 147 the two LISP xTRs LR3 and LR4. HA and HB are the EIDs of the two 148 hosts. LR1, LR2, LR3, and LR4 are the RLOCs of the xTRs. PxTR is a 149 proxy xTR and MR/MS plays the roles of Map Server and/or Map 150 Resolver. 152 +-----+ 153 | HA | 154 +-----+ 155 | EID: HA 156 | 157 ----------------- 158 | | 159 +-----+ +-----+ 160 | LR1 | | LR2 | 161 +-----+ +-----+ 162 | | 163 | | 164 +-----+ +-----+ 165 |ISP1 | |ISP2 | 166 +-----+ +-----+ 167 | | 168 +------+ +----------------+ +-----+ 169 | PxTR |-----| |-----| SA | 170 +------+ | | +-----+ 171 | Internet | 172 +-------+ | | +-----+ 173 | MR/MS |----| |-----| NSA | 174 +-------+ +----------------+ +-----+ 175 | | 176 +-----+ +-----+ 177 | LR3 | | LR4 | 178 +-----+ +-----+ 179 | | 180 ------------------- 181 | 182 | EID: HB 183 +-----+ 184 | HB | 185 +-----+ 187 Figure 1: Reference Network 189 We consider two off-path attackers with different capabilities: 191 SA is an off-path attacker that is able to send spoofed packets, 192 i.e., packets with a different source IP address than its 193 assigned IP address. SA stands for Spoofing Attacker. 195 NSA is an off-path attacker that is only able to send packets whose 196 source address is its assigned IP address. NSA stands for Non 197 Spoofing Attacker. 199 It should be noted that with LISP, packet spoofing is slightly 200 different than in the current Internet. Generally the term "spoofed 201 packet" indicates a packet containing a source IP address that is not 202 the one of the actual originator of the packet. Since LISP uses 203 encapsulation, the spoofed address could be in the outer header as 204 well as in the inner header, this translates in two types of 205 spoofing: 207 EID Spoofing: the originator of the packet puts in it a spoofed EID. 208 The packet will be normally encapsulated by the ITR of the site 209 (or a PITR if the source site is not LISP enabled). 211 RLOC Spoofing: the originator of the packet generates directly a 212 LISP-encapsulated packet with a spoofed source RLOC. 214 Note that the two types of spoofing are not mutually exclusive, 215 rather all combinations are possible and could be used to perform 216 different kind of attacks. 218 In the reference environment, both SA and NSA attackers are capable 219 of sending LISP encapsulated data packets and LISP control packets. 220 This means that SA is able to perform both RLOC and EID spoofing 221 while NSA can only perform EID spoofing. They may also send other 222 types of IP packets such as ICMP messages. We assume that both 223 attackers can query the LISP mapping system (e.g., through a public 224 Map Resolver) to obtain the mappings for both HA and HB. 226 4. Attack vectors 228 This section presents techniques that can be used by attackers to 229 succeed attacks leveraging the LISP protocol and architecture. This 230 section focuses on the techniques while Section 5 presents the 231 attacks that can be succeeded while using these techniques. 233 4.1. Configured EID-to-RLOC mappings 235 Each xTR maintains a set of configured mappings related to the EID- 236 Prefixes that are "behind" the xTR [RFC6830]. Where "behind" means 237 that at least one of the xTR's globally visible IP addresses is a 238 RLOC for those EID-Prefixes. 240 As these mappings are determined by configuration. This means that 241 the only way to attack this data structure is by gaining privileged 242 access to the xTR. As such, it is out of the scope of LISP to 243 propose any mechanism to protect routers and, hence, it is no further 244 analyzed in this document. 246 4.2. EID-to-RLOC Cache 248 The EID-to-RLOC Cache (also called the Map-Cache) is the data 249 structure that stores a copy of the mappings retrieved from a remote 250 ETR's mapping via the LISP control-plane. Attacks against this data 251 structure could happen either when the mappings are first installed 252 in the cache or by corrupting (poisoning) the mappings already 253 present in the cache. 255 This document calls "cache poisoning attack", any attack that alters 256 the EID-to-RLOC Cache. Cache poisoning attacks are use to alter (any 257 combination of) the following parts of mapping installed in the EID- 258 to-RLOC Cache: 260 o EID prefix 262 o RLOC list 264 o RLOC priority 266 o RLOC weight 268 o RLOC reachability 270 o Mapping TTL 272 o Mapping version 274 o Mapping Instance ID 276 4.3. Attacks using the data-plane 278 The data-plane is constituted of the operations of encapsulation, 279 decapsulation, and forwarding as well as the content of the EID-to- 280 RLOC Cache and configured EID-to-RLOC mappings as specified in the 281 original LISP document ([RFC6830]). 283 4.3.1. Attacks not leveraging on the LISP header 284 An attacker can inject packets into flows without using the LISP 285 header, i.e., with the N, L, E, V, and I bits ([RFC6830]). 287 Taking notation of the reference environment notation (Figure 1), to 288 inject a packet in the HA->HB flow, a spoofing off-path attacker (SA) 289 could send a LISP encapsulated packet whose source is set to LR1 or 290 LR2 and destination LR3 or LR4. The packet will reach HB as if the 291 packet was sent by host HA. This is not different from today's 292 Internet where a spoofing off-path attacker may inject data packets 293 in any flow. A non-spoofing off-path attacker (NSA) could only send 294 a packet whose source address is set to its assigned IP address. The 295 destination address of the encapsulated packet could be LR3 or LR4. 297 4.3.1.1. Gleaning Attacks 299 In order to reduce the time required to obtain a mapping, [RFC6830] 300 proposes the gleaning mechanism that allows an ITR to learn a mapping 301 from the LISP data encapsulated packets and the Map-Request packets 302 that it receives. LISP data encapsulated packet contains a source 303 RLOC, destination RLOC, source EID and destination EID. When an ITR 304 receives a data encapsulated packet coming from a source EID for 305 which it does not already know a mapping, it may insert the mapping 306 between the source RLOC and the source EID in its EID-to-RLOC Cache. 307 Gleaning could also be used when an ITR receives a Map-Request as the 308 Map-Request also contains a source EID address and a source RLOC. 309 Once a gleaned entry has been added to the EID-to-RLOC cache, the 310 LISP ITR sends a Map-Request to retrieve the mapping for the gleaned 311 EID from the mapping system. [RFC6830] recommends storing the 312 gleaned entries for only a few seconds. 314 An attacker can send LISP encapsulated packets to host HB with host 315 HA's EID and if the xTRs that serve host HB do not store a mapping 316 for host HA at that time. The xTR will store the gleaned entry and 317 use it to return the packets sent by host HB. In parallel, the ETR 318 will send a Map-Request to retrieve the mapping for HA but until the 319 reception of the Map-Reply, host HB will exchange packets with the 320 attacker instead of HA. 322 Similarly, if an off-path attacker knows that hosts HA and HB that 323 resides in different sites will exchange information at time t the 324 attacker could send to LR1 (resp. LR3) a LISP data encapsulated 325 packet whose source RLOC is its IP address and contains an IP packet 326 whose source is set to HB (resp. HA). The attacker chooses a packet 327 that will not trigger an answer, for example the last part of a 328 fragmented packet. Upon reception of these packets, LR1 and LR3 329 install gleaned entries that point to the attacker. If host HA is 330 willing to establishes a flow with host HB at that time, the packets 331 that they exchange will pass through the attacker as long as the 332 gleaned entry is active on the xTRs. 334 By itself, an attack made solely using gleaning cannot last long, 335 however it should be noted that with current network capacities, a 336 large amount of packets might be exchanged during even a small 337 fraction of time. 339 4.3.1.2. Threats concerning Interworking 341 [RFC6832] defines Proxy-ITR And Proxy-ETR network elements to allow 342 LISP and non-LISP sites to communicate. The Proxy-ITR has 343 functionality similar to the ITR, however, its main purpose is to 344 encapsulate packets arriving from the DFZ in order to reach LISP 345 sites. A Proxy-ETR has functionality similar to the ETR, however, 346 its main purpose is to inject de-encapsulated packets in the DFZ in 347 order to reach non-LISP Sites from LISP sites. As a PITR (resp. 348 PETR) is a particular case of ITR (resp. ETR), it is subject to same 349 attacks than ITRs (resp. ETR). 351 PxTRs can be targeted by attacks aiming to influence traffic between 352 LISP and non-LISP sites but also to launch relay attacks. 354 It is worth to notice that when PITR and PETR functions are 355 separated, attacks targeting nodes that collocate PITR and PETR 356 functionality are ineffective. 358 4.3.2. Attacks leveraging on the LISP header 360 The main LISP document [RFC6830] defines several flags that modify 361 the interpretation of the LISP header in data packets. In this 362 section, we discuss how an off-path attacker could exploit this LISP 363 header. 365 4.3.2.1. Attacks using the Locator Status Bits 367 When the L bit is set to 1, it indicates that the second 32-bits 368 longword of the LISP header contains the Locator Status Bits. In 369 this field, each bit position reflects the status of one of the RLOCs 370 mapped to the source EID found in the encapsulated packet. In 371 particular, a packet with the L bit set and all Locator Status Bits 372 set to zero indicates that none of the locators of the encapsulated 373 source EID are reachable. The reaction of a LISP ETR that receives 374 such a packet is not clearly described in [RFC6830]. 376 An attacker can send a data packet with the L bit set to 1 and some 377 or all Locator Status Bits set to zero. Therefore, by blindly 378 trusting the Locator Status Bits communication going on can be 379 altered or forced to go through a particular set of locators. 381 4.3.2.2. Attacks using the Map-Version bit 383 The optional Map-Version bit is used to indicate whether the low- 384 order 24 bits of the first 32 bits longword of the LISP header 385 contain a Source and Destination Map-Version. When a LISP ETR 386 receives a LISP encapsulated packet with the Map-Version bit set to 387 1, the following actions are taken: 389 o It compares the Destination Map-Version found in the header with 390 the current version of its own configured EID-to-RLOC mapping, for 391 the destination EID found in the encapsulated packet. If the 392 received Destination Map-Version is smaller (i.e., older) than the 393 current version, the ETR should apply the SMR procedure described 394 in [RFC6830] and send a Map-Request with the SMR bit set. 396 o If a mapping exists in the EID-to-RLOC Cache for the source EID, 397 then it compares the Map-Version of that entry with the Source 398 Map-Version found in the header of the packet. If the stored 399 mapping is older (i.e., the Map-Version is smaller) than the 400 source version of the LISP encapsulated packet, the xTR should 401 send a Map-Request for the source EID. 403 An off-path attacker could use the Map-Version bit to force an ETR to 404 send Map-Request messages. The attacker could retrieve the current 405 source and destination Map-Version for both HA and HB. Based on this 406 information, it could send a spoofed packet with an older Source Map- 407 Version or Destination Map-Version. If the size of the Map-Request 408 message is larger than the size of the smallest LISP-encapsulated 409 packet that could trigger such a message, this could lead to 410 amplification attacks (see Section 4.4.1) so that more bandwidth is 411 consumed on the target than the bandwidth necessary at the attacker 412 side. 414 4.3.2.3. Attacks using the Nonce-Present and the Echo-Nonce bits 416 The Nonce-Present and Echo-Nonce bits are used when verifying the 417 reachability of a remote ETR. Assume that LR3 wants to verify that 418 LR1 receives the packets that it sends. LR3 can set the Echo-Nonce 419 and the Nonce-Present bits in LISP data encapsulated packets and 420 include a random nonce in these packets. Upon reception of these 421 packets, LR1 will store the nonce sent by LR3 and echo it when it 422 returns LISP encapsulated data packets to LR3. 424 A spoofing off-path attacker (SA) could interfere with this 425 reachability test by sending two different types of packets: 427 1. LISP data encapsulated packets with the Nonce-Present bit set and 428 a random nonce and the appropriate source and destination RLOCs. 430 2. LISP data encapsulated packets with the Nonce-Present and the 431 Echo-Nonce bits both set and the appropriate source and 432 destination RLOCs. These packets will force the receiving ETR to 433 store the received nonce and echo it in the LISP encapsulated 434 packets that it sends. 436 The first type of packet should not cause any major problem to ITRs. 437 As the reachability test uses a 24 bits nonce, it is unlikely that an 438 off-path attacker could send a single packet that causes an ITR to 439 believe that the ETR it is testing is reachable while in reality it 440 is not reachable. To increase the success likelihood of such attack, 441 the attacker should created a massive amount of packets carrying all 442 possible nonce values. 444 The second type of packet could be exploited to attack the nonce- 445 based reachability test. Consider a spoofing off-path attacker (SA) 446 that sends a continuous flow of spoofed LISP data encapsulated 447 packets that contain the Nonce-Present and the Echo-Nonce bit and 448 each packet contains a different random nonce. The ETR that receives 449 such packets will continuously change the nonce that it returns to 450 the remote ITR. If the remote ITR starts a nonce-reachability test, 451 this test may fail because the ETR has received a spoofed LISP data 452 encapsulated packet with a different random nonce and never echoes 453 the real nonce. In this case the ITR will consider the ETR not 454 reachable. The success of this test depends on the ratio between the 455 amount of packets sent by the legitimate ITR and the spoofing off- 456 path attacker (SA). 458 4.3.2.4. Attacks using the Instance ID bits 460 LISP allows to carry in its header a 24-bits value called "Instance 461 ID" and used on the ITR to indicate which local Instance ID has been 462 used for encapsulation, while on the ETR can be used to select the 463 forwarding table used for forwarding the decapsulated packet. 465 The Instance ID increases exposure to attacks ([RFC6169]) as if an 466 off-path attacker can randomly guess a valid Instance ID value to get 467 access to network that might not been accessible in normal 468 conditions. However, the impact of such attack is directly on end- 469 systems which is is out of the scope of this document. 471 4.4. Attacks using the control-plane 473 In this section, we discuss the different types of attacks that could 474 occur when an off-path attacker sends control-plane packets. We 475 focus on the packets that are sent directly to the ETR and do not 476 analyze the particularities of the different LISP indexing sub- 477 system. 479 4.4.1. Attacks with Map-Request messages 481 An off-path attacker could send Map-Request packets to a victim ETR. 482 In theory, a Map-Request packet is only used to solicit an answer and 483 as such it should not lead to security problems. However, the LISP 484 specification [RFC6830] contains several particularities that could 485 be exploited by an off-path attacker. 487 The first possible exploitation is the RLOC record P bit. The RLOC 488 record P bit is used to probe the reachability of remote ETRs. In 489 our reference environment, LR3 could probe the reachability of LR1 by 490 sending a Map-Request with the RLOC record P bit set. LR1 would 491 reply by sending a Map-Reply message with the RLOC record P bit set 492 and the same nonce as in the Map-Request message. 494 A spoofing off-path attacker (SA) could use the RLOC record P bit to 495 force a victim ETR to send a Map-Reply to the spoofed source address 496 of the Map-Request message. As the Map-Reply can be larger than the 497 Map-Request message, there is a risk of amplification attack. 498 Considering only IPv6 addresses, a Map-Request can be as small as 40 499 bytes, considering one single ITR address and no Mapping Protocol 500 Data. The Map-Reply instead has a proportional to the maximum number 501 of RLOCs in a mapping and maximum number of records in a Map-Reply. 502 Since up to 255 RLOCs can be associated to an EID-Prefix and 255 503 records can be stored in a Map-Reply, the maximum size of a Map-Reply 504 is thus above 1 MB, largely bigger than the message sent by the 505 attacker. These numbers are however theoretical values not 506 considering transport layer limitations and it is more likely that 507 the reply will contain only one record with at most a dozen of 508 locators, limiting so the amplification factor. 510 Similarly, if a non-spoofing off-path attacker (NSA) sends a Map- 511 Request with the RLOC record P bit set, it will receive a Map-Reply 512 with the RLOC record P bit set. 514 An amplification attack could be launched by a spoofing off-path 515 attacker (SA) as follows. Consider an attacker SA and EID-Prefix 516 192.0.2.0/24 and a victim ITR, SA could send spoofed Map-Request 517 messages whose source EID addresses are all the addresses inside 518 192.0.2.0/24 and source RLOC address is the victim ITR. Upon 519 reception of these Map-Request messages, the ETR would send large 520 Map-Reply messages for each of the addresses inside p/P back to the 521 victim ITR. 523 The Map-Request message may also contain the SMR bit. Upon reception 524 of a Map-Request message with the SMR bit, an ETR must return to the 525 source of the Map-Request message a Map-Request message to retrieve 526 the corresponding mapping. This raises similar problems as the RLOC 527 record P bit discussed above except that as the Map-Request messages 528 are smaller than Map-Reply messages, the risk of amplification 529 attacks is reduced. This is not true anymore if the ETR append to 530 the Map-Request messages its own Map-Records. This mechanism is 531 meant to reduce the delay in mapping distribution since mapping 532 information is provided in the Map-Request message. 534 Furthermore, appending Map-Records to Map-Request messages allows an 535 off-path attacker to generate a (spoofed or not) Map-Request message 536 and include in the Map-Reply portion of the message mapping for EID 537 prefixes that it does not serve. 539 Moreover, attackers can use Map Resolver and/or Map Server network 540 elements to perform relay attacks. Indeed, on the one hand, a Map 541 Resolver is used to dispatch Map-Request to the mapping system and, 542 on the other hand, a Map Server is used to dispatch Map-Requests 543 coming from the mapping system to ETRs that are authoritative for the 544 EID in the Map-Request. 546 4.4.2. Attacks with Map-Reply messages 548 In this section we analyze the attacks that could occur when an off- 549 path attacker sends directly Map-Reply messages to ETRs without using 550 one of the proposed LISP mapping systems. 552 There are two different types of Map-Reply messages: 554 Positive Map-Reply: These messages contain a Map-Record binding an 555 EID-Prefix to one or more RLOCs. 557 Negative Map-Reply: These messages contain a Map-Record for an EID- 558 Prefix with an empty locator-set and specifying an action, 559 which may be either Drop, natively forward, or Send Map- 560 Request. 562 Positive Map-Reply messages are used to map EID-Prefixes onto RLOCs. 563 Negative Map-Reply messages are used to indicate non-LISP prefixes. 564 ITRs can, if needed, be configured to send all traffic destined for 565 non-LISP prefixes to a Proxy-ETR. 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 acceptable given the size of the nonce 571 (64 bits). However, 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 In addition, an attacker could perform EID-to-RLOC Cache overflow 576 attack by de-aggregating (i.e., splitting an EID prefix into 577 artificially smaller EID prefixes) either positive or negative 578 mappings. 580 In presence of malicious ETRs, overclaiming attacks are possible. 581 Such an attack happens when and ETR replies to a legitimate Map- 582 Request message it received with a Map-Reply message that contains an 583 EID-Prefix that is larger than the prefix owned by the site that 584 encompasses the EID of the Map-Request. For instance if the prefix 585 owned by the site is 192.0.2.0/25 but the Map-Reply contains a 586 mapping for 192.0.2.0/24, then the mapping will influence packets 587 destined to other EIDs than the one the LISP site has authority on. 589 A malicious ETR might also fragment its configured EID-to-RLOC 590 mappings so that ITR's might have to install much more mappings than 591 really necessary. This attack is called de-aggregation attack. 593 4.4.3. Attacks with Map-Register messages 595 Map-Register messages are sent by ETRs to indicate to the mapping 596 system the EID prefixes associated to them. The Map-Register message 597 provides an EID prefix and the list of ETRs that are able to provide 598 Map-Replies for the EID covered by the EID prefix. 600 As Map-Register messages are protected by an authentication 601 mechanism, only a compromised ETR can register itself to its 602 allocated Map Server. 604 A compromised ETR can perform an overclaiming attack in order to 605 influence the route followed by Map-Requests for EIDs outside the 606 scope of its legitimate EID prefix. 608 A compromised ETR can also perform a deaggregation attack in order to 609 register more EID prefixes than necessary to its Map Servers. 611 Similarly, a compromised Map Server can accept invalid registration 612 or advertise invalid EID prefix to the indexing sub-system. 614 4.4.4. Attacks with Map-Notify messages 616 Map-Notify messages are sent by a Map Server to an ETR to acknowledge 617 the good reception and processing of a Map-Register message. 619 An compromised ETR using EID that it is not authoritative for can 620 send a Map-Register with the M-bit set and a spoofed source address 621 to force the Map Server to send a Map-Notify message to the spoofed 622 address and then succeed a relay attack. Similarly to the pair Map- 623 Request/Map-Reply, the pair Map-Register/Map-Notify is protected by a 624 nonce making it hard for an attacker to inject a falsified 625 notification to an ETR to make this ETR believe that the registration 626 succeeded while it has not. 628 5. Attack categories 630 5.1. Intrusion 632 5.1.1. Description 634 With an intrusion attack an attacker gains remote access to some 635 resources (e.g., a host, a router, or a network) that are normally 636 denied to her. 638 5.1.2. Vectors 640 Intrusion attacks can be mounted using: 642 o Spoofing EID or RLOCs 644 o Instance ID bits 646 5.2. Denial of Service (DoS) 648 5.2.1. Description 650 A Denial of Service (DoS) attack aims at disrupting a specific 651 targeted service either by exhausting the resources of the victim up 652 to the point that it is not able to provide a reliable service to 653 legit traffic and/or systems or by exploiting vulnerabilities to make 654 the targeted service unable to operate properly. 656 5.2.2. Vectors 658 Denial of Service attacks can be mounted using 660 o Gleaning 662 o Interworking 664 o Locator Status Bits 666 o Map-Version bit 668 o Nonce-Present and Echo-Nonce bits 670 o Map-Request message 672 o Map-Reply message 674 o Map-Register message 676 o Map-Notify message 678 5.3. Subversion 680 5.3.1. Description 682 With subversion an attacker can gain access (e.g., using 683 eavesdropping or impersonation) to restricted or sensitive 684 information such as passwords, session tokens, or any other 685 confidential information. This type of attack is usually carried out 686 in a way such that the target does not even notice the attack. When 687 the attacker is positioned on the path of the target traffic, it is 688 called a Man-in-the-Middle attack. However, this is not a 689 requirement to carry out and eavesdropping attack. Indeed the 690 attacker might be able, for instance through an intrusion attack on a 691 weaker system, either to duplicate or even re-direct the traffic, in 692 both cases having access to the raw packets. 694 5.3.2. Vectors 696 Subversion attacks can be mounted using 698 o Gleaning 699 o Locator Status Bits 701 o Nonce-Present and the Echo-Nonce bits 703 o Map-Request messages 705 o Map-Reply messages 707 6. Note on privacy 709 As presented by [RFC6973], universal privacy considerations are 710 impossible to establish as the privacy definition may vary from one 711 to another. As a consequence, this document does not aim at 712 identifying privacy issues related to the LISP protocol but it is 713 necessary to highlight that security threats identified in this 714 document could play a role in privacy threats as defined in section 5 715 of [RFC6973]. 717 7. IANA Considerations 719 This document makes no request to IANA. 721 8. Security Considerations 723 This document is devoted to threat analysis of the Locator/Identifier 724 Separation Protocol and is then a piece of choice to understand the 725 security risks at stake while deploying LISP in non-trustable 726 environment. 728 The purpose of this document is not to provide recommendations to 729 protect against attacks, however most of threats can be prevented 730 with careful deployment and configuration (e.g., filter) and also by 731 applying the general rules in security that consist in activating 732 only features that are necessary in the deployment and verifying the 733 validity of the information obtained from third parties. More 734 detailed recommendation are given in [book_chapter]. 736 The control-plane is probably the most critical part of LISP from a 737 security viewpoint and it is worth to notice that the specifications 738 already offer authentication mechanism for Map-Register messages 739 ([RFC6833]) and that [I-D.ietf-lisp-sec] and [I-D.ietf-lisp-ddt] are 740 clearly going in the direction of a secure control-plane. 742 9. Acknowledgments 744 This document builds upon the draft of Marcelo Bagnulo 745 ([I-D.bagnulo-lisp-threat]), where the flooding attack and the 746 reference environment were first described. 748 The authors would like to thank Ronald Bonica, Albert Cabellos, Noel 749 Chiappa, Florin Coras, Vina Ermagan, Dino Farinacci, Stephen Farrell, 750 Joel Halpern, Emily Hiltzik, Darrel Lewis, Edward Lopez, Fabio Maino, 751 Terry Manderson, and Jeff Wheeler for their comments. 753 This work has been partially supported by the INFSO-ICT-216372 754 TRILOGY Project (www.trilogy-project.org). 756 10. References 758 10.1. Normative References 760 [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security 761 Concerns with IP Tunneling", RFC 6169, April 2011. 763 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 764 Locator/ID Separation Protocol (LISP)", RFC 6830, January 765 2013. 767 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 768 "Interworking between Locator/ID Separation Protocol 769 (LISP) and Non-LISP Sites", RFC 6832, January 2013. 771 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 772 Protocol (LISP) Map-Server Interface", RFC 6833, January 773 2013. 775 [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID 776 Separation Protocol (LISP) Map-Versioning", RFC 6834, 777 January 2013. 779 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 780 "Locator/ID Separation Protocol Alternative Logical 781 Topology (LISP+ALT)", RFC 6836, January 2013. 783 [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to 784 Routing Locator (RLOC) Database", RFC 6837, January 2013. 786 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 787 Morris, J., Hansen, M., and R. Smith, "Privacy 788 Considerations for Internet Protocols", RFC 6973, July 789 2013. 791 10.2. Informative References 793 [Chu] Jerry Chu, H., "Tuning TCP Parameters for the 21st Century 794 ", 75th IETF, Stockholm, July 2009, 795 . 797 [I-D.bagnulo-lisp-threat] 798 Bagnulo, M., "Preliminary LISP Threat Analysis", draft- 799 bagnulo-lisp-threat-01 (work in progress), July 2007. 801 [I-D.ietf-lisp-ddt] 802 Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP 803 Delegated Database Tree", draft-ietf-lisp-ddt-01 (work in 804 progress), March 2013. 806 [I-D.ietf-lisp-sec] 807 Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D., 808 and O. Bonaventure, "LISP-Security (LISP-SEC)", draft- 809 ietf-lisp-sec-04 (work in progress), October 2012. 811 [I-D.ietf-tcpm-tcp-security] 812 Gont, F., "Survey of Security Hardening Methods for 813 Transmission Control Protocol (TCP) Implementations", 814 draft-ietf-tcpm-tcp-security-03 (work in progress), March 815 2012. 817 [I-D.meyer-lisp-cons] 818 Brim, S., "LISP-CONS: A Content distribution Overlay 819 Network Service for LISP", draft-meyer-lisp-cons-04 (work 820 in progress), April 2008. 822 [I-D.saucez-lisp-mapping-security] 823 Saucez, D. and O. Bonaventure, "Securing LISP Mapping 824 replies", draft-saucez-lisp-mapping-security-00 (work in 825 progress), February 2011. 827 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 828 Networks", BCP 84, RFC 3704, March 2004. 830 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 831 Internet Protocol", RFC 4301, December 2005. 833 [RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing 834 Security: An Unauthenticated Mode of IPsec", RFC 5386, 835 November 2008. 837 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 838 Secure Internet Routing", RFC 6480, February 2012. 840 [SAVI] IETF, "Source Address Validation Improvements Working 841 Group ", 2013, . 843 [Saucez09] 844 Saucez, D. and L. Iannone, "How to mitigate the effect of 845 scans on mapping systems ", Trilogy Summer School on 846 Future Internet, 2009. 848 [book_chapter] 849 Saucez, D., Iannone, L., and O. Bonaventure, "The Map-and- 850 Encap Locator/Identifier separation paradigm: a Security 851 Analysis ", Solutions for Sustaining Scalability in 852 Internet Growth, IGI Global, 2013. 854 Appendix A. Document Change Log 856 o Version 08 Posted October 2013. 858 * Addition of a privacy consideration note. 860 * Editorial changes 862 o Version 07 Posted October 2013. 864 * This version is updated according to the thorough review made 865 during October 2013 LISP WG interim meeting. 867 * Brief recommendations put in the security consideration 868 section. 870 * Editorial changes 872 o Version 06 Posted October 2013. 874 * Complete restructuration, temporary version to be used at 875 October 2013 interim meeting. 877 o Version 05 Posted August 2013. 879 * Removal of severity levels to become a short recommendation to 880 reduce the risk of the discussed threat. 882 o Version 04 Posted February 2013. 884 * Clear statement that the document compares threats of public 885 LISP deployments with threats in the current Internet 886 architecture. 888 * Addition of a severity level discussion at the end of each 889 section. 891 * Addressed comments from V. Ermagan and D. Lewis' reviews. 893 * Updated References. 895 * Further editorial polishing. 897 o Version 03 Posted October 2012. 899 * Dropped Reference to RFC 2119 notation because it is not 900 actually used in the document. 902 * Deleted future plans section. 904 * Updated References 906 * Deleted/Modified sentences referring to the early status of the 907 LISP WG and documents at the time of writing early versions of 908 the document. 910 * Further editorial polishing. 912 * Fixed all ID nits. 914 o Version 02 Posted September 2012. 916 * Added a new attack that combines overclaiming and de- 917 aggregation (see Section 4.4.2). 919 * Editorial polishing. 921 o Version 01 Posted February 2012. 923 * Added discussion on LISP-DDT. 925 o Version 00 Posted July 2011. 927 * Added discussion on LISP-MS>. 929 * Added discussion on Instance ID in Section 4.3.2. 931 * Editorial polishing of the whole document. 933 * Added "Change Log" appendix to keep track of main changes. 935 * Renamed "draft-saucez-lisp-security-03.txt. 937 Authors' Addresses 939 Damien Saucez 940 INRIA 941 2004 route des Lucioles BP 93 942 06902 Sophia Antipolis Cedex 943 France 945 Email: damien.saucez@inria.fr 947 Luigi Iannone 948 Telecom ParisTech 949 23, Avenue d'Italie, CS 51327 950 75214 PARIS Cedex 13 951 France 953 Email: luigi.iannone@telecom-paristech.fr 955 Olivier Bonaventure 956 Universite catholique de Louvain 957 Place St. Barbe 2 958 Louvain la Neuve 959 Belgium 961 Email: olivier.bonaventure@uclouvain.be