idnits 2.17.1
draft-ietf-lisp-threats-04.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 (February 25, 2013) is 4077 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301)
** Obsolete normative reference: RFC 6833 (Obsoleted by RFC 9301)
** Obsolete normative reference: RFC 6834 (Obsoleted by RFC 9302)
== Outdated reference: A later version (-09) exists of
draft-ietf-lisp-ddt-00
== Outdated reference: A later version (-29) exists of
draft-ietf-lisp-sec-04
Summary: 3 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: August 29, 2013 Telecom ParisTech
6 O. Bonaventure
7 Universite catholique de Louvain
8 February 25, 2013
10 LISP Threats Analysis
11 draft-ietf-lisp-threats-04.txt
13 Abstract
15 This document analyzes the potential threats against the security of
16 the Locator/Identifier Separation Protocol (LISP) if deployed in the
17 Internet. This document proposes a set of recommendations to
18 mitigate the identified security risks and keep a security level
19 equivalent to what is observed in the Internet today (i.e., without
20 LISP). By following the recommendations of this draft a LISP
21 deployment can achieve a security level that is comparable to the
22 existing Internet architecture.
24 Status of this Memo
26 This Internet-Draft is submitted in full conformance with the
27 provisions of BCP 78 and BCP 79.
29 Internet-Drafts are working documents of the Internet Engineering
30 Task Force (IETF). Note that other groups may also distribute
31 working documents as Internet-Drafts. The list of current Internet-
32 Drafts is at http://datatracker.ietf.org/drafts/current/.
34 Internet-Drafts are draft documents valid for a maximum of six months
35 and may be updated, replaced, or obsoleted by other documents at any
36 time. It is inappropriate to use Internet-Drafts as reference
37 material or to cite them other than as "work in progress."
39 This Internet-Draft will expire on August 29, 2013.
41 Copyright Notice
43 Copyright (c) 2013 IETF Trust and the persons identified as the
44 document authors. All rights reserved.
46 This document is subject to BCP 78 and the IETF Trust's Legal
47 Provisions Relating to IETF Documents
48 (http://trustee.ietf.org/license-info) in effect on the date of
49 publication of this document. Please review these documents
50 carefully, as they describe your rights and restrictions with respect
51 to this document. Code Components extracted from this document must
52 include Simplified BSD License text as described in Section 4.e of
53 the Trust Legal Provisions and are provided without warranty as
54 described in the Simplified BSD License.
56 Table of Contents
58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
59 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4
60 3. On-path Attackers . . . . . . . . . . . . . . . . . . . . . . 4
61 4. Off-Path Attackers: Reference Environment . . . . . . . . . . 5
62 5. Data-Plane Threats . . . . . . . . . . . . . . . . . . . . . . 6
63 5.1. EID-to-RLOC Database Threats . . . . . . . . . . . . . . . 7
64 5.2. EID-to-RLOC Cache Threats . . . . . . . . . . . . . . . . 7
65 5.2.1. EID-to-RLOC Cache poisoning . . . . . . . . . . . . . 7
66 5.2.2. EID-to-RLOC Cache overflow . . . . . . . . . . . . . . 9
67 5.3. Attacks not leveraging on the LISP header . . . . . . . . 10
68 5.4. Attacks leveraging on the LISP header . . . . . . . . . . 10
69 5.4.1. Attacks using the Locator Status Bits . . . . . . . . 10
70 5.4.2. Attacks using the Map-Version bit . . . . . . . . . . 12
71 5.4.3. Attacks using the Nonce-Present and the Echo-Nonce
72 bits . . . . . . . . . . . . . . . . . . . . . . . . . 13
73 5.4.4. Attacks using the Instance ID bits . . . . . . . . . . 14
74 6. Control Plane Threats . . . . . . . . . . . . . . . . . . . . 14
75 6.1. Attacks with Map-Request messages . . . . . . . . . . . . 14
76 6.2. Attacks with Map-Reply messages . . . . . . . . . . . . . 16
77 6.3. Gleaning Attacks . . . . . . . . . . . . . . . . . . . . . 17
78 7. Threats concerning Interworking . . . . . . . . . . . . . . . 18
79 8. Threats with Malicious xTRs . . . . . . . . . . . . . . . . . 19
80 9. Security of the Proposed Mapping Systems . . . . . . . . . . . 23
81 9.1. LISP+ALT . . . . . . . . . . . . . . . . . . . . . . . . . 23
82 9.2. LISP-DDT . . . . . . . . . . . . . . . . . . . . . . . . . 24
83 10. Threats concerning LISP-MS . . . . . . . . . . . . . . . . . . 25
84 10.1. Map Server . . . . . . . . . . . . . . . . . . . . . . . . 25
85 10.2. Map Resolver . . . . . . . . . . . . . . . . . . . . . . . 26
86 11. Security Recommendations . . . . . . . . . . . . . . . . . . . 28
87 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
88 13. Security Considerations . . . . . . . . . . . . . . . . . . . 30
89 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
90 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
91 15.1. Normative References . . . . . . . . . . . . . . . . . . . 31
92 15.2. Informative References . . . . . . . . . . . . . . . . . . 31
93 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 32
94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
96 1. Introduction
98 The Locator/ID Separation Protocol (LISP) is defined in [RFC6830].
99 The present document assesses the security level and identifies
100 security threats in the LISP specification if LISP is deployed in the
101 Internet (i.e., a public non-trustable environment). As a result of
102 the performed analysis, the document determines the severity of the
103 threats and proposes recommendations to reach the same level of
104 security in LISP than in Internet today (e.g., without LISP).
106 The document is composed of three main parts: the first discussing
107 the LISP data-plane; while the second discussing the LISP control-
108 plane. The final part summarizes the recommendations to prevent the
109 identified threats.
111 The LISP data-plane consists of LISP packet encapsulation,
112 decapsulation, and forwarding and includes the EID-to-RLOC Cache and
113 EID-to-RLOC Database data structures used to perform these
114 operations.
116 The LISP control-plane consists in the mapping distribution system,
117 which can be one of the mapping distribution systems proposed so far
118 (e.g., [RFC6830], [I-D.ietf-lisp-ddt], [RFC6836], [RFC6833],
119 [I-D.meyer-lisp-cons], and [RFC6837]), and the Map-Request, Map-
120 Reply, Map-Register, and Map-Notification messages.
122 This document does not consider all the possible uses of LISP as
123 discussed in [RFC6830]. The document focuses on LISP unicast,
124 including as well LISP Interworking [RFC6832], LISP-MS [RFC6833],
125 LISP Map-Versioning [RFC6834], and briefly considering the ALT
126 mapping system described in [RFC6836] and the Delegated Database Tree
127 mapping system described in [I-D.ietf-lisp-ddt]. The reading of
128 these documents is a prerequisite for understanding the present
129 document.
131 Unless otherwise stated, the document assumes a generic IP service
132 and does not discuss the difference, from a security viewpoint,
133 between using IPv4 or IPv6.
135 This document has identified several threats on LISP in the case of
136 public deployments. However, most of the threats can be prevented
137 with careful deployment and configuration. Moreover, several threats
138 are introduced by optimization techniques that can be deactivated in
139 public deployments of LISP without alteration of its functioning as
140 these techniques are designed for LISP deployments in private
141 trustable environments. Finally, this document has not identified
142 any threats that would require a change in the LISP protocol or
143 architecture.
145 2. Definition of Terms
147 Severity level: this document specifies the severity level of every
148 identified threat. We identified four severity levels for the
149 threats.
151 Level 0: the threat is not introduced by LISP and is equivalent to
152 what is encountered without LISP.
154 Level 1: the threat is introduced by LISP but can be neutralized by
155 configuration or deployment techniques, i.e., LISP protocol and
156 architecture does not need to be reconsidered for public
157 deployment.
159 Level 2: the threat is introduced by LISP but can be avoided by
160 deactivating the feature in public deployment.
162 Level 3: the threat is introduced by LISP and cannot be avoided
163 without changing the LISP specification or architecture.
165 The present document does not introduce any other new term, compared
166 to the main LISP specification. For a complete list of terms please
167 refer to [RFC6830].
169 3. On-path Attackers
171 On-path attackers are attackers that are able to capture and modify
172 all the packets exchanged between an Ingress Tunnel Router (ITR) and
173 an Egress Tunnel Router (ETR). To cope with such an attacker,
174 cryptographic techniques such as those used by IPSec ([RFC4301]) are
175 required. As with IP, LISP relies on higher layer cryptography to
176 secure packet payloads from on path attacks, so we do not consider
177 on-path attackers in this document.
179 Mobile IP has also considered time-shifted attacks from on-path
180 attackers. A time-shifted attack is an attack where the attacker is
181 temporarily on the path between two communicating hosts. While it is
182 on-path, the attacker sends specially crafted packets or modifies
183 packets exchanged by the communicating hosts in order to disturb the
184 packet flow (e.g., by performing a man in the middle attack). An
185 important issue for time-shifted attacks is the duration of the
186 attack once the attacker has left the path between the two
187 communicating hosts. We do not consider time-shifted attacks in this
188 document.
190 4. Off-Path Attackers: Reference Environment
192 Throughout this document we consider the reference environment shown
193 in the figure below. There are two hosts attached to LISP routers:
194 HA and HB. HA is attached to the two LISP xTRs LR1 and LR2, which in
195 turn are attached to two different ISPs. HB is attached to the two
196 LISP xTRs LR3 and LR4. HA and HB are the EIDs of the two hosts.
197 LR1, LR2, LR3, and LR4 are the RLOCs of the xTRs.
199 +-----+
200 | HA |
201 +-----+
202 | EID: HA
203 |
204 -----------------
205 | |
206 +-----+ +-----+
207 | LR1 | | LR2 |
208 +-----+ +-----+
209 | |
210 | |
211 +-----+ +-----+
212 |ISP1 | |ISP2 |
213 +-----+ +-----+
214 | |
215 +----------------+ +-----+
216 | |-----| SA |
217 | | +-----+
218 | Internet |
219 | | +-----+
220 | |-----| NSA |
221 +----------------+ +-----+
222 | |
223 +-----+ +-----+
224 | LR3 | | LR4 |
225 +-----+ +-----+
226 | |
227 -------------------
228 |
229 | EID: HB
230 +-----+
231 | HB |
232 +-----+
234 Figure 1: Reference Network
236 We consider two off-path attackers with different capabilities:
238 SA is an off-path attacker that is able to send spoofed packets,
239 i.e., packets with a different source IP address than its
240 assigned IP address. SA stands for Spoofing Attacker.
242 NSA is an off-path attacker that is only able to send packets whose
243 source address is its assigned IP address. NSA stands for Non
244 Spoofing Attacker.
246 It should be noted that with LISP, packet spoofing is slightly
247 different than in the current Internet. Generally the term "spoofed
248 packet" indicates a packet containing a source IP address that is not
249 the one of the actual originator of the packet. Since LISP uses
250 encapsulation, the spoofed address could be in the outer header as
251 well as in the inner header, this translates in two types of
252 spoofing:
254 EID Spoofing: the originator of the packet puts in it a spoofed EID.
255 The packet will be normally encapsulated by the ITR of the site
256 (or a PITR if the source site is not LISP enabled).
258 RLOC Spoofing: the originator of the packet generates directly a
259 LISP-encapsulated packet with a spoofed source RLOC.
261 Note that the two types of spoofing are not mutually exclusive,
262 rather all combinations are possible and could be used to perform
263 different kind of attacks.
265 In the reference environment, both SA and NSA attackers are capable
266 of sending LISP encapsulated data packets and LISP control packets.
267 This means that SA is able to perform both RLOC and EID spoofing
268 while NSA can only perform EID spoofing. They may also send other
269 types of IP packets such as ICMP messages. We assume that both
270 attackers can query the LISP mapping system (e.g., through a public
271 Map Resolver) to obtain the mappings for both HA and HB.
273 5. Data-Plane Threats
275 This section discusses threats and attacks related to the LISP data-
276 plane. More precisely, we discuss the operations of encapsulation,
277 decapsulation, and forwarding as well as the content of the EID-to-
278 RLOC Cache and EID-to-RLOC Database as specified in the original LISP
279 document ([RFC6830]).
281 We start considering the two main data structures of LISP, namely the
282 EID-to-RLOC Database and the EID-to-RLOC Cache. Then, we look at the
283 data plane attacks that can be performed by a spoofing off-path
284 attacker (SA) and discuss how they can be mitigated by LISP xTRs. In
285 this analysis, we assume that the LR1 and LR2 (resp. LR3 and LR4)
286 xTRs maintain an EID-to-RLOC Cache that contains the required mapping
287 entries to allow HA and HB to exchange packets.
289 5.1. EID-to-RLOC Database Threats
291 The EID-to-RLOC Database on each xTR maintains the set of mappings
292 related to the EID-Prefixes that are "behind" the xTR. Where
293 "behind" means that at least one of the xTR's globally visible IP
294 addresses is a RLOC for those EID-Prefixes.
296 As described in [RFC6830], the EID-to-RLOC Database content is
297 determined by configuration. This means that the only way to attack
298 this data structure is by gaining privileged access to the xTR. As
299 such, it is out of the scope of LISP to propose any mechanism to
300 protect routers and, hence, it is no further analyzed in this
301 document.
303 Severity level 0.
305 5.2. EID-to-RLOC Cache Threats
307 The EID-to-RLOC Cache (also called the Map-Cache) is the data
308 structure that stores a copy of the mappings retrieved from a remote
309 ETR's mapping database via the LISP control plane. Attacks against
310 this data structure could happen either when the mappings are first
311 installed in the cache (see also Section 6) or by corrupting
312 (poisoning) the mappings already present in the cache.
314 Severity level 2. The severity level of EID-to-RLOC Cache Threats
315 depends on the attack vector as described below.
317 5.2.1. EID-to-RLOC Cache poisoning
319 The content of the EID-to-RLOC Cache could be poisoned by spoofing
320 LISP encapsulated packets. Examples of EID-to-RLOC Cache poisoning
321 are:
323 Fake mapping: The cache contains entirely fake mappings that do not
324 originate from an authoritative mapping server. This could be
325 achieved either through gleaning as described in Section 6.3 or
326 by attacking the control-plane as described in Section 6.
328 EID Poisoning: The EID-Prefix in a specific mapping is not owned by
329 the originator of the entry. Similarly to the previous case,
330 this could be achieved either through gleaning as described in
331 Section 6.3 or by attacking the control-plane as described in
332 Section 6.
334 EID redirection/RLOC poisoning: The EID-Prefix in the mapping is not
335 bound to (located by) the set of RLOCs present in the mapping.
336 This could result in packets being redirected elsewhere,
337 eavesdropped, or even black-holed. Note that not necessarily
338 all RLOCs are fake/spoofed. The attack works also if only part
339 of the RLOCs, the highest priority ones, is compromised.
340 Again, this could be achieved either through the gleaning as
341 described in Section 6.3 or by attacking the control-plane as
342 described in Section 6.
344 Reachability poisoning: The reachability information stored in the
345 mapping could be poisoned, redirecting the packets to a subset
346 of the RLOCs (or even stopping it if locator status bits are
347 all set to 0). If reachability information is not verified
348 through the control-plane this attack could be achieved by
349 sending a spoofed packet with swapped or all locator status
350 bits reset. The same result could be obtained by attacking the
351 control-plane as described in Section 6. Depending on how the
352 RLOC reachability information is stored on the router, the
353 attack could impact only one mapping or all the mappings that
354 share the same RLOC.
356 Traffic Engineering information poisoning: The LISP protocol defines
357 two attributes associated to each RLOC in order to perform
358 inbound Traffic Engineering (TE), namely priority and weight.
359 By injecting fake TE attributes, the attacker is able to break
360 load balancing policies and concentrate all the traffic on a
361 single RLOC or put more load on a RLOC than what is expected,
362 creating congestion. It is even possible to block the traffic
363 if all the priorities are set to 255 (special value indicating
364 not to use the RLOC). Corrupting the TE attributes could be
365 achieved by attacking the control-plane as described in
366 Section 6.
368 Mapping TTL poisoning: The LISP protocol associates a Time-To-Live
369 to each mapping that, once expired, allows to delete a mapping
370 from the EID-to-RLOC Cache (or forces a Map-Request/Map-Reply
371 exchange to refresh it if still needed). By injecting fake TTL
372 values, an attacker could either shrink the EID-to-RLOC Cache
373 (using very short TTL), thus creating an excess of cache miss
374 causing a DoS on the mapping system, or it could increase the
375 size of the cache by putting very high TTL values, up to a
376 cache overflow (see Section 5.2.2). Corrupting the TTL could
377 be achieved by attacking the control-plane as described in
378 Section 6. Long TTL could be used in fake mappings to increase
379 attack duration.
381 Instance ID poisoning: The LISP protocol allows using a 24-bit
382 identifier to select the forwarding table to use on the
383 decapsulating ETR to forward the decapsulated packet. By
384 spoofing this attribute the attacker might cause traffic to be
385 either dropped or decapsulated and then placed into the
386 incorrect VRF at the destination ETR. Corrupting the Instance
387 ID attribute could be achieved by attacking the control-plane
388 as described in Section 6.
390 Map-Version poisoning: The LISP protocol offers the option to
391 associate a version number to mappings ([RFC6834]). The LISP
392 header can transport source and destination map-versions,
393 describing which version of the mapping have been used to
394 select the source and the destination RLOCs of the LISP
395 encapsulated packet. By spoofing this attribute the attacker
396 is able to trigger Map-Request on the receiving ETR.
397 Corrupting the Map-Version attribute could be achieved either
398 by attacking the control-plane as described in Section 6 or by
399 using spoofed packets as described in Section 5.4.2.
401 If the ITR's map-cache is compromised (likely via compromising the
402 LISP control-plane) it is possible that traffic in the data-plane may
403 be redirected (encapsulated to the wrong destination) a or dropped by
404 the ITR.
406 If data-plane redirection is of a critical concern, then deploying
407 some sort of IPSEC or TLS based security on a layer above LISP (just
408 like you would on top of IP) is recommended.
410 5.2.2. EID-to-RLOC Cache overflow
412 Depending on how the EID-to-RLOC Cache is managed (e.g., Least
413 Recently Used - LRU vs. Least Frequently Used - LFU) and depending on
414 its size, an attacker could try to fill the cache with fake mappings.
415 Once the cache is full, some mappings will be replaced by new fake
416 ones, causing traffic disruption.
418 This could be achieved either through gleaning as described in
419 Section 6.3 or by attacking the control-plane as described in
420 Section 6.
422 Another way to generate an EID-to-RLOC Cache overflow is by injecting
423 mapping with a fake and very large TTL value. In this case the cache
424 will keep a large amount of mappings ending with a completely full
425 cache. This type of attack could also be performed through the
426 control-plane.
428 5.3. Attacks not leveraging on the LISP header
430 We first consider an attacker that sends packets without exploiting
431 the LISP header, i.e., with the N, L, E, V, and I bits reset
432 ([RFC6830]).
434 To inject a packet in the HA-HB flow, a spoofing off-path attacker
435 (SA) could send a LISP encapsulated packet whose source is set to LR1
436 or LR2 and destination LR3 or LR4. The packet will reach HB as if
437 the packet was sent by host HA. This is not different from today's
438 Internet where a spoofing off-path attacker may inject data packets
439 in any flow. Several existing techniques could be used by hosts to
440 prevent such attacks from affecting established flows, e.g.,
441 [RFC4301] and [I-D.ietf-tcpm-tcp-security].
443 On the other hand, a non-spoofing off-path attacker (NSA) could only
444 send a packet whose source address is set to its assigned IP address.
445 The destination address of the encapsulated packet could be LR3 or
446 LR4. When the LISP ETR that serves HB receives the encapsulated
447 packet, it can consult its EID-to-RLOC Cache and verify that NSA is
448 not a valid source address for LISP encapsulated packets containing a
449 packet sent by HA. This verification is only possible if the ETR
450 already has a valid mapping for HA. Otherwise, and to avoid such
451 data packet injection attacks, the LISP ETR should reject the packet
452 and possibly query the mapping system to obtain a mapping for the
453 encapsulated source EID (HA).
455 Severity level 1: use well known anti-spoofing techniques and
456 configure ETRs to verify the that RLOCs and EIDs are consistent with
457 the entries in the EID-to-RLOC Cache.
459 5.4. Attacks leveraging on the LISP header
461 The main LISP document [RFC6830] defines several flags that modify
462 the interpretation of the LISP header in data packets. In this
463 section, we discuss how an off-path attacker could exploit this LISP
464 header.
466 Severity level 2. The severity level of attacks leveraging on the
467 LISP header depends on the attack vector as described below.
469 5.4.1. Attacks using the Locator Status Bits
471 When the L bit is set to 1, it indicates that the second 32-bits
472 longword of the LISP header contains the Locator Status Bits. In
473 this field, each bit position reflects the status of one of the RLOCs
474 mapped to the source EID found in the encapsulated packet. In
475 particular, a packet with the L bit set and all Locator Status Bits
476 set to zero indicates that none of the locators of the encapsulated
477 source EID are reachable. The reaction of a LISP ETR that receives
478 such a packet is not clearly described in [RFC6830].
480 A spoofing off-path attacker (SA) could send a data packet with the L
481 bit set to 1, all Locator Status Bits set to zero, a spoofed source
482 RLOC (e.g. LR1), destination LR3, and containing an encapsulated
483 packet whose source is HA. If LR3 blindly trusts the Locator Status
484 Bits of the received packet it will set LR1 and LR2 as unreachable,
485 possibly disrupting ongoing communication.
487 Locator Status Bits could be blindly trusted only in secure
488 environments. In the general unsecured Internet environment, the
489 safest practice for xTRs is to confirm the reachability change
490 through the control plane (e.g., RLOC probing). In the above
491 example, LR3 should note that something has changed in the Locator
492 Status Bits and query the mapping system (assuming it is trusted) in
493 order to confirm status of the RLOCs of the source EID.
495 A similar attack could occur by setting only one Locator Status Bit
496 to 1, e.g., the one that corresponds to the source RLOC of the
497 packet.
499 If a non-spoofing off-path attacker (NSA) sends a data packet with
500 the L bit set to 1 and all Locator Status Bits set to zero, this
501 packet will contain the source address of the attacker. Similarly as
502 in Section 5.3, if the xTR accepts the packet without checking the
503 EID-to-RLOC Cache for a mapping that binds the source EID and the
504 source RLOC of the received packet, then the same observation like
505 for the spoofing attacker (SA) apply with the difference that instead
506 of complete disruption, the traffic will flow through only one RLOC,
507 possibly resulting in a DoS attack.
509 Otherwise, if the xTR does make the check through the EID-to-RLOC
510 Cache, it should reject the packet because its source address is not
511 one of the addresses listed as RLOCs for the source EID.
512 Nevertheless, in this case a Map-Request should be sent, which could
513 be used to perform Denial of Service attacks. Indeed an attacker
514 could frequently change the Locator Status Bits in order to trigger a
515 large amount of Map-Requests. Rate limitation, as described in
516 [RFC6830], if implemented in a very simple way a single bucket for
517 all triggered control plane messages, does not allow sending high
518 number of such a request, resulting in the attacker saturating the
519 rate with these spoofed packets.
521 Severity level 2: to avoid any risk, Locator Status Bits should be
522 deactivated in public deployments of LISP. Deactivating LSB does not
523 reduce LISP functionality.
525 5.4.2. Attacks using the Map-Version bit
527 The optional Map-Version bit is used to indicate whether the low-
528 order 24 bits of the first 32 bits longword of the LISP header
529 contain a Source and Destination Map-Version. When a LISP ETR
530 receives a LISP encapsulated packet with the Map-Version bit set to
531 1, the following actions are taken:
533 o It compares the Destination Map-Version found in the header with
534 the current version of its own mapping, in the EID-to-RLOC
535 Database, for the destination EID found in the encapsulated
536 packet. If the received Destination Map-Version is smaller (i.e.,
537 older) than the current version, the ETR should apply the SMR
538 procedure described in [RFC6830] and send a Map-Request with the
539 SMR bit set.
541 o If a mapping exists in the EID-to-RLOC Cache for the source EID,
542 then it compares the Map-Version of that entry with the Source
543 Map-Version found in the header of the packet. If the stored
544 mapping is older (i.e., the Map-Version is smaller) than the
545 source version of the LISP encapsulated packet, the xTR should
546 send a Map-Request for the source EID.
548 A spoofing off-path attacker (SA) could use the Map-Version bit to
549 force an ETR to send Map-Request messages. The attacker could
550 retrieve the current source and destination Map-Version for both HA
551 and HB. Based on this information, it could send a spoofed packet
552 with an older Source Map-Version or Destination Map-Version. If the
553 size of the Map-Request message is larger than the size of the
554 smallest LISP-encapsulated packet that could trigger such a message,
555 this could lead to amplification attacks (see Section 6.1). However,
556 [RFC6830] recommends to rate limit the Map-Request messages that are
557 sent by an xTR. This prevents the amplification attack, but there is
558 a risk of Denial of Service attack if an attacker sends packets with
559 Source and Destination Map-Versions that frequently change. In this
560 case, and depending on the implementation of the rate limitation
561 policy, the ETR might consume its entire rate by sending Map-Request
562 messages in response to these spoofed packets.
564 A non-spoofing off-path attacker (NSA) could not success in such an
565 attack if the destination xTR rejects the LISP encapsulated packets
566 that are not sent by one of the RLOCs mapped to the included source
567 EID. If it is not the case, the attacker could be able to perform
568 attacks concerning the Destination Map Version number as for the
569 spoofing off-path attacker (SA).
571 Severity level 1: the correct deployment of anti-spoofing and rate
572 limitation techniques prevents the attacks leveraging on the Map-
573 Version.
575 5.4.3. Attacks using the Nonce-Present and the Echo-Nonce bits
577 The Nonce-Present and Echo-Nonce bits are used when verifying the
578 reachability of a remote ETR. Assume that LR3 wants to verify that
579 LR1 receives the packets that it sends. LR3 can set the Echo-Nonce
580 and the Nonce-Present bits in LISP data encapsulated packets and
581 include a random nonce in these packets. Upon reception of these
582 packets, LR1 will store the nonce sent by LR3 and echo it when it
583 returns LISP encapsulated data packets to LR3.
585 A spoofing off-path attacker (SA) could interfere with this
586 reachability test by sending two different types of packets:
588 1. LISP data encapsulated packets with the Nonce-Present bit set and
589 a random nonce and the appropriate source and destination RLOCs.
591 2. LISP data encapsulated packets with the Nonce-Present and the
592 Echo-Nonce bits both set and the appropriate source and
593 destination RLOCs. These packets will force the receiving ETR to
594 store the received nonce and echo it in the LISP encapsulated
595 packets that it sends.
597 The first type of packet should not cause any major problem to ITRs.
598 As the reachability test uses a 24 bits nonce, it is unlikely that an
599 off-path attacker could send a single packet that causes an ITR to
600 believe that the ETR it is testing is reachable while in reality it
601 is not reachable. To increase the success likelihood of such attach,
602 the attacker should created a massive amount of packets carrying all
603 possible nonce values. However, "flood attack" can be easily
604 detected and blocked.
606 The second type of packet could be exploited to create a Denial of
607 Service attack against the nonce-based reachability test. Consider a
608 spoofing off-path attacker (SA) that sends a continuous flow of
609 spoofed LISP data encapsulated packets that contain the Nonce-Present
610 and the Echo-Nonce bit and each packet contains a different random
611 nonce. The ETR that receives such packets will continuously change
612 the nonce that it returns to the remote ITR. If the remote ITR
613 starts a nonce-reachability test, this test may fail because the ETR
614 has received a spoofed LISP data encapsulated packet with a different
615 random nonce and never echoes the real nonce. In this case the ITR
616 will consider the ETR not reachable. The success of this test will
617 of course depend on the ratio between the amount of packets sent by
618 the legitimate ITR and the spoofing off-path attacker (SA).
620 Packets sent by a non-spoofing off-path attacker (NSA) can cause
621 similar problem if no check is done with the EID-to-RLOC Cache (see
622 Section 5.3 for the EID-to-RLOC Cache check). Otherwise, if the
623 check is performed the packets will be rejected by the ETR that
624 receives them and cannot cause problems.
626 Severity level 2: to avoid any problem, echo nonce should be
627 deactivated. Deactivating echo-nonce does not reduce LISP
628 functionality as it is an optimization for symmetric data flow path
629 and because other techniques exist to test the reachability of a
630 RLOC.
632 5.4.4. Attacks using the Instance ID bits
634 LISP allows to carry in its header a 24-bits value called "Instance
635 ID" and used on the ITR to indicate which private Instance ID has
636 been used for encapsulation, while on the ETR can be used to select
637 the forwarding table used for forwarding the decapsulated packet.
639 Even if an off-path attacker could randomly guess a valid Instance ID
640 value, there is no LISP specific problem. Obviously the attacker
641 could be now able to reach hosts that are only reachable through the
642 routing table identified by the attacked Instance ID, however, end-
643 system security is out of the scope of this document. Nevertheless,
644 access lists can be configured to protect the network from Instance
645 ID based attacks.
647 Severity level 1: the correct deployment of access control lists and
648 firewalls prevent the attacks leveraging on the Instance ID.
650 6. Control Plane Threats
652 In this section, we discuss the different types of attacks that could
653 occur when an off-path attacker sends control plane packets. We
654 focus on the packets that are sent directly to the ETR and do not
655 analyze the particularities of a LISP mapping system. The LISP+ALT
656 and LISP-DDT mapping systems are discussed in Section 9.
658 Severity level 2. The severity level of attacks on the LISP control-
659 plane depends on the attack vector as described below.
661 6.1. Attacks with Map-Request messages
663 An off-path attacker could send Map-Request packets to a victim ETR.
664 In theory, a Map-Request packet is only used to solicit an answer and
665 as such it should not lead to security problems. However, the LISP
666 specification [RFC6830] contains several particularities that could
667 be exploited by an off-path attacker.
669 The first possible exploitation is the P bit. The P bit is used to
670 probe the reachability of remote ETRs. In our reference environment,
671 LR3 could probe the reachability of LR1 by sending a Map-Request with
672 the P bit set. LR1 would reply by sending a Map-Reply message with
673 the P bit set and the same nonce as in the Map-Request message.
675 A spoofing off-path attacker (SA) could use the P bit to force a
676 victim ETR to send a Map-Reply to the spoofed source address of the
677 Map-Request message. As the Map-Reply can be larger than the Map-
678 Request message, there is a risk of amplification attack.
679 Considering only IPv6 addresses, a Map-Request can be as small as 40
680 bytes, considering one single ITR address and no Mapping Protocol
681 Data. The Map-Reply instead has a size of O(12 + (R * (28 + N *
682 24))) bytes, where N is the maximum number of RLOCs in a mapping and
683 R the maximum number of records in a Map-Reply. Since up to 255
684 RLOCs can be associated to an EID-Prefix and 255 records can be
685 stored in a Map-Reply, the maximum size of a Map-Reply is thus above
686 1 MB showing a size factor of up to 39,193 between the message sent
687 by the attacker and the message sent by the ETR. These numbers are
688 however theoretical values not considering transport layer
689 limitations and it is more likely that the reply will contain only
690 one record with at most a dozen of locators, giving an amplification
691 factor around 8.
693 Any ISP with a large number of potential RLOCs for a given EID-Prefix
694 should carefully ponder the best trade-off between the number of
695 RLOCs through which it wants that the EID is reachable and the
696 consequences that an amplification attack can produce.
698 It should be noted that the maximum rate of Map-Reply messages should
699 apply to all Map-Replies and also be associated to each destination
700 that receives Map-Reply messages. Otherwise, a possible
701 amplification attack could be launched by a spoofing off-path
702 attacker (SA) as follows. Consider an attacker SA and EID-Prefix
703 192.0.2.0/24 and a victim ITR. To amplify a Denial of Service attack
704 against the victim ITR, SA could send spoofed Map-Request messages
705 whose source EID addresses are all the addresses inside 192.0.2.0/24
706 and source RLOC address is the victim ITR. Upon reception of these
707 Map-Request messages, the ETR would send large Map-Reply messages for
708 each of the addresses inside p/P back to the victim ITR.
710 If a non-spoofing off-path attacker (NSA) sends a Map-Request with
711 the P bit set, it will receive a Map-Reply with the P bit set. This
712 does not raise security issues besides the usual risk of overloading
713 a victim ETR by sending too many Map-Request messages.
715 The Map-Request message may also contain the SMR bit. Upon reception
716 of a Map-Request message with the SMR bit, an ETR must return to the
717 source of the Map-Request message a Map-Request message to retrieve
718 the corresponding mapping. This raises similar problems as the P bit
719 discussed above except that as the Map-Request messages are smaller
720 than Map-Reply messages, the risk of amplification attacks is
721 reduced. This is not true anymore if the ETR append to the Map-
722 Request messages its own Map-Records. This mechanism is meant to
723 reduce the delay in mapping distribution since mapping information is
724 provided in the Map-Request message.
726 Severity level 1: the correct deployment of anti-spoofing and rate
727 limitation techniques prevents the attacks leveraging the Map-Request
728 message.
730 Furthermore, appending Map-Records to Map-Request messages represents
731 a major security risk since an off-path attacker could generate a
732 (spoofed or not) Map-Request message and include in the Map-Reply
733 portion of the message mapping for EID prefixes that it does not
734 serve. This could lead to various types of redirection and denial of
735 service attacks. An xTR should not process the Map-Records
736 information that it receives in a Map-Request message. As it is a
737 performance optimization, we recommend to deactivate this
738 functionality in public LISP deployments.
740 Severity level 2: to avoid any risk, appending Map-Records to Map-
741 Request messages should be deactivated in public deployments of LISP.
742 Deactivating appending Map-Records to Map-Request messages does not
743 reduce LISP functionality.
745 6.2. Attacks with Map-Reply messages
747 In this section we analyze the attacks that could occur when an off-
748 path attacker sends directly Map-Reply messages to ETRs without using
749 one of the proposed LISP mapping systems.
751 There are two different types of Map-Reply messages:
753 Positive Map-Reply: These messages contain a Map-Record binding an
754 EID-Prefix to one or more RLOCs.
756 Negative Map-Reply: These messages contain a Map-Record for an EID-
757 Prefix with an empty locator-set and specifying an action,
758 which may be either Drop, natively forward, or Send Map-
759 Request.
761 Positive Map-Reply messages are used to map EID-Prefixes onto RLOCs.
762 Negative map-reply messages are used to indicate non-lisp prefixes.
763 ITRs can, if needed, be configured to send all traffic destined for
764 non-lisp prefixes to a Proxy-ETR.
766 Most of the security of the Map-Reply messages depends on the 64 bits
767 nonce that is included in a Map-Request and returned in the Map-
768 Reply. An ETR must never accept a Map-Reply message whose nonce does
769 not match one of the pending Map-Request messages. If an ETR does
770 not accept Map-Reply messages with an invalid nonce, the risk of
771 attack is acceptable given the size of the nonce (64 bits).
773 The nonce only confirms that the map-reply received was sent in
774 response to a map-request sent, it does not validate the contents of
775 that map-reply.
777 In addition, an attacker could perform EID-to-RLOC Cache overflow
778 attack by de-aggregating (i.e., splitting an EID prefix into
779 artificially smaller EID prefixes) either positive or negative
780 mappings.
782 Severity level 1: the correct deployment of anti-spoofing techniques
783 prevents attacks leveraging the Map-Reply message.
785 6.3. Gleaning Attacks
787 A third type of attack involves the gleaning mechanism proposed in
788 [RFC6830] and discussed in [Saucez09]. In order to reduce the time
789 required to obtain a mapping, [RFC6830] allows an ITR to learn a
790 mapping from the LISP data encapsulated packets and the Map-Request
791 packets that it receives. LISP data encapsulated packet contains a
792 source RLOC, destination RLOC, source EID and destination EID. When
793 an ITR receives a data encapsulated packet coming from a source EID
794 for which it does not already know a mapping, it may insert the
795 mapping between the source RLOC and the source EID in its EID-to-RLOC
796 Cache. Gleaning could also be used when an ITR receives a Map-
797 Request as the Map-Request also contains a source EID address and a
798 source RLOC. Once a gleaned entry has been added to the EID-to-RLOC
799 cache, the LISP ITR sends a Map-Request to retrieve the mapping for
800 the gleaned EID from the mapping system. [RFC6830] recommends
801 storing the gleaned entries for only a few seconds.
803 The first risk of gleaning is the ability to temporarily hijack an
804 identity. Consider an off-path attacker that wants to temporarily
805 hijack host HA's identity and send packets to host HB with host HA's
806 identity. If the xTRs that serve host HB do not store a mapping for
807 host HA, a non-spoofing off-path attacker (NSA) could send a LISP
808 encapsulated data packet to LR3 or LR4. The ETR will store the
809 gleaned entry and use it to return the packets sent by host HB to the
810 attacker. In parallel, the ETR will send a Map-Request to retrieve
811 the mapping for HA. During a few seconds or until the reception of
812 the Map-Reply, host HB will exchange packets with the attacker that
813 has hijacked HA's identity. Note that the attacker could in parallel
814 send lots of Map-Requests or lots of LISP data encapsulated packets
815 with random sources to force the xTR that is responsible for host HA
816 to send lots of Map-Request messages in order to force it to exceed
817 its rate limit for control plane messages. This could further delay
818 the arrival of the Map-Reply message on the requesting ETR.
820 Gleaning also introduces the possibility of a man-in-the-middle
821 attack. Consider an off-path attacker that knows that hosts HA and
822 HB that resides in different sites will exchange information at time
823 t. An off-path attacker could use this knowledge to launch a man-in-
824 the-middle attack if the xTRs that serve the two hosts do not have
825 mapping for the other EID. For this, the attacker sends to LR1
826 (resp. LR3) a LISP data encapsulated packet whose source RLOC is its
827 IP address and contains an IP packet whose source is set to HB (resp.
828 HA). The attacker chooses a packet that will not trigger an answer,
829 for example the last part of a fragmented packet. Upon reception of
830 these packets, LR1 and LR3 install gleaned entries that point to the
831 attacker. As explained above, the attacker could, at the same time,
832 send lots of packets to LR1 and LR3 to force them to exhaust their
833 control plane rate limit. This will extend the duration of the
834 gleaned entry. If host HA establishes a flow with host HB at that
835 time, the packets that they exchange will first pass through the
836 attacker.
838 In both cases, the attack only lasts for a few seconds (unless the
839 attacker is able to exhaust the rate limitation). However it should
840 be noted that today a large amount of packets might be exchanged
841 during even a small fraction of time.
843 Severity level 2: to avoid any risk, gleaning should be deactivated
844 in public deployments of LISP. Deactivating gleaning does not reduce
845 LISP functionality.
847 7. Threats concerning Interworking
849 [RFC6832] defines two network elements to allow LISP and non-LISP
850 sites to communicate, namely the Proxy-ITR and the Proxy-ETR. The
851 Proxy-ITR encapsulates traffic from non-LISP sites in order to
852 forward it toward LISP sites, while the Proxy-ETR decapsulates
853 traffic arriving from LISP sites in order to forward it toward non-
854 LISP sites. For these elements some of the attack based on the LISP
855 specific header are not possible, for the simple reason that some of
856 the fields cannot be used due to the unidirectional nature of the
857 traffic.
859 The Proxy-ITR has functionality similar to the ITR, however, its main
860 purpose is to encapsulate packets arriving from the DFZ in order to
861 reach LISP sites. This means that it is no bound to any particular
862 EID-Prefix, hence no mapping exists and no mapping can be configured
863 in the EID-to-RLOC Database. This means that the Proxy-ITR element
864 itself is not able to check whether or not the arriving traffic has
865 the right to be encapsulated or not. To limit Proxy-ITRs being used
866 as relays for attacks, Proxy-ITRs operators are encouraged to
867 implement best practices for data plane access control on the Proxy-
868 ITRs and the border of the network, that is the edge of the scope of
869 the Proxy-ITR's announcement of the EID-Prefix. On the other side,
870 the Proxy-ITR is meant to encapsulate only packets that are destined
871 to one of the LISP sites it is serving. This is the case for
872 instance for a service provider selling Proxy-ITR services. For this
873 purpose a static EID-to-RLOC Cache can be configured in order to
874 encapsulate only valid packets. In case of a cache-miss no Map-
875 Request needs to be sent and the packet can be silently dropped.
877 The Proxy-ETR has functionality similar to the ETR, however, its main
878 purpose is to inject un-encapsulated packet in the DFZ in order to
879 reach non-LISP-Sites. This means that since there is no specific
880 EID-Prefix downstream, it has no EID-to-RLOC Database that can be
881 used to check whether or not the destination EID is part of its
882 domain. In order to avoid for the Proxy-ETR to be used as relay in a
883 DoS attack it is preferable to configure the EID-to-RLOC Cache with
884 static entries used to check if an encapsulated packet coming from a
885 specific RLOC and having a specific source EID is actually allowed to
886 transit through the Proxy-ETR. This is also important for services
887 provider selling Proxy-ETR service to actually process only packets
888 arriving from its customers. However, in case of cache-miss no Map-
889 Request needs to be sent, rather the packet can be silently dropped
890 since it is not originating from a valid site. The same drop policy
891 should be used for packets with an invalid source RLOC or a valid
892 source RLOC but an invalid EID.
894 As it is the case without LISP, the addition of public proxies offers
895 opportunities to attackers to commit attacks. LISP interworking does
896 not open new threats compared to other interworking techniques based
897 on public proxies.
899 Severity level 0: the careful configuration of PETR and PITR combined
900 with the deployment of anti-spoofing techniques mitigates the attacks
901 leveraging interworking and provides the same level of severity as
902 interworking techniques in the Internet.
904 8. Threats with Malicious xTRs
906 In this section, we discuss the threats that could be caused by
907 malicious xTRs. We consider the reference environment below where
908 EL1 is a malicious or compromised xTR. This malicious xTR serves a
909 set of hosts that includes HC. The other xTRs and hosts in this
910 network play the same role as in the reference environment described
911 in Section 4.
913 +-----+
914 | HA |
915 +-----+
916 | EID: HA
917 |
918 -----------------
919 | |
920 +-----+ +-----+
921 | LR1 | | LR2 |
922 +-----+ +-----+
923 | |
924 | |
925 +-----+ +-----+
926 |ISP1 | |ISP2 |
927 +-----+ +-----+
928 | |
929 +----------------+ +-----+ |
930 | |-----| EL1 |--|
931 | | +-----+ |
932 | Internet | | +-----+
933 | | |--| HC |
934 | | | +-----+
935 +----------------+ EID: HC
936 | |
937 +-----+ +-----+
938 | LR3 | | LR4 |
939 +-----+ +-----+
940 | |
941 -------------------
942 |
943 | EID: HB
944 +-----+
945 | HB |
946 +-----+
948 Figure 2: Malicious xTRs' Reference Environment
950 Since xTRs are cornerstone in the LISP architecture, malicious xTRs
951 are probably the most serious threat to the LISP control plane from a
952 security viewpoint. Indeed, the impact of compromised LISP Control
953 Plane can be severe, and the most effective way to attack any multi-
954 organizational control plane is from within the system itself. To
955 understand the problem, let us consider the following scenario. Host
956 HC and HB exchange packets with host HA. As all these hosts reside
957 in LISP sites, LR1 and LR2 store mappings for HB and HC. Thus, these
958 xTRs may need to exchange LISP control plane packets with EL1, e.g.,
959 to perform reachability tests or to refresh expired mappings (e.g.,
960 if HC's mapping has a small TTL).
962 A first threat against the LISP control plane is when EL1 replies to
963 a legitimate Map-Request message sent by LR1 or LR2 with a Map-Reply
964 message that contains an EID-Prefix that is larger than the prefix
965 owned by the site attached to EL1. For instance if the prefix owned
966 by EL1 is 192.0.2.0/25 but the Map-Reply contain a mapping for
967 192.0.2.0/24. This could allow EL1 to attract packets destined to
968 other EIDs than the EIDs that are attached to EL1. This attack is
969 called an "overclaiming" attack.
971 A malicious ETR might fragment its eid-to-rloc database and then
972 instigate traffic to its site, therefore creating state on the
973 corresponding ITR's map-cache. This attack is called de-aggregation
974 attack.
976 Overclaiming attack could be combined with de-aggregation to succeed
977 a LISP Cache poisoning attack and prefix hijacking. For example, if
978 the EID prefix of the attacker is 192.0.2.0/25, it cannot provide a
979 mapping for the EID prefix 192.0.2.128/25 (i.e., it cannot hijack the
980 prefix). However, since a Map-Reply can contain several map records,
981 it is possible to hijack such a prefix by providing as well a mapping
982 for it. To this end, the attacker could send a Map-Reply with an EID
983 prefix that covers at the same time the requested EID and the
984 hijacked target prefix. Continuing the previous example, if the
985 requested mapping is for EID 192.0.2.1, and the target hijack prefix
986 is 192.0.2.128/25, the Map-Reply will contain a map record for
987 192.0.2.0/24 and a map record for 192.0.2.128/25. Such a reply is
988 considered legitimate according to the requested EID, while the map
989 record of the hijacked prefix may lead to traffic redirection/
990 disruption and ITR's Cache poisoning.
992 Another variant of the overclaiming attack is a Denial of Service
993 attack by sending a Negative Map-Reply message for a larger prefix
994 without any locator and with the Drop action. Such a Negative Map-
995 Reply indicates that the ETR that receives it should discard all
996 packets.
998 By enabling [I-D.ietf-lisp-sec], overclaiming attacks are mitigated
999 under the assumption that the mapping system can be trusted. This
1000 assumption is equivalent to the general assumption that the control-
1001 plane is trustable in BGP meaning that the threat is not more severe
1002 than what is observed today. In addition, at the time of the writing
1003 all Map Server implementations are configured with the minimal prefix
1004 allowed to be register by their customers such that a customer cannot
1005 register an overclaimed attack. Therefore, if mappings are always
1006 retrieved via the mapping system with LISP-Sec activated and if Map-
1007 Registers are cryptographically protected as recommended in the
1008 specifications, overclaiming attack is not possible.
1010 Another concern with malicious xTRs is the possibility of Denial of
1011 Service attacks. A first attack is the flooding attack that was
1012 described in [I-D.bagnulo-lisp-threat]. This attack allows a
1013 malicious xTR to redirect traffic to a victim. The malicious xTR
1014 first defines a mapping for HC with two RLOCs: its own RLOC (EL1) and
1015 the RLOC of the victim (e.g., LR3). The victim's RLOC is set as
1016 unreachable in the mapping. HC starts a large download from host HA.
1017 Once the download starts, the malicious xTR updates its Locator
1018 Status Bits, changes the mapping's version number or sets the SMR bit
1019 such that LR1 updates its EID-to-RLOC Cache to send all packets
1020 destined to HC to the victim's RLOC. Instead of downloading from HA,
1021 the attacker could also send packets that trigger a response (e.g.,
1022 ICMP, TCP SYN, DNS request, ...) to HA. HA would then send its
1023 response and its xTR would forward it to the victim's RLOC.
1025 An important point to note about this flooding attack is that it
1026 reveals a limitation of the LISP architecture. A LISP ITR relies on
1027 the received mapping and possible reachability information to select
1028 the RLOC of the ETR that it uses to reach a given EID or block of
1029 EIDs. However, if the ITR made a mistake, e.g., due to
1030 misconfiguration, wrong implementation, or other types of errors and
1031 has chosen a RLOC that does not serve the destination EID, there is
1032 no easy way for the LISP ETR to inform the ITR of its mistake. A
1033 possible solution is to enforce an ETR to perform a reachability test
1034 with the selected ITR as soon as there is LISP encapsulated traffic
1035 between the two. We recommend to never use reachability information
1036 without verifying them first.
1038 Note that the attacks discussed in this section are for documentation
1039 purpose only. Malicious xTRs are either somehow directly deployed by
1040 attackers or the result of attackers gaining privileged access to
1041 existing xTRs. As such, it is out of the scope of LISP to propose
1042 any mechanism to protect routers or to avoid their deployments with
1043 malicious intentions.
1045 Severity level 2: the correct deployment of anti-spoofing and rate
1046 limiting techniques combined with LISP-Sec and Map-Register
1047 authentication prevents threats caused by malicious xTRs, as long as
1048 mappings are always retrieved via a trustable mapping system. In
1049 addition reachability information should never been used without
1050 being verified first.
1052 9. Security of the Proposed Mapping Systems
1054 9.1. LISP+ALT
1056 One of the assumptions in [RFC6830] is that the mapping system is
1057 more secure than sending Map-Request and Map-Reply messages directly.
1058 We analyze this assumption in this section by analyzing the security
1059 of the ALT mapping system.
1061 The ALT mapping system is basically a manually configured overlay of
1062 GRE tunnels between ALT routers. BGP sessions are established
1063 between ALT routers that are connected through such tunnels. An ALT
1064 router advertises the EID prefixes that it serves over its BGP
1065 sessions with neighboring ALT routers and the EID-Prefixes that it
1066 has learned from neighboring ALT routers.
1068 The ALT mapping system is in fact a discovery system that allows any
1069 ALT router to discover the ALT router that is responsible for a given
1070 EID-Prefix. To obtain a mapping from the ALT system, an ITR sends a
1071 packet containing a Map-Request on the overlay. This Map-Request is
1072 sent inside a packet whose destination is the requested EID. The
1073 Map-Request is routed on the overlay until it reaches the ALT router
1074 that advertised initially the prefix that contains the requested EID.
1075 This ALT router then replies directly by sending a Map-Reply to the
1076 RLOC of the requesting ITR.
1078 The security of the ALT mapping system depends on many factors,
1079 including:
1081 o The security of the intermediate ALT routers.
1083 o The validity of the BGP advertisements sent on the ALT overlay.
1085 ALT routers are interconnected with tunnels, the usage of secured
1086 tunnels prevents BGP advertisements to be altered, dropped, or added
1087 by on-path or off path attackers. If a high level of security is
1088 required, works in the SIDR working group that develop security
1089 solutions for BGP ([RFC6480]) could be applied to LISP+ALT.
1091 The security of the intermediate ALT routers is another concern. A
1092 malicious intermediate ALT router could manipulate the received BGP
1093 advertisements and also answer to received Map-Requests without
1094 forwarding them to their final destination on the overlay. This
1095 could lead to various types of redirection attacks. Note that in
1096 contrast with a regular IP router that could also manipulate in
1097 transit packets, when a malicious or compromised ALT router replies
1098 to a Map-Request, it can redirect legitimate traffic for a long
1099 period of time by sending an invalid Map-Reply message. Thus, the
1100 impact of a malicious ALT router could be more severe than a
1101 malicious router in today's Internet. BGP is also weak in case of a
1102 router involved in the BGP topology is compromised.
1104 Severity level 1: configuring correctly the Map Servers, Map
1105 Revolvers, and ALT routers with filters corresponding to their
1106 customer cones provides the same security level as in BGP. If more
1107 security is necessary, cryptography must be used to validate the
1108 mappings themselves.
1110 9.2. LISP-DDT
1112 The LISP Delegated Database Tree (LISP-DDT) mapping system is
1113 proposed as an alternative for LISP+ALT [I-D.ietf-lisp-ddt]. LISP-
1114 DDT is a hierarchical distributed database for EID-to-RLOC mappings.
1115 Each DDT node is configured with an EID prefix it is authoritative
1116 for, as well as the RLOC addresses and EID prefixes of the LISP-DDT
1117 nodes that are authoritative for more specific EID prefix. In LISP-
1118 DDT, mappings are retrieved iterative. A Map Resolver that needs to
1119 locate a mapping traverses the tree of DDT nodes contacting them one
1120 after another until the leaf of the DDT tree that is authoritative
1121 for the longest matching EID prefix for the mapping's EID is reached.
1122 The Map Resolver traverses the hierarchy of LISP-DDT nodes by sending
1123 Map-Requests, with the LISP-DDT-originated bit set, to LISP-DDT
1124 nodes. The Map Resolver first contacts the root of the hierarchy.
1125 When a LISP-DDT node receives a Map-Request, it replies to the Map
1126 Resolver with a Map-Referral that contains the list of the locators
1127 of its children that are authoritative of a prefix that covers the
1128 EID in the Map-Request. The Map Resolver then contacts one of these
1129 children that will return, at its turn, a Map-Referral. This
1130 procedure is iteratively executed until a Map-Referral marked with
1131 the done flag is received. The locators that appear in a referral
1132 with the done flag are those of the authoritative ETRs for the EID in
1133 the Map-Request. At that moment, the Map Resolver falls back to its
1134 normal behavior and sends a Map-Request to the ETR in order for the
1135 ITR to obtain the mapping. It is worth to mention that the Map
1136 Resolver can cache the referrals to avoid traversing all the whole
1137 hierarchy for all mapping retrievals.
1139 The operation in LISP-DDT is different from ALT and thus it does not
1140 present the same threats as LISP+ALT. As a first difference, LISP-
1141 DDT natively includes security specification providing data origin
1142 authentication, data integrity protection and secure EID prefix
1143 delegation. Hence, these aspects are no further explored in this
1144 document.
1146 However, threats exist for LISP-DDT as well. For instance, a DoS
1147 attack could be performed on the mapping infrastructure by asking to
1148 retrieve a large amount of mappings at the same time, hence, the
1149 importance of carefully dimensioning the topology of the DDT
1150 hierarchy.
1152 If an attacker manages to compromise a LISP-DDT node it could send
1153 fake referrals to the Map Resolver and then control the mappings
1154 delivered to the ITRs. Furthermore, the effects of such an attack
1155 could be longer than the attack itself if the Map Resolver caches the
1156 referrals.
1158 Severity level 1: the correct deployment of anti-spoofing and rate
1159 limiting techniques combined with embedded security features of LISP-
1160 DDT prevent attacks leveraging LISP-DDT.
1162 10. Threats concerning LISP-MS
1164 LISP-MS ([RFC6833] specifies two network elements, namely the Map
1165 Server and the Map Resolver, that are meant to be used by xTRs to
1166 access the mapping system. The advantage is clearly the fact that
1167 even if the mapping system changes in time xTRs do not need to change
1168 anything since they deal only with Map Servers and Map Resolvers.
1169 This includes the security aspects, since no change in the local
1170 security policies is needed.
1172 10.1. Map Server
1174 Map Server is used to dispatch Map-Request coming from the mapping
1175 system to ETRs that are authoritative for the EID in the request. To
1176 this end it is necessary that ETRs register their mappings to the Map
1177 Server. This allows the Map Server to know toward which ETR to
1178 forward Map-Requests and also to announce the EID-prefixes of the
1179 registered mappings in the mapping system.
1181 LISP uses a shared key approach in order to protect the Map Server
1182 and grant registration rights only to ETRs that have a valid key.
1183 Shared key must be used to protect both the registration message and
1184 the Map-Notify message when used. The mechanism used to share the
1185 key between a Map Server and an ETRs must be secured to avoid that a
1186 malicious nodes catch the key and uses it to send forged Map-Register
1187 message to the Map Server. A forged Map-Register message could be
1188 used to attract Map-Request and thus provide invalid Map-Replies or
1189 the redirect Map-Requests to a target to mount a DoS attack.
1191 More subtle attacks could be carried out only in the case of
1192 malicious ETRs. A malicious ETR could register an invalid RLOC to
1193 divert Map-Requests to a target ETR and succeed a DoS attack on it.
1194 To avoid this kind of attack, the Map Server must check that the
1195 registered RLOCs belong to ETRs authoritative for the registered EID
1196 prefix. Such check can be done by sending and explicit Map-Request
1197 for the EID to the ETRs in the mapping and check that replies with a
1198 Map-Reply. If the ETRs return a valid Map-Reply, the RLOC belongs to
1199 an authoritative ETR. Note that this does not protect against
1200 malicious ETRs that create forged Map-Replies. Stronger techniques
1201 for RLOC check are presented in [I-D.saucez-lisp-mapping-security].
1203 Similarly to the previous case, a malicious ETR could register an
1204 invalid EID-prefix to attract Map-Requests or to redirect them to a
1205 target to mount a DoS attack. To avoid this kind of attack, the Map
1206 Server must check that the prefixes registered by an ETR belong to
1207 that ETR. One method could be to manually configure EID-prefix
1208 ranges that can be announced by ETRs.
1209 [I-D.saucez-lisp-mapping-security] present alternative techniques to
1210 verify the prefix claimed by an ETR.
1212 Severity level 1: the correct deployment of anti-spoofing and rate
1213 limiting techniques combined with usage of Map-Register
1214 authentication prevents attacks leveraging the Map Server.
1216 10.2. Map Resolver
1218 Map Resolvers receive Map-Requests, typically from ITRs, and use the
1219 mapping system to find a mapping for the EID in the Map-Request. It
1220 can work in two modes:
1222 Non-Caching Mode: The resolver just forwards the Map-Request to the
1223 mapping system, which will take care of delivering the request
1224 to an authoritative ETR. The latter will send back a Map-Reply
1225 directly to the ITR that has originally issued the request.
1227 Caching Mode: The resolver will generate a new Map-Request and send
1228 it to the mapping system. In this way it will receive the
1229 corresponding reply, store a local copy in a cache, and send
1230 back a reply to the original requester. Since all requested
1231 mappings are locally cached, before actually making a request
1232 to the mapping system it performs a lookup in the local cache
1233 and in case of an hit, it send back a reply without querying
1234 the mapping system.
1236 In its basic mode, i.e., non-caching mode, the Map Resolver does not
1237 keep state, hence, the only direct form of attack is a DoS attack,
1238 where an attacker (or a group of attackers) could try to exhaust
1239 computational power by flooding the resolver with requests. Common
1240 filtering techniques and BCP against DoS attacks could be applied in
1241 this case.
1243 Nonetheless, attackers could use resolvers as relay for DoS attacks
1244 against xTRs. An off-path spoofing attacker could generate a high
1245 load of requests to a set of resolvers, hence distributing the load
1246 in order to avoid to be blocked. All this requests can use a
1247 specific EID that makes all the requests to be forwarded to a
1248 specific ETR, which, as a result, will be victim of a DDoS attack.
1249 Similarly, the attacker could use a spoofed source address making all
1250 the replies to converge to one single ITR, which, as a result, will
1251 be victim of a DDoS attack. Such scenarios are not specific to LISP,
1252 but rather a common problem of every query infrastructure, hence the
1253 same BCP can be applied in order to limit the attacks.
1255 When functioning in caching-mode, the resolver will use the same type
1256 of cache than ITRs. Due to its similarity with the ITRs' cache the
1257 analysis provided in Section 5.2 holds also in this case. However,
1258 an important difference exists: this cache is not used for packet
1259 encapsulation but only for quick replies when new requests arrive.
1260 Therefore, as the caching-mode is only an optimization, the attacks
1261 that aim at filling the Map Resolver cache have a less severe impact
1262 on the traffic. The usage of LISP-Sec prevents ITR to obtain invalid
1263 mappings. It is worth noting that caching is not used in current
1264 implementations as it makes mapping synchronization hard for mobile
1265 devices.
1267 When Map Resolvers are used as front-end of the LIS-DDT mapping
1268 system they may be exposed to another variant of DoS. Indeed, the
1269 iterative operation of the Map Resolver on the DDT hierarchy implies
1270 that it has to maintain state about the ITR that requested the
1271 mapping, this in order to send the final Map-Request to the ETR on
1272 behalf of the ITR. An attacker might leverage on this to fill the
1273 Map Resolver memory and then cause a DoS. Rate limiting can be used
1274 to present this attack.
1276 The question may arise on whether a Kaminsky-like attack is possible
1277 for an off-path attacker against ITRs sending requests to a certain
1278 resolver. The 64-bits nonce present in every message has been
1279 introduced in the LISP specification to avoid such kind of attack.
1280 There has been discussion within the LISP Working Group on the
1281 optimal size of the nonce, and it seems that 64-bits provides
1282 sufficient protection.
1284 A possible way to limit the above-described attacks is to introduce
1285 strong identification in the Map-Request/Map-Reply by using the
1286 Encapsulated Control Message with authentication enabled
1287 [I-D.ietf-lisp-sec].
1289 Severity level 1: the correct deployment of anti-spoofing and rate
1290 limiting techniques combined with LISP-Sec and Map-Register
1291 authentication prevent attacks leveraging Map Resolver.
1293 11. Security Recommendations
1295 Different deployments of LISP may have different security
1296 requirements. The recommendations in this document aim at mitigating
1297 threats in in public deployments of LISP.
1299 To mitigate the impact of attacks against LISP in public deployments,
1300 the following recommendations should be followed.
1302 First, the use of some form of filtering can help in avoid or at
1303 least mitigate some types of attacks.
1305 o On ETRs, packets should be decapsulated only if the destination
1306 EID is effectively part of the EID-Prefix downstream the ETR.
1307 Further, still on ETRs, packets should be decapsulated only if a
1308 mapping for the source EID is present in the EID-to-RLOC Cache and
1309 has been obtained through the mapping system (not gleaned).
1311 o On ITRs, packets should be encapsulated only if the source EID is
1312 effectively part of the EID-Prefix downstream the ITR. Further,
1313 still on ITRs, packets should be encapsulated only if a mapping
1314 obtained from the mapping system is present in the EID-to-RLOC
1315 Cache (no Data-Probing).
1317 Note that this filtering, since complete mappings need to be
1318 installed in both ITRs and ETRs, can introduce higher connection
1319 setup latency and hence potentially more packets drops due to the
1320 lack of mappings in the EID-to-RLOC Cache.
1322 While the gleaning mechanism allows starting encapsulating packets to
1323 a certain EID in parallel with the Map-Request to obtain a mapping
1324 when a new flow is established, it creates important security risks
1325 since it allows attackers to perform identity hijacks. Although the
1326 duration of these identity hijacks is limited (except the case of
1327 rate limitation exhaustion), their impact can be severe. A first
1328 option would be to disable gleaning until the security concerns are
1329 solved. A second option would be to strictly limit the number of
1330 packets that can be forwarded via a gleaned entry. Overall the
1331 benefits of gleaning, i.e., avoiding the loss of the first packet of
1332 a flow, seems very small compared to the associated security risks.
1333 Furthermore, measurements performed in data centers show that today's
1334 Internet often operate with packet loss ratio of 1 or 2 percentage
1335 ([Chu]). These packet loss ratios are probably already orders of
1336 magnitude larger than the improvement provided by the gleaning
1337 mechanism.
1339 With the increasing deployment of spoofing prevention techniques such
1340 as [RFC3704] or SAVI [SAVI], it can be expected that attackers will
1341 become less capable of sending packets with a spoofed source address.
1342 To prevent packet injection attacks from non-spoofing attackers
1343 (NSA), ETRs should always verify that the source RLOC of each
1344 received LISP data encapsulated packet corresponds to one of the
1345 RLOCs listed in the mappings for the source EID found in the inner
1346 packet. An alternative could be to use existing IPSec techniques
1347 [RFC4301] and when necessary including perhaps [RFC5386] to establish
1348 an authenticated tunnel between the ITR and the ETR.
1350 [RFC6830] recommends to rate limit the control messages that are sent
1351 by an xTR. This limit is important to deal with denial of service
1352 attacks. However, a strict limit, e.g., implemented with a token
1353 bucket, on all the Map-Request and Map-Reply messages sent by an xTR
1354 is not sufficient. An xTR should distinguish between different types
1355 of control plane packets:
1357 1. The Map-Request messages that it sends to refresh expired mapping
1358 information.
1360 2. The Map-Request messages that it sends to obtain mapping
1361 information because one of the served hosts tried to contact an
1362 external EID.
1364 3. The Map-Request messages that it sends as reachability probes.
1366 4. The Map-Reply messages that it sends as response to reachability
1367 probes.
1369 5. The Map-Request messages that it sends to support gleaning.
1371 These control plane messages are used for different purposes. Fixing
1372 a global rate limit for all control plane messages increases the risk
1373 of Denial of Service attacks if a single type of control plane
1374 message can exceed the configured limit. This risk could be
1375 mitigated by either specifying a rate for each of the five types of
1376 control plane messages. Another option could be to define a maximum
1377 rate for all control plane messages, and prioritize the control plane
1378 messages according to the list above (with the highest priority for
1379 message type 1).
1381 In [RFC6830], there is no mechanism that allows an xTR to verify the
1382 validity of the content a Map-Reply message that it receives.
1383 Besides the attacks discussed earlier in the document, a time-shifted
1384 attack where an attacker is able to modify the content of a Map-Reply
1385 message but then needs to move off-path could also create redirection
1386 attacks. The nonce only allows an xTR to verify that a Map-Reply
1387 responds to a previously sent Map-Request message. To verify the
1388 validity and integrity of bindings between EID-Prefixes and their
1389 RLOCS, solutions proposed in [I-D.saucez-lisp-mapping-security] and
1390 [I-D.ietf-lisp-sec] could be deployed. Having LISP-SEC and lisp-
1391 mapping-security in place would prevent all the above-mentioned
1392 threats.
1394 Finally, there is also the risk of Denial of Service attack against
1395 the EID-to-RLOC Cache. We have discussed these attacks when
1396 considering external attackers with, e.g., the gleaning mechanism and
1397 in Section 5.2. If an ITR has a limited EID-to-RLOC Cache, a
1398 malicious or compromised host residing in the site that it serves
1399 could generate packets to random destinations to force the ITR to
1400 issue a large number of Map-Requests whose answers could fill its
1401 cache. Faced with such misbehaving hosts, LISP ITR should be able to
1402 limit the percent of Map-Requests that it sends for a given source
1403 EID.
1405 In order to mitigate flooding attacks it would be worth consider
1406 developing secure mechanisms to allow an ETR to indicate to an ITR
1407 that it does not serve a particular EID or block of EIDs.
1409 12. IANA Considerations
1411 This document makes no request to IANA.
1413 13. Security Considerations
1415 Security considerations are the core of this document and do not need
1416 to be further discussed in this section.
1418 14. Acknowledgments
1420 This document builds upon the draft of Marcelo Bagnulo
1421 ([I-D.bagnulo-lisp-threat]), where the flooding attack and the
1422 reference environment were first described.
1424 The authors would like to thank Vina Ermagan, Darrel Lewis, and Jeff
1425 Wheeler for their comments.
1427 This work has been partially supported by the INFSO-ICT-216372
1428 TRILOGY Project (www.trilogy-project.org).
1430 15. References
1431 15.1. Normative References
1433 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
1434 Locator/ID Separation Protocol (LISP)", RFC 6830,
1435 January 2013.
1437 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
1438 "Interworking between Locator/ID Separation Protocol
1439 (LISP) and Non-LISP Sites", RFC 6832, January 2013.
1441 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation
1442 Protocol (LISP) Map-Server Interface", RFC 6833,
1443 January 2013.
1445 [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
1446 Separation Protocol (LISP) Map-Versioning", RFC 6834,
1447 January 2013.
1449 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
1450 "Locator/ID Separation Protocol Alternative Logical
1451 Topology (LISP+ALT)", RFC 6836, January 2013.
1453 [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to
1454 Routing Locator (RLOC) Database", RFC 6837, January 2013.
1456 15.2. Informative References
1458 [Chu] Jerry Chu, H., "Tuning TCP Parameters for the 21st
1459 Century", 75th IETF, Stockholm, July 2009,
1460 .
1462 [I-D.bagnulo-lisp-threat]
1463 Bagnulo, M., "Preliminary LISP Threat Analysis",
1464 draft-bagnulo-lisp-threat-01 (work in progress),
1465 July 2007.
1467 [I-D.ietf-lisp-ddt]
1468 Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP
1469 Delegated Database Tree", draft-ietf-lisp-ddt-00 (work in
1470 progress), October 2012.
1472 [I-D.ietf-lisp-sec]
1473 Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D.,
1474 and O. Bonaventure, "LISP-Security (LISP-SEC)",
1475 draft-ietf-lisp-sec-04 (work in progress), October 2012.
1477 [I-D.ietf-tcpm-tcp-security]
1478 Gont, F., "Survey of Security Hardening Methods for
1479 Transmission Control Protocol (TCP) Implementations",
1480 draft-ietf-tcpm-tcp-security-03 (work in progress),
1481 March 2012.
1483 [I-D.meyer-lisp-cons]
1484 Brim, S., "LISP-CONS: A Content distribution Overlay
1485 Network Service for LISP", draft-meyer-lisp-cons-04 (work
1486 in progress), April 2008.
1488 [I-D.saucez-lisp-mapping-security]
1489 Saucez, D. and O. Bonaventure, "Securing LISP Mapping
1490 replies", draft-saucez-lisp-mapping-security-00 (work in
1491 progress), February 2011.
1493 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
1494 Networks", BCP 84, RFC 3704, March 2004.
1496 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
1497 Internet Protocol", RFC 4301, December 2005.
1499 [RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing
1500 Security: An Unauthenticated Mode of IPsec", RFC 5386,
1501 November 2008.
1503 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
1504 Secure Internet Routing", RFC 6480, February 2012.
1506 [SAVI] IETF, "Source Address Validation Improvements Working
1507 Group", .
1509 [Saucez09]
1510 Saucez, D. and L. Iannone, "How to mitigate the effect of
1511 scans on mapping systems", Submitted to the Trilogy
1512 Summer School on Future Internet.
1514 Appendix A. Document Change Log
1516 o Version 04 Posted February 2013.
1518 * Clear statement that the document compares threats of public
1519 LISP deployments with threats in the current Internet
1520 architecture.
1522 * Addition of a severity level discussion at the end of each
1523 section.
1525 * Addressed comments from D. Lewis' review.
1527 * Updated References.
1529 * Further editorial polishing.
1531 o Version 03 Posted October 2012.
1533 * Dropped Reference to RFC 2119 notation because it is not
1534 actually used in the document.
1536 * Deleted future plans section.
1538 * Updated References
1540 * Deleted/Modified sentences referring to the early status of the
1541 LISP WG and documents at the time of writing early versions of
1542 the document.
1544 * Further editorial polishing.
1546 * Fixed all ID nits.
1548 o Version 02 Posted September 2012.
1550 * Added a new attack that combines overclaiming and de-
1551 aggregation (see Section 6.2).
1553 * Editorial polishing.
1555 o Version 01 Posted February 2012.
1557 * Added discussion on LISP-DDT in Section 9.2.
1559 o Version 00 Posted July 2011.
1561 * Added discussion on LISP-MS in Section 10.
1563 * Added discussion on Instance ID in Section 5.4.
1565 * Editorial polishing of the whole document.
1567 * Added "Change Log" appendix to keep track of main changes.
1569 * Renamed "draft-saucez-lisp-security-03.txt.
1571 Authors' Addresses
1573 Damien Saucez
1574 INRIA
1575 2004 route des Lucioles BP 93
1576 06902 Sophia Antipolis Cedex
1577 France
1579 Email: damien.saucez@inria.fr
1581 Luigi Iannone
1582 Telecom ParisTech
1583 23, Avenue d'Italie, CS 51327
1584 75214 PARIS Cedex 13
1585 France
1587 Email: luigi.iannone@telecom-paristech.fr
1589 Olivier Bonaventure
1590 Universite catholique de Louvain
1591 Place St. Barbe 2
1592 Louvain la Neuve
1593 Belgium
1595 Email: olivier.bonaventure@uclouvain.be