idnits 2.17.1 draft-ietf-lisp-threats-02.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 : ---------------------------------------------------------------------------- == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 12, 2012) is 4244 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-24) exists of draft-ietf-lisp-23 == Outdated reference: A later version (-04) exists of draft-fuller-lisp-ddt-00 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). 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: March 16, 2013 Telecom ParisTech 6 O. Bonaventure 7 Universite catholique de Louvain 8 September 12, 2012 10 LISP Threats Analysis 11 draft-ietf-lisp-threats-02.txt 13 Abstract 15 This document analyzes the threats against the security of the 16 Locator/Identifier Separation Protocol and proposes a set of 17 recommendations to mitigate some of the identified security risks. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on March 16, 2013. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 54 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 56 4. On-path Attackers . . . . . . . . . . . . . . . . . . . . . . 4 57 5. Off-Path Attackers: Reference Environment . . . . . . . . . . 4 58 6. Data-Plane Threats . . . . . . . . . . . . . . . . . . . . . . 6 59 6.1. EID-to-RLOC Database Threats . . . . . . . . . . . . . . . 6 60 6.2. EID-to-RLOC Cache Threats . . . . . . . . . . . . . . . . 7 61 6.2.1. EID-to-RLOC Cache poisoning . . . . . . . . . . . . . 7 62 6.2.2. EID-to-RLOC Cache overflow . . . . . . . . . . . . . . 9 63 6.3. Attacks not leveraging on the LISP header . . . . . . . . 9 64 6.4. Attacks leveraging on the LISP header . . . . . . . . . . 10 65 6.4.1. Attacks using the Locator Status Bits . . . . . . . . 10 66 6.4.2. Attacks using the Map-Version bit . . . . . . . . . . 11 67 6.4.3. Attacks using the Nonce-Present and the Echo-Nonce 68 bits . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 6.4.4. Attacks using the ID Instance bits . . . . . . . . . . 13 70 7. Control Plane Threats . . . . . . . . . . . . . . . . . . . . 13 71 7.1. Attacks with Map-Request messages . . . . . . . . . . . . 13 72 7.2. Attacks with Map-Reply messages . . . . . . . . . . . . . 15 73 7.3. Gleaning Attacks . . . . . . . . . . . . . . . . . . . . . 16 74 8. Threats concerning Interworking . . . . . . . . . . . . . . . 17 75 9. Threats with Malicious xTRs . . . . . . . . . . . . . . . . . 18 76 10. Security of the Proposed Mapping Systems . . . . . . . . . . . 20 77 10.1. LISP+ALT . . . . . . . . . . . . . . . . . . . . . . . . . 21 78 10.2. LISP-DDT . . . . . . . . . . . . . . . . . . . . . . . . . 22 79 11. Threats concerning LISP-MS . . . . . . . . . . . . . . . . . . 22 80 11.1. Map Server . . . . . . . . . . . . . . . . . . . . . . . . 23 81 11.2. Map-Resolver . . . . . . . . . . . . . . . . . . . . . . . 24 82 12. Suggested Recommendations . . . . . . . . . . . . . . . . . . 25 83 13. Document Status and Plans . . . . . . . . . . . . . . . . . . 27 84 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 85 15. Security Considerations . . . . . . . . . . . . . . . . . . . 28 86 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 87 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 88 17.1. Normative References . . . . . . . . . . . . . . . . . . . 28 89 17.2. Informative References . . . . . . . . . . . . . . . . . . 29 90 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 30 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 93 1. Requirements notation 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 2. Introduction 101 The Locator/ID Separation Protocol (LISP) is defined in 102 [I-D.ietf-lisp]. The present document aims at identifying threats in 103 the current LISP specification. We also propose some recommendations 104 on mechanisms that could improve the security of LISP against off- 105 path attackers. This document builds upon [I-D.bagnulo-lisp-threat]. 107 This document is split in two parts. The first discusses the LISP 108 data-plane and the second the LISP control-plane. 110 The LISP data-plane consists of LISP packet encapsulation, 111 decapsulation, and forwarding and includes the EID-to-RLOC Cache and 112 EID-to-RLOC Database data structures used to perform these 113 operations. 115 The LISP control-plane consists in the mapping distribution system, 116 which can be one of the mapping distribution systems proposed so far 117 (e.g., [I-D.ietf-lisp], [I-D.ietf-lisp-alt], [I-D.ietf-lisp-ms], 118 [I-D.meyer-lisp-cons], and [I-D.lear-lisp-nerd]), and the Map- 119 Request, Map-Reply, Map-Register messages. 121 This document does not consider all the possible uses of LISP as 122 discussed in [I-D.ietf-lisp]. The document focuses on LISP unicast, 123 including as well LISP Interworking [I-D.ietf-lisp-interworking], 124 LISP-MS [I-D.ietf-lisp-ms], and briefly considers the ALT mapping 125 system described in [I-D.ietf-lisp-alt]. 127 Furthermore, here we assume a generic IP service and do not discuss 128 the difference from a security viewpoint between using IPv4 or IPv6. 130 3. Definition of Terms 132 The present document does not introduce any new term, compared to the 133 main LISP specification. For a complete list of terms please refer 134 to [I-D.ietf-lisp]. 136 4. On-path Attackers 138 On-path attackers are attackers that are able to capture and modify 139 all the packets exchanged between an ITR and an ETR. To cope with 140 such an attacker, cryptographic techniques such as those used by 141 IPSec are required. We do not consider that LISP has to cope with 142 such attackers. 144 Mobile IP has also considered time-shifted attacks from on-path 145 attackers. A time-shifted attack is an attack where the attacker is 146 temporarily on the path between two communicating hosts. While it is 147 on-path, the attacker sends specially crafted packets or modifies 148 packets exchanged by the communicating hosts in order to disturb the 149 packet flow (e.g., by performing a man in the middle attack). An 150 important issue for time-shifted attacks is the duration of the 151 attack once the attacker has left the path between the two 152 communicating hosts. We do not consider time-shifted attacks in this 153 document. 155 5. Off-Path Attackers: Reference Environment 157 Throughout this document we consider the reference environment shown 158 in the figure below. There are two hosts attached to LISP routers: 159 HA and HB. HA is attached to the two LISP xTRs LR1 and LR2, which 160 are attached to two different ISPs. HB is attached to the two LISP 161 xTRs LR3 and LR4. HA and HB are the EIDs of the two hosts. LR1, 162 LR2, LR3, and LR4 are the RLOCs of the xTRs. 164 +-----+ 165 | HA | 166 +-----+ 167 | EID: HA 168 | 169 ----------------- 170 | | 171 +-----+ +-----+ 172 | LR1 | | LR2 | 173 +-----+ +-----+ 174 | | 175 | | 176 +-----+ +-----+ 177 |ISP1 | |ISP2 | 178 +-----+ +-----+ 179 | | 180 +----------------+ +-----+ 181 | |-----| SA | 182 | | +-----+ 183 | Internet | 184 | | +-----+ 185 | |-----| NSA | 186 +----------------+ +-----+ 187 | | 188 +-----+ +-----+ 189 | LR3 | | LR4 | 190 +-----+ +-----+ 191 | | 192 ------------------- 193 | 194 | EID: HB 195 +-----+ 196 | HB | 197 +-----+ 199 Figure 1: Reference Network 201 We consider two off-path attackers with different capabilities: 203 SA is an off-path attacker that is able to send spoofed packets, 204 i.e., packets with a different source IP address than its 205 assigned IP address. SA stands for Spoofing Attacker. 207 NSA is an off-path attacker that is only able to send packets whose 208 source address is its assigned IP address. NSA stands for Non 209 Spoofing Attacker. 211 It should be noted that with LISP, packet spoofing is slightly 212 different than in the current Internet. Generally the term "spoofed 213 packet" indicates a packet containing a source IP address which is 214 not the one of the actual originator of the packet. Since LISP uses 215 encapsulation, the spoofed address can be in the outer header as well 216 as in the inner header, this translates in two types of spoofing: 218 EID Spoofing: the originator of the packet puts in it a spoofed EID. 219 The packet will be normally encapsulated by the ITR of the 220 site. 222 RLOC Spoofing: the originator of the packet generates directly a 223 LISP-encapsulated packet with a spoofed source RLOC. 225 Note that the two types of spoofing are not mutually exclusive, 226 rather all combinations are possible and can be used to perform 227 different kind of attacks. 229 In our reference environment, both SA and NSA attackers are capable 230 of sending LISP encapsulated data packets and LISP control packets. 231 This means that SA is able to perform both RLOC and EID spoofing 232 while NSA can only perform EID spoofing. They may also send other 233 types of IP packets such as ICMP messages. We assume that both 234 attackers can query the LISP mapping system to obtain the mappings 235 for both HA and HB. 237 6. Data-Plane Threats 239 This section discusses threats and attacks related to the LISP data- 240 plane. More precisely, we discuss the operations of encapsulation, 241 decapsulation, and forwarding as well as the content of the EID-to- 242 RLOC Cache and EID-to-RLOC Database as specified in the original LISP 243 document ([I-D.ietf-lisp]). 245 We start considering the two main data structures of LISP, namely the 246 EID-to-RLOC Database and the EID-to-RLOC Cache. Then, we look at the 247 data plane attacks that can be performed by a spoofing off-path 248 attacker (SA) and discuss how they can be mitigated by the LISP xTRs. 249 In this analysis, we assume that the LR1 and LR2 (resp. LR3 and LR4) 250 xTRs maintain a EID-to-RLOC Cache that contains the required mapping 251 entries to allow HA and HB to exchange packets. 253 6.1. EID-to-RLOC Database Threats 255 The EID-to-RLOC Database on each xTR maintains the set of mappings 256 related to the EID-Prefixes that are "behind" the xTR. Where 257 "behind" means that at least one of the xTR's globally-visible IP 258 addresses is a RLOC for those EID-Prefixes. 260 As described in [I-D.ietf-lisp], the EID-to-RLOC Database content is 261 determined by configuration. This means that the only way to attack 262 this data structure is by gaining privileged access to the xTR. As 263 such, it is out of the scope of LISP to propose any mechanism to 264 protect routers and, hence, it is no further analyzed in this 265 document. 267 6.2. EID-to-RLOC Cache Threats 269 A key component of the overall LISP architecture is the EID-to-RLOC 270 Cache. The EID-to-RLOC Cache is the data structure that stores the 271 bindings between EID and RLOC (namely the "mappings") to be used 272 later on. Attacks against this data structure can happen either when 273 the mappings are first installed in the cache (see also Section 7) or 274 by corrupting (poisoning) the mappings already present in the cache. 276 6.2.1. EID-to-RLOC Cache poisoning 278 The content of the EID-to-RLOC Cache can be poisoned by spoofing LISP 279 encapsulated packets. Example of EID-to-RLOC Cache poisoning are: 281 Fake mapping: The cache contains entirely fake mappings that do not 282 originate from an authoritative mapping server. This can be 283 achieved either through gleaning as described in Section 7.3 or 284 by attacking the control-plane as described in Section 7. 286 EID Poisoning: The EID-Prefix in a specific mapping is not owned by 287 the originator of the entry. Similarly to the previous case, 288 this can be achieved either through gleaning as described in 289 Section 7.3 or by attacking the control-plane as described in 290 Section 7. 292 EID redirection/RLOC poisoning: The EID-Prefix in the mapping is not 293 bound to (located by) the set of RLOCs present in the mapping. 294 This can result in packets being redirected elsewhere, 295 eavesdropped, or even blackholed. Note that not necessarily 296 all RLOCs are fake/spoofed. The attack works also if only part 297 of the RLOCs, the highest priority ones, is compromised. 298 Again, this can be achieved either through the gleaning as 299 described in Section 7.3 or by attacking the control-plane as 300 described in Section 7. 302 Reachability poisoning: The reachability information stored in the 303 mapping could be poisoned, redirecting the packets to a subset 304 of the RLOCs (or even stopping it if locator status bits are 305 all set to 0). If reachability information is not verified 306 through the control-plane this attack can be simply achieved by 307 sending a spoofed packet with swapped or all locator status 308 bits reset. The same result can be obtained by attacking the 309 control-plane as described in Section 7. Depending on how the 310 RLOC reachability information is stored on the router, the 311 attack can impact only one mapping or all the mappings that 312 share the same RLOC. 314 Traffic Engineering information poisoning: The LISP protocol defines 315 two attributes associated to each RLOC in order to perform 316 inbound Traffic Engineering (TE): namely priority and weight. 317 By injecting fake TE attributes, the attacker is able to break 318 load balancing policies and concentrate all the traffic on a 319 single RLOC or put more load on a RLOC than what is expected, 320 creating congestion. It is even possible to block the traffic 321 if all the priorities are set to 255. Corrupting the TE 322 attributes can be achieved by attacking the control-plane as 323 described in Section 7. 325 Mapping TTL poisoning: The LISP protocol associates a Time-To-Live 326 to each mapping that, once expired, allows to delete a mapping 327 from the EID-to-RLOC Cache (or forces a Map-Request/Map-Reply 328 exchange to refresh it if still needed). By injecting fake TTL 329 values, an attacker can either shrink the EID-to-RLOC Cache 330 (using very short TTL), thus creating an excess of cache miss 331 causing a DoS on the mapping system, or it can increase the 332 size of the cache by putting very high TTL values, up to a 333 cache overflow (see Section 6.2.2). Corrupting the TTL can be 334 achieved by attacking the control-plane as described in 335 Section 7. Long TTL can be use in fake mappings to increase an 336 attack duration. 338 Instance ID poisoning: The LISP protocol allows to use a 24-bit 339 identifier to select the forwarding table to use on the 340 decapsulating ETR to forward the decapsulated packet. By 341 spoofing this attribute the attacker is able to redirect or 342 blackhole inbound traffic. Corrupting the Instance ID 343 attribute can be achieved by attacking the control-plane as 344 described in Section 7. 346 Map-Version poisoning: The LISP protocol allows to associate a 347 version number to mappings ([I-D.ietf-lisp-map-versioning]). 348 The LISP header can transport source and destination map- 349 versions, describing which version of the mapping have been 350 used to select the source and the destination RLOCs of the LISP 351 encapsulated packet. By spoofing this attribute the attacker 352 is able to trigger Map-Request on the receiving ETR. 353 Corrupting the Map-Version attribute can be achieved either by 354 attacking the control-plane as described in Section 7 or by 355 using spoofed packets as described in Section 6.4.2. 357 If the above listed attacks succeed, the attacker has the means of 358 controlling the traffic. 360 6.2.2. EID-to-RLOC Cache overflow 362 Depending on how the EID-to-RLOC Cache is managed (e.g., LRU vs. LFU) 363 and depending on its size, an attacker can try to fill the cache with 364 fake mappings. Once the cache is full, some mappings will be 365 replaced by new fake ones, causing traffic disruption. 367 This can be achieved either through the gleaning as described in 368 Section 7.3 or by attacking the control-plane as described in 369 Section 7. 371 Another way to generate a EID-to-RLOC Cache overflow is by injecting 372 mapping with a fake and very large TTL value. In this case the cache 373 will keep a large amount of mappings ending with a completely full 374 cache. This type of attack can also be performed through the 375 control-plane. 377 6.3. Attacks not leveraging on the LISP header 379 We first consider an attacker that sends packets without exploiting 380 the LISP header, i.e., with the N, L, E, V, and I bits reset 381 ([I-D.ietf-lisp]). 383 To inject a packet in the HA-HB flow, a spoofing off-path attacker 384 (SA) can send a LISP encapsulated packet whose source is set to LR1 385 or LR2 and destination LR3 or LR4. The packet will reach HB as if 386 the packet was sent by host HA. This is not different from today's 387 Internet where a spoofing off-path attacker may inject data packets 388 in any flow. Several existing techniques can be used by hosts to 389 prevent such attacks from affecting established flows, e.g., 390 [RFC4301] and [I-D.ietf-tcpm-tcp-security]. 392 On the other hand, a non-spoofing off-path attacker (NSA) can only 393 send a packet whose source address is set to its assigned IP address. 394 The destination address of the encapsulated packet can be LR3 or LR4. 395 When the LISP ETR that serves HB receives the encapsulated packet, it 396 can consult its EID-to-RLOC Cache and verify that NSA is not a valid 397 source address for LISP encapsulated packets containing a packet sent 398 by HA. This verification is only possible if the ETR already has a 399 valid mapping for HA. Otherwise, and to avoid such data packet 400 injection attacks, the LISP ETR should reject the packet and possibly 401 query the mapping system to obtain a mapping for the encapsulated 402 source EID (HA). 404 6.4. Attacks leveraging on the LISP header 406 The latest LISP draft [I-D.ietf-lisp] defines several flags that 407 modify the interpretation of the LISP header in data packets. In 408 this section, we discuss how an off-path attacker could exploit this 409 LISP header. 411 6.4.1. Attacks using the Locator Status Bits 413 When the L bit is set to 1, it indicates that the second 32-bits 414 longword of the LISP header contains the Locator Status Bits. In 415 this field, each bit position reflects the status of one of the RLOCs 416 mapped to the source EID found in the encapsulated packet. In 417 particular, a packet with the L bit set and all Locator Status Bits 418 set to zero indicates that none of the locators of the encapsulated 419 source EID are reachable. The reaction of a LISP ETR that receives 420 such a packet is not clearly described in [I-D.ietf-lisp]. 422 A spoofing off-path attacker (SA) can send a data packet with the L 423 bit set to 1, all Locator Status Bits set to zero, a spoofed source 424 RLOC (e.g. LR1), destination LR3, and containing an encapsulated 425 packet whose source is HA. If LR3 blindly trust the Locator Status 426 Bits of the received packet it will set LR1 and LR2 as unreachable, 427 possibly disrupting ongoing communication. 429 Locator Status Bits can be blindly trusted only in secure 430 environments. In the general unsecured Internet environment, the 431 safest practice for xTRs is to confirm the reachability change 432 through the control plane (e.g., RLOC probing). In the above 433 example, LR3 should note that something has changed in the Locator 434 Status Bits and query the mapping system in order to confirm status 435 of the RLOCs of the source EID. 437 A similar attack could occur by setting only one Locator Status Bit 438 to 1, e.g., the one that corresponds to the source RLOC of the 439 packet. 441 If a non-spoofing off-path attacker (NSA) sends a data packet with 442 the L bit set to 1 and all Locator Status Bits set to zero, this 443 packet will contain the source address of the attacker. Similarly as 444 in Section 6.3, if the xTR accepts the packet without checking the 445 EID-to-RLOC Cache for a mapping that binds the source EID and the 446 source RLOC of the received packet, then the same observation like 447 for the the spoofing attacker (SA) apply. 449 Otherwise, if the xTR does make the check through the EID-to-RLOC 450 Cache, it should reject the packet because its source address is not 451 one of the addresses listed as RLOCs for the source EID. 453 Nevertheless, in this case a Map-Request should be sent, which can be 454 used to perform Denial of Service attacks. Indeed an attacker can 455 frequently change the Locator Status Bits in order to trigger a large 456 amount of Map-Requests. Rate limitation, as described in 457 [I-D.ietf-lisp], does not allow to send high number of such a 458 request, resulting in the attacker saturating the rate with these 459 spoofed packets. 461 6.4.2. Attacks using the Map-Version bit 463 The Map-Version bit is used to indicate whether the low-order 24 bits 464 of the first 32 bits word of the LISP header contain an Source and 465 Destination Map-Version. When a LISP ETR receives a LISP 466 encapsulated packet with the Map-Version bit set to 1, the following 467 actions are taken: 469 o It compares the Destination Map-Version found in the header with 470 the current version of its own mapping, in the EID-to-RLOC 471 Database, for the destination EID found in the encapsulated 472 packet. If the received Destination Map-Version is smaller (i.e., 473 older) than the current version, the ETR should apply the SMR 474 procedure described in [I-D.ietf-lisp] and send a Map-Request with 475 the SMR bit set. 477 o If a mapping exists in the EID-to-RLOC Cache for the source EID, 478 then it compares the Map-Version of that entry with the Source 479 Map-Version found in the header of the packet. If the stored 480 mapping is older (i.e., the Map-Version is smaller) than the 481 source version of the LISP encapsulated packet, the xTR should 482 send a Map-Request for the source EID. 484 A spoofing off-path attacker (SA) could use the Map-Version bit to 485 force an ETR to send Map-Request messages. The attacker can retrieve 486 the current source and destination Map-Version for both HA and HB. 487 Based on this information, it can send a spoofed packet with an older 488 Source Map-Version or Destination Map-Version. If the size of the 489 Map-Request message is larger than the size of the smallest LISP- 490 encapsulated packet that could trigger such a message, this could 491 lead to amplification attacks (see Section 7.1). Fortunately, 492 [I-D.ietf-lisp] recommends to rate limit the Map-Request messages 493 that are sent by an xTR. This prevents the amplification attack, but 494 there is a risk of Denial of Service attack if an attacker sends 495 packets with Source and Destination Map-Versions that frequently 496 change. In this case, the ETR could consume all its rate by sending 497 Map-Request messages in response to these spoofed packets. 499 A non-spoofing off-path attacker (NSA) cannot success in such an 500 attack if the destination xTR rejects the LISP encapsulated packets 501 that are not sent by one of the RLOCs mapped to the included source 502 EID. If it is not the case, the attacker can be able to perform 503 attacks concerning the Destination Map Version number as for the 504 spoofing off-path attacker (SA). 506 6.4.3. Attacks using the Nonce-Present and the Echo-Nonce bits 508 The Nonce-Present and Echo-Nonce bits are used when verifying the 509 reachability of a remote ETR. Assume that LR3 wants to verify that 510 LR1 receives the packets that it sends. LR3 can set the Echo-Nonce 511 and the Nonce-Present bits in LISP data encapsulated packets and 512 include a random nonce in these packets. Upon reception of these 513 packets, LR1 will store the nonce sent by LR3 and echo it when it 514 returns LISP encapsulated data packets to LR3. 516 A spoofing off-path attacker (SA) could interfere with this 517 reachability test by sending two different types of packets: 519 1. LISP data encapsulated packets with the Nonce-Present bit set and 520 a random nonce and the appropriate source and destination RLOCs. 522 2. LISP data encapsulated packets with the Nonce-Present and the 523 Echo-Nonce bits both set and the appropriate source and 524 destination RLOCs. These packets will force the receiving ETR to 525 store the received nonce and echo it in the LISP encapsulated 526 packets that it sends. 528 The first type of packet should not cause any major problem to ITRs. 529 As the reachability test uses a 24 bits nonce, it is unlikely that an 530 off-path attacker could send a single packet that causes an ITR to 531 believe that the ETR it is testing is reachable while in reality it 532 is not reachable. To increase the success likelihood of such attach, 533 the attacker should created a massive amount of packets carrying all 534 possible nonce values. However, "flood attack" can be easily 535 detected and blocked. 537 The second type of packet could be exploited to create a Denial of 538 Service attack against the nonce-based reachability test. Consider a 539 spoofing off-path attacker (SA) that sends a continuous flow of 540 spoofed LISP data encapsulated packets that contain the Nonce-Present 541 and the Echo-Nonce bit and each packet contains a different random 542 nonce. The ETR that receives such packets will continuously change 543 the nonce that it returns to the remote ITR. If the remote ITR 544 starts a nonce-reachability test, this test may fail because the ETR 545 has received a spoofed LISP data encapsulated packet with a different 546 random nonce and never echoes the real nonce. In this case the ITR 547 will consider the ETR not reachable. The success of this test will 548 of course depend on the ratio between the amount of packets sent by 549 the legitimate ITR and the spoofing off-path attacker (SA). 551 Packets sent by a non-spoofing off-path attacker (NSA) can cause 552 similar problem if no check is done with the EID-to-RLOC Cache (see 553 Section 6.3 for the EID-to-RLOC Cache check). Otherwise, if the 554 check is performed the packets will be rejected by the ETR that 555 receives them and cannot cause problems. 557 6.4.4. Attacks using the ID Instance bits 559 LISP allows to carry in its header a 24-bits value called "Instance 560 ID" and used on the ITR to indicate which private Instance ID has 561 been used for encapsulation, while on the ETR can be used to select 562 the forwarding table used for forwarding the decapsulated packet. 564 Even if an off-path attacker could randomly guess a valid Instance ID 565 value, there is no LISP specific problem. Obviously the attacker 566 could be now able to reach hosts that are only reachable through the 567 routing table identified by the attacked Instance ID, however, end- 568 system security is out of the scope of this document. Nevertheless, 569 access lists can be configured to protect the network from Instance 570 ID based attacks. 572 7. Control Plane Threats 574 In this section, we discuss the different types of attacks that can 575 occur when an off-path attacker sends control plane packets. We 576 focus on the packets that are sent directly to the ETR and do not 577 analyze the particularities of a LISP mapping system. The LISP+ALT 578 and LISP-DDT mapping systems are discussed in Section 10. 580 7.1. Attacks with Map-Request messages 582 An off-path attacker could send Map-Request packets to a victim ETR. 583 In theory, a Map-Request packet is only used to solicit an answer and 584 as such it should not lead to security problems. However, the LISP 585 specification [I-D.ietf-lisp] contains several particularities that 586 could be exploited by an off-path attacker. 588 The first possible exploitation is the P bit. The P bit is used to 589 probe the reachability of remote ETRs in the control plane. In our 590 reference environment, LR3 could probe the reachability of LR1 by 591 sending a Map-Request with the P bit set. LR1 would reply by sending 592 a Map-Reply message with the P bit set and the same nonce as in the 593 Map-Request message. 595 A spoofing off-path attacker (SA) could use the P bit to force a 596 victim ETR to send a Map-Reply to the spoofed source address of the 597 Map-Request message. As the Map-Reply can be larger than the Map- 598 Request message, there is a risk of amplification attack. 599 Considering only IPv6 addresses, a Map-Request can be as small as 40 600 bytes, considering one single ITR address and no Mapping Protocol 601 Data. The Map-Reply instead has a size of O(12 + (R * (28 + N * 602 24))) bytes, where N is the maximum number of RLOCs in a mapping and 603 R the maximum number of records in a Map-Reply. Since up to 255 604 RLOCs can be associated to an EID-Prefix and 255 records can be 605 stored in a Map-Reply, the maximum size of a Map-Reply is thus above 606 1 MB showing a size factor of up to 39,193 between the message sent 607 by the attacker and the message sent by the ETR. These numbers are 608 however theoretical values not considering transport layer 609 limitations and it is more likely that the reply will contain only 610 one record with at most a dozen of locators, giving an amplification 611 factor around 8. 613 Any ISP with a large number of potential RLOCs for a given EID-Prefix 614 should carefully ponder the best trade-off between the number of 615 RLOCs through which it wants that the EID is reachable and the 616 consequences that an amplification attack can produce. 618 It should be noted that the maximum rate of Map-Reply messages should 619 apply to all Map-Replies and also be associated to each destination 620 that receives Map-Reply messages. Otherwise, a possible 621 amplification attack could be launched by a spoofing off-path 622 attacker (SA) as follows. Consider an attacker SA and and EID-Prefix 623 p/P and a victim ITR. To amplify a Denial of Service attack against 624 the victim ITR, SA could send spoofed Map-Request messages whose 625 source EID addresses are all the addresses inside p/P and source RLOC 626 address is the victim ITR. Upon reception of these Map-Request 627 messages, the ETR would send large Map-Reply messages for each of the 628 addresses inside p/P back to the victim ITR. 630 If a non-spoofing off-path attacker (NSA) sends a Map-Request with 631 the P bit set, it will receive a Map-Reply with the P bit set. This 632 does not raise security issues besides the usual risk of overloading 633 a victim ETR by sending too many Map-Request messages. 635 The Map-Request message may also contain the SMR bit. Upon reception 636 of a Map-Request message with the SMR bit, an ETR must return to the 637 source of the Map-Request message a Map-Request message to retrieve 638 the corresponding mapping. This raises similar problems as the P bit 639 discussed above except that as the Map-Request messages are smaller 640 than Map-Reply messages, the risk of amplification attacks is 641 reduced. This is not true anymore if the ETR append to the Map- 642 Request messages its own Map-Records. This mechanism is meant to 643 reduce the delay in mapping distribution since mapping information is 644 provided in the Map-Request message. 646 Furthermore, appending Map-Records to Map-Request messages represents 647 a major security risk since an off-path attacker could generate a 648 (spoofed or not) Map-Request message and include in the Map-Reply 649 portion of the message mapping for EID prefixes that it does not 650 serve. This could lead to various types of redirection and denial of 651 service attacks. An xTR should not process the Map-Records 652 information that it receives in a Map-Request message. 654 7.2. Attacks with Map-Reply messages 656 In this section we analyze the attacks that could occur when an off- 657 path attacker sends directly Map-Reply messages to ETRs without using 658 one of the proposed LISP mapping systems. 660 There are two different types of Map-Reply messages: 662 Positive Map-Reply: This messages contain a Map-Record binding an 663 EID-Prefix to one or more RLOCs. 665 Negative Map-Reply: This messages contain a Map-Record for an EID- 666 Prefix with an empty locator-set and specifying an action, 667 which may be either Drop, Natively forward, or Send Map- 668 Request. 670 Positive Map-Reply messages are used to map EID-Prefixes onto RLOCs. 671 Negative Map-Reply messages are used to support PTR and interconnect 672 the LISP Internet with the legacy Internet. 674 Most of the security of the Map-Reply messages depend on the 64 bits 675 nonce that is included in a Map-Request and returned in the Map- 676 Reply. An ETR must never accept a Map-Reply message whose nonce does 677 not match one of the pending Map-Request messages. If an ETR does 678 not accept Map-Reply messages with an invalid nonce, the risk of 679 attack is acceptable given the size of the nonce (64 bits). 681 Note, however, that the nonce only confirms that the Map-Reply was 682 sent by the ETR that received the Map-Request. It does not validate 683 the content of the Map-Reply message. 685 In addition, an attacker can perform EID-to-RLOC Cache overflow 686 attack by de-aggregating (i.e., splitting an EID prefix into 687 artificially smaller EID prefixes) either positive or negative 688 mappings. 690 An attacker can combine overclaiming and de-aggregation to succeed a 691 cache poisoning attack. For example, if the attacker EID prefix is 692 10.0.0.0/24, she cannot provide a mapping for 10.0.1.0/24. But, as a 693 Map-Reply can contain several mappings, it is possible to finally 694 control this prefix. To do so, the attacker sends a mapping with an 695 EID prefix that covers at the same time the requested EID and the 696 prefix she wants to control. For example, if the request is for 697 10.0.0.1, and the target prefix is 10.0.1.0/24, the Map-Reply can 698 contain the mapping 10.0.0.0/23 and a mapping for 10.0.1.0/24. The 699 reply is perfectly legitimate according to the requested EID and the 700 attack is a success. 702 7.3. Gleaning Attacks 704 A third type of attack involves the gleaning mechanism proposed in 705 [I-D.ietf-lisp] and discussed in [Saucez09]. In order to reduce the 706 time required to obtain a mapping, [I-D.ietf-lisp] allows an ITR to 707 learn a mapping from the LISP data encapsulated packets and the Map- 708 Request packets that it receives. LISP data encapsulated packet 709 contains a source RLOC, destination RLOC, source EID and destination 710 EID. When an ITR receives a data encapsulated packet coming from a 711 source EID for which it does not already know a mapping, it may 712 insert the mapping between the source RLOC and the source EID in its 713 EID-to-RLOC Cache. Gleaning can also be used when an ITR receives a 714 Map-Request as the Map-Request also contains a source EID address and 715 a source RLOC. Once a gleaned entry has been added to the EID-to- 716 RLOC cache, the LISP ITR sends a Map-Request to retrieve the mapping 717 for the gleaned EID from the mapping system. [I-D.ietf-lisp] 718 recommends to store the gleaned entries for only a few seconds. 720 The first risk of gleaning is the ability to temporarily hijack an 721 identity. Consider an off-path attacker that wants to temporarily 722 hijack host HA's identity and send packets to host HB with host HA's 723 identity. If the xTRs that serve host HB do not store a mapping for 724 host HA, a non-spoofing off-path attacker (NSA) could send a LISP 725 encapsulated data packet to LR3 or LR4. The ETR will store the 726 gleaned entry and use it to return the packets sent by host HB to the 727 attacker. In parallel, the ETR will send a Map-Request to retrieve 728 the mapping for HA. During a few seconds or until the reception of 729 the Map-Reply, host HB will exchange packets with the attacker that 730 has hijacked HA's identity. Note that the attacker could in parallel 731 send lots of Map-Requests or lots of LISP data encapsulated packets 732 with random sources to force the xTR that is responsible for host HA 733 to send lots of Map-Request messages in order to force it to exceed 734 its rate limit for control plane messages. This could further delay 735 the arrival of the Map-Reply message on the requesting ETR. 737 Gleaning also introduces the possibility of a man-in-the-middle 738 attack. Consider an off-path attacker that knows that hosts HA and 739 HB that reside in different sites will exchange information at time 740 t. An off-path attacker could use this knowledge to launch a man-in- 741 the-middle attack if the xTRs that serve the two hosts do not have 742 mapping for the other EID. For this, the attacker sends to LR1 743 (resp. LR3) a LISP data encapsulated packet whose source RLOC is its 744 IP address and contains an IP packet whose source is set to HB (resp. 745 HA). The attacker chooses a packet that will not trigger an answer, 746 for example the last part of a fragmented packet. Upon reception of 747 these packets, LR1 and LR3 install gleaned entries that point to the 748 attacker. As explained above, the attacker could, at the same time, 749 send lots of packets to LR1 and LR3 to force them to exhaust their 750 control plane rate limit. This will extend the duration of the 751 gleaned entry. If host HA establishes a flow with host HB at that 752 time, the packets that they exchange will first pass through the 753 attacker. 755 In both cases, the attack only lasts for a few seconds (unless the 756 attacker is able to exhaust the rate limitation). However it should 757 be noted that today a large amount of packets may be exchanged during 758 even a small fraction of time. 760 8. Threats concerning Interworking 762 [I-D.ietf-lisp-interworking] defines two network elements to allow 763 LISP and non-LISP sites to communicate, namely the Proxy-ITR and the 764 Proxy-ETR. The Proxy-ITR encapsulates traffic from non-LISP sites in 765 order to forward it toward LISP sites, while the Proxy-ETR 766 decapsulates traffic arriving from LISP sites in order to forward it 767 toward non-LISP sites. For these elements some of the attack based 768 on the LISP specific header are not possible, for the simple reason 769 that some of the fields cannot be used due to the unidirectional 770 nature of the traffic. 772 The Proxy-ITR has functionalities similar to the ITR, however, its 773 main purpose is to encapsulate packets arriving from the DFZ in order 774 to reach LISP sites. This means that it is no bound to any 775 particular EID-Prefix, hence no mapping exists and no mapping can be 776 configured in the EID-to-RLOC Database. This means that the Proxy- 777 ITR element itself is not able to check whether or not the arriving 778 traffic has the right to be encapsulated or not. To limit such an 779 issue it is recommended to use the current practice based on 780 firewalls and ACLs on the machine running the Proxy-ITR service. On 781 the other side, the Proxy-ITR is meant to encapsulate only packets 782 that are destined to one of the LISP sites it is serving. This is 783 the case for instance for a service provider selling Proxy-ITR 784 services. For this purpose a static EID-to-RLOC Cache can be 785 configured in order to encapsulate only valid packets. In case of a 786 cache-miss no Map-Request needs to be sent and the packet can be 787 silently dropped. 789 The Proxy-ETR has functionalities similar to the ETR, however, its 790 main purpose is to inject un-encapsulated packet in the DFZ in order 791 to reach non-LISP-Sites. This means that since there is no specific 792 EID-Prefix downstream, it has no EID-to-RLOC Database that can be 793 used to check whether or not the destination EID is part of its 794 domain. In order to avoid for the Proxy-ETR to be used as relay in a 795 DoS attack it is preferable to configure the EID-to-RLOC Cache with 796 static entries used to check if an encapsulated packet coming from a 797 specific RLOC and having a specific source EID is actually allowed to 798 transit through the Proxy-ETR. This is also important for services 799 provider selling Proxy-ETR service to actually process only packets 800 arriving from its customers. However, in case of cache-miss no Map- 801 Request needs to be sent, rather the packet can be silently dropped 802 since it is not originating from a valid site. The same drop policy 803 should be used for packets with an invalid source RLOC or a valid 804 source RLOC but an invalid EID. 806 9. Threats with Malicious xTRs 808 In this section, we discuss the threats that could be caused by 809 malicious xTRs. We consider the reference environment below where 810 EL1 is a malicious or compromised xTR. This malicious xTR serves a 811 set of hosts that includes HC. The other xTR and hosts in this 812 network play the same role as in the reference environment described 813 in Section 5. 815 +-----+ 816 | HA | 817 +-----+ 818 | EID: HA 819 | 820 ----------------- 821 | | 822 +-----+ +-----+ 823 | LR1 | | LR2 | 824 +-----+ +-----+ 825 | | 826 | | 827 +-----+ +-----+ 828 |ISP1 | |ISP2 | 829 +-----+ +-----+ 830 | | 831 +----------------+ +-----+ | 832 | |-----| EL1 |--| 833 | | +-----+ | 834 | Internet | | +-----+ 835 | | |--| HC | 836 | | | +-----+ 837 +----------------+ EID: HC 838 | | 839 +-----+ +-----+ 840 | LR3 | | LR4 | 841 +-----+ +-----+ 842 | | 843 ------------------- 844 | 845 | EID: HB 846 +-----+ 847 | HB | 848 +-----+ 850 Figure 2: Malicious xTRs' Reference Environment 852 Malicious xTRs are probably the most serious threat to the LISP 853 control plane from a security viewpoint. To understand the problem, 854 let us consider the following scenario. Host HC and HB exchange 855 packets with host HA. As all these hosts reside in LISP sites, LR1 856 and LR2 store mappings for HB and HC. Thus, these xTRs may need to 857 exchange LISP control plane packets with EL1, e.g., to perform 858 reachability tests or to refresh expired mappings (e.g., if HC's 859 mapping has a small TTL). 861 A first threat against the LISP control plane is when EL1 replies to 862 a legitimate Map-Request message sent by LR1 or LR2 with a Map-Reply 863 message that contains an EID-Prefix that is larger than the prefix 864 owned by the site attached to EL1. This could allow EL1 to attract 865 packets destined to other EIDs than the EIDs that are attached to 866 EL1. This attack is called an "overclaiming" attack. 867 [I-D.maino-lisp-sec] proposes a solution to protect LISP against 868 overclaiming attacks under the assumption that the mapping system can 869 be trusted. 871 Another possible attack is a Denial of Service attack by sending a 872 Negative Map-Reply message for a coarser prefix without any locator 873 and with the Drop action. Such a Negative Map-Reply indicates that 874 the ETR that receives it should discard all packets. The current 875 LISP specification briefly discusses this problem [I-D.ietf-lisp], 876 but the proposed solutions does not solve the problem. 878 Another concern with malicious xTRs is the possibility of Denial of 879 Service attacks. A first attack is the flooding attack that was 880 described in [I-D.bagnulo-lisp-threat]. This attack allows a 881 malicious xTR to redirect traffic to a victim. The malicious xTR 882 first defines a mapping for HC with two RLOCs: its own RLOC (EL1) and 883 the RLOC of the victim (e.g., LR3). The victim's RLOC is set as 884 unreachable in the mapping. HC starts a large download from host HA. 885 Once the download starts, the malicious xTR updates its Locator 886 Status Bits, changes the mapping's version number or sets the SMR bit 887 such that LR1 updates its EID-to-RLOC Cache to send all packets 888 destined to HC to the victim's RLOC. Instead of downloading from HA, 889 the attacker could also send packets that trigger a response (e.g., 890 ICMP, TCP SYN, DNS request, ...) to HA. HA would then send its 891 response and its xTR would forward it to the victim's RLOC. 893 An important point to note about this flooding attack is that it 894 reveals a potential problem in the LISP architecture. A LISP ITR 895 relies on the received mapping and possible reachability information 896 to select the RLOC of the ETR that it uses to reach a given EID or 897 block of EIDs. However, if the ITR made a mistake, e.g., due to 898 configuration, implementation or other types of errors and has chosen 899 a RLOC that does not serve the destination EID, there is no easy way 900 for the LISP ETR to inform the ITR of its mistake. A possible 901 solution could be to force a ETR to perform a reachability test with 902 the selected ITR as soon as it selects it. This will be analyzed in 903 the next version of this document. 905 10. Security of the Proposed Mapping Systems 906 10.1. LISP+ALT 908 One of the assumptions in [I-D.ietf-lisp] is that the mapping system 909 is more secure than sending Map-Request and Map-Reply messages 910 directly. We analyze this assumption in this section by analyzing 911 the security of the ALT mapping system. 913 The ALT mapping system is basically a manually configured overlay of 914 GRE tunnels between ALT routers. BGP sessions are established 915 between ALT routers that are connected through such a tunnel. An ALT 916 router advertises the EID prefixes that it serves over its BGP 917 sessions with neighboring ALT routers and the EID-Prefixes that it 918 has learned from neighboring ALT routers. 920 The ALT mapping system is in fact a discovery system that allows any 921 ALT router to discover the ALT router that is responsible for a given 922 EID-Prefix. To obtain a mapping from the ALT system, an ITR sends a 923 packet containing a Map-Request on the overlay. This Map-Request is 924 sent inside a packet whose destination is the requested EID. The 925 Map-Request is routed on the overlay until it reaches the ALT router 926 that advertised initially the prefix that contains the requested EID. 927 This ALT router then replies directly by sending a Map-Reply to the 928 RLOC of the requesting ITR. 930 The security of the ALT mapping system depends on many factors, 931 including: 933 o The security of the intermediate ALT routers. 935 o The validity of the BGP advertisements sent on the ALT overlay. 937 Unfortunately, experience with BGP on the global Internet has shown 938 that BGP is subject to various types of misconfiguration problems and 939 security attacks. The SIDR working group is developing a more secure 940 inter-domain routing architecture to solve this problem 941 ([I-D.ietf-sidr-arch]). 943 The security of the intermediate ALT routers is another concern. A 944 malicious intermediate ALT router could manipulate the received BGP 945 advertisements and also answer to received Map-Requests without 946 forwarding them to their final destination on the overlay. This 947 could lead to various types of redirection attacks. Note that in 948 contrast with a regular IP router that could also manipulate in 949 transit packets, when a malicious or compromised ALT router replies 950 to a Map-Request, it can redirect legitimate traffic for a long 951 period of time by sending an invalid Map-Reply message. Thus, the 952 impact of a malicious ALT router could be much more severe than a 953 malicious router in today's Internet. 955 10.2. LISP-DDT 957 The LISP Delegated Database Tree (LISP-DDT) mapping system is 958 proposed as an alternative for LISP+ALT [I-D.fuller-lisp-ddt]. LISP- 959 DDT is a hierarchical distributed database for EID-to-RLOC mappings. 960 Each DDT node is configured with an EID prefix it owns, as well as 961 the RLOC addresses and EID prefixes of the LISP-DDT nodes that own a 962 more specific EID prefix than the one it owns. In LISP-DDT, mappings 963 are retrieved iteratively. A MR that needs to locate a mapping 964 traverses the tree of DDT nodes contacting them one after another 965 until the leaf of the DDT tree that owns the longest matching EID 966 prefix for the mapping's EID is reached. The MR traverses the 967 hierarchy of LISP-DDT nodes by sending Map-Requests, with the LISP- 968 DDT-originated bit set, to LISP-DDT nodes. The MR first contacts the 969 root of the hierarchy. When a LISP-DDT node receives a Map-Request, 970 it replies the MR with a Map-Referral that contains the list of the 971 locators of its childrens that own a prefix that covers the EID in 972 the Map-Request. The MR then contacts one of these childrens that 973 will return, at its turn, a Map-Referral. This procedure is 974 iteratively executed until a Map-Referral marked with the done flag 975 is received. The locators that appear in a referral with the done 976 flag are those of the authoritative ETRs for the EID in the Map- 977 Request. At that moment, the MR falls back to its normal behavior 978 and sends a Map-Request to the ETR in order for the ITR to obtain the 979 mapping. It is worth noticing that the MR can cache the referrals to 980 avoid traversing all the whole hierarchy for every mapping 981 retrievals. 983 The operation in LISP-DDT is different from ALT and thus it does not 984 present the same threats as LISP+ALT. However, threats exist for 985 LISP-DDT as well. First, a DoS attack can be performed on the MR by 986 asking her to retrieve a large amount of mappings at the same time. 987 Indeed, the iterative operation of the MR implies that it has to 988 maintain state about the ITR that requested the mapping, this in 989 order to send the final Map-Request to the ETR on behalf of the ITR. 990 An attacker might leverage on this to fill the MR memory and then 991 cause a DoS on the MR. 993 If an attacker manages to compromise a LISP-DDT node it can send fake 994 referrals to the MR and then control the mappings delivered to the 995 ITRs. Furthermore, the effects of such an attack can be longer than 996 the attack itself if the MR caches the referrals. 998 11. Threats concerning LISP-MS 1000 LISP-MS ([I-D.ietf-lisp-ms] specifies two network elements, namely 1001 the Map Server and the Map-Resolver, that are meant to be used by 1002 xTRs to access the mapping system. The advantage is clearly the fact 1003 that even if the mapping system changes in time xTRs do not need to 1004 change anything since they deal only with Map Servers and Map- 1005 Resolvers. This includes the security aspects, since no change in 1006 the local security policies is needed. 1008 11.1. Map Server 1010 Map Server is used to dispatch Map-Request coming from the mapping 1011 system to ETRs that are authoritative for the EID in the request. To 1012 this end it is necessary that ETRs register their mappings to the Map 1013 Server. This allows the Map Server to know toward which ETR to 1014 forward Map-Requests and also to announce the EID-prefix of the 1015 mapping in the mapping system. 1017 LISP uses a shared key approach in order to protect the Map Server 1018 and grant registration rights only to ETRs that have a valid key. 1019 Shared key must be used to protect both the registration message and 1020 the Map-Notify message when used. The mechanism used to share the 1021 key between a MS and an ETRs must be secured to avoid that a 1022 malicious nodes catch the key and uses it to send forged Map-Register 1023 message to the MS. A forged Map-Register message can be use to 1024 attract Map-Request and thus provide invalid Map-Replies or the 1025 redirect Map-Requests to a target to mount a DoS attack. 1027 More subtle attacks can be carried out only in the case of malicious 1028 ETRs. A malicious ETR can register an invalid RLOC to divert Map- 1029 Requests to a target ETR and succeed a DoS attack on it. To avoid 1030 this kind of attack, the Map Server must check that the registered 1031 RLOCs belongs to ETRs authoritative for the registered EID prefix. 1032 Such check can be done by sending and explicit Map-Request for the 1033 EID to the ETRs in the mapping and check that replies with a Map- 1034 Reply. If the ETRs return a valid Map-Reply, the RLOC belongs to an 1035 authoritative ETR. Note that this does not protect against malicious 1036 ETRs that create forged Map-Replies. Stronger techniques for RLOC 1037 check are presented in [I-D.saucez-lisp-mapping-security]. 1039 Similarly to the previous case, a malicious ETR can register an 1040 invalid EID-prefix to attract Map-Requests or to redirect them to a 1041 target to mount a DoS attack. To avoid this kind of attack, the Map 1042 Server must check that the prefixes registered by an ETR belong to 1043 that ETR. One method could be to manually configure EID-prefix 1044 ranges that can be announced by ETRs. 1045 [I-D.saucez-lisp-mapping-security] present alternative techniques to 1046 verify the prefix claimed by an ETR. 1048 11.2. Map-Resolver 1050 Map-Resolvers receive Map-Requests, typically from ITRs, and use the 1051 mapping system to find a mapping for the EID in the Map-Request. It 1052 can work in two modes: 1054 Non-Caching Mode: The resolver just forwards the Map-Request to the 1055 mapping system, which will take care of delivering the request 1056 to an authoritative ETR. The latter will send back a Map-Reply 1057 directly to the ITR that has originally issued the request. 1059 Caching Mode: The resolver will generate a new Map-Request and send 1060 it to the mapping system. In this way it will receive the 1061 corresponding reply, store a local copy in a cache, and send 1062 back a reply to the original requester. Since all requested 1063 mappings are locally cached, before actually making a request 1064 to the mapping system it performs a lookup in the local cache 1065 and in case of an hit, it send back a reply without querying 1066 the mapping system. 1068 In its basic mode, i.e., non-caching mode, the Map-Resolver does not 1069 keep state, hence, the only direct form of attack is a DoS attack, 1070 where an attacker (or a group of attackers) can try to exhaust 1071 computational power by flooding the resolver with requests. Common 1072 filtering techniques and BCP against DoS attacks can be applied in 1073 this case. 1075 Nonetheless, resolvers can be used by attackers as relay for DoS 1076 attacks against xTRs. An off-path spoofing attacker can generate a 1077 high load of requests to a set of resolvers, hence distributing the 1078 load in order to avoid to be blocked. All this requests can use a 1079 specific EID that makes all the requests to be forwarded to a 1080 specific ETR, which, as a result, will be victim of a DDoS attack. 1081 Similarly, the attacker can use a spoofed source address making all 1082 the replies to converge to one single ITR, which, as a result, will 1083 be victim of a DDoS attack. Such scenarios are not specific to LISP, 1084 but rather a common problem of every query infrastructure, hence the 1085 same BCP can be applied in order to limit the attacks. 1087 When functioning in caching-mode, the resolver will use the same type 1088 of cache than ITRs. Due to its similarity with the ITRs' cache the 1089 analysis provided in Section 6.2 holds also in this case. However, 1090 an important difference exists: this cache is not used for packet 1091 encapsulation but only for quick replies when new requests arrive. 1092 Therefore, as the caching-mode is only an optimization, the attacks 1093 that tends to fill the MR cache have a less severe impact on the 1094 traffic. 1096 The question may arise on whether a Kaminsky-like attack is possible 1097 for an off-path attacker against ITRs sending requests to a certain 1098 resolver. The 64-bits nonce present in every message has been 1099 introduced in the LISP specification to avoid such kind of attack. 1100 There has been discussion within the LISP Working Group on the 1101 optimal size of the nonce, and it seems that 64-bits provides 1102 sufficient protection. 1104 A possible way to limit the above-described attacks is to introduce 1105 strong identification in the Map-Request/Map-Reply by using the 1106 Encapsulated Control Message with authentication enabled. 1108 12. Suggested Recommendations 1110 To mitigate the impact of attacks against LISP, the following 1111 recommendations should be followed. 1113 First, the use of some form of filtering can help in avoid or at 1114 least mitigate some types of attacks. 1116 o On ETRs, packets should be decapsulated only if the destination 1117 EID is effectively part of the EID-Prefix downstream the ETR. 1118 Further, still on ETRs, packets should be decapsulated only if a 1119 mapping for the source EID is present in the EID-to-RLOC Cache and 1120 has been obtained through the mapping system (not gleaned). 1122 o On ITRs, packets should be encapsulated only if the source EID is 1123 effectively part of the EID-Prefix downstream the ITR. Further, 1124 still on ITRs, packets should be encapsulated only if a mapping 1125 obtained from the mapping system is present in the EID-to-RLOC 1126 Cache (no Data-Probing). 1128 Note that this filtering, since complete mappings need to be 1129 installed in both ITRs and ETRs, can introduce a higher connection 1130 setup latency and hence potentially more packets drops due to the 1131 lack of mappings in the EID-to-RLOC Cache. 1133 While the gleaning mechanism allows to start encapsulating packets to 1134 a certain EID in parallel with the Map-Request to obtain a mapping 1135 when a new flow is established, it creates important security risks 1136 since it allows attackers to perform identity hijacks. Although the 1137 duration of these identity hijacks is limited (except the case of 1138 rate limitation exhaustion), their impact can be severe. A first 1139 option would be to disable gleaning until the security concerns are 1140 solved. A second option would be to strictly limit the number of 1141 packets that can be forwarded via a gleaned entry. Overall the 1142 benefits of gleaning, i.e., avoiding the loss of the first packet of 1143 a flow, seems very small compared to the associated security risks. 1144 Furthermore, measurements performed in data centers show that today's 1145 Internet often operate with packet loss ratio of 1 or 2 percentage 1146 ([Chu]). These packet loss ratio are probably already orders of 1147 magnitude larger than the improvement provided by the gleaning 1148 mechanism. 1150 With the increasing deployment of spoofing prevention techniques such 1151 as [RFC3704] or SAVI [SAVI], it can be expected that attackers will 1152 become less capable of sending packets with a spoofed source address. 1153 To prevent packet injection attacks from non-spoofing attackers 1154 (NSA), ETRs should always verify that the source RLOC of each 1155 received LISP data encapsulated packet corresponds to one of the 1156 RLOCs listed in the mappings for the source EID found in the inner 1157 packet. An alternative could be to use existing IPSec techniques 1158 [RFC4301] and when necessary including perhaps [RFC5386] to establish 1159 an authenticated tunnel between the ITR and the ETR. 1161 [I-D.ietf-lisp] recommends to rate limit the control messages that 1162 are sent by a xTR. This limit is important to deal with denial of 1163 service attacks. However, a strict limit, e.g., implemented with a 1164 token bucket, on all the Map-Request and Map-Reply messages sent by a 1165 xTR is not sufficient. A xTR should distinguish between different 1166 types of control plane packets: 1168 1. The Map-Request messages that it sends to refresh expired mapping 1169 information. 1171 2. The Map-Request messages that it sends to obtain mapping 1172 information because one of the served hosts tried to contact an 1173 external EID. 1175 3. The Map-Request messages that it sends as reachability probes. 1177 4. The Map-Reply messages that it sends as response to reachability 1178 probes. 1180 5. The Map-Request messages that it sends to support gleaning. 1182 These control plane messages are used for different purposes. Fixing 1183 a global rate limit for all control plane messages increases the risk 1184 of Denial of Service attacks if a single type of control plane 1185 message can exceed the configured limit. This risk could be 1186 mitigated by either specifying a rate for each of the five types of 1187 control plane messages. Another option could be to define a maximum 1188 rate for all control plane messages, and prioritize the control plane 1189 messages according to the list above (with the highest priority for 1190 message type 1). 1192 In [I-D.ietf-lisp], there is no mechanism that allows a xTR to verify 1193 the validity of the content a Map-Reply message that it receives. 1194 Besides the attacks discussed earlier in the document, a time-shifted 1195 attack where an attacker is able to modify the content of a Map-Reply 1196 message but then needs to move off-path could also create redirection 1197 attacks. The nonce only allows a xTR to verify that a Map-Reply 1198 responds to a previously sent Map-Request message. The LISP Working 1199 Group should explore solutions that allow to verify the validity and 1200 integrity of bindings between EID-Prefixes and their RLOCS (e.g., 1201 [I-D.saucez-lisp-mapping-security] and [I-D.maino-lisp-sec]). Having 1202 such kind of mechanism would allow ITRs to ignore non-verified 1203 mappings, thus increasing security. 1205 LISP Working Group should consider developing secure mechanisms to 1206 allow an ETR to indicate to an ITR that it does not serve a 1207 particular EID or block of EIDs in order to mitigate the flooding 1208 attacks. 1210 Finally, there is also the risk of Denial of Service attack against 1211 the EID-to-RLOC Cache. We have discussed these attacks when 1212 considering external attackers with, e.g., the gleaning mechanism and 1213 in Section 6.2. If an ITR has a limited EID-to-RLOC Cache, a 1214 malicious or compromised host residing in the site that it serves 1215 could generate packets to random destinations to force the ITR to 1216 issue a large number of Map-Requests whose answers could fill its 1217 cache. Faced with such misbehaving hosts, LISP ITR should be able to 1218 limit the percent of Map-Requests that it sends for a given source 1219 EID. 1221 13. Document Status and Plans 1223 In this document, we have analyzed some of the security threats that 1224 affect the Locator/Identifier Separation Protocol (LISP). We have 1225 focused our analysis on unicast traffic and considered both the LISP 1226 data and control planes, and provided some recommendations to improve 1227 the security of LISP. 1229 Revisions of this document will document the security threats of 1230 other parts of the LISP architecture, including but not limited to: 1232 o LISP Multicast ([I-D.ietf-lisp-multicast]). 1234 14. IANA Considerations 1236 This document makes no request to IANA. 1238 15. Security Considerations 1240 Security considerations are the core of this document and do not need 1241 to be further discussed in this section. 1243 16. Acknowledgments 1245 The flooding attack and the reference environment were first 1246 described in Marcelo Bagnulo's draft [I-D.bagnulo-lisp-threat]. 1248 We would like to thank Jeff Wheeler for his comments. 1250 This work has been partially supported by the INFSO-ICT-216372 1251 TRILOGY Project (www.trilogy-project.org). 1253 17. References 1255 17.1. Normative References 1257 [I-D.ietf-lisp] 1258 Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 1259 "Locator/ID Separation Protocol (LISP)", 1260 draft-ietf-lisp-23 (work in progress), May 2012. 1262 [I-D.ietf-lisp-alt] 1263 Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP 1264 Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-10 1265 (work in progress), December 2011. 1267 [I-D.ietf-lisp-interworking] 1268 Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 1269 "Interworking LISP with IPv4 and IPv6", 1270 draft-ietf-lisp-interworking-06 (work in progress), 1271 March 2012. 1273 [I-D.ietf-lisp-map-versioning] 1274 Iannone, L., Saucez, D., and O. Bonaventure, "LISP Map- 1275 Versioning", draft-ietf-lisp-map-versioning-09 (work in 1276 progress), March 2012. 1278 [I-D.ietf-lisp-ms] 1279 Fuller, V. and D. Farinacci, "LISP Map Server Interface", 1280 draft-ietf-lisp-ms-16 (work in progress), March 2012. 1282 [I-D.ietf-lisp-multicast] 1283 Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, 1284 "LISP for Multicast Environments", 1285 draft-ietf-lisp-multicast-14 (work in progress), 1286 February 2012. 1288 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1289 Requirement Levels", BCP 14, RFC 2119, March 1997. 1291 17.2. Informative References 1293 [Chu] Jerry Chu, H., "Tuning TCP Parameters for the 21st 1294 Century", 75th IETF, Stockholm, July 2009, 1295 . 1297 [I-D.bagnulo-lisp-threat] 1298 Bagnulo, M., "Preliminary LISP Threat Analysis", 1299 draft-bagnulo-lisp-threat-01 (work in progress), 1300 July 2007. 1302 [I-D.fuller-lisp-ddt] 1303 Lewis, D., Farinacci, D., and V. Fuller, "LISP Delegated 1304 Database Tree", draft-fuller-lisp-ddt-00 (work in 1305 progress), November 2011. 1307 [I-D.ietf-sidr-arch] 1308 Lepinski, M. and S. Kent, "An Infrastructure to Support 1309 Secure Internet Routing", draft-ietf-sidr-arch-13 (work in 1310 progress), May 2011. 1312 [I-D.ietf-tcpm-tcp-security] 1313 Gont, F., "Survey of Security Hardening Methods for 1314 Transmission Control Protocol (TCP) Implementations", 1315 draft-ietf-tcpm-tcp-security-03 (work in progress), 1316 March 2012. 1318 [I-D.lear-lisp-nerd] 1319 Lear, E., "NERD: A Not-so-novel EID to RLOC Database", 1320 draft-lear-lisp-nerd-09 (work in progress), April 2012. 1322 [I-D.maino-lisp-sec] 1323 Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D., 1324 and O. Bonaventure, "LISP-Security (LISP-SEC)", 1325 draft-maino-lisp-sec-00 (work in progress), March 2011. 1327 [I-D.meyer-lisp-cons] 1328 Brim, S., "LISP-CONS: A Content distribution Overlay 1329 Network Service for LISP", draft-meyer-lisp-cons-04 (work 1330 in progress), April 2008. 1332 [I-D.saucez-lisp-mapping-security] 1333 Saucez, D. and O. Bonaventure, "Securing LISP Mapping 1334 replies", draft-saucez-lisp-mapping-security-00 (work in 1335 progress), February 2011. 1337 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1338 Networks", BCP 84, RFC 3704, March 2004. 1340 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1341 Internet Protocol", RFC 4301, December 2005. 1343 [RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing 1344 Security: An Unauthenticated Mode of IPsec", RFC 5386, 1345 November 2008. 1347 [SAVI] IETF, "Source Address Validation Improvements Working 1348 Group", . 1350 [Saucez09] 1351 Saucez, D. and L. Iannone, "How to mitigate the effect of 1352 scans on mapping systems", Submitted to the Trilogy 1353 Summer School on Future Internet. 1355 Appendix A. Document Change Log 1357 o Version 02 Posted September 2012. 1359 * Added a new attack that combines overclaiming and de- 1360 aggregation (see Section 7.2). 1362 * Editorial polishing. 1364 o Version 01 Posted February 2012. 1366 * Added discussion on LISP-DDT in Section 10.2. 1368 o Version 00 Posted July 2011. 1370 * Added discussion on LISP-MS in Section 11. 1372 * Added discussion on Instance ID in Section 6.4. 1374 * Editorial polishing of the whole document. 1376 * Added "Change Log" appendix to keep track of main changes. 1378 * Renamed "draft-saucez-lisp-security-03.txt. 1380 Authors' Addresses 1382 Damien Saucez 1383 INRIA 1384 2004 route des Lucioles BP 93 1385 06902 Sophia Antipolis Cedex 1386 France 1388 Email: damien.saucez@inria.fr 1390 Luigi Iannone 1391 Telecom ParisTech 1392 23, Avenue d'Italie, CS 51327 1393 75214 PARIS Cedex 13 1394 France 1396 Email: luigi.iannone@telecom-paristech.fr 1398 Olivier Bonaventure 1399 Universite catholique de Louvain 1400 Place St. Barbe 2 1401 Louvain la Neuve 1402 Belgium 1404 Email: olivier.bonaventure@uclouvain.be