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