idnits 2.17.1 draft-ietf-lisp-threats-07.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 07, 2013) is 3854 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'Chu' is defined on line 775, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-tcpm-tcp-security' is defined on line 793, but no explicit reference was found in the text == Unused Reference: 'I-D.saucez-lisp-mapping-security' is defined on line 804, but no explicit reference was found in the text == Unused Reference: 'RFC3704' is defined on line 809, but no explicit reference was found in the text == Unused Reference: 'RFC5386' is defined on line 815, but no explicit reference was found in the text == Unused Reference: 'RFC6480' is defined on line 819, but no explicit reference was found in the text == Unused Reference: 'SAVI' is defined on line 822, but no explicit reference was found in the text == Unused Reference: 'Saucez09' is defined on line 825, 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 10, 2014 Telecom ParisTech 6 O. Bonaventure 7 Universite catholique de Louvain 8 October 07, 2013 10 LISP Threats Analysis 11 draft-ietf-lisp-threats-07.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 10, 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 . . . . . . . . . . 3 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 . . . . . . 7 60 4.3.2. Attacks leveraging on the LISP header . . . . . . . . 8 61 4.4. Attacks using the control-plane . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . . . 14 73 5.3. Subversion . . . . . . . . . . . . . . . . . . . . . . . 15 74 5.3.1. Description . . . . . . . . . . . . . . . . . . . . . 15 75 5.3.2. Vectors . . . . . . . . . . . . . . . . . . . . . . . 15 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 78 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 81 9.2. Informative References . . . . . . . . . . . . . . . . . 17 82 Appendix A. Document Change Log . . . . . . . . . . . . . . . . 18 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 85 1. Introduction 87 The Locator/ID Separation Protocol (LISP) is defined in [RFC6830]. 88 The present document assesses the security level and identifies 89 security threats in the LISP specification if LISP is deployed in the 90 Internet (i.e., a public non-trustable environment). As a result of 91 the performed analysis, the document discusses the severity of the 92 threats and proposes recommendations to reach the same level of 93 security in LISP than in Internet today (e.g., without LISP). 95 The document is composed of three main parts: the first discussing 96 the LISP data-plane; while the second discussing the LISP control- 97 plane. The final part summarizes the recommendations to prevent the 98 identified threats. 100 The LISP data-plane consists of LISP packet encapsulation, 101 decapsulation, and forwarding and includes the map cache data 102 structures used to perform these operations. 104 The LISP control-plane consists in the mapping distribution system, 105 which can be one of the mapping distribution systems proposed so far 106 (e.g., [RFC6830], [I-D.ietf-lisp-ddt], [RFC6836], [RFC6833], 107 [I-D.meyer-lisp-cons], and [RFC6837]), and the Map-Request, Map- 108 Reply, Map-Register, and Map-Notification messages. 110 This document does not consider all the possible uses of LISP as 111 discussed in [RFC6830]. The document focuses on LISP unicast, 112 including as well LISP Interworking [RFC6832], LISP-MS [RFC6833], and 113 LISP Map-Versioning [RFC6834]. The reading of these documents is a 114 prerequisite for understanding the present document. 116 Unless otherwise stated, the document assumes a generic IP service 117 and does not discuss the difference, from a security viewpoint, 118 between using IPv4 or IPv6. 120 2. On-path Attackers 122 On-path attackers are attackers that are able to capture and modify 123 all the packets exchanged between an Ingress Tunnel Router (ITR) and 124 an Egress Tunnel Router (ETR). To cope with such an attacker, 125 cryptographic techniques such as those used by IPSec ([RFC4301]) are 126 required. As with IP, LISP relies on higher layer cryptography to 127 secure packet payloads from on path attacks, so we do not consider 128 on-path attackers in this document. 130 Similarly, a time-shifted attack is an attack where the attacker is 131 temporarily on the path between two communicating hosts. While it is 132 on-path, the attacker sends specially crafted packets or modifies 133 packets exchanged by the communicating hosts in order to disturb the 134 packet flow (e.g., by performing a man in the middle attack). An 135 important issue for time-shifted attacks is the duration of the 136 attack once the attacker has left the path between the two 137 communicating hosts. We do not consider time-shifted attacks in this 138 document. 140 3. Off-Path Attackers: Reference Environment 141 Throughout this document we consider the reference environment shown 142 in the figure below. There are two hosts attached to LISP routers: 143 HA and HB. HA is attached to the two LISP xTRs LR1 and LR2, which in 144 turn are attached to two different ISPs. HB is attached to the two 145 LISP xTRs LR3 and LR4. HA and HB are the EIDs of the two hosts. 146 LR1, LR2, LR3, and LR4 are the RLOCs of the xTRs. PxTR is a proxy 147 xTR and MR/MS plays the roles of Map Server and/or Map Resolver. 149 +-----+ 150 | HA | 151 +-----+ 152 | EID: HA 153 | 154 ----------------- 155 | | 156 +-----+ +-----+ 157 | LR1 | | LR2 | 158 +-----+ +-----+ 159 | | 160 | | 161 +-----+ +-----+ 162 |ISP1 | |ISP2 | 163 +-----+ +-----+ 164 | | 165 +------+ +----------------+ +-----+ 166 | PxTR |-----| |-----| SA | 167 +------+ | | +-----+ 168 | Internet | 169 +-------+ | | +-----+ 170 | MR/MS |----| |-----| NSA | 171 +-------+ +----------------+ +-----+ 172 | | 173 +-----+ +-----+ 174 | LR3 | | LR4 | 175 +-----+ +-----+ 176 | | 177 ------------------- 178 | 179 | EID: HB 180 +-----+ 181 | HB | 182 +-----+ 184 Figure 1: Reference Network 186 We consider two off-path attackers with different capabilities: 188 SA is an off-path attacker that is able to send spoofed packets, 189 i.e., packets with a different source IP address than its 190 assigned IP address. SA stands for Spoofing Attacker. 192 NSA is an off-path attacker that is only able to send packets whose 193 source address is its assigned IP address. NSA stands for Non 194 Spoofing Attacker. 196 It should be noted that with LISP, packet spoofing is slightly 197 different than in the current Internet. Generally the term "spoofed 198 packet" indicates a packet containing a source IP address that is not 199 the one of the actual originator of the packet. Since LISP uses 200 encapsulation, the spoofed address could be in the outer header as 201 well as in the inner header, this translates in two types of 202 spoofing: 204 EID Spoofing: the originator of the packet puts in it a spoofed EID. 205 The packet will be normally encapsulated by the ITR of the site 206 (or a PITR if the source site is not LISP enabled). 208 RLOC Spoofing: the originator of the packet generates directly a 209 LISP-encapsulated packet with a spoofed source RLOC. 211 Note that the two types of spoofing are not mutually exclusive, 212 rather all combinations are possible and could be used to perform 213 different kind of attacks. 215 In the reference environment, both SA and NSA attackers are capable 216 of sending LISP encapsulated data packets and LISP control packets. 217 This means that SA is able to perform both RLOC and EID spoofing 218 while NSA can only perform EID spoofing. They may also send other 219 types of IP packets such as ICMP messages. We assume that both 220 attackers can query the LISP mapping system (e.g., through a public 221 Map Resolver) to obtain the mappings for both HA and HB. 223 4. Attack vectors 225 This section presents techniques that can be used by attackers to 226 succeed attacks leveraging the LISP protocol and architecture. This 227 section focuses on the techniques while Section 5 presents the 228 attacks that can be succeeded while using these techniques. 230 4.1. Configured EID-to-RLOC mappings 232 Each xTR maintains a set of configured mappings related to the EID- 233 Prefixes that are "behind" the xTR [RFC6830]. Where "behind" means 234 that at least one of the xTR's globally visible IP addresses is a 235 RLOC for those EID-Prefixes. 237 As these mappings are determined by configuration. This means that 238 the only way to attack this data structure is by gaining privileged 239 access to the xTR. As such, it is out of the scope of LISP to 240 propose any mechanism to protect routers and, hence, it is no further 241 analyzed in this document. 243 4.2. EID-to-RLOC Cache 245 The EID-to-RLOC Cache (also called the Map-Cache) is the data 246 structure that stores a copy of the mappings retrieved from a remote 247 ETR's mapping via the LISP control-plane. Attacks against this data 248 structure could happen either when the mappings are first installed 249 in the cache or by corrupting (poisoning) the mappings already 250 present in the cache. 252 In this document we call "cache poisoning attack", any attack that 253 alters the EID-to-RLOC Cache. Cache poisoning attacks are use to 254 alter (any combination of) the following parts of mapping installed 255 in the EID-to-RLOC Cache: 257 o EID prefix 259 o RLOC list 261 o RLOC priority 263 o RLOC weight 265 o RLOC reachability 267 o Mapping TTL 269 o Mapping version 271 o Mapping Instance ID 273 4.3. Attacks using the data-plane 275 The data-plane is constituted of the operations of encapsulation, 276 decapsulation, and forwarding as well as the content of the EID-to- 277 RLOC Cache and configured EID-to-RLOC mappings as specified in the 278 original LISP document ([RFC6830]). 280 4.3.1. Attacks not leveraging on the LISP header 282 An attacker can inject packets into flows without using the LISP 283 header, i.e., with the N, L, E, V, and I bits ([RFC6830]). 285 Taking notation of the reference environment notation (Figure 1), to 286 inject a packet in the HA->HB flow, a spoofing off-path attacker (SA) 287 could send a LISP encapsulated packet whose source is set to LR1 or 288 LR2 and destination LR3 or LR4. The packet will reach HB as if the 289 packet was sent by host HA. This is not different from today's 290 Internet where a spoofing off-path attacker may inject data packets 291 in any flow. A non-spoofing off-path attacker (NSA) could only send 292 a packet whose source address is set to its assigned IP address. The 293 destination address of the encapsulated packet could be LR3 or LR4. 295 4.3.1.1. Gleaning Attacks 297 In order to reduce the time required to obtain a mapping, [RFC6830] 298 proposes the gleaning mechanism that allows an ITR to learn a mapping 299 from the LISP data encapsulated packets and the Map-Request packets 300 that it receives. LISP data encapsulated packet contains a source 301 RLOC, destination RLOC, source EID and destination EID. When an ITR 302 receives a data encapsulated packet coming from a source EID for 303 which it does not already know a mapping, it may insert the mapping 304 between the source RLOC and the source EID in its EID-to-RLOC Cache. 305 Gleaning could also be used when an ITR receives a Map-Request as the 306 Map-Request also contains a source EID address and a source RLOC. 307 Once a gleaned entry has been added to the EID-to-RLOC cache, the 308 LISP ITR sends a Map-Request to retrieve the mapping for the gleaned 309 EID from the mapping system. [RFC6830] recommends storing the 310 gleaned entries for only a few seconds. 312 An attacker can send LISP encapsulated packets to host HB with host 313 HA's EID and if the xTRs that serve host HB do not store a mapping 314 for host HA at that time. The xTR will store the gleaned entry and 315 use it to return the packets sent by host HB. In parallel, the ETR 316 will send a Map-Request to retrieve the mapping for HA but until the 317 reception of the Map-Reply, host HB will exchange packets with the 318 attacker instead of HA. 320 Similarly, if an off-path attacker knows that hosts HA and HB that 321 resides in different sites will exchange information at time t the 322 attacker could send to LR1 (resp. LR3) a LISP data encapsulated 323 packet whose source RLOC is its IP address and contains an IP packet 324 whose source is set to HB (resp. HA). The attacker chooses a packet 325 that will not trigger an answer, for example the last part of a 326 fragmented packet. Upon reception of these packets, LR1 and LR3 327 install gleaned entries that point to the attacker. If host HA is 328 willing to establishes a flow with host HB at that time, the packets 329 that they exchange will pass through the attacker as long as the 330 gleaned entry is active on the xTRs. 332 By itself, an attack made solely using gleaning cannot last long, 333 however it should be noted that with current network capacities, a 334 large amount of packets might be exchanged during even a small 335 fraction of time. 337 4.3.1.2. Threats concerning Interworking 339 [RFC6832] defines Proxy-ITR And Proxy-ETR network elements to allow 340 LISP and non-LISP sites to communicate. The Proxy-ITR has 341 functionality similar to the ITR, however, its main purpose is to 342 encapsulate packets arriving from the DFZ in order to reach LISP 343 sites. A Proxy-ETR has functionality similar to the ETR, however, 344 its main purpose is to inject de-encapsulated packets in the DFZ in 345 order to reach non-LISP Sites from LISP sites. As a PITR (resp. 346 PETR) is a particular case of ITR (resp. ETR), it is subject to same 347 attacks than ITRs (resp. ETR). 349 PxTRs can be targeted by attacks aiming to influence traffic between 350 LISP and non-LISP sites but also to launch relay attacks. 352 It is worth to notice that when PITR and PETR functions are 353 separated, attacks targeting nodes that collocate PITR and PETR 354 functionality are ineffective. 356 4.3.2. Attacks leveraging on the LISP header 358 The main LISP document [RFC6830] defines several flags that modify 359 the interpretation of the LISP header in data packets. In this 360 section, we discuss how an off-path attacker could exploit this LISP 361 header. 363 4.3.2.1. Attacks using the Locator Status Bits 365 When the L bit is set to 1, it indicates that the second 32-bits 366 longword of the LISP header contains the Locator Status Bits. In 367 this field, each bit position reflects the status of one of the RLOCs 368 mapped to the source EID found in the encapsulated packet. In 369 particular, a packet with the L bit set and all Locator Status Bits 370 set to zero indicates that none of the locators of the encapsulated 371 source EID are reachable. The reaction of a LISP ETR that receives 372 such a packet is not clearly described in [RFC6830]. 374 An attacker can send a data packet with the L bit set to 1 and some 375 or all Locator Status Bits set to zero. Therefore, by blindly 376 trusting the Locator Status Bits communication going on can be 377 altered or forced to go through a particular set of locators. 379 4.3.2.2. Attacks using the Map-Version bit 381 The optional Map-Version bit is used to indicate whether the low- 382 order 24 bits of the first 32 bits longword of the LISP header 383 contain a Source and Destination Map-Version. When a LISP ETR 384 receives a LISP encapsulated packet with the Map-Version bit set to 385 1, the following actions are taken: 387 o It compares the Destination Map-Version found in the header with 388 the current version of its own configured EID-to-RLOC mapping, for 389 the destination EID found in the encapsulated packet. If the 390 received Destination Map-Version is smaller (i.e., older) than the 391 current version, the ETR should apply the SMR procedure described 392 in [RFC6830] and send a Map-Request with the SMR bit set. 394 o If a mapping exists in the EID-to-RLOC Cache for the source EID, 395 then it compares the Map-Version of that entry with the Source 396 Map-Version found in the header of the packet. If the stored 397 mapping is older (i.e., the Map-Version is smaller) than the 398 source version of the LISP encapsulated packet, the xTR should 399 send a Map-Request for the source EID. 401 An off-path attacker could use the Map-Version bit to force an ETR to 402 send Map-Request messages. The attacker could retrieve the current 403 source and destination Map-Version for both HA and HB. Based on this 404 information, it could send a spoofed packet with an older Source Map- 405 Version or Destination Map-Version. If the size of the Map-Request 406 message is larger than the size of the smallest LISP-encapsulated 407 packet that could trigger such a message, this could lead to 408 amplification attacks (see Section 4.4.1) so that more bandwidth is 409 consumed on the target than the bandwidth necessary at the attacker 410 side. 412 4.3.2.3. Attacks using the Nonce-Present and the Echo-Nonce bits 414 The Nonce-Present and Echo-Nonce bits are used when verifying the 415 reachability of a remote ETR. Assume that LR3 wants to verify that 416 LR1 receives the packets that it sends. LR3 can set the Echo-Nonce 417 and the Nonce-Present bits in LISP data encapsulated packets and 418 include a random nonce in these packets. Upon reception of these 419 packets, LR1 will store the nonce sent by LR3 and echo it when it 420 returns LISP encapsulated data packets to LR3. 422 A spoofing off-path attacker (SA) could interfere with this 423 reachability test by sending two different types of packets: 425 1. LISP data encapsulated packets with the Nonce-Present bit set and 426 a random nonce and the appropriate source and destination RLOCs. 428 2. LISP data encapsulated packets with the Nonce-Present and the 429 Echo-Nonce bits both set and the appropriate source and 430 destination RLOCs. These packets will force the receiving ETR to 431 store the received nonce and echo it in the LISP encapsulated 432 packets that it sends. 434 The first type of packet should not cause any major problem to ITRs. 435 As the reachability test uses a 24 bits nonce, it is unlikely that an 436 off-path attacker could send a single packet that causes an ITR to 437 believe that the ETR it is testing is reachable while in reality it 438 is not reachable. To increase the success likelihood of such attack, 439 the attacker should created a massive amount of packets carrying all 440 possible nonce values. 442 The second type of packet could be exploited to attack the nonce- 443 based reachability test. Consider a spoofing off-path attacker (SA) 444 that sends a continuous flow of spoofed LISP data encapsulated 445 packets that contain the Nonce-Present and the Echo-Nonce bit and 446 each packet contains a different random nonce. The ETR that receives 447 such packets will continuously change the nonce that it returns to 448 the remote ITR. If the remote ITR starts a nonce-reachability test, 449 this test may fail because the ETR has received a spoofed LISP data 450 encapsulated packet with a different random nonce and never echoes 451 the real nonce. In this case the ITR will consider the ETR not 452 reachable. The success of this test depends on the ratio between the 453 amount of packets sent by the legitimate ITR and the spoofing off- 454 path attacker (SA). 456 4.3.2.4. Attacks using the Instance ID bits 458 LISP allows to carry in its header a 24-bits value called "Instance 459 ID" and used on the ITR to indicate which local Instance ID has been 460 used for encapsulation, while on the ETR can be used to select the 461 forwarding table used for forwarding the decapsulated packet. 463 The Instance ID increases exposure to attacks ([RFC6169]) as if an 464 off-path attacker can randomly guess a valid Instance ID value to get 465 access to network that might not been accessible in normal 466 conditions. However, the impact of such attack is directly on end- 467 systems which is is out of the scope of this document. 469 4.4. Attacks using the control-plane 471 In this section, we discuss the different types of attacks that could 472 occur when an off-path attacker sends control-plane packets. We 473 focus on the packets that are sent directly to the ETR and do not 474 analyze the particularities of the different LISP indexing sub- 475 system. 477 4.4.1. Attacks with Map-Request messages 479 An off-path attacker could send Map-Request packets to a victim ETR. 480 In theory, a Map-Request packet is only used to solicit an answer and 481 as such it should not lead to security problems. However, the LISP 482 specification [RFC6830] contains several particularities that could 483 be exploited by an off-path attacker. 485 The first possible exploitation is the RLOC record P bit. The RLOC 486 record P bit is used to probe the reachability of remote ETRs. In 487 our reference environment, LR3 could probe the reachability of LR1 by 488 sending a Map-Request with the RLOC record P bit set. LR1 would 489 reply by sending a Map-Reply message with the RLOC record P bit set 490 and the same nonce as in the Map-Request message. 492 A spoofing off-path attacker (SA) could use the RLOC record P bit to 493 force a victim ETR to send a Map-Reply to the spoofed source address 494 of the Map-Request message. As the Map-Reply can be larger than the 495 Map-Request message, there is a risk of amplification attack. 496 Considering only IPv6 addresses, a Map-Request can be as small as 40 497 bytes, considering one single ITR address and no Mapping Protocol 498 Data. The Map-Reply instead has a proportional to the maximum number 499 of RLOCs in a mapping and maximum number of records in a Map-Reply. 500 Since up to 255 RLOCs can be associated to an EID-Prefix and 255 501 records can be stored in a Map-Reply, the maximum size of a Map-Reply 502 is thus above 1 MB, largely bigger than the message sent by the 503 attacker. These numbers are however theoretical values not 504 considering transport layer limitations and it is more likely that 505 the reply will contain only one record with at most a dozen of 506 locators, limiting so the amplification factor. 508 Similarly, if a non-spoofing off-path attacker (NSA) sends a Map- 509 Request with the RLOC record P bit set, it will receive a Map-Reply 510 with the RLOC record P bit set. 512 An amplification attack could be launched by a spoofing off-path 513 attacker (SA) as follows. Consider an attacker SA and EID-Prefix 514 192.0.2.0/24 and a victim ITR, SA could send spoofed Map-Request 515 messages whose source EID addresses are all the addresses inside 516 192.0.2.0/24 and source RLOC address is the victim ITR. Upon 517 reception of these Map-Request messages, the ETR would send large 518 Map-Reply messages for each of the addresses inside p/P back to the 519 victim ITR. 521 The Map-Request message may also contain the SMR bit. Upon reception 522 of a Map-Request message with the SMR bit, an ETR must return to the 523 source of the Map-Request message a Map-Request message to retrieve 524 the corresponding mapping. This raises similar problems as the RLOC 525 record P bit discussed above except that as the Map-Request messages 526 are smaller than Map-Reply messages, the risk of amplification 527 attacks is reduced. This is not true anymore if the ETR append to 528 the Map-Request messages its own Map-Records. This mechanism is 529 meant to reduce the delay in mapping distribution since mapping 530 information is provided in the Map-Request message. 532 Furthermore, appending Map-Records to Map-Request messages allows an 533 off-path attacker to generate a (spoofed or not) Map-Request message 534 and include in the Map-Reply portion of the message mapping for EID 535 prefixes that it does not serve. 537 Moreover, attackers can use Map Resolver and/or Map Server network 538 elements to perform relay attacks. Indeed, on the one hand, a Map 539 Resolver is used to dispatch Map-Request to the mapping system and, 540 on the other hand, a Map Server is used to dispatch Map-Requests 541 coming from the mapping system to ETRs that are authoritative for the 542 EID in the Map-Request. 544 4.4.2. Attacks with Map-Reply messages 546 In this section we analyze the attacks that could occur when an off- 547 path attacker sends directly Map-Reply messages to ETRs without using 548 one of the proposed LISP mapping systems. 550 There are two different types of Map-Reply messages: 552 Positive Map-Reply: These messages contain a Map-Record binding an 553 EID-Prefix to one or more RLOCs. 555 Negative Map-Reply: These messages contain a Map-Record for an EID- 556 Prefix with an empty locator-set and specifying an action, 557 which may be either Drop, natively forward, or Send Map- 558 Request. 560 Positive Map-Reply messages are used to map EID-Prefixes onto RLOCs. 561 Negative Map-Reply messages are used to indicate non-LISP prefixes. 562 ITRs can, if needed, be configured to send all traffic destined for 563 non-LISP prefixes to a Proxy-ETR. 565 Most of the security of the Map-Reply messages depends on the 64 bits 566 nonce that is included in a Map-Request and returned in the Map- 567 Reply. If an ETR does not accept Map-Reply messages with an invalid 568 nonce, the risk of attack is acceptable given the size of the nonce 569 (64 bits). However, the nonce only confirms that the Map-Reply 570 received was sent in response to a Map-Request sent, it does not 571 validate the contents of that Map-Reply. 573 In addition, an attacker could perform EID-to-RLOC Cache overflow 574 attack by de-aggregating (i.e., splitting an EID prefix into 575 artificially smaller EID prefixes) either positive or negative 576 mappings. 578 In presence of malicious ETRs, overclaiming attacks are possible. 579 Such an attack happens when and ETR replies to a legitimate Map- 580 Request message it received with a Map-Reply message that contains an 581 EID-Prefix that is larger than the prefix owned by the site that 582 encompasses the EID of the Map-Request. For instance if the prefix 583 owned by the site is 192.0.2.0/25 but the Map-Reply contains a 584 mapping for 192.0.2.0/24, then the mapping will influence packets 585 destined to other EIDs than the one the LISP site has authority on. 587 A malicious ETR might also fragment its configured EID-to-RLOC 588 mappings so that ITR's might have to install much more mappings than 589 really necessary. This attack is called de-aggregation attack. 591 4.4.3. Attacks with Map-Register messages 593 Map-Register messages are sent by ETRs to indicate to the mapping 594 system the EID prefixes associated to them. The Map-Register message 595 provides an EID prefix and the list of ETRs that are able to provide 596 Map-Replies for the EID covered by the EID prefix. 598 As Map-Register messages are protected by an authentication 599 mechanism, only a compromised ETR can register itself to its 600 allocated Map Server. 602 A compromised ETR can perform an overclaiming attack in order to 603 influence the route followed by Map-Requests for EIDs outside the 604 scope of its legitimate EID prefix. 606 A compromised ETR can also perform a deaggregation attack in order to 607 register more EID prefixes than necessary to its Map Servers. 609 Similarly, a compromised Map Server can accept invalid registration 610 or advertise invalid EID prefix to the indexing sub-system. 612 4.4.4. Attacks with Map-Notify messages 614 Map-Notify messages are sent by a Map Server to an ETR to acknowledge 615 the good reception and processing of a Map-Register message. 617 An compromised ETR using EID that it is not authoritative for can 618 send a Map-Register with the M-bit set and a spoofed source address 619 to force the Map Server to send a Map-Notify message to the spoofed 620 address and then succeed a relay attack. Similarly to the pair Map- 621 Request/Map-Reply, the pair Map-Register/Map-Notify is protected by a 622 nonce making it hard for an attacker to inject a falsified 623 notification to an ETR to make this ETR believe that the registration 624 succeeded while it has not. 626 5. Attack categories 628 5.1. Intrusion 630 5.1.1. Description 632 With an intrusion attack an attacker gains remote access to some 633 resources (e.g., a host, a router, or a network) that are normally 634 denied to her. 636 5.1.2. Vectors 638 Intrusion attacks can be mounted using: 640 o Spoofing EID or RLOCs 642 o Instance ID bits 644 5.2. Denial of Service (DoS) 646 5.2.1. Description 648 A Denial of Service (DoS) attack aims at disrupting a specific 649 targeted service either by exhausting the resources of the victim up 650 to the point that it is not able to provide a reliable service to 651 legit traffic and/or systems or by exploiting vulnerabilities to make 652 the targeted service unable to operate properly. 654 5.2.2. Vectors 656 Denial of Service attacks can be mounted using 658 o Gleaning 659 o Interworking 661 o Locator Status Bits 663 o Map-Version bit 665 o Nonce-Present and Echo-Nonce bits 667 o Map-Request message 669 o Map-Reply message 671 o Map-Register message 673 o Map-Notify message 675 5.3. Subversion 677 5.3.1. Description 679 With subversion an attacker can gain access (e.g., using 680 eavesdropping or impersonation) to restricted or sensitive 681 information such as passwords, session tokens, or any other 682 confidential information. This type of attack is usually carried out 683 in a way such that the target does not even notice the attack. When 684 the attacker is positioned on the path of the target traffic, it is 685 called a Man-in-the-Middle attack. However, this is not a 686 requirement to carry out and eavesdropping attack. Indeed the 687 attacker might be able, for instance through an intrusion attack on a 688 weaker system, either to duplicate or even re-direct the traffic, in 689 both cases having access to the raw packets. 691 5.3.2. Vectors 693 Subversion attacks can be mounted using 695 o Gleaning 697 o Locator Status Bits 699 o Nonce-Present and the Echo-Nonce bits 701 o Map-Request messages 703 o Map-Reply messages 705 6. IANA Considerations 706 This document makes no request to IANA. 708 7. Security Considerations 710 This document is devoted to threat analysis of the Locator/Identifier 711 Separation Protocol and is then a piece of choice to understand the 712 security risks at stake while deploying LISP in non-trustable 713 environment. 715 The purpose of this document is not to provide recommendations to 716 protect against attacks, however most of threats can be prevented 717 with careful deployment and configuration (e.g., filter) and also by 718 applying the general rules in security that consist in activating 719 only features that are necessary in the deployment and verifying the 720 validity of the information obtained from third parties. More 721 detailed recommendation are given in [book_chapter]. 723 The control-plane is probably the most critical part of LISP from a 724 security viewpoint and it is worth to notice that the specifications 725 already offer authentication mechanism for Map-Register messages 726 ([RFC6833]) and that [I-D.ietf-lisp-sec] and [I-D.ietf-lisp-ddt] are 727 clearly going in the direction of a secure control-plane. 729 8. Acknowledgments 731 This document builds upon the draft of Marcelo Bagnulo 732 ([I-D.bagnulo-lisp-threat]), where the flooding attack and the 733 reference environment were first described. 735 The authors would like to thank Ronald Bonica, Albert Cabellos, Noel 736 Chiappa, Florin Coras, Vina Ermagan, Dino Farinacci, Joel Halpern, 737 Emily Hiltzik, Darrel Lewis, Edward Lopez, Fabio Maino, Terry 738 Manderson, and Jeff Wheeler for their comments. 740 This work has been partially supported by the INFSO-ICT-216372 741 TRILOGY Project (www.trilogy-project.org). 743 9. References 745 9.1. Normative References 747 [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security 748 Concerns with IP Tunneling", RFC 6169, April 2011. 750 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 751 Locator/ID Separation Protocol (LISP)", RFC 6830, January 752 2013. 754 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 755 "Interworking between Locator/ID Separation Protocol 756 (LISP) and Non-LISP Sites", RFC 6832, January 2013. 758 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 759 Protocol (LISP) Map-Server Interface", RFC 6833, January 760 2013. 762 [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID 763 Separation Protocol (LISP) Map-Versioning", RFC 6834, 764 January 2013. 766 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 767 "Locator/ID Separation Protocol Alternative Logical 768 Topology (LISP+ALT)", RFC 6836, January 2013. 770 [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to 771 Routing Locator (RLOC) Database", RFC 6837, January 2013. 773 9.2. Informative References 775 [Chu] Jerry Chu, H., "Tuning TCP Parameters for the 21st Century 776 ", 75th IETF, Stockholm, July 2009, 777 . 779 [I-D.bagnulo-lisp-threat] 780 Bagnulo, M., "Preliminary LISP Threat Analysis", draft- 781 bagnulo-lisp-threat-01 (work in progress), July 2007. 783 [I-D.ietf-lisp-ddt] 784 Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP 785 Delegated Database Tree", draft-ietf-lisp-ddt-01 (work in 786 progress), March 2013. 788 [I-D.ietf-lisp-sec] 789 Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D., 790 and O. Bonaventure, "LISP-Security (LISP-SEC)", draft- 791 ietf-lisp-sec-04 (work in progress), October 2012. 793 [I-D.ietf-tcpm-tcp-security] 794 Gont, F., "Survey of Security Hardening Methods for 795 Transmission Control Protocol (TCP) Implementations", 796 draft-ietf-tcpm-tcp-security-03 (work in progress), March 797 2012. 799 [I-D.meyer-lisp-cons] 800 Brim, S., "LISP-CONS: A Content distribution Overlay 801 Network Service for LISP", draft-meyer-lisp-cons-04 (work 802 in progress), April 2008. 804 [I-D.saucez-lisp-mapping-security] 805 Saucez, D. and O. Bonaventure, "Securing LISP Mapping 806 replies", draft-saucez-lisp-mapping-security-00 (work in 807 progress), February 2011. 809 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 810 Networks", BCP 84, RFC 3704, March 2004. 812 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 813 Internet Protocol", RFC 4301, December 2005. 815 [RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing 816 Security: An Unauthenticated Mode of IPsec", RFC 5386, 817 November 2008. 819 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 820 Secure Internet Routing", RFC 6480, February 2012. 822 [SAVI] IETF, "Source Address Validation Improvements Working 823 Group ", 2013, . 825 [Saucez09] 826 Saucez, D. and L. Iannone, "How to mitigate the effect of 827 scans on mapping systems ", Trilogy Summer School on 828 Future Internet, 2009. 830 [book_chapter] 831 Saucez, D., Iannone, L., and O. Bonaventure, "The Map-and- 832 Encap Locator/Identifier separation paradigm: a Security 833 Analysis ", Solutions for Sustaining Scalability in 834 Internet Growth, IGI Global, 2013. 836 Appendix A. Document Change Log 838 o Version 07 Posted October 2013. 840 * This version is updated according to the thorough review made 841 during October 2013 LISP WG interim meeting. 843 * Brief recommendations put in the security consideration 844 section. 846 * Editorial changes 848 o Version 06 Posted October 2013. 850 * Complete restructuration, temporary version to be used at 851 October 2013 interim meeting. 853 o Version 05 Posted August 2013. 855 * Removal of severity levels to become a short recommendation to 856 reduce the risk of the discussed threat. 858 o Version 04 Posted February 2013. 860 * Clear statement that the document compares threats of public 861 LISP deployments with threats in the current Internet 862 architecture. 864 * Addition of a severity level discussion at the end of each 865 section. 867 * Addressed comments from V. Ermagan and D. Lewis' reviews. 869 * Updated References. 871 * Further editorial polishing. 873 o Version 03 Posted October 2012. 875 * Dropped Reference to RFC 2119 notation because it is not 876 actually used in the document. 878 * Deleted future plans section. 880 * Updated References 882 * Deleted/Modified sentences referring to the early status of the 883 LISP WG and documents at the time of writing early versions of 884 the document. 886 * Further editorial polishing. 888 * Fixed all ID nits. 890 o Version 02 Posted September 2012. 892 * Added a new attack that combines overclaiming and de- 893 aggregation (see Section 4.4.2). 895 * Editorial polishing. 897 o Version 01 Posted February 2012. 899 * Added discussion on LISP-DDT. 901 o Version 00 Posted July 2011. 903 * Added discussion on LISP-MS>. 905 * Added discussion on Instance ID in Section 4.3.2. 907 * Editorial polishing of the whole document. 909 * Added "Change Log" appendix to keep track of main changes. 911 * Renamed "draft-saucez-lisp-security-03.txt. 913 Authors' Addresses 915 Damien Saucez 916 INRIA 917 2004 route des Lucioles BP 93 918 06902 Sophia Antipolis Cedex 919 France 921 Email: damien.saucez@inria.fr 923 Luigi Iannone 924 Telecom ParisTech 925 23, Avenue d'Italie, CS 51327 926 75214 PARIS Cedex 13 927 France 929 Email: luigi.iannone@telecom-paristech.fr 931 Olivier Bonaventure 932 Universite catholique de Louvain 933 Place St. Barbe 2 934 Louvain la Neuve 935 Belgium 937 Email: olivier.bonaventure@uclouvain.be