idnits 2.17.1 draft-ietf-lisp-threats-03.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 16, 2012) is 4209 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 (-29) exists of draft-ietf-lisp-sec-04 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Saucez 3 Internet-Draft INRIA 4 Intended status: Informational L. Iannone 5 Expires: April 19, 2013 Telecom ParisTech 6 O. Bonaventure 7 Universite catholique de Louvain 8 October 16, 2012 10 LISP Threats Analysis 11 draft-ietf-lisp-threats-03.txt 13 Abstract 15 This document analyzes the threats against the security of the 16 Locator/Identifier Separation Protocol (LISP) 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 April 19, 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 55 3. On-path Attackers . . . . . . . . . . . . . . . . . . . . . . 4 56 4. Off-Path Attackers: Reference Environment . . . . . . . . . . 4 57 5. Data-Plane Threats . . . . . . . . . . . . . . . . . . . . . . 6 58 5.1. EID-to-RLOC Database Threats . . . . . . . . . . . . . . . 6 59 5.2. EID-to-RLOC Cache Threats . . . . . . . . . . . . . . . . 7 60 5.2.1. EID-to-RLOC Cache poisoning . . . . . . . . . . . . . 7 61 5.2.2. EID-to-RLOC Cache overflow . . . . . . . . . . . . . . 9 62 5.3. Attacks not leveraging on the LISP header . . . . . . . . 9 63 5.4. Attacks leveraging on the LISP header . . . . . . . . . . 10 64 5.4.1. Attacks using the Locator Status Bits . . . . . . . . 10 65 5.4.2. Attacks using the Map-Version bit . . . . . . . . . . 11 66 5.4.3. Attacks using the Nonce-Present and the Echo-Nonce 67 bits . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 5.4.4. Attacks using the ID Instance bits . . . . . . . . . . 13 69 6. Control Plane Threats . . . . . . . . . . . . . . . . . . . . 13 70 6.1. Attacks with Map-Request messages . . . . . . . . . . . . 13 71 6.2. Attacks with Map-Reply messages . . . . . . . . . . . . . 15 72 6.3. Gleaning Attacks . . . . . . . . . . . . . . . . . . . . . 16 73 7. Threats concerning Interworking . . . . . . . . . . . . . . . 17 74 8. Threats with Malicious xTRs . . . . . . . . . . . . . . . . . 18 75 9. Security of the Proposed Mapping Systems . . . . . . . . . . . 21 76 9.1. LISP+ALT . . . . . . . . . . . . . . . . . . . . . . . . . 21 77 9.2. LISP-DDT . . . . . . . . . . . . . . . . . . . . . . . . . 22 78 10. Threats concerning LISP-MS . . . . . . . . . . . . . . . . . . 23 79 10.1. Map Server . . . . . . . . . . . . . . . . . . . . . . . . 23 80 10.2. Map Resolver . . . . . . . . . . . . . . . . . . . . . . . 24 81 11. Suggested Recommendations . . . . . . . . . . . . . . . . . . 26 82 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 83 13. Security Considerations . . . . . . . . . . . . . . . . . . . 28 84 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 85 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 86 15.1. Normative References . . . . . . . . . . . . . . . . . . . 28 87 15.2. Informative References . . . . . . . . . . . . . . . . . . 29 88 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 30 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 91 1. Introduction 93 The Locator/ID Separation Protocol (LISP) is defined in 94 [I-D.ietf-lisp]. The present document aims at assessing the security 95 level and identifying security threats in the LISP specification. As 96 a result of the performed analysis, the document also proposes some 97 recommendations aiming at improving LISP's resiliency against off- 98 path attackers. 100 The document is composed of two main parts: the first discussing the 101 LISP data-plane; while the second discussing the LISP control-plane. 103 The LISP data-plane consists of LISP packet encapsulation, 104 decapsulation, and forwarding and includes the EID-to-RLOC Cache and 105 EID-to-RLOC Database data structures used to perform these 106 operations. 108 The LISP control-plane consists in the mapping distribution system, 109 which can be one of the mapping distribution systems proposed so far 110 (e.g., [I-D.ietf-lisp], [I-D.fuller-lisp-ddt], [I-D.ietf-lisp-alt], 111 [I-D.ietf-lisp-ms], [I-D.meyer-lisp-cons], and [I-D.lear-lisp-nerd]), 112 and the Map-Request, Map-Reply, Map-Register, and Map-Notification 113 messages. 115 This document does not consider all the possible uses of LISP as 116 discussed in [I-D.ietf-lisp]. The document focuses on LISP unicast, 117 including as well LISP Interworking [I-D.ietf-lisp-interworking], 118 LISP-MS [I-D.ietf-lisp-ms], LISP Map-Versioning 119 [I-D.ietf-lisp-map-versioning], and briefly considering the ALT 120 mapping system described in [I-D.ietf-lisp-alt] and the Delegated 121 Database Tree mapping system described in [I-D.fuller-lisp-ddt]. The 122 reading of these documents is a prerequisite for understanding the 123 present document. 125 Unless otherwise stated, the document assumes a generic IP service 126 and does not discuss the difference, from a security viewpoint, 127 between using IPv4 or IPv6. 129 2. Definition of Terms 131 The present document does not introduce any new term, compared to the 132 main LISP specification. For a complete list of terms please refer 133 to [I-D.ietf-lisp]. 135 3. On-path Attackers 137 On-path attackers are attackers that are able to capture and modify 138 all the packets exchanged between an Ingress Tunnel Router (ITR) and 139 an Egress Tunnel Router (ETR). To cope with such an attacker, 140 cryptographic techniques such as those used by IPSec ([RFC4301]) are 141 required. We do not consider that LISP has to cope with such kind of 142 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 4. 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 in 160 turn are attached to two different ISPs. HB is attached to the two 161 LISP xTRs LR3 and LR4. HA and HB are the EIDs of the two hosts. 162 LR1, 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 that is not 214 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 site 220 (or a PITR if the source site is not LISP enabled). 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 the 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 (e.g., through a public 235 Map Resolver) to obtain the mappings for both HA and HB. 237 5. 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 LISP xTRs. In 249 this analysis, we assume that the LR1 and LR2 (resp. LR3 and LR4) 250 xTRs maintain an EID-to-RLOC Cache that contains the required mapping 251 entries to allow HA and HB to exchange packets. 253 5.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 5.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 6) or 274 by corrupting (poisoning) the mappings already present in the cache. 276 5.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. Examples 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 6.3 or 284 by attacking the control-plane as described in Section 6. 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 6.3 or by attacking the control-plane as described in 290 Section 6. 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 6.3 or by attacking the control-plane as 300 described in Section 6. 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 6. 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 (special value indicating 322 not to use the RLOC). Corrupting the TE attributes can be 323 achieved by attacking the control-plane as described in 324 Section 6. 326 Mapping TTL poisoning: The LISP protocol associates a Time-To-Live 327 to each mapping that, once expired, allows to delete a mapping 328 from the EID-to-RLOC Cache (or forces a Map-Request/Map-Reply 329 exchange to refresh it if still needed). By injecting fake TTL 330 values, an attacker can either shrink the EID-to-RLOC Cache 331 (using very short TTL), thus creating an excess of cache miss 332 causing a DoS on the mapping system, or it can increase the 333 size of the cache by putting very high TTL values, up to a 334 cache overflow (see Section 5.2.2). Corrupting the TTL can be 335 achieved by attacking the control-plane as described in 336 Section 6. Long TTL can be use in fake mappings to increase 337 attack duration. 339 Instance ID poisoning: The LISP protocol allows using a 24-bit 340 identifier to select the forwarding table to use on the 341 decapsulating ETR to forward the decapsulated packet. By 342 spoofing this attribute the attacker is able to redirect or 343 blackhole inbound traffic. Corrupting the Instance ID 344 attribute can be achieved by attacking the control-plane as 345 described in Section 6. 347 Map-Version poisoning: The LISP protocol allows associating a 348 version number to mappings ([I-D.ietf-lisp-map-versioning]). 349 The LISP header can transport source and destination map- 350 versions, describing which version of the mapping have been 351 used to select the source and the destination RLOCs of the LISP 352 encapsulated packet. By spoofing this attribute the attacker 353 is able to trigger Map-Request on the receiving ETR. 354 Corrupting the Map-Version attribute can be achieved either by 355 attacking the control-plane as described in Section 6 or by 356 using spoofed packets as described in Section 5.4.2. 358 If the above listed attacks succeed, the attacker has the means of 359 controlling the traffic. 361 5.2.2. EID-to-RLOC Cache overflow 363 Depending on how the EID-to-RLOC Cache is managed (e.g., Least 364 Recently Used - LRU vs. Least Frequently Used - LFU) and depending on 365 its size, an attacker can try to fill the cache with fake mappings. 366 Once the cache is full, some mappings will be replaced by new fake 367 ones, causing traffic disruption. 369 This can be achieved either through gleaning as described in 370 Section 6.3 or by attacking the control-plane as described in 371 Section 6. 373 Another way to generate an EID-to-RLOC Cache overflow is by injecting 374 mapping with a fake and very large TTL value. In this case the cache 375 will keep a large amount of mappings ending with a completely full 376 cache. This type of attack can also be performed through the 377 control-plane. 379 5.3. Attacks not leveraging on the LISP header 381 We first consider an attacker that sends packets without exploiting 382 the LISP header, i.e., with the N, L, E, V, and I bits reset 383 ([I-D.ietf-lisp]). 385 To inject a packet in the HA-HB flow, a spoofing off-path attacker 386 (SA) can send a LISP encapsulated packet whose source is set to LR1 387 or LR2 and destination LR3 or LR4. The packet will reach HB as if 388 the packet was sent by host HA. This is not different from today's 389 Internet where a spoofing off-path attacker may inject data packets 390 in any flow. Several existing techniques can be used by hosts to 391 prevent such attacks from affecting established flows, e.g., 392 [RFC4301] and [I-D.ietf-tcpm-tcp-security]. 394 On the other hand, a non-spoofing off-path attacker (NSA) can only 395 send a packet whose source address is set to its assigned IP address. 396 The destination address of the encapsulated packet can be LR3 or LR4. 397 When the LISP ETR that serves HB receives the encapsulated packet, it 398 can consult its EID-to-RLOC Cache and verify that NSA is not a valid 399 source address for LISP encapsulated packets containing a packet sent 400 by HA. This verification is only possible if the ETR already has a 401 valid mapping for HA. Otherwise, and to avoid such data packet 402 injection attacks, the LISP ETR should reject the packet and possibly 403 query the mapping system to obtain a mapping for the encapsulated 404 source EID (HA). 406 5.4. Attacks leveraging on the LISP header 408 The main LISP document [I-D.ietf-lisp] defines several flags that 409 modify the interpretation of the LISP header in data packets. In 410 this section, we discuss how an off-path attacker could exploit this 411 LISP header. 413 5.4.1. Attacks using the Locator Status Bits 415 When the L bit is set to 1, it indicates that the second 32-bits 416 longword of the LISP header contains the Locator Status Bits. In 417 this field, each bit position reflects the status of one of the RLOCs 418 mapped to the source EID found in the encapsulated packet. In 419 particular, a packet with the L bit set and all Locator Status Bits 420 set to zero indicates that none of the locators of the encapsulated 421 source EID are reachable. The reaction of a LISP ETR that receives 422 such a packet is not clearly described in [I-D.ietf-lisp]. 424 A spoofing off-path attacker (SA) can send a data packet with the L 425 bit set to 1, all Locator Status Bits set to zero, a spoofed source 426 RLOC (e.g. LR1), destination LR3, and containing an encapsulated 427 packet whose source is HA. If LR3 blindly trusts the Locator Status 428 Bits of the received packet it will set LR1 and LR2 as unreachable, 429 possibly disrupting ongoing communication. 431 Locator Status Bits can be blindly trusted only in secure 432 environments. In the general unsecured Internet environment, the 433 safest practice for xTRs is to confirm the reachability change 434 through the control plane (e.g., RLOC probing). In the above 435 example, LR3 should note that something has changed in the Locator 436 Status Bits and query the mapping system (assuming it is trusted) in 437 order to confirm status of the RLOCs of the source EID. 439 A similar attack could occur by setting only one Locator Status Bit 440 to 1, e.g., the one that corresponds to the source RLOC of the 441 packet. 443 If a non-spoofing off-path attacker (NSA) sends a data packet with 444 the L bit set to 1 and all Locator Status Bits set to zero, this 445 packet will contain the source address of the attacker. Similarly as 446 in Section 5.3, if the xTR accepts the packet without checking the 447 EID-to-RLOC Cache for a mapping that binds the source EID and the 448 source RLOC of the received packet, then the same observation like 449 for the spoofing attacker (SA) apply with the difference that instead 450 of complete disruption, the traffic will flow through only one RLOC, 451 possibly resulting in a DoS attack. 453 Otherwise, if the xTR does make the check through the EID-to-RLOC 454 Cache, it should reject the packet because its source address is not 455 one of the addresses listed as RLOCs for the source EID. 456 Nevertheless, in this case a Map-Request should be sent, which can be 457 used to perform Denial of Service attacks. Indeed an attacker can 458 frequently change the Locator Status Bits in order to trigger a large 459 amount of Map-Requests. Rate limitation, as described in 460 [I-D.ietf-lisp], does not allow sending high number of such a 461 request, resulting in the attacker saturating the rate with these 462 spoofed packets. 464 5.4.2. Attacks using the Map-Version bit 466 The Map-Version bit is used to indicate whether the low-order 24 bits 467 of the first 32 bits longword of the LISP header contain a Source and 468 Destination Map-Version. When a LISP ETR receives a LISP 469 encapsulated packet with the Map-Version bit set to 1, the following 470 actions are taken: 472 o It compares the Destination Map-Version found in the header with 473 the current version of its own mapping, in the EID-to-RLOC 474 Database, for the destination EID found in the encapsulated 475 packet. If the received Destination Map-Version is smaller (i.e., 476 older) than the current version, the ETR should apply the SMR 477 procedure described in [I-D.ietf-lisp] and send a Map-Request with 478 the SMR bit set. 480 o If a mapping exists in the EID-to-RLOC Cache for the source EID, 481 then it compares the Map-Version of that entry with the Source 482 Map-Version found in the header of the packet. If the stored 483 mapping is older (i.e., the Map-Version is smaller) than the 484 source version of the LISP encapsulated packet, the xTR should 485 send a Map-Request for the source EID. 487 A spoofing off-path attacker (SA) could use the Map-Version bit to 488 force an ETR to send Map-Request messages. The attacker can retrieve 489 the current source and destination Map-Version for both HA and HB. 490 Based on this information, it can send a spoofed packet with an older 491 Source Map-Version or Destination Map-Version. If the size of the 492 Map-Request message is larger than the size of the smallest LISP- 493 encapsulated packet that could trigger such a message, this could 494 lead to amplification attacks (see Section 6.1). However, 495 [I-D.ietf-lisp] recommends to rate limit the Map-Request messages 496 that are sent by an xTR. This prevents the amplification attack, but 497 there is a risk of Denial of Service attack if an attacker sends 498 packets with Source and Destination Map-Versions that frequently 499 change. In this case, the ETR could consume its entire rate by 500 sending Map-Request messages in response to these spoofed packets. 502 A non-spoofing off-path attacker (NSA) cannot success in such an 503 attack if the destination xTR rejects the LISP encapsulated packets 504 that are not sent by one of the RLOCs mapped to the included source 505 EID. If it is not the case, the attacker can be able to perform 506 attacks concerning the Destination Map Version number as for the 507 spoofing off-path attacker (SA). 509 5.4.3. Attacks using the Nonce-Present and the Echo-Nonce bits 511 The Nonce-Present and Echo-Nonce bits are used when verifying the 512 reachability of a remote ETR. Assume that LR3 wants to verify that 513 LR1 receives the packets that it sends. LR3 can set the Echo-Nonce 514 and the Nonce-Present bits in LISP data encapsulated packets and 515 include a random nonce in these packets. Upon reception of these 516 packets, LR1 will store the nonce sent by LR3 and echo it when it 517 returns LISP encapsulated data packets to LR3. 519 A spoofing off-path attacker (SA) could interfere with this 520 reachability test by sending two different types of packets: 522 1. LISP data encapsulated packets with the Nonce-Present bit set and 523 a random nonce and the appropriate source and destination RLOCs. 525 2. LISP data encapsulated packets with the Nonce-Present and the 526 Echo-Nonce bits both set and the appropriate source and 527 destination RLOCs. These packets will force the receiving ETR to 528 store the received nonce and echo it in the LISP encapsulated 529 packets that it sends. 531 The first type of packet should not cause any major problem to ITRs. 532 As the reachability test uses a 24 bits nonce, it is unlikely that an 533 off-path attacker could send a single packet that causes an ITR to 534 believe that the ETR it is testing is reachable while in reality it 535 is not reachable. To increase the success likelihood of such attach, 536 the attacker should created a massive amount of packets carrying all 537 possible nonce values. However, "flood attack" can be easily 538 detected and blocked. 540 The second type of packet could be exploited to create a Denial of 541 Service attack against the nonce-based reachability test. Consider a 542 spoofing off-path attacker (SA) that sends a continuous flow of 543 spoofed LISP data encapsulated packets that contain the Nonce-Present 544 and the Echo-Nonce bit and each packet contains a different random 545 nonce. The ETR that receives such packets will continuously change 546 the nonce that it returns to the remote ITR. If the remote ITR 547 starts a nonce-reachability test, this test may fail because the ETR 548 has received a spoofed LISP data encapsulated packet with a different 549 random nonce and never echoes the real nonce. In this case the ITR 550 will consider the ETR not reachable. The success of this test will 551 of course depend on the ratio between the amount of packets sent by 552 the legitimate ITR and the spoofing off-path attacker (SA). 554 Packets sent by a non-spoofing off-path attacker (NSA) can cause 555 similar problem if no check is done with the EID-to-RLOC Cache (see 556 Section 5.3 for the EID-to-RLOC Cache check). Otherwise, if the 557 check is performed the packets will be rejected by the ETR that 558 receives them and cannot cause problems. 560 5.4.4. Attacks using the ID Instance bits 562 LISP allows to carry in its header a 24-bits value called "Instance 563 ID" and used on the ITR to indicate which private Instance ID has 564 been used for encapsulation, while on the ETR can be used to select 565 the forwarding table used for forwarding the decapsulated packet. 567 Even if an off-path attacker could randomly guess a valid Instance ID 568 value, there is no LISP specific problem. Obviously the attacker 569 could be now able to reach hosts that are only reachable through the 570 routing table identified by the attacked Instance ID, however, end- 571 system security is out of the scope of this document. Nevertheless, 572 access lists can be configured to protect the network from Instance 573 ID based attacks. 575 6. Control Plane Threats 577 In this section, we discuss the different types of attacks that can 578 occur when an off-path attacker sends control plane packets. We 579 focus on the packets that are sent directly to the ETR and do not 580 analyze the particularities of a LISP mapping system. The LISP+ALT 581 and LISP-DDT mapping systems are discussed in Section 9. 583 6.1. Attacks with Map-Request messages 585 An off-path attacker could send Map-Request packets to a victim ETR. 586 In theory, a Map-Request packet is only used to solicit an answer and 587 as such it should not lead to security problems. However, the LISP 588 specification [I-D.ietf-lisp] contains several particularities that 589 could be exploited by an off-path attacker. 591 The first possible exploitation is the P bit. The P bit is used to 592 probe the reachability of remote ETRs in the control plane. In our 593 reference environment, LR3 could probe the reachability of LR1 by 594 sending a Map-Request with the P bit set. LR1 would reply by sending 595 a Map-Reply message with the P bit set and the same nonce as in the 596 Map-Request message. 598 A spoofing off-path attacker (SA) could use the P bit to force a 599 victim ETR to send a Map-Reply to the spoofed source address of the 600 Map-Request message. As the Map-Reply can be larger than the Map- 601 Request message, there is a risk of amplification attack. 602 Considering only IPv6 addresses, a Map-Request can be as small as 40 603 bytes, considering one single ITR address and no Mapping Protocol 604 Data. The Map-Reply instead has a size of O(12 + (R * (28 + N * 605 24))) bytes, where N is the maximum number of RLOCs in a mapping and 606 R the maximum number of records in a Map-Reply. Since up to 255 607 RLOCs can be associated to an EID-Prefix and 255 records can be 608 stored in a Map-Reply, the maximum size of a Map-Reply is thus above 609 1 MB showing a size factor of up to 39,193 between the message sent 610 by the attacker and the message sent by the ETR. These numbers are 611 however theoretical values not considering transport layer 612 limitations and it is more likely that the reply will contain only 613 one record with at most a dozen of locators, giving an amplification 614 factor around 8. 616 Any ISP with a large number of potential RLOCs for a given EID-Prefix 617 should carefully ponder the best trade-off between the number of 618 RLOCs through which it wants that the EID is reachable and the 619 consequences that an amplification attack can produce. 621 It should be noted that the maximum rate of Map-Reply messages should 622 apply to all Map-Replies and also be associated to each destination 623 that receives Map-Reply messages. Otherwise, a possible 624 amplification attack could be launched by a spoofing off-path 625 attacker (SA) as follows. Consider an attacker SA and EID-Prefix 626 192.0.2.0/24 and a victim ITR. To amplify a Denial of Service attack 627 against the victim ITR, SA could send spoofed Map-Request messages 628 whose source EID addresses are all the addresses inside 192.0.2.0/24 629 and source RLOC address is the victim ITR. Upon reception of these 630 Map-Request messages, the ETR would send large Map-Reply messages for 631 each of the addresses inside p/P back to the victim ITR. 633 If a non-spoofing off-path attacker (NSA) sends a Map-Request with 634 the P bit set, it will receive a Map-Reply with the P bit set. This 635 does not raise security issues besides the usual risk of overloading 636 a victim ETR by sending too many Map-Request messages. 638 The Map-Request message may also contain the SMR bit. Upon reception 639 of a Map-Request message with the SMR bit, an ETR must return to the 640 source of the Map-Request message a Map-Request message to retrieve 641 the corresponding mapping. This raises similar problems as the P bit 642 discussed above except that as the Map-Request messages are smaller 643 than Map-Reply messages, the risk of amplification attacks is 644 reduced. This is not true anymore if the ETR append to the Map- 645 Request messages its own Map-Records. This mechanism is meant to 646 reduce the delay in mapping distribution since mapping information is 647 provided in the Map-Request message. 649 Furthermore, appending Map-Records to Map-Request messages represents 650 a major security risk since an off-path attacker could generate a 651 (spoofed or not) Map-Request message and include in the Map-Reply 652 portion of the message mapping for EID prefixes that it does not 653 serve. This could lead to various types of redirection and denial of 654 service attacks. An xTR should not process the Map-Records 655 information that it receives in a Map-Request message. 657 6.2. Attacks with Map-Reply messages 659 In this section we analyze the attacks that could occur when an off- 660 path attacker sends directly Map-Reply messages to ETRs without using 661 one of the proposed LISP mapping systems. 663 There are two different types of Map-Reply messages: 665 Positive Map-Reply: These messages contain a Map-Record binding an 666 EID-Prefix to one or more RLOCs. 668 Negative Map-Reply: These messages contain a Map-Record for an EID- 669 Prefix with an empty locator-set and specifying an action, 670 which may be either Drop, Natively forward, or Send Map- 671 Request. 673 Positive Map-Reply messages are used to map EID-Prefixes onto RLOCs. 674 Negative Map-Reply messages are used to support PTR and interconnect 675 the LISP Internet with the legacy Internet. 677 Most of the security of the Map-Reply messages depends on the 64 bits 678 nonce that is included in a Map-Request and returned in the Map- 679 Reply. An ETR must never accept a Map-Reply message whose nonce does 680 not match one of the pending Map-Request messages. If an ETR does 681 not accept Map-Reply messages with an invalid nonce, the risk of 682 attack is acceptable given the size of the nonce (64 bits). 684 Note, however, that the nonce only confirms that the Map-Reply was 685 sent by the ETR that received the Map-Request. It does not validate 686 the content of the Map-Reply message. 688 In addition, an attacker can perform EID-to-RLOC Cache overflow 689 attack by de-aggregating (i.e., splitting an EID prefix into 690 artificially smaller EID prefixes) either positive or negative 691 mappings. 693 6.3. Gleaning Attacks 695 A third type of attack involves the gleaning mechanism proposed in 696 [I-D.ietf-lisp] and discussed in [Saucez09]. In order to reduce the 697 time required to obtain a mapping, [I-D.ietf-lisp] allows an ITR to 698 learn a mapping from the LISP data encapsulated packets and the Map- 699 Request packets that it receives. LISP data encapsulated packet 700 contains a source RLOC, destination RLOC, source EID and destination 701 EID. When an ITR receives a data encapsulated packet coming from a 702 source EID for which it does not already know a mapping, it may 703 insert the mapping between the source RLOC and the source EID in its 704 EID-to-RLOC Cache. Gleaning can also be used when an ITR receives a 705 Map-Request as the Map-Request also contains a source EID address and 706 a source RLOC. Once a gleaned entry has been added to the EID-to- 707 RLOC cache, the LISP ITR sends a Map-Request to retrieve the mapping 708 for the gleaned EID from the mapping system. [I-D.ietf-lisp] 709 recommends storing the gleaned entries for only a few seconds. 711 The first risk of gleaning is the ability to temporarily hijack an 712 identity. Consider an off-path attacker that wants to temporarily 713 hijack host HA's identity and send packets to host HB with host HA's 714 identity. If the xTRs that serve host HB do not store a mapping for 715 host HA, a non-spoofing off-path attacker (NSA) could send a LISP 716 encapsulated data packet to LR3 or LR4. The ETR will store the 717 gleaned entry and use it to return the packets sent by host HB to the 718 attacker. In parallel, the ETR will send a Map-Request to retrieve 719 the mapping for HA. During a few seconds or until the reception of 720 the Map-Reply, host HB will exchange packets with the attacker that 721 has hijacked HA's identity. Note that the attacker could in parallel 722 send lots of Map-Requests or lots of LISP data encapsulated packets 723 with random sources to force the xTR that is responsible for host HA 724 to send lots of Map-Request messages in order to force it to exceed 725 its rate limit for control plane messages. This could further delay 726 the arrival of the Map-Reply message on the requesting ETR. 728 Gleaning also introduces the possibility of a man-in-the-middle 729 attack. Consider an off-path attacker that knows that hosts HA and 730 HB that resides in different sites will exchange information at time 731 t. An off-path attacker could use this knowledge to launch a man-in- 732 the-middle attack if the xTRs that serve the two hosts do not have 733 mapping for the other EID. For this, the attacker sends to LR1 734 (resp. LR3) a LISP data encapsulated packet whose source RLOC is its 735 IP address and contains an IP packet whose source is set to HB (resp. 736 HA). The attacker chooses a packet that will not trigger an answer, 737 for example the last part of a fragmented packet. Upon reception of 738 these packets, LR1 and LR3 install gleaned entries that point to the 739 attacker. As explained above, the attacker could, at the same time, 740 send lots of packets to LR1 and LR3 to force them to exhaust their 741 control plane rate limit. This will extend the duration of the 742 gleaned entry. If host HA establishes a flow with host HB at that 743 time, the packets that they exchange will first pass through the 744 attacker. 746 In both cases, the attack only lasts for a few seconds (unless the 747 attacker is able to exhaust the rate limitation). However it should 748 be noted that today a large amount of packets might be exchanged 749 during even a small fraction of time. 751 7. Threats concerning Interworking 753 [I-D.ietf-lisp-interworking] defines two network elements to allow 754 LISP and non-LISP sites to communicate, namely the Proxy-ITR and the 755 Proxy-ETR. The Proxy-ITR encapsulates traffic from non-LISP sites in 756 order to forward it toward LISP sites, while the Proxy-ETR 757 decapsulates traffic arriving from LISP sites in order to forward it 758 toward non-LISP sites. For these elements some of the attack based 759 on the LISP specific header are not possible, for the simple reason 760 that some of the fields cannot be used due to the unidirectional 761 nature of the traffic. 763 The Proxy-ITR has functionalities similar to the ITR, however, its 764 main purpose is to encapsulate packets arriving from the DFZ in order 765 to reach LISP sites. This means that it is no bound to any 766 particular EID-Prefix, hence no mapping exists and no mapping can be 767 configured in the EID-to-RLOC Database. This means that the Proxy- 768 ITR element itself is not able to check whether or not the arriving 769 traffic has the right to be encapsulated or not. To limit such an 770 issue it is recommended to use the current practice based on 771 firewalls and ACLs on the machine running the Proxy-ITR service. On 772 the other side, the Proxy-ITR is meant to encapsulate only packets 773 that are destined to one of the LISP sites it is serving. This is 774 the case for instance for a service provider selling Proxy-ITR 775 services. For this purpose a static EID-to-RLOC Cache can be 776 configured in order to encapsulate only valid packets. In case of a 777 cache-miss no Map-Request needs to be sent and the packet can be 778 silently dropped. 780 The Proxy-ETR has functionalities similar to the ETR, however, its 781 main purpose is to inject un-encapsulated packet in the DFZ in order 782 to reach non-LISP-Sites. This means that since there is no specific 783 EID-Prefix downstream, it has no EID-to-RLOC Database that can be 784 used to check whether or not the destination EID is part of its 785 domain. In order to avoid for the Proxy-ETR to be used as relay in a 786 DoS attack it is preferable to configure the EID-to-RLOC Cache with 787 static entries used to check if an encapsulated packet coming from a 788 specific RLOC and having a specific source EID is actually allowed to 789 transit through the Proxy-ETR. This is also important for services 790 provider selling Proxy-ETR service to actually process only packets 791 arriving from its customers. However, in case of cache-miss no Map- 792 Request needs to be sent, rather the packet can be silently dropped 793 since it is not originating from a valid site. The same drop policy 794 should be used for packets with an invalid source RLOC or a valid 795 source RLOC but an invalid EID. 797 8. Threats with Malicious xTRs 799 In this section, we discuss the threats that could be caused by 800 malicious xTRs. We consider the reference environment below where 801 EL1 is a malicious or compromised xTR. This malicious xTR serves a 802 set of hosts that includes HC. The other xTRs and hosts in this 803 network play the same role as in the reference environment described 804 in Section 4. 806 +-----+ 807 | HA | 808 +-----+ 809 | EID: HA 810 | 811 ----------------- 812 | | 813 +-----+ +-----+ 814 | LR1 | | LR2 | 815 +-----+ +-----+ 816 | | 817 | | 818 +-----+ +-----+ 819 |ISP1 | |ISP2 | 820 +-----+ +-----+ 821 | | 822 +----------------+ +-----+ | 823 | |-----| EL1 |--| 824 | | +-----+ | 825 | Internet | | +-----+ 826 | | |--| HC | 827 | | | +-----+ 828 +----------------+ EID: HC 829 | | 830 +-----+ +-----+ 831 | LR3 | | LR4 | 832 +-----+ +-----+ 833 | | 834 ------------------- 835 | 836 | EID: HB 837 +-----+ 838 | HB | 839 +-----+ 841 Figure 2: Malicious xTRs' Reference Environment 843 Malicious xTRs are probably the most serious threat to the LISP 844 control plane from a security viewpoint. To understand the problem, 845 let us consider the following scenario. Host HC and HB exchange 846 packets with host HA. As all these hosts reside in LISP sites, LR1 847 and LR2 store mappings for HB and HC. Thus, these xTRs may need to 848 exchange LISP control plane packets with EL1, e.g., to perform 849 reachability tests or to refresh expired mappings (e.g., if HC's 850 mapping has a small TTL). 852 A first threat against the LISP control plane is when EL1 replies to 853 a legitimate Map-Request message sent by LR1 or LR2 with a Map-Reply 854 message that contains an EID-Prefix that is larger than the prefix 855 owned by the site attached to EL1. For instance if the prefix owned 856 by EL1 is 192.0.2.0/25 but the Map-Reply contain a mapping for 857 192.0.2.0/24. This could allow EL1 to attract packets destined to 858 other EIDs than the EIDs that are attached to EL1. This attack is 859 called an "overclaiming" attack. 861 Overclaiming attack can be combined with de-aggregation to succeed a 862 LISP Cache poisoning attack and prefix hijacking. For example, if 863 the EID prefix of the attacker is 192.0.2.0/25, it cannot provide a 864 mapping for the EID prefix 192.0.2.128/25 (i.e., it cannot hijack the 865 prefix). However, since a Map-Reply can contain several map records, 866 it is possible to hijack such a prefix by providing as well a mapping 867 for it. To this end, the attacker can send a Map-Reply with an EID 868 prefix that covers at the same time the requested EID and the 869 hijacked target prefix. Continuing the previous example, if the 870 requested mapping is for EID 192.0.2.1, and the target hijack prefix 871 is 192.0.2.128/25, the Map-Reply will contain a map record for 872 192.0.2.0/24 and a map record for 192.0.2.128/25. Such a reply is 873 considered legitimate according to the requested EID, while the map 874 record of the hijacked prefix may lead to traffic redirection/ 875 disruption and ITR's Cache poisoning. 877 Another variant of the overclaiming attack is a Denial of Service 878 attack by sending a Negative Map-Reply message for a larger prefix 879 without any locator and with the Drop action. Such a Negative Map- 880 Reply indicates that the ETR that receives it should discard all 881 packets. 883 The current LISP specification briefly discusses the overclaiming 884 problem [I-D.ietf-lisp], but does not propose any specific solution 885 to solve the problem. Nevertheless, [I-D.ietf-lisp-sec] proposes a 886 solution to protect LISP against overclaiming attacks under the 887 assumption that the mapping system can be trusted. 889 Another concern with malicious xTRs is the possibility of Denial of 890 Service attacks. A first attack is the flooding attack that was 891 described in [I-D.bagnulo-lisp-threat]. This attack allows a 892 malicious xTR to redirect traffic to a victim. The malicious xTR 893 first defines a mapping for HC with two RLOCs: its own RLOC (EL1) and 894 the RLOC of the victim (e.g., LR3). The victim's RLOC is set as 895 unreachable in the mapping. HC starts a large download from host HA. 896 Once the download starts, the malicious xTR updates its Locator 897 Status Bits, changes the mapping's version number or sets the SMR bit 898 such that LR1 updates its EID-to-RLOC Cache to send all packets 899 destined to HC to the victim's RLOC. Instead of downloading from HA, 900 the attacker could also send packets that trigger a response (e.g., 901 ICMP, TCP SYN, DNS request, ...) to HA. HA would then send its 902 response and its xTR would forward it to the victim's RLOC. 904 An important point to note about this flooding attack is that it 905 reveals a limitation of the LISP architecture. A LISP ITR relies on 906 the received mapping and possible reachability information to select 907 the RLOC of the ETR that it uses to reach a given EID or block of 908 EIDs. However, if the ITR made a mistake, e.g., due to 909 misconfiguration, wrong implementation, or other types of errors and 910 has chosen a RLOC that does not serve the destination EID, there is 911 no easy way for the LISP ETR to inform the ITR of its mistake. A 912 possible solution is to enforce an ETR to perform a reachability test 913 with the selected ITR as soon as there is LISP encapsulated traffic 914 between the two. 916 Note that the attacks discussed in this section are for documentation 917 purpose only. Malicious xTRs are either somehow directly deployed by 918 attackers or the result of attackers gaining privileged access to 919 existing xTRs. As such, it is out of the scope of LISP to propose 920 any mechanism to protect routers or to avoid their deployments with 921 malicious intentions. 923 9. Security of the Proposed Mapping Systems 925 9.1. LISP+ALT 927 One of the assumptions in [I-D.ietf-lisp] is that the mapping system 928 is more secure than sending Map-Request and Map-Reply messages 929 directly. We analyze this assumption in this section by analyzing 930 the security of the ALT mapping system. 932 The ALT mapping system is basically a manually configured overlay of 933 GRE tunnels between ALT routers. BGP sessions are established 934 between ALT routers that are connected through such tunnels. An ALT 935 router advertises the EID prefixes that it serves over its BGP 936 sessions with neighboring ALT routers and the EID-Prefixes that it 937 has learned from neighboring ALT routers. 939 The ALT mapping system is in fact a discovery system that allows any 940 ALT router to discover the ALT router that is responsible for a given 941 EID-Prefix. To obtain a mapping from the ALT system, an ITR sends a 942 packet containing a Map-Request on the overlay. This Map-Request is 943 sent inside a packet whose destination is the requested EID. The 944 Map-Request is routed on the overlay until it reaches the ALT router 945 that advertised initially the prefix that contains the requested EID. 946 This ALT router then replies directly by sending a Map-Reply to the 947 RLOC of the requesting ITR. 949 The security of the ALT mapping system depends on many factors, 950 including: 952 o The security of the intermediate ALT routers. 954 o The validity of the BGP advertisements sent on the ALT overlay. 956 Unfortunately, experience with BGP on the global Internet has shown 957 that BGP is subject to various types of misconfiguration problems and 958 security attacks. The SIDR working group is developing a more secure 959 inter-domain routing architecture to solve this problem ([RFC6480]). 961 The security of the intermediate ALT routers is another concern. A 962 malicious intermediate ALT router could manipulate the received BGP 963 advertisements and also answer to received Map-Requests without 964 forwarding them to their final destination on the overlay. This 965 could lead to various types of redirection attacks. Note that in 966 contrast with a regular IP router that could also manipulate in 967 transit packets, when a malicious or compromised ALT router replies 968 to a Map-Request, it can redirect legitimate traffic for a long 969 period of time by sending an invalid Map-Reply message. Thus, the 970 impact of a malicious ALT router could be much more severe than a 971 malicious router in today's Internet. 973 9.2. LISP-DDT 975 The LISP Delegated Database Tree (LISP-DDT) mapping system is 976 proposed as an alternative for LISP+ALT [I-D.fuller-lisp-ddt]. LISP- 977 DDT is a hierarchical distributed database for EID-to-RLOC mappings. 978 Each DDT node is configured with an EID prefix it is authoritative 979 for, as well as the RLOC addresses and EID prefixes of the LISP-DDT 980 nodes that are authoritative for more specific EID prefix. In LISP- 981 DDT, mappings are retrieved iteratively. A Map Resolver that needs 982 to locate a mapping traverses the tree of DDT nodes contacting them 983 one after another until the leaf of the DDT tree that is 984 authoritative for the longest matching EID prefix for the mapping's 985 EID is reached. The Map Resolver traverses the hierarchy of LISP-DDT 986 nodes by sending Map-Requests, with the LISP-DDT-originated bit set, 987 to LISP-DDT nodes. The Map Resolver first contacts the root of the 988 hierarchy. When a LISP-DDT node receives a Map-Request, it replies 989 to the Map Resolver with a Map-Referral that contains the list of the 990 locators of its children that are authoritative of a prefix that 991 covers the EID in the Map-Request. The Map Resolver then contacts 992 one of these children that will return, at its turn, a Map-Referral. 993 This procedure is iteratively executed until a Map-Referral marked 994 with the done flag is received. The locators that appear in a 995 referral with the done flag are those of the authoritative ETRs for 996 the EID in the Map-Request. At that moment, the Map Resolver falls 997 back to its normal behavior and sends a Map-Request to the ETR in 998 order for the ITR to obtain the mapping. It is worth to mention that 999 the Map Resolver can cache the referrals to avoid traversing all the 1000 whole hierarchy for all mapping retrievals. 1002 The operation in LISP-DDT is different from ALT and thus it does not 1003 present the same threats as LISP+ALT. As a first difference, LISP- 1004 DDT natively includes security specification providing data origin 1005 authentication, data integrity protection and secure EID prefix 1006 delegation. Hence, these aspects are no further explored in this 1007 document. 1009 However, threats exist for LISP-DDT as well. For instance, a DoS 1010 attack can be performed on the mapping infrastructure by asking to 1011 retrieve a large amount of mappings at the same time, hence, the 1012 importance of carefully dimensioning the topology of the DDT 1013 hierarchy. 1015 If an attacker manages to compromise a LISP-DDT node it can send fake 1016 referrals to the Map Resolver and then control the mappings delivered 1017 to the ITRs. Furthermore, the effects of such an attack can be 1018 longer than the attack itself if the Map Resolver caches the 1019 referrals. 1021 10. Threats concerning LISP-MS 1023 LISP-MS ([I-D.ietf-lisp-ms] specifies two network elements, namely 1024 the Map Server and the Map Resolver, that are meant to be used by 1025 xTRs to access the mapping system. The advantage is clearly the fact 1026 that even if the mapping system changes in time xTRs do not need to 1027 change anything since they deal only with Map Servers and Map 1028 Resolvers. This includes the security aspects, since no change in 1029 the local security policies is needed. 1031 10.1. Map Server 1033 Map Server is used to dispatch Map-Request coming from the mapping 1034 system to ETRs that are authoritative for the EID in the request. To 1035 this end it is necessary that ETRs register their mappings to the Map 1036 Server. This allows the Map Server to know toward which ETR to 1037 forward Map-Requests and also to announce the EID-prefixes of the 1038 registered mappings in the mapping system. 1040 LISP uses a shared key approach in order to protect the Map Server 1041 and grant registration rights only to ETRs that have a valid key. 1042 Shared key must be used to protect both the registration message and 1043 the Map-Notify message when used. The mechanism used to share the 1044 key between a Map Server and an ETRs must be secured to avoid that a 1045 malicious nodes catch the key and uses it to send forged Map-Register 1046 message to the Map Server. A forged Map-Register message can be use 1047 to attract Map-Request and thus provide invalid Map-Replies or the 1048 redirect Map-Requests to a target to mount a DoS attack. 1050 More subtle attacks can be carried out only in the case of malicious 1051 ETRs. A malicious ETR can register an invalid RLOC to divert Map- 1052 Requests to a target ETR and succeed a DoS attack on it. To avoid 1053 this kind of attack, the Map Server must check that the registered 1054 RLOCs belong to ETRs authoritative for the registered EID prefix. 1055 Such check can be done by sending and explicit Map-Request for the 1056 EID to the ETRs in the mapping and check that replies with a Map- 1057 Reply. If the ETRs return a valid Map-Reply, the RLOC belongs to an 1058 authoritative ETR. Note that this does not protect against malicious 1059 ETRs that create forged Map-Replies. Stronger techniques for RLOC 1060 check are presented in [I-D.saucez-lisp-mapping-security]. 1062 Similarly to the previous case, a malicious ETR can register an 1063 invalid EID-prefix to attract Map-Requests or to redirect them to a 1064 target to mount a DoS attack. To avoid this kind of attack, the Map 1065 Server must check that the prefixes registered by an ETR belong to 1066 that ETR. One method could be to manually configure EID-prefix 1067 ranges that can be announced by ETRs. 1068 [I-D.saucez-lisp-mapping-security] present alternative techniques to 1069 verify the prefix claimed by an ETR. 1071 10.2. Map Resolver 1073 Map Resolvers receive Map-Requests, typically from ITRs, and use the 1074 mapping system to find a mapping for the EID in the Map-Request. It 1075 can work in two modes: 1077 Non-Caching Mode: The resolver just forwards the Map-Request to the 1078 mapping system, which will take care of delivering the request 1079 to an authoritative ETR. The latter will send back a Map-Reply 1080 directly to the ITR that has originally issued the request. 1082 Caching Mode: The resolver will generate a new Map-Request and send 1083 it to the mapping system. In this way it will receive the 1084 corresponding reply, store a local copy in a cache, and send 1085 back a reply to the original requester. Since all requested 1086 mappings are locally cached, before actually making a request 1087 to the mapping system it performs a lookup in the local cache 1088 and in case of an hit, it send back a reply without querying 1089 the mapping system. 1091 In its basic mode, i.e., non-caching mode, the Map Resolver does not 1092 keep state, hence, the only direct form of attack is a DoS attack, 1093 where an attacker (or a group of attackers) can try to exhaust 1094 computational power by flooding the resolver with requests. Common 1095 filtering techniques and BCP against DoS attacks can be applied in 1096 this case. 1098 Nonetheless, attackers can use resolvers as relay for DoS attacks 1099 against xTRs. An off-path spoofing attacker can generate a high load 1100 of requests to a set of resolvers, hence distributing the load in 1101 order to avoid to be blocked. All this requests can use a specific 1102 EID that makes all the requests to be forwarded to a specific ETR, 1103 which, as a result, will be victim of a DDoS attack. Similarly, the 1104 attacker can use a spoofed source address making all the replies to 1105 converge to one single ITR, which, as a result, will be victim of a 1106 DDoS attack. Such scenarios are not specific to LISP, but rather a 1107 common problem of every query infrastructure, hence the same BCP can 1108 be applied in order to limit the attacks. 1110 When functioning in caching-mode, the resolver will use the same type 1111 of cache than ITRs. Due to its similarity with the ITRs' cache the 1112 analysis provided in Section 5.2 holds also in this case. However, 1113 an important difference exists: this cache is not used for packet 1114 encapsulation but only for quick replies when new requests arrive. 1115 Therefore, as the caching-mode is only an optimization, the attacks 1116 that aim at filling the Map Resolver cache have a less severe impact 1117 on the traffic. 1119 When Map Resolvers are used as front-end of the LIS-DDT mapping 1120 system they may be exposed to another variant of DoS. Indeed, the 1121 iterative operation of the Map Resolver on the DDT hierarchy implies 1122 that it has to maintain state about the ITR that requested the 1123 mapping, this in order to send the final Map-Request to the ETR on 1124 behalf of the ITR. An attacker might leverage on this to fill the 1125 Map Resolver memory and then cause a DoS. 1127 The question may arise on whether a Kaminsky-like attack is possible 1128 for an off-path attacker against ITRs sending requests to a certain 1129 resolver. The 64-bits nonce present in every message has been 1130 introduced in the LISP specification to avoid such kind of attack. 1131 There has been discussion within the LISP Working Group on the 1132 optimal size of the nonce, and it seems that 64-bits provides 1133 sufficient protection. 1135 A possible way to limit the above-described attacks is to introduce 1136 strong identification in the Map-Request/Map-Reply by using the 1137 Encapsulated Control Message with authentication enabled. 1139 11. Suggested Recommendations 1141 To mitigate the impact of attacks against LISP, the following 1142 recommendations should be followed. 1144 First, the use of some form of filtering can help in avoid or at 1145 least mitigate some types of attacks. 1147 o On ETRs, packets should be decapsulated only if the destination 1148 EID is effectively part of the EID-Prefix downstream the ETR. 1149 Further, still on ETRs, packets should be decapsulated only if a 1150 mapping for the source EID is present in the EID-to-RLOC Cache and 1151 has been obtained through the mapping system (not gleaned). 1153 o On ITRs, packets should be encapsulated only if the source EID is 1154 effectively part of the EID-Prefix downstream the ITR. Further, 1155 still on ITRs, packets should be encapsulated only if a mapping 1156 obtained from the mapping system is present in the EID-to-RLOC 1157 Cache (no Data-Probing). 1159 Note that this filtering, since complete mappings need to be 1160 installed in both ITRs and ETRs, can introduce higher connection 1161 setup latency and hence potentially more packets drops due to the 1162 lack of mappings in the EID-to-RLOC Cache. 1164 While the gleaning mechanism allows starting encapsulating packets to 1165 a certain EID in parallel with the Map-Request to obtain a mapping 1166 when a new flow is established, it creates important security risks 1167 since it allows attackers to perform identity hijacks. Although the 1168 duration of these identity hijacks is limited (except the case of 1169 rate limitation exhaustion), their impact can be severe. A first 1170 option would be to disable gleaning until the security concerns are 1171 solved. A second option would be to strictly limit the number of 1172 packets that can be forwarded via a gleaned entry. Overall the 1173 benefits of gleaning, i.e., avoiding the loss of the first packet of 1174 a flow, seems very small compared to the associated security risks. 1175 Furthermore, measurements performed in data centers show that today's 1176 Internet often operate with packet loss ratio of 1 or 2 percentage 1177 ([Chu]). These packet loss ratios are probably already orders of 1178 magnitude larger than the improvement provided by the gleaning 1179 mechanism. 1181 With the increasing deployment of spoofing prevention techniques such 1182 as [RFC3704] or SAVI [SAVI], it can be expected that attackers will 1183 become less capable of sending packets with a spoofed source address. 1184 To prevent packet injection attacks from non-spoofing attackers 1185 (NSA), ETRs should always verify that the source RLOC of each 1186 received LISP data encapsulated packet corresponds to one of the 1187 RLOCs listed in the mappings for the source EID found in the inner 1188 packet. An alternative could be to use existing IPSec techniques 1189 [RFC4301] and when necessary including perhaps [RFC5386] to establish 1190 an authenticated tunnel between the ITR and the ETR. 1192 [I-D.ietf-lisp] recommends to rate limit the control messages that 1193 are sent by an xTR. This limit is important to deal with denial of 1194 service attacks. However, a strict limit, e.g., implemented with a 1195 token bucket, on all the Map-Request and Map-Reply messages sent by 1196 an xTR is not sufficient. An xTR should distinguish between 1197 different types of control plane packets: 1199 1. The Map-Request messages that it sends to refresh expired mapping 1200 information. 1202 2. The Map-Request messages that it sends to obtain mapping 1203 information because one of the served hosts tried to contact an 1204 external EID. 1206 3. The Map-Request messages that it sends as reachability probes. 1208 4. The Map-Reply messages that it sends as response to reachability 1209 probes. 1211 5. The Map-Request messages that it sends to support gleaning. 1213 These control plane messages are used for different purposes. Fixing 1214 a global rate limit for all control plane messages increases the risk 1215 of Denial of Service attacks if a single type of control plane 1216 message can exceed the configured limit. This risk could be 1217 mitigated by either specifying a rate for each of the five types of 1218 control plane messages. Another option could be to define a maximum 1219 rate for all control plane messages, and prioritize the control plane 1220 messages according to the list above (with the highest priority for 1221 message type 1). 1223 In [I-D.ietf-lisp], there is no mechanism that allows an xTR to 1224 verify the validity of the content a Map-Reply message that it 1225 receives. Besides the attacks discussed earlier in the document, a 1226 time-shifted attack where an attacker is able to modify the content 1227 of a Map-Reply message but then needs to move off-path could also 1228 create redirection attacks. The nonce only allows an xTR to verify 1229 that a Map-Reply responds to a previously sent Map-Request message. 1230 In order to allow verifying the validity and integrity of bindings 1231 between EID-Prefixes and their RLOCS solutions proposed in 1232 [I-D.saucez-lisp-mapping-security] and [I-D.ietf-lisp-sec] should be 1233 deployed. Having such kind of mechanisms would allow ITRs to ignore 1234 non-verified mappings, thus increasing security. 1236 Finally, there is also the risk of Denial of Service attack against 1237 the EID-to-RLOC Cache. We have discussed these attacks when 1238 considering external attackers with, e.g., the gleaning mechanism and 1239 in Section 5.2. If an ITR has a limited EID-to-RLOC Cache, a 1240 malicious or compromised host residing in the site that it serves 1241 could generate packets to random destinations to force the ITR to 1242 issue a large number of Map-Requests whose answers could fill its 1243 cache. Faced with such misbehaving hosts, LISP ITR should be able to 1244 limit the percent of Map-Requests that it sends for a given source 1245 EID. 1247 In order to mitigate flooding attacks it would be worth consider 1248 developing secure mechanisms to allow an ETR to indicate to an ITR 1249 that it does not serve a particular EID or block of EIDs. 1251 12. IANA Considerations 1253 This document makes no request to IANA. 1255 13. Security Considerations 1257 Security considerations are the core of this document and do not need 1258 to be further discussed in this section. 1260 14. Acknowledgments 1262 This document builds upon the draft of Marcelo Bagnulo 1263 ([I-D.bagnulo-lisp-threat]), where the flooding attack and the 1264 reference environment were first described. 1266 We would like to thank Jeff Wheeler for his comments. 1268 This work has been partially supported by the INFSO-ICT-216372 1269 TRILOGY Project (www.trilogy-project.org). 1271 15. References 1273 15.1. Normative References 1275 [I-D.fuller-lisp-ddt] 1276 Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP 1277 Delegated Database Tree", draft-fuller-lisp-ddt-04 (work 1278 in progress), September 2012. 1280 [I-D.ietf-lisp] 1281 Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 1282 "Locator/ID Separation Protocol (LISP)", 1283 draft-ietf-lisp-23 (work in progress), May 2012. 1285 [I-D.ietf-lisp-alt] 1286 Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP 1287 Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-10 1288 (work in progress), December 2011. 1290 [I-D.ietf-lisp-interworking] 1291 Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 1292 "Interworking LISP with IPv4 and IPv6", 1293 draft-ietf-lisp-interworking-06 (work in progress), 1294 March 2012. 1296 [I-D.ietf-lisp-map-versioning] 1297 Iannone, L., Saucez, D., and O. Bonaventure, "LISP Map- 1298 Versioning", draft-ietf-lisp-map-versioning-09 (work in 1299 progress), March 2012. 1301 [I-D.ietf-lisp-ms] 1302 Fuller, V. and D. Farinacci, "LISP Map Server Interface", 1303 draft-ietf-lisp-ms-16 (work in progress), March 2012. 1305 15.2. Informative References 1307 [Chu] Jerry Chu, H., "Tuning TCP Parameters for the 21st 1308 Century", 75th IETF, Stockholm, July 2009, 1309 . 1311 [I-D.bagnulo-lisp-threat] 1312 Bagnulo, M., "Preliminary LISP Threat Analysis", 1313 draft-bagnulo-lisp-threat-01 (work in progress), 1314 July 2007. 1316 [I-D.ietf-lisp-sec] 1317 Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D., 1318 and O. Bonaventure, "LISP-Security (LISP-SEC)", 1319 draft-ietf-lisp-sec-04 (work in progress), October 2012. 1321 [I-D.ietf-tcpm-tcp-security] 1322 Gont, F., "Survey of Security Hardening Methods for 1323 Transmission Control Protocol (TCP) Implementations", 1324 draft-ietf-tcpm-tcp-security-03 (work in progress), 1325 March 2012. 1327 [I-D.lear-lisp-nerd] 1328 Lear, E., "NERD: A Not-so-novel EID to RLOC Database", 1329 draft-lear-lisp-nerd-09 (work in progress), April 2012. 1331 [I-D.meyer-lisp-cons] 1332 Brim, S., "LISP-CONS: A Content distribution Overlay 1333 Network Service for LISP", draft-meyer-lisp-cons-04 (work 1334 in progress), April 2008. 1336 [I-D.saucez-lisp-mapping-security] 1337 Saucez, D. and O. Bonaventure, "Securing LISP Mapping 1338 replies", draft-saucez-lisp-mapping-security-00 (work in 1339 progress), February 2011. 1341 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 1342 Networks", BCP 84, RFC 3704, March 2004. 1344 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1345 Internet Protocol", RFC 4301, December 2005. 1347 [RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing 1348 Security: An Unauthenticated Mode of IPsec", RFC 5386, 1349 November 2008. 1351 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support 1352 Secure Internet Routing", RFC 6480, February 2012. 1354 [SAVI] IETF, "Source Address Validation Improvements Working 1355 Group", . 1357 [Saucez09] 1358 Saucez, D. and L. Iannone, "How to mitigate the effect of 1359 scans on mapping systems", Submitted to the Trilogy 1360 Summer School on Future Internet. 1362 Appendix A. Document Change Log 1364 o Version 03 Posted October 2012. 1366 * Dropped Reference to RFC 2119 notation because it is not 1367 actually used in the document. 1369 * Deleted future plans section. 1371 * Updated References 1373 * Deleted/Modified sentences referring to the early status of the 1374 LISP WG and documents at the time of writing early versions of 1375 the document. 1377 * Further editorial polishing. 1379 * Fixed all ID nits. 1381 o Version 02 Posted September 2012. 1383 * Added a new attack that combines overclaiming and de- 1384 aggregation (see Section 6.2). 1386 * Editorial polishing. 1388 o Version 01 Posted February 2012. 1390 * Added discussion on LISP-DDT in Section 9.2. 1392 o Version 00 Posted July 2011. 1394 * Added discussion on LISP-MS in Section 10. 1396 * Added discussion on Instance ID in Section 5.4. 1398 * Editorial polishing of the whole document. 1400 * Added "Change Log" appendix to keep track of main changes. 1402 * Renamed "draft-saucez-lisp-security-03.txt. 1404 Authors' Addresses 1406 Damien Saucez 1407 INRIA 1408 2004 route des Lucioles BP 93 1409 06902 Sophia Antipolis Cedex 1410 France 1412 Email: damien.saucez@inria.fr 1413 Luigi Iannone 1414 Telecom ParisTech 1415 23, Avenue d'Italie, CS 51327 1416 75214 PARIS Cedex 13 1417 France 1419 Email: luigi.iannone@telecom-paristech.fr 1421 Olivier Bonaventure 1422 Universite catholique de Louvain 1423 Place St. Barbe 2 1424 Louvain la Neuve 1425 Belgium 1427 Email: olivier.bonaventure@uclouvain.be