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