idnits 2.17.1 draft-ietf-lisp-threats-06.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 02, 2013) is 3849 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'Chu' is defined on line 783, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-lisp-sec' is defined on line 796, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-tcpm-tcp-security' is defined on line 801, but no explicit reference was found in the text == Unused Reference: 'I-D.saucez-lisp-mapping-security' is defined on line 812, but no explicit reference was found in the text == Unused Reference: 'RFC3704' is defined on line 817, but no explicit reference was found in the text == Unused Reference: 'RFC5386' is defined on line 823, but no explicit reference was found in the text == Unused Reference: 'RFC6480' is defined on line 827, but no explicit reference was found in the text == Unused Reference: 'SAVI' is defined on line 830, but no explicit reference was found in the text == Unused Reference: 'Saucez09' is defined on line 833, 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 (~~), 12 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 05, 2014 Telecom ParisTech 6 O. Bonaventure 7 Universite catholique de Louvain 8 October 02, 2013 10 LISP Threats Analysis 11 draft-ietf-lisp-threats-06.txt 13 Abstract 15 This document discusses potential security concerns with the Locator/ 16 Identifier Separation Protocol (LISP) if deployed in the Internet and 17 proposes a set of recommendations to mitigate the identified threats 18 and to reach a level of security equivalent to what is observed in 19 the Internet today (i.e., without LISP). By following the 20 recommendations of this draft a LISP deployment can achieve a 21 security level that is comparable to the existing Internet 22 architecture. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 05, 2014. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 60 3. On-path Attackers . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Off-Path Attackers: Reference Environment . . . . . . . . . . 4 62 5. Attack vectors . . . . . . . . . . . . . . . . . . . . . . . 6 63 5.1. EID-to-RLOC Database . . . . . . . . . . . . . . . . . . 6 64 5.2. EID-to-RLOC Cache . . . . . . . . . . . . . . . . . . . . 6 65 5.3. Attack using the data-plane . . . . . . . . . . . . . . . 7 66 5.3.1. Attacks not leveraging on the LISP header . . . . . . 7 67 5.3.2. Attacks leveraging on the LISP header . . . . . . . . 9 68 5.4. Attack using the control-plane . . . . . . . . . . . . . 11 69 5.4.1. Attacks with Map-Request messages . . . . . . . . . . 11 70 5.4.2. Attacks with Map-Reply messages . . . . . . . . . . . 13 71 5.4.3. Attacks with Map-Register messages . . . . . . . . . 14 72 5.4.4. Attacks with Map-Notify messages . . . . . . . . . . 14 73 6. Attack categories . . . . . . . . . . . . . . . . . . . . . . 14 74 6.1. Intrusion . . . . . . . . . . . . . . . . . . . . . . . . 14 75 6.1.1. Description . . . . . . . . . . . . . . . . . . . . . 14 76 6.1.2. Vectors . . . . . . . . . . . . . . . . . . . . . . . 14 77 6.2. Denial of Service (DoS) . . . . . . . . . . . . . . . . . 15 78 6.2.1. Description . . . . . . . . . . . . . . . . . . . . . 15 79 6.2.2. Vectors . . . . . . . . . . . . . . . . . . . . . . . 15 80 6.3. Eavesdropping . . . . . . . . . . . . . . . . . . . . . . 15 81 6.3.1. Description . . . . . . . . . . . . . . . . . . . . . 15 82 6.3.2. Vectors . . . . . . . . . . . . . . . . . . . . . . . 16 83 7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 16 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 85 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 86 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 87 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 88 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 89 11.2. Informative References . . . . . . . . . . . . . . . . . 17 90 Appendix A. Document Change Log . . . . . . . . . . . . . . . . 18 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 93 1. Introduction 95 The Locator/ID Separation Protocol (LISP) is defined in [RFC6830]. 96 The present document assesses the security level and identifies 97 security threats in the LISP specification if LISP is deployed in the 98 Internet (i.e., a public non-trustable environment). As a result of 99 the performed analysis, the document discusses the severity of the 100 threats and proposes recommendations to reach the same level of 101 security in LISP than in Internet today (e.g., without LISP). 103 The document is composed of three main parts: the first discussing 104 the LISP data-plane; while the second discussing the LISP control- 105 plane. The final part summarizes the recommendations to prevent the 106 identified threats. 108 The LISP data-plane consists of LISP packet encapsulation, 109 decapsulation, and forwarding and includes the EID-to-RLOC Cache and 110 EID-to-RLOC Database data structures used to perform these 111 operations. 113 The LISP control-plane consists in the mapping distribution system, 114 which can be one of the mapping distribution systems proposed so far 115 (e.g., [RFC6830], [I-D.ietf-lisp-ddt], [RFC6836], [RFC6833], 116 [I-D.meyer-lisp-cons], and [RFC6837]), and the Map-Request, Map- 117 Reply, Map-Register, and Map-Notification messages. 119 This document does not consider all the possible uses of LISP as 120 discussed in [RFC6830]. The document focuses on LISP unicast, 121 including as well LISP Interworking [RFC6832], LISP-MS [RFC6833], 122 LISP Map-Versioning [RFC6834], and briefly considering the ALT 123 mapping system described in [RFC6836] and the Delegated Database Tree 124 mapping system described in [I-D.ietf-lisp-ddt]. The reading of 125 these documents is a prerequisite for understanding the present 126 document. 128 Unless otherwise stated, the document assumes a generic IP service 129 and does not discuss the difference, from a security viewpoint, 130 between using IPv4 or IPv6. 132 This document has identified several threats on LISP in the case of 133 public deployments. However, most of the threats can be prevented 134 with careful deployment and configuration and general rules in 135 security that consist in activating only features that are necessary 136 in the deployment and to carefully verifying the validity of the 137 information obtained from third parties also applies in the case of 138 LISP. Finally, this document has not identified any threats that 139 would require a change in the LISP protocol or architecture. 141 2. Definition of Terms 142 The present document does not introduce any other new term, compared 143 to the main LISP specification. For a complete list of terms please 144 refer to [RFC6830]. 146 3. On-path Attackers 148 On-path attackers are attackers that are able to capture and modify 149 all the packets exchanged between an Ingress Tunnel Router (ITR) and 150 an Egress Tunnel Router (ETR). To cope with such an attacker, 151 cryptographic techniques such as those used by IPSec ([RFC4301]) are 152 required. As with IP, LISP relies on higher layer cryptography to 153 secure packet payloads from on path attacks, so we do not consider 154 on-path attackers in this document. 156 Similarly, a time-shifted attack is an attack where the attacker is 157 temporarily on the path between two communicating hosts. While it is 158 on-path, the attacker sends specially crafted packets or modifies 159 packets exchanged by the communicating hosts in order to disturb the 160 packet flow (e.g., by performing a man in the middle attack). An 161 important issue for time-shifted attacks is the duration of the 162 attack once the attacker has left the path between the two 163 communicating hosts. We do not consider time-shifted attacks in this 164 document. 166 4. Off-Path Attackers: Reference Environment 168 Throughout this document we consider the reference environment shown 169 in the figure below. There are two hosts attached to LISP routers: 170 HA and HB. HA is attached to the two LISP xTRs LR1 and LR2, which in 171 turn are attached to two different ISPs. HB is attached to the two 172 LISP xTRs LR3 and LR4. HA and HB are the EIDs of the two hosts. 173 LR1, LR2, LR3, and LR4 are the RLOCs of the xTRs. PxTR is a proxy 174 xTR and MR/MS plays the roles of Map Server and/or Map Resolver. 176 +-----+ 177 | HA | 178 +-----+ 179 | EID: HA 180 | 181 ----------------- 182 | | 183 +-----+ +-----+ 184 | LR1 | | LR2 | 185 +-----+ +-----+ 186 | | 187 | | 188 +-----+ +-----+ 189 |ISP1 | |ISP2 | 190 +-----+ +-----+ 191 | | 192 +------+ +----------------+ +-----+ 193 | PxTR |-----| |-----| SA | 194 +------+ | | +-----+ 195 | Internet | 196 +-------+ | | +-----+ 197 | MR/MS |----| |-----| NSA | 198 +-------+ +----------------+ +-----+ 199 | | 200 +-----+ +-----+ 201 | LR3 | | LR4 | 202 +-----+ +-----+ 203 | | 204 ------------------- 205 | 206 | EID: HB 207 +-----+ 208 | HB | 209 +-----+ 211 Figure 1: Reference Network 213 We consider two off-path attackers with different capabilities: 215 SA is an off-path attacker that is able to send spoofed packets, 216 i.e., packets with a different source IP address than its 217 assigned IP address. SA stands for Spoofing Attacker. 219 NSA is an off-path attacker that is only able to send packets whose 220 source address is its assigned IP address. NSA stands for Non 221 Spoofing Attacker. 223 It should be noted that with LISP, packet spoofing is slightly 224 different than in the current Internet. Generally the term "spoofed 225 packet" indicates a packet containing a source IP address that is not 226 the one of the actual originator of the packet. Since LISP uses 227 encapsulation, the spoofed address could be in the outer header as 228 well as in the inner header, this translates in two types of 229 spoofing: 231 EID Spoofing: the originator of the packet puts in it a spoofed EID. 232 The packet will be normally encapsulated by the ITR of the site 233 (or a PITR if the source site is not LISP enabled). 235 RLOC Spoofing: the originator of the packet generates directly a 236 LISP-encapsulated packet with a spoofed source RLOC. 238 Note that the two types of spoofing are not mutually exclusive, 239 rather all combinations are possible and could be used to perform 240 different kind of attacks. 242 In the reference environment, both SA and NSA attackers are capable 243 of sending LISP encapsulated data packets and LISP control packets. 244 This means that SA is able to perform both RLOC and EID spoofing 245 while NSA can only perform EID spoofing. They may also send other 246 types of IP packets such as ICMP messages. We assume that both 247 attackers can query the LISP mapping system (e.g., through a public 248 Map Resolver) to obtain the mappings for both HA and HB. 250 5. Attack vectors 252 This section presents techniques that can be used by attackers to 253 succeed attacks leveraging the LISP protocol and architecture. This 254 section focuses on the techniques while Section 6 presents the 255 attacks that can be succeeded while using these techniques. 257 5.1. EID-to-RLOC Database 259 The EID-to-RLOC Database on each xTR maintains the set of mappings 260 related to the EID-Prefixes that are "behind" the xTR. Where 261 "behind" means that at least one of the xTR's globally visible IP 262 addresses is a RLOC for those EID-Prefixes. 264 As described in [RFC6830], the EID-to-RLOC Database content is 265 determined by configuration. This means that the only way to attack 266 this data structure is by gaining privileged access to the xTR. As 267 such, it is out of the scope of LISP to propose any mechanism to 268 protect routers and, hence, it is no further analyzed in this 269 document. 271 5.2. EID-to-RLOC Cache 273 The EID-to-RLOC Cache (also called the Map-Cache) is the data 274 structure that stores a copy of the mappings retrieved from a remote 275 ETR's mapping database via the LISP control-plane. Attacks against 276 this data structure could happen either when the mappings are first 277 installed in the cache or by corrupting (poisoning) the mappings 278 already present in the cache. 280 In this document we call "cache poisoning attack", any attach that 281 alters the EID-to-RLOC Cache. Cache poisoning attacks are use to 282 alter (any combination of) the following parts of mapping installed 283 in the EID-to-RLOC Cache: 285 o EID prefix 286 o RLOC list 288 o RLOC priority 290 o RLOC weight 292 o RLOC reachability 294 o Mapping TTL 296 o Mapping version 298 o Mapping Instance ID 300 5.3. Attack using the data-plane 302 The data-plane is constituted of the operations of encapsulation, 303 decapsulation, and forwarding as well as the content of the EID-to- 304 RLOC Cache and EID-to-RLOC Database as specified in the original LISP 305 document ([RFC6830]). 307 5.3.1. Attacks not leveraging on the LISP header 309 An attacker can inject packets into flows without using the LISP 310 header, i.e., with the N, L, E, V, and I bits ([RFC6830]). 312 To inject a packet in the HA-HB flow, a spoofing off-path attacker 313 (SA) could send a LISP encapsulated packet whose source is set to LR1 314 or LR2 and destination LR3 or LR4. The packet will reach HB as if 315 the packet was sent by host HA. This is not different from today's 316 Internet where a spoofing off-path attacker may inject data packets 317 in any flow. A non-spoofing off-path attacker (NSA) could only send 318 a packet whose source address is set to its assigned IP address. The 319 destination address of the encapsulated packet could be LR3 or LR4. 321 5.3.1.1. Gleaning Attacks 323 In order to reduce the time required to obtain a mapping, [RFC6830] 324 proposes the gleaning mechanism that allows an ITR to learn a mapping 325 from the LISP data encapsulated packets and the Map-Request packets 326 that it receives. LISP data encapsulated packet contains a source 327 RLOC, destination RLOC, source EID and destination EID. When an ITR 328 receives a data encapsulated packet coming from a source EID for 329 which it does not already know a mapping, it may insert the mapping 330 between the source RLOC and the source EID in its EID-to-RLOC Cache. 331 Gleaning could also be used when an ITR receives a Map-Request as the 332 Map-Request also contains a source EID address and a source RLOC. 333 Once a gleaned entry has been added to the EID-to-RLOC cache, the 334 LISP ITR sends a Map-Request to retrieve the mapping for the gleaned 335 EID from the mapping system. [RFC6830] recommends storing the 336 gleaned entries for only a few seconds. 338 An attacker can send LISP encapsulated packets to host HB with host 339 HA's EID and if the xTRs that serve host HB do not store a mapping 340 for host HA at that time The xTR will store the gleaned entry and use 341 it to return the packets sent by host HB. In parallel, the ETR will 342 send a Map-Request to retrieve the mapping for HA but until the 343 reception of the Map-Reply, host HB will exchange packets with the 344 attacker instead of HA. 346 Similarly, if an off-path attacker knows that hosts HA and HB that 347 resides in different sites will exchange information at time t the 348 attacker could send to LR1 (resp. LR3) a LISP data encapsulated 349 packet whose source RLOC is its IP address and contains an IP packet 350 whose source is set to HB (resp. HA). The attacker chooses a packet 351 that will not trigger an answer, for example the last part of a 352 fragmented packet. Upon reception of these packets, LR1 and LR3 353 install gleaned entries that point to the attacker. If host HA is 354 willing to establishes a flow with host HB at that time, the packets 355 that they exchange will pass through the attacker as long as the 356 gleaned entry is active on the xTRs. 358 By itself, an attack made solely using gleaning cannot last long, 359 however it should be noted that with current network capacities, a 360 large amount of packets might be exchanged during even a small 361 fraction of time. 363 5.3.1.2. Threats concerning Interworking 365 [RFC6832] defines Proxy-ITR And Proxy-ETR network elements to allow 366 LISP and non-LISP sites to communicate. The Proxy-ITR has 367 functionality similar to the ITR, however, its main purpose is to 368 encapsulate packets arriving from the DFZ in order to reach LISP 369 sites. A Proxy-ETR has functionality similar to the ETR, however, 370 its main purpose is to inject de-encapsulated packets in the DFZ in 371 order to reach non-LISP Sites from LISP sites. As a PITR (resp. 372 PETR) is a particular case of ITR (resp. ETR), it is subject to same 373 attacks than ITRs (resp. ETR). 375 PxTRs can be targeted by attacks aiming to influence traffic between 376 LISP and non-LISP sites but also to launch relay attacks. 378 It is worth to notice that when PITR and PETR functions are 379 separated, attacks targeting xTRs are ineffective. 381 5.3.2. Attacks leveraging on the LISP header 383 The main LISP document [RFC6830] defines several flags that modify 384 the interpretation of the LISP header in data packets. In this 385 section, we discuss how an off-path attacker could exploit this LISP 386 header. 388 5.3.2.1. Attacks using the Locator Status Bits 390 When the L bit is set to 1, it indicates that the second 32-bits 391 longword of the LISP header contains the Locator Status Bits. In 392 this field, each bit position reflects the status of one of the RLOCs 393 mapped to the source EID found in the encapsulated packet. In 394 particular, a packet with the L bit set and all Locator Status Bits 395 set to zero indicates that none of the locators of the encapsulated 396 source EID are reachable. The reaction of a LISP ETR that receives 397 such a packet is not clearly described in [RFC6830]. 399 An attacker can send a data packet with the L bit set to 1 and some 400 or all Locator Status Bits set to zero. Therefore, by blindly 401 trusting the Locator Status Bits communication going on can be 402 altered or forced to go through a particular set of locators. 404 5.3.2.2. Attacks using the Map-Version bit 406 The optional Map-Version bit is used to indicate whether the low- 407 order 24 bits of the first 32 bits longword of the LISP header 408 contain a Source and Destination Map-Version. When a LISP ETR 409 receives a LISP encapsulated packet with the Map-Version bit set to 410 1, the following actions are taken: 412 o It compares the Destination Map-Version found in the header with 413 the current version of its own mapping, in the EID-to-RLOC 414 Database, for the destination EID found in the encapsulated 415 packet. If the received Destination Map-Version is smaller (i.e., 416 older) than the current version, the ETR should apply the SMR 417 procedure described in [RFC6830] and send a Map-Request with the 418 SMR bit set. 420 o If a mapping exists in the EID-to-RLOC Cache for the source EID, 421 then it compares the Map-Version of that entry with the Source 422 Map-Version found in the header of the packet. If the stored 423 mapping is older (i.e., the Map-Version is smaller) than the 424 source version of the LISP encapsulated packet, the xTR should 425 send a Map-Request for the source EID. 427 An off-path attacker could use the Map-Version bit to force an ETR to 428 send Map-Request messages. The attacker could retrieve the current 429 source and destination Map-Version for both HA and HB. Based on this 430 information, it could send a spoofed packet with an older Source Map- 431 Version or Destination Map-Version. If the size of the Map-Request 432 message is larger than the size of the smallest LISP-encapsulated 433 packet that could trigger such a message, this could lead to 434 amplification attacks (see Section 5.4.1). 436 5.3.2.3. Attacks using the Nonce-Present and the Echo-Nonce bits 438 The Nonce-Present and Echo-Nonce bits are used when verifying the 439 reachability of a remote ETR. Assume that LR3 wants to verify that 440 LR1 receives the packets that it sends. LR3 can set the Echo-Nonce 441 and the Nonce-Present bits in LISP data encapsulated packets and 442 include a random nonce in these packets. Upon reception of these 443 packets, LR1 will store the nonce sent by LR3 and echo it when it 444 returns LISP encapsulated data packets to LR3. 446 A spoofing off-path attacker (SA) could interfere with this 447 reachability test by sending two different types of packets: 449 1. LISP data encapsulated packets with the Nonce-Present bit set and 450 a random nonce and the appropriate source and destination RLOCs. 452 2. LISP data encapsulated packets with the Nonce-Present and the 453 Echo-Nonce bits both set and the appropriate source and 454 destination RLOCs. These packets will force the receiving ETR to 455 store the received nonce and echo it in the LISP encapsulated 456 packets that it sends. 458 The first type of packet should not cause any major problem to ITRs. 459 As the reachability test uses a 24 bits nonce, it is unlikely that an 460 off-path attacker could send a single packet that causes an ITR to 461 believe that the ETR it is testing is reachable while in reality it 462 is not reachable. To increase the success likelihood of such attach, 463 the attacker should created a massive amount of packets carrying all 464 possible nonce values. 466 The second type of packet could be exploited to attack the nonce- 467 based reachability test. Consider a spoofing off-path attacker (SA) 468 that sends a continuous flow of spoofed LISP data encapsulated 469 packets that contain the Nonce-Present and the Echo-Nonce bit and 470 each packet contains a different random nonce. The ETR that receives 471 such packets will continuously change the nonce that it returns to 472 the remote ITR. If the remote ITR starts a nonce-reachability test, 473 this test may fail because the ETR has received a spoofed LISP data 474 encapsulated packet with a different random nonce and never echoes 475 the real nonce. In this case the ITR will consider the ETR not 476 reachable. The success of this test depends on the ratio between the 477 amount of packets sent by the legitimate ITR and the spoofing off- 478 path attacker (SA). 480 5.3.2.4. Attacks using the Instance ID bits 482 LISP allows to carry in its header a 24-bits value called "Instance 483 ID" and used on the ITR to indicate which local Instance ID has been 484 used for encapsulation, while on the ETR can be used to select the 485 forwarding table used for forwarding the decapsulated packet. 487 The Instance ID increases exposure to attacks ([RFC6169]) as if an 488 off-path attacker can randomly guess a valid Instance ID value she 489 gets access to network that she might not have access. However, the 490 impact of such attack is directly on end-systems which is is out of 491 the scope of this document. 493 5.4. Attack using the control-plane 495 In this section, we discuss the different types of attacks that could 496 occur when an off-path attacker sends control-plane packets. We 497 focus on the packets that are sent directly to the ETR and do not 498 analyze the particularities of a LISP mapping system. 500 5.4.1. Attacks with Map-Request messages 502 An off-path attacker could send Map-Request packets to a victim ETR. 503 In theory, a Map-Request packet is only used to solicit an answer and 504 as such it should not lead to security problems. However, the LISP 505 specification [RFC6830] contains several particularities that could 506 be exploited by an off-path attacker. 508 The first possible exploitation is the P bit. The P bit is used to 509 probe the reachability of remote ETRs. In our reference environment, 510 LR3 could probe the reachability of LR1 by sending a Map-Request with 511 the P bit set. LR1 would reply by sending a Map-Reply message with 512 the P bit set and the same nonce as in the Map-Request message. 514 A spoofing off-path attacker (SA) could use the P bit to force a 515 victim ETR to send a Map-Reply to the spoofed source address of the 516 Map-Request message. As the Map-Reply can be larger than the Map- 517 Request message, there is a risk of amplification attack. 518 Considering only IPv6 addresses, a Map-Request can be as small as 40 519 bytes, considering one single ITR address and no Mapping Protocol 520 Data. The Map-Reply instead has a size of O(12 + (R * (28 + N * 521 24))) bytes, where N is the maximum number of RLOCs in a mapping and 522 R the maximum number of records in a Map-Reply. Since up to 255 523 RLOCs can be associated to an EID-Prefix and 255 records can be 524 stored in a Map-Reply, the maximum size of a Map-Reply is thus above 525 1 MB showing a size factor of up to 39,193 between the message sent 526 by the attacker and the message sent by the ETR. These numbers are 527 however theoretical values not considering transport layer 528 limitations and it is more likely that the reply will contain only 529 one record with at most a dozen of locators, giving an amplification 530 factor around 8. 532 Similarly, if a non-spoofing off-path attacker (NSA) sends a Map- 533 Request with the P bit set, it will receive a Map-Reply with the P 534 bit set. 536 An amplification attack could be launched by a spoofing off-path 537 attacker (SA) as follows. Consider an attacker SA and EID-Prefix 538 192.0.2.0/24 and a victim ITR, SA could send spoofed Map-Request 539 messages whose source EID addresses are all the addresses inside 540 192.0.2.0/24 and source RLOC address is the victim ITR. Upon 541 reception of these Map-Request messages, the ETR would send large 542 Map-Reply messages for each of the addresses inside p/P back to the 543 victim ITR. 545 The Map-Request message may also contain the SMR bit. Upon reception 546 of a Map-Request message with the SMR bit, an ETR must return to the 547 source of the Map-Request message a Map-Request message to retrieve 548 the corresponding mapping. This raises similar problems as the P bit 549 discussed above except that as the Map-Request messages are smaller 550 than Map-Reply messages, the risk of amplification attacks is 551 reduced. This is not true anymore if the ETR append to the Map- 552 Request messages its own Map-Records. This mechanism is meant to 553 reduce the delay in mapping distribution since mapping information is 554 provided in the Map-Request message. 556 Furthermore, appending Map-Records to Map-Request messages allows an 557 off-path attacker to generate a (spoofed or not) Map-Request message 558 and include in the Map-Reply portion of the message mapping for EID 559 prefixes that it does not serve. 561 Moreover, attackers can use Map Resolver and/or Map Server network 562 elements to perform relay attacks. Indeed, on the one hand, a Map 563 Resolver is used to dispatch Map-Request to the mapping system and, 564 on the other hand, a Map Server is used to dispatch Map-Requests 565 coming from the mapping system to ETRs that are authoritative for the 566 EID in the Map-Request. 568 5.4.2. Attacks with Map-Reply messages 570 In this section we analyze the attacks that could occur when an off- 571 path attacker sends directly Map-Reply messages to ETRs without using 572 one of the proposed LISP mapping systems. 574 There are two different types of Map-Reply messages: 576 Positive Map-Reply: These messages contain a Map-Record binding an 577 EID-Prefix to one or more RLOCs. 579 Negative Map-Reply: These messages contain a Map-Record for an EID- 580 Prefix with an empty locator-set and specifying an action, 581 which may be either Drop, natively forward, or Send Map- 582 Request. 584 Positive Map-Reply messages are used to map EID-Prefixes onto RLOCs. 585 Negative map-reply messages are used to indicate non-lisp prefixes. 586 ITRs can, if needed, be configured to send all traffic destined for 587 non-lisp prefixes to a Proxy-ETR. 589 Most of the security of the Map-Reply messages depends on the 64 bits 590 nonce that is included in a Map-Request and returned in the Map- 591 Reply. f an ETR does not accept Map-Reply messages with an invalid 592 nonce, the risk of attack is acceptable given the size of the nonce 593 (64 bits). However, the nonce only confirms that the map-reply 594 received was sent in response to a map-request sent, it does not 595 validate the contents of that map-reply. 597 In addition, an attacker could perform EID-to-RLOC Cache overflow 598 attack by de-aggregating (i.e., splitting an EID prefix into 599 artificially smaller EID prefixes) either positive or negative 600 mappings. 602 In presence of malicious ETRs, overclaiming attacks are possible. 603 Such an attack happens when and ETR replies to a legitimate Map- 604 Request message it received with a Map-Reply message that contains an 605 EID-Prefix that is larger than the prefix owned by the site that 606 encompasses the EID of the Map-Request. For instance if the prefix 607 owned by the site is 192.0.2.0/25 but the Map-Reply contains a 608 mapping for 192.0.2.0/24, then the mapping will influence packets 609 destined to other EIDs than the one the LISP site has authority on. 611 A malicious ETR might also fragment its EID-to-RLOC database so that 612 ITR's might have to install much more mappings than really necessary. 613 This attack is called de-aggregation attack. 615 5.4.3. Attacks with Map-Register messages 617 Map-Register messages are sent by ETRs to indicate to the mapping 618 system the EID prefixes associated to them. The Map-Register message 619 provides an EID prefix and the list of ETRs that are able to provide 620 Map-Replies for the EID covered by the EID prefix. 622 As Map-Register messages are protected by an authentication 623 mechanism, only a compromised ETR can register itself to its 624 allocated Map Server. 626 A compromised ETR can perform an overclaiming attack in order to 627 influence the route followed by Map-Requests for EIDs outside the 628 scope of its legitimate EID prefix. 630 A compromised ETR can also perform a deaggregation attack in order to 631 register more EID prefixes than necessary to its Map Servers. 633 5.4.4. Attacks with Map-Notify messages 635 Map-Notify messages are sent by a Map Server to an ETR to acknowledge 636 the good reception and processing of a Map-Register message. 638 A spoofing attacker compromised ETR can send a Map-Register with the 639 M-bit set and a spoofed source address to force the Map Server to 640 send a Map-Notify message to the spoofed address and then succeed a 641 relay attack. Similarly to the pair Map-Request/Map-Reply, the pair 642 Map-Register/Map-Notify is protected by a nonce making hard for an 643 attacker to inject a falsified notification to an ETR to make this 644 ETR believe that the registration succeeded while it has not. 646 6. Attack categories 648 6.1. Intrusion 650 6.1.1. Description 652 With an intrusion attack an attacker gains remote access to some 653 resources (e.g., a host, a router, or a network) that are normally 654 denied to her. 656 6.1.2. Vectors 658 Intrusion attacks can be mounted using: 660 o Spoofing EID or RLOCs 662 o Instance ID bits 664 6.2. Denial of Service (DoS) 666 6.2.1. Description 668 A Denial of Service (DoS) attack aims at disrupting a specific 669 targeted service either by exhausting the resources of the victim up 670 to the point that it is not able to provide a reliable service to 671 legit traffic and/or systems or by exploiting vulnerabilities to make 672 the targeted service unable to operate properly. 674 6.2.2. Vectors 676 Denial of Service attacks can be mounted using 678 o Gleaning 680 o Interworking 682 o Locator Status Bits 684 o Map-Version bit 686 o Nonce-Present and Echo-Nonce bits 688 o Map-Request message 690 o Map-Reply message 692 o Map-Register message 694 o Map-Notify message 696 6.3. Eavesdropping 698 6.3.1. Description 700 With an eavesdropping attack, the attacker collects traffic of a 701 target through deep packet inspection in order to gain access to 702 restricted or sensitive information such as passwords, session 703 tokens, or any other confidential information. This type of attack 704 is usually carried out in a way such that the target does not even 705 notice the attack. When the attacker is positioned on the path of 706 the target traffic, it is called a Man-in-the-Middle attack. 707 However, this is not a requirement to carry out and eavesdropping 708 attack. Indeed the attacker might be able, for instance through an 709 intrusion attack on a weaker system, either to duplicate or even re- 710 direct the traffic, in both cases having access to the raw packets. 712 6.3.2. Vectors 714 Eavesdropping attacks can be mounted using 716 o Gleaning 718 o Locator Status Bits 720 o Nonce-Present and the Echo-Nonce bits 722 o Map-Request messages 724 o Map-Reply messages 726 7. Recommendations 728 TBD 730 8. IANA Considerations 732 This document makes no request to IANA. 734 9. Security Considerations 736 Security considerations are the core of this document and do not need 737 to be further discussed in this section. 739 10. Acknowledgments 741 This document builds upon the draft of Marcelo Bagnulo 742 ([I-D.bagnulo-lisp-threat]), where the flooding attack and the 743 reference environment were first described. 745 The authors would like to thank Florin Coras, Vina Ermagan, Darrel 746 Lewis, and Jeff Wheeler for their comments. 748 This work has been partially supported by the INFSO-ICT-216372 749 TRILOGY Project (www.trilogy-project.org). 751 11. References 753 11.1. Normative References 755 [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security 756 Concerns with IP Tunneling", RFC 6169, April 2011. 758 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 759 Locator/ID Separation Protocol (LISP)", RFC 6830, January 760 2013. 762 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 763 "Interworking between Locator/ID Separation Protocol 764 (LISP) and Non-LISP Sites", RFC 6832, January 2013. 766 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 767 Protocol (LISP) Map-Server Interface", RFC 6833, January 768 2013. 770 [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID 771 Separation Protocol (LISP) Map-Versioning", RFC 6834, 772 January 2013. 774 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 775 "Locator/ID Separation Protocol Alternative Logical 776 Topology (LISP+ALT)", RFC 6836, January 2013. 778 [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to 779 Routing Locator (RLOC) Database", RFC 6837, January 2013. 781 11.2. Informative References 783 [Chu] Jerry Chu, H., "Tuning TCP Parameters for the 21st Century 784 ", 75th IETF, Stockholm, July 2009, 785 . 787 [I-D.bagnulo-lisp-threat] 788 Bagnulo, M., "Preliminary LISP Threat Analysis", draft- 789 bagnulo-lisp-threat-01 (work in progress), July 2007. 791 [I-D.ietf-lisp-ddt] 792 Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP 793 Delegated Database Tree", draft-ietf-lisp-ddt-01 (work in 794 progress), March 2013. 796 [I-D.ietf-lisp-sec] 797 Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D., 798 and O. Bonaventure, "LISP-Security (LISP-SEC)", draft- 799 ietf-lisp-sec-04 (work in progress), October 2012. 801 [I-D.ietf-tcpm-tcp-security] 802 Gont, F., "Survey of Security Hardening Methods for 803 Transmission Control Protocol (TCP) Implementations", 804 draft-ietf-tcpm-tcp-security-03 (work in progress), March 805 2012. 807 [I-D.meyer-lisp-cons] 808 Brim, S., "LISP-CONS: A Content distribution Overlay 809 Network Service for LISP", draft-meyer-lisp-cons-04 (work 810 in progress), April 2008. 812 [I-D.saucez-lisp-mapping-security] 813 Saucez, D. and O. Bonaventure, "Securing LISP Mapping 814 replies", draft-saucez-lisp-mapping-security-00 (work in 815 progress), February 2011. 817 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 818 Networks", BCP 84, RFC 3704, March 2004. 820 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 821 Internet Protocol", RFC 4301, December 2005. 823 [RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing 824 Security: An Unauthenticated Mode of IPsec", RFC 5386, 825 November 2008. 827 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 828 Secure Internet Routing", RFC 6480, February 2012. 830 [SAVI] IETF, "Source Address Validation Improvements Working 831 Group ", 2013, . 833 [Saucez09] 834 Saucez, D. and L. Iannone, "How to mitigate the effect of 835 scans on mapping systems ", Submitted to the Trilogy 836 Summer School on Future Internet, 2009. 838 Appendix A. Document Change Log 840 o Version 06 Posted October 2013. 842 * Complete restructuration, temporary version to be used at 843 October 2013 interim meeting. 845 o Version 05 Posted August 2013. 847 * Removal of severity levels to become a short recommendation to 848 reduce the risk of the discussed threat. 850 o Version 04 Posted February 2013. 852 * Clear statement that the document compares threats of public 853 LISP deployments with threats in the current Internet 854 architecture. 856 * Addition of a severity level discussion at the end of each 857 section. 859 * Addressed comments from V. Ermagan and D. Lewis' reviews. 861 * Updated References. 863 * Further editorial polishing. 865 o Version 03 Posted October 2012. 867 * Dropped Reference to RFC 2119 notation because it is not 868 actually used in the document. 870 * Deleted future plans section. 872 * Updated References 874 * Deleted/Modified sentences referring to the early status of the 875 LISP WG and documents at the time of writing early versions of 876 the document. 878 * Further editorial polishing. 880 * Fixed all ID nits. 882 o Version 02 Posted September 2012. 884 * Added a new attack that combines overclaiming and de- 885 aggregation (see Section 5.4.2). 887 * Editorial polishing. 889 o Version 01 Posted February 2012. 891 * Added discussion on LISP-DDT. 893 o Version 00 Posted July 2011. 895 * Added discussion on LISP-MS>. 897 * Added discussion on Instance ID in Section 5.3.2. 899 * Editorial polishing of the whole document. 901 * Added "Change Log" appendix to keep track of main changes. 903 * Renamed "draft-saucez-lisp-security-03.txt. 905 Authors' Addresses 907 Damien Saucez 908 INRIA 909 2004 route des Lucioles BP 93 910 06902 Sophia Antipolis Cedex 911 France 913 Email: damien.saucez@inria.fr 915 Luigi Iannone 916 Telecom ParisTech 917 23, Avenue d'Italie, CS 51327 918 75214 PARIS Cedex 13 919 France 921 Email: luigi.iannone@telecom-paristech.fr 923 Olivier Bonaventure 924 Universite catholique de Louvain 925 Place St. Barbe 2 926 Louvain la Neuve 927 Belgium 929 Email: olivier.bonaventure@uclouvain.be