idnits 2.17.1
draft-ietf-lisp-threats-07.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
-- The document has examples using IPv4 documentation addresses according
to RFC6890, but does not use any IPv6 documentation addresses. Maybe
there should be IPv6 examples, too?
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (October 07, 2013) is 3854 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Unused Reference: 'Chu' is defined on line 775, but no explicit
reference was found in the text
== Unused Reference: 'I-D.ietf-tcpm-tcp-security' is defined on line 793,
but no explicit reference was found in the text
== Unused Reference: 'I-D.saucez-lisp-mapping-security' is defined on line
804, but no explicit reference was found in the text
== Unused Reference: 'RFC3704' is defined on line 809, but no explicit
reference was found in the text
== Unused Reference: 'RFC5386' is defined on line 815, but no explicit
reference was found in the text
== Unused Reference: 'RFC6480' is defined on line 819, but no explicit
reference was found in the text
== Unused Reference: 'SAVI' is defined on line 822, but no explicit
reference was found in the text
== Unused Reference: 'Saucez09' is defined on line 825, but no explicit
reference was found in the text
** 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-01
== Outdated reference: A later version (-29) exists of
draft-ietf-lisp-sec-04
Summary: 3 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group D. Saucez
3 Internet-Draft INRIA
4 Intended status: Informational L. Iannone
5 Expires: April 10, 2014 Telecom ParisTech
6 O. Bonaventure
7 Universite catholique de Louvain
8 October 07, 2013
10 LISP Threats Analysis
11 draft-ietf-lisp-threats-07.txt
13 Abstract
15 This document proposes a threat analysis of the Locator/Identifier
16 Separation Protocol (LISP) if deployed in the Internet.
18 Status of This Memo
20 This Internet-Draft is submitted in full conformance with the
21 provisions of BCP 78 and BCP 79.
23 Internet-Drafts are working documents of the Internet Engineering
24 Task Force (IETF). Note that other groups may also distribute
25 working documents as Internet-Drafts. The list of current Internet-
26 Drafts is at http://datatracker.ietf.org/drafts/current/.
28 Internet-Drafts are draft documents valid for a maximum of six months
29 and may be updated, replaced, or obsoleted by other documents at any
30 time. It is inappropriate to use Internet-Drafts as reference
31 material or to cite them other than as "work in progress."
33 This Internet-Draft will expire on April 10, 2014.
35 Copyright Notice
37 Copyright (c) 2013 IETF Trust and the persons identified as the
38 document authors. All rights reserved.
40 This document is subject to BCP 78 and the IETF Trust's Legal
41 Provisions Relating to IETF Documents
42 (http://trustee.ietf.org/license-info) in effect on the date of
43 publication of this document. Please review these documents
44 carefully, as they describe your rights and restrictions with respect
45 to this document. Code Components extracted from this document must
46 include Simplified BSD License text as described in Section 4.e of
47 the Trust Legal Provisions and are provided without warranty as
48 described in the Simplified BSD License.
50 Table of Contents
52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
53 2. On-path Attackers . . . . . . . . . . . . . . . . . . . . . . 3
54 3. Off-Path Attackers: Reference Environment . . . . . . . . . . 3
55 4. Attack vectors . . . . . . . . . . . . . . . . . . . . . . . 5
56 4.1. Configured EID-to-RLOC mappings . . . . . . . . . . . . . 5
57 4.2. EID-to-RLOC Cache . . . . . . . . . . . . . . . . . . . . 6
58 4.3. Attacks using the data-plane . . . . . . . . . . . . . . 6
59 4.3.1. Attacks not leveraging on the LISP header . . . . . . 7
60 4.3.2. Attacks leveraging on the LISP header . . . . . . . . 8
61 4.4. Attacks using the control-plane . . . . . . . . . . . . . 10
62 4.4.1. Attacks with Map-Request messages . . . . . . . . . . 11
63 4.4.2. Attacks with Map-Reply messages . . . . . . . . . . . 12
64 4.4.3. Attacks with Map-Register messages . . . . . . . . . 13
65 4.4.4. Attacks with Map-Notify messages . . . . . . . . . . 14
66 5. Attack categories . . . . . . . . . . . . . . . . . . . . . . 14
67 5.1. Intrusion . . . . . . . . . . . . . . . . . . . . . . . . 14
68 5.1.1. Description . . . . . . . . . . . . . . . . . . . . . 14
69 5.1.2. Vectors . . . . . . . . . . . . . . . . . . . . . . . 14
70 5.2. Denial of Service (DoS) . . . . . . . . . . . . . . . . . 14
71 5.2.1. Description . . . . . . . . . . . . . . . . . . . . . 14
72 5.2.2. Vectors . . . . . . . . . . . . . . . . . . . . . . . 14
73 5.3. Subversion . . . . . . . . . . . . . . . . . . . . . . . 15
74 5.3.1. Description . . . . . . . . . . . . . . . . . . . . . 15
75 5.3.2. Vectors . . . . . . . . . . . . . . . . . . . . . . . 15
76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
78 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
80 9.1. Normative References . . . . . . . . . . . . . . . . . . 16
81 9.2. Informative References . . . . . . . . . . . . . . . . . 17
82 Appendix A. Document Change Log . . . . . . . . . . . . . . . . 18
83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
85 1. Introduction
87 The Locator/ID Separation Protocol (LISP) is defined in [RFC6830].
88 The present document assesses the security level and identifies
89 security threats in the LISP specification if LISP is deployed in the
90 Internet (i.e., a public non-trustable environment). As a result of
91 the performed analysis, the document discusses the severity of the
92 threats and proposes recommendations to reach the same level of
93 security in LISP than in Internet today (e.g., without LISP).
95 The document is composed of three main parts: the first discussing
96 the LISP data-plane; while the second discussing the LISP control-
97 plane. The final part summarizes the recommendations to prevent the
98 identified threats.
100 The LISP data-plane consists of LISP packet encapsulation,
101 decapsulation, and forwarding and includes the map cache data
102 structures used to perform these operations.
104 The LISP control-plane consists in the mapping distribution system,
105 which can be one of the mapping distribution systems proposed so far
106 (e.g., [RFC6830], [I-D.ietf-lisp-ddt], [RFC6836], [RFC6833],
107 [I-D.meyer-lisp-cons], and [RFC6837]), and the Map-Request, Map-
108 Reply, Map-Register, and Map-Notification messages.
110 This document does not consider all the possible uses of LISP as
111 discussed in [RFC6830]. The document focuses on LISP unicast,
112 including as well LISP Interworking [RFC6832], LISP-MS [RFC6833], and
113 LISP Map-Versioning [RFC6834]. The reading of these documents is a
114 prerequisite for understanding the present document.
116 Unless otherwise stated, the document assumes a generic IP service
117 and does not discuss the difference, from a security viewpoint,
118 between using IPv4 or IPv6.
120 2. On-path Attackers
122 On-path attackers are attackers that are able to capture and modify
123 all the packets exchanged between an Ingress Tunnel Router (ITR) and
124 an Egress Tunnel Router (ETR). To cope with such an attacker,
125 cryptographic techniques such as those used by IPSec ([RFC4301]) are
126 required. As with IP, LISP relies on higher layer cryptography to
127 secure packet payloads from on path attacks, so we do not consider
128 on-path attackers in this document.
130 Similarly, a time-shifted attack is an attack where the attacker is
131 temporarily on the path between two communicating hosts. While it is
132 on-path, the attacker sends specially crafted packets or modifies
133 packets exchanged by the communicating hosts in order to disturb the
134 packet flow (e.g., by performing a man in the middle attack). An
135 important issue for time-shifted attacks is the duration of the
136 attack once the attacker has left the path between the two
137 communicating hosts. We do not consider time-shifted attacks in this
138 document.
140 3. Off-Path Attackers: Reference Environment
141 Throughout this document we consider the reference environment shown
142 in the figure below. There are two hosts attached to LISP routers:
143 HA and HB. HA is attached to the two LISP xTRs LR1 and LR2, which in
144 turn are attached to two different ISPs. HB is attached to the two
145 LISP xTRs LR3 and LR4. HA and HB are the EIDs of the two hosts.
146 LR1, LR2, LR3, and LR4 are the RLOCs of the xTRs. PxTR is a proxy
147 xTR and MR/MS plays the roles of Map Server and/or Map Resolver.
149 +-----+
150 | HA |
151 +-----+
152 | EID: HA
153 |
154 -----------------
155 | |
156 +-----+ +-----+
157 | LR1 | | LR2 |
158 +-----+ +-----+
159 | |
160 | |
161 +-----+ +-----+
162 |ISP1 | |ISP2 |
163 +-----+ +-----+
164 | |
165 +------+ +----------------+ +-----+
166 | PxTR |-----| |-----| SA |
167 +------+ | | +-----+
168 | Internet |
169 +-------+ | | +-----+
170 | MR/MS |----| |-----| NSA |
171 +-------+ +----------------+ +-----+
172 | |
173 +-----+ +-----+
174 | LR3 | | LR4 |
175 +-----+ +-----+
176 | |
177 -------------------
178 |
179 | EID: HB
180 +-----+
181 | HB |
182 +-----+
184 Figure 1: Reference Network
186 We consider two off-path attackers with different capabilities:
188 SA is an off-path attacker that is able to send spoofed packets,
189 i.e., packets with a different source IP address than its
190 assigned IP address. SA stands for Spoofing Attacker.
192 NSA is an off-path attacker that is only able to send packets whose
193 source address is its assigned IP address. NSA stands for Non
194 Spoofing Attacker.
196 It should be noted that with LISP, packet spoofing is slightly
197 different than in the current Internet. Generally the term "spoofed
198 packet" indicates a packet containing a source IP address that is not
199 the one of the actual originator of the packet. Since LISP uses
200 encapsulation, the spoofed address could be in the outer header as
201 well as in the inner header, this translates in two types of
202 spoofing:
204 EID Spoofing: the originator of the packet puts in it a spoofed EID.
205 The packet will be normally encapsulated by the ITR of the site
206 (or a PITR if the source site is not LISP enabled).
208 RLOC Spoofing: the originator of the packet generates directly a
209 LISP-encapsulated packet with a spoofed source RLOC.
211 Note that the two types of spoofing are not mutually exclusive,
212 rather all combinations are possible and could be used to perform
213 different kind of attacks.
215 In the reference environment, both SA and NSA attackers are capable
216 of sending LISP encapsulated data packets and LISP control packets.
217 This means that SA is able to perform both RLOC and EID spoofing
218 while NSA can only perform EID spoofing. They may also send other
219 types of IP packets such as ICMP messages. We assume that both
220 attackers can query the LISP mapping system (e.g., through a public
221 Map Resolver) to obtain the mappings for both HA and HB.
223 4. Attack vectors
225 This section presents techniques that can be used by attackers to
226 succeed attacks leveraging the LISP protocol and architecture. This
227 section focuses on the techniques while Section 5 presents the
228 attacks that can be succeeded while using these techniques.
230 4.1. Configured EID-to-RLOC mappings
232 Each xTR maintains a set of configured mappings related to the EID-
233 Prefixes that are "behind" the xTR [RFC6830]. Where "behind" means
234 that at least one of the xTR's globally visible IP addresses is a
235 RLOC for those EID-Prefixes.
237 As these mappings are determined by configuration. This means that
238 the only way to attack this data structure is by gaining privileged
239 access to the xTR. As such, it is out of the scope of LISP to
240 propose any mechanism to protect routers and, hence, it is no further
241 analyzed in this document.
243 4.2. EID-to-RLOC Cache
245 The EID-to-RLOC Cache (also called the Map-Cache) is the data
246 structure that stores a copy of the mappings retrieved from a remote
247 ETR's mapping via the LISP control-plane. Attacks against this data
248 structure could happen either when the mappings are first installed
249 in the cache or by corrupting (poisoning) the mappings already
250 present in the cache.
252 In this document we call "cache poisoning attack", any attack that
253 alters the EID-to-RLOC Cache. Cache poisoning attacks are use to
254 alter (any combination of) the following parts of mapping installed
255 in the EID-to-RLOC Cache:
257 o EID prefix
259 o RLOC list
261 o RLOC priority
263 o RLOC weight
265 o RLOC reachability
267 o Mapping TTL
269 o Mapping version
271 o Mapping Instance ID
273 4.3. Attacks using the data-plane
275 The data-plane is constituted of the operations of encapsulation,
276 decapsulation, and forwarding as well as the content of the EID-to-
277 RLOC Cache and configured EID-to-RLOC mappings as specified in the
278 original LISP document ([RFC6830]).
280 4.3.1. Attacks not leveraging on the LISP header
282 An attacker can inject packets into flows without using the LISP
283 header, i.e., with the N, L, E, V, and I bits ([RFC6830]).
285 Taking notation of the reference environment notation (Figure 1), to
286 inject a packet in the HA->HB flow, a spoofing off-path attacker (SA)
287 could send a LISP encapsulated packet whose source is set to LR1 or
288 LR2 and destination LR3 or LR4. The packet will reach HB as if the
289 packet was sent by host HA. This is not different from today's
290 Internet where a spoofing off-path attacker may inject data packets
291 in any flow. A non-spoofing off-path attacker (NSA) could only send
292 a packet whose source address is set to its assigned IP address. The
293 destination address of the encapsulated packet could be LR3 or LR4.
295 4.3.1.1. Gleaning Attacks
297 In order to reduce the time required to obtain a mapping, [RFC6830]
298 proposes the gleaning mechanism that allows an ITR to learn a mapping
299 from the LISP data encapsulated packets and the Map-Request packets
300 that it receives. LISP data encapsulated packet contains a source
301 RLOC, destination RLOC, source EID and destination EID. When an ITR
302 receives a data encapsulated packet coming from a source EID for
303 which it does not already know a mapping, it may insert the mapping
304 between the source RLOC and the source EID in its EID-to-RLOC Cache.
305 Gleaning could also be used when an ITR receives a Map-Request as the
306 Map-Request also contains a source EID address and a source RLOC.
307 Once a gleaned entry has been added to the EID-to-RLOC cache, the
308 LISP ITR sends a Map-Request to retrieve the mapping for the gleaned
309 EID from the mapping system. [RFC6830] recommends storing the
310 gleaned entries for only a few seconds.
312 An attacker can send LISP encapsulated packets to host HB with host
313 HA's EID and if the xTRs that serve host HB do not store a mapping
314 for host HA at that time. The xTR will store the gleaned entry and
315 use it to return the packets sent by host HB. In parallel, the ETR
316 will send a Map-Request to retrieve the mapping for HA but until the
317 reception of the Map-Reply, host HB will exchange packets with the
318 attacker instead of HA.
320 Similarly, if an off-path attacker knows that hosts HA and HB that
321 resides in different sites will exchange information at time t the
322 attacker could send to LR1 (resp. LR3) a LISP data encapsulated
323 packet whose source RLOC is its IP address and contains an IP packet
324 whose source is set to HB (resp. HA). The attacker chooses a packet
325 that will not trigger an answer, for example the last part of a
326 fragmented packet. Upon reception of these packets, LR1 and LR3
327 install gleaned entries that point to the attacker. If host HA is
328 willing to establishes a flow with host HB at that time, the packets
329 that they exchange will pass through the attacker as long as the
330 gleaned entry is active on the xTRs.
332 By itself, an attack made solely using gleaning cannot last long,
333 however it should be noted that with current network capacities, a
334 large amount of packets might be exchanged during even a small
335 fraction of time.
337 4.3.1.2. Threats concerning Interworking
339 [RFC6832] defines Proxy-ITR And Proxy-ETR network elements to allow
340 LISP and non-LISP sites to communicate. The Proxy-ITR has
341 functionality similar to the ITR, however, its main purpose is to
342 encapsulate packets arriving from the DFZ in order to reach LISP
343 sites. A Proxy-ETR has functionality similar to the ETR, however,
344 its main purpose is to inject de-encapsulated packets in the DFZ in
345 order to reach non-LISP Sites from LISP sites. As a PITR (resp.
346 PETR) is a particular case of ITR (resp. ETR), it is subject to same
347 attacks than ITRs (resp. ETR).
349 PxTRs can be targeted by attacks aiming to influence traffic between
350 LISP and non-LISP sites but also to launch relay attacks.
352 It is worth to notice that when PITR and PETR functions are
353 separated, attacks targeting nodes that collocate PITR and PETR
354 functionality are ineffective.
356 4.3.2. Attacks leveraging on the LISP header
358 The main LISP document [RFC6830] defines several flags that modify
359 the interpretation of the LISP header in data packets. In this
360 section, we discuss how an off-path attacker could exploit this LISP
361 header.
363 4.3.2.1. Attacks using the Locator Status Bits
365 When the L bit is set to 1, it indicates that the second 32-bits
366 longword of the LISP header contains the Locator Status Bits. In
367 this field, each bit position reflects the status of one of the RLOCs
368 mapped to the source EID found in the encapsulated packet. In
369 particular, a packet with the L bit set and all Locator Status Bits
370 set to zero indicates that none of the locators of the encapsulated
371 source EID are reachable. The reaction of a LISP ETR that receives
372 such a packet is not clearly described in [RFC6830].
374 An attacker can send a data packet with the L bit set to 1 and some
375 or all Locator Status Bits set to zero. Therefore, by blindly
376 trusting the Locator Status Bits communication going on can be
377 altered or forced to go through a particular set of locators.
379 4.3.2.2. Attacks using the Map-Version bit
381 The optional Map-Version bit is used to indicate whether the low-
382 order 24 bits of the first 32 bits longword of the LISP header
383 contain a Source and Destination Map-Version. When a LISP ETR
384 receives a LISP encapsulated packet with the Map-Version bit set to
385 1, the following actions are taken:
387 o It compares the Destination Map-Version found in the header with
388 the current version of its own configured EID-to-RLOC mapping, for
389 the destination EID found in the encapsulated packet. If the
390 received Destination Map-Version is smaller (i.e., older) than the
391 current version, the ETR should apply the SMR procedure described
392 in [RFC6830] and send a Map-Request with the SMR bit set.
394 o If a mapping exists in the EID-to-RLOC Cache for the source EID,
395 then it compares the Map-Version of that entry with the Source
396 Map-Version found in the header of the packet. If the stored
397 mapping is older (i.e., the Map-Version is smaller) than the
398 source version of the LISP encapsulated packet, the xTR should
399 send a Map-Request for the source EID.
401 An off-path attacker could use the Map-Version bit to force an ETR to
402 send Map-Request messages. The attacker could retrieve the current
403 source and destination Map-Version for both HA and HB. Based on this
404 information, it could send a spoofed packet with an older Source Map-
405 Version or Destination Map-Version. If the size of the Map-Request
406 message is larger than the size of the smallest LISP-encapsulated
407 packet that could trigger such a message, this could lead to
408 amplification attacks (see Section 4.4.1) so that more bandwidth is
409 consumed on the target than the bandwidth necessary at the attacker
410 side.
412 4.3.2.3. Attacks using the Nonce-Present and the Echo-Nonce bits
414 The Nonce-Present and Echo-Nonce bits are used when verifying the
415 reachability of a remote ETR. Assume that LR3 wants to verify that
416 LR1 receives the packets that it sends. LR3 can set the Echo-Nonce
417 and the Nonce-Present bits in LISP data encapsulated packets and
418 include a random nonce in these packets. Upon reception of these
419 packets, LR1 will store the nonce sent by LR3 and echo it when it
420 returns LISP encapsulated data packets to LR3.
422 A spoofing off-path attacker (SA) could interfere with this
423 reachability test by sending two different types of packets:
425 1. LISP data encapsulated packets with the Nonce-Present bit set and
426 a random nonce and the appropriate source and destination RLOCs.
428 2. LISP data encapsulated packets with the Nonce-Present and the
429 Echo-Nonce bits both set and the appropriate source and
430 destination RLOCs. These packets will force the receiving ETR to
431 store the received nonce and echo it in the LISP encapsulated
432 packets that it sends.
434 The first type of packet should not cause any major problem to ITRs.
435 As the reachability test uses a 24 bits nonce, it is unlikely that an
436 off-path attacker could send a single packet that causes an ITR to
437 believe that the ETR it is testing is reachable while in reality it
438 is not reachable. To increase the success likelihood of such attack,
439 the attacker should created a massive amount of packets carrying all
440 possible nonce values.
442 The second type of packet could be exploited to attack the nonce-
443 based reachability test. Consider a spoofing off-path attacker (SA)
444 that sends a continuous flow of spoofed LISP data encapsulated
445 packets that contain the Nonce-Present and the Echo-Nonce bit and
446 each packet contains a different random nonce. The ETR that receives
447 such packets will continuously change the nonce that it returns to
448 the remote ITR. If the remote ITR starts a nonce-reachability test,
449 this test may fail because the ETR has received a spoofed LISP data
450 encapsulated packet with a different random nonce and never echoes
451 the real nonce. In this case the ITR will consider the ETR not
452 reachable. The success of this test depends on the ratio between the
453 amount of packets sent by the legitimate ITR and the spoofing off-
454 path attacker (SA).
456 4.3.2.4. Attacks using the Instance ID bits
458 LISP allows to carry in its header a 24-bits value called "Instance
459 ID" and used on the ITR to indicate which local Instance ID has been
460 used for encapsulation, while on the ETR can be used to select the
461 forwarding table used for forwarding the decapsulated packet.
463 The Instance ID increases exposure to attacks ([RFC6169]) as if an
464 off-path attacker can randomly guess a valid Instance ID value to get
465 access to network that might not been accessible in normal
466 conditions. However, the impact of such attack is directly on end-
467 systems which is is out of the scope of this document.
469 4.4. Attacks using the control-plane
471 In this section, we discuss the different types of attacks that could
472 occur when an off-path attacker sends control-plane packets. We
473 focus on the packets that are sent directly to the ETR and do not
474 analyze the particularities of the different LISP indexing sub-
475 system.
477 4.4.1. Attacks with Map-Request messages
479 An off-path attacker could send Map-Request packets to a victim ETR.
480 In theory, a Map-Request packet is only used to solicit an answer and
481 as such it should not lead to security problems. However, the LISP
482 specification [RFC6830] contains several particularities that could
483 be exploited by an off-path attacker.
485 The first possible exploitation is the RLOC record P bit. The RLOC
486 record P bit is used to probe the reachability of remote ETRs. In
487 our reference environment, LR3 could probe the reachability of LR1 by
488 sending a Map-Request with the RLOC record P bit set. LR1 would
489 reply by sending a Map-Reply message with the RLOC record P bit set
490 and the same nonce as in the Map-Request message.
492 A spoofing off-path attacker (SA) could use the RLOC record P bit to
493 force a victim ETR to send a Map-Reply to the spoofed source address
494 of the Map-Request message. As the Map-Reply can be larger than the
495 Map-Request message, there is a risk of amplification attack.
496 Considering only IPv6 addresses, a Map-Request can be as small as 40
497 bytes, considering one single ITR address and no Mapping Protocol
498 Data. The Map-Reply instead has a proportional to the maximum number
499 of RLOCs in a mapping and maximum number of records in a Map-Reply.
500 Since up to 255 RLOCs can be associated to an EID-Prefix and 255
501 records can be stored in a Map-Reply, the maximum size of a Map-Reply
502 is thus above 1 MB, largely bigger than the message sent by the
503 attacker. These numbers are however theoretical values not
504 considering transport layer limitations and it is more likely that
505 the reply will contain only one record with at most a dozen of
506 locators, limiting so the amplification factor.
508 Similarly, if a non-spoofing off-path attacker (NSA) sends a Map-
509 Request with the RLOC record P bit set, it will receive a Map-Reply
510 with the RLOC record P bit set.
512 An amplification attack could be launched by a spoofing off-path
513 attacker (SA) as follows. Consider an attacker SA and EID-Prefix
514 192.0.2.0/24 and a victim ITR, SA could send spoofed Map-Request
515 messages whose source EID addresses are all the addresses inside
516 192.0.2.0/24 and source RLOC address is the victim ITR. Upon
517 reception of these Map-Request messages, the ETR would send large
518 Map-Reply messages for each of the addresses inside p/P back to the
519 victim ITR.
521 The Map-Request message may also contain the SMR bit. Upon reception
522 of a Map-Request message with the SMR bit, an ETR must return to the
523 source of the Map-Request message a Map-Request message to retrieve
524 the corresponding mapping. This raises similar problems as the RLOC
525 record P bit discussed above except that as the Map-Request messages
526 are smaller than Map-Reply messages, the risk of amplification
527 attacks is reduced. This is not true anymore if the ETR append to
528 the Map-Request messages its own Map-Records. This mechanism is
529 meant to reduce the delay in mapping distribution since mapping
530 information is provided in the Map-Request message.
532 Furthermore, appending Map-Records to Map-Request messages allows an
533 off-path attacker to generate a (spoofed or not) Map-Request message
534 and include in the Map-Reply portion of the message mapping for EID
535 prefixes that it does not serve.
537 Moreover, attackers can use Map Resolver and/or Map Server network
538 elements to perform relay attacks. Indeed, on the one hand, a Map
539 Resolver is used to dispatch Map-Request to the mapping system and,
540 on the other hand, a Map Server is used to dispatch Map-Requests
541 coming from the mapping system to ETRs that are authoritative for the
542 EID in the Map-Request.
544 4.4.2. Attacks with Map-Reply messages
546 In this section we analyze the attacks that could occur when an off-
547 path attacker sends directly Map-Reply messages to ETRs without using
548 one of the proposed LISP mapping systems.
550 There are two different types of Map-Reply messages:
552 Positive Map-Reply: These messages contain a Map-Record binding an
553 EID-Prefix to one or more RLOCs.
555 Negative Map-Reply: These messages contain a Map-Record for an EID-
556 Prefix with an empty locator-set and specifying an action,
557 which may be either Drop, natively forward, or Send Map-
558 Request.
560 Positive Map-Reply messages are used to map EID-Prefixes onto RLOCs.
561 Negative Map-Reply messages are used to indicate non-LISP prefixes.
562 ITRs can, if needed, be configured to send all traffic destined for
563 non-LISP prefixes to a Proxy-ETR.
565 Most of the security of the Map-Reply messages depends on the 64 bits
566 nonce that is included in a Map-Request and returned in the Map-
567 Reply. If an ETR does not accept Map-Reply messages with an invalid
568 nonce, the risk of attack is acceptable given the size of the nonce
569 (64 bits). However, the nonce only confirms that the Map-Reply
570 received was sent in response to a Map-Request sent, it does not
571 validate the contents of that Map-Reply.
573 In addition, an attacker could perform EID-to-RLOC Cache overflow
574 attack by de-aggregating (i.e., splitting an EID prefix into
575 artificially smaller EID prefixes) either positive or negative
576 mappings.
578 In presence of malicious ETRs, overclaiming attacks are possible.
579 Such an attack happens when and ETR replies to a legitimate Map-
580 Request message it received with a Map-Reply message that contains an
581 EID-Prefix that is larger than the prefix owned by the site that
582 encompasses the EID of the Map-Request. For instance if the prefix
583 owned by the site is 192.0.2.0/25 but the Map-Reply contains a
584 mapping for 192.0.2.0/24, then the mapping will influence packets
585 destined to other EIDs than the one the LISP site has authority on.
587 A malicious ETR might also fragment its configured EID-to-RLOC
588 mappings so that ITR's might have to install much more mappings than
589 really necessary. This attack is called de-aggregation attack.
591 4.4.3. Attacks with Map-Register messages
593 Map-Register messages are sent by ETRs to indicate to the mapping
594 system the EID prefixes associated to them. The Map-Register message
595 provides an EID prefix and the list of ETRs that are able to provide
596 Map-Replies for the EID covered by the EID prefix.
598 As Map-Register messages are protected by an authentication
599 mechanism, only a compromised ETR can register itself to its
600 allocated Map Server.
602 A compromised ETR can perform an overclaiming attack in order to
603 influence the route followed by Map-Requests for EIDs outside the
604 scope of its legitimate EID prefix.
606 A compromised ETR can also perform a deaggregation attack in order to
607 register more EID prefixes than necessary to its Map Servers.
609 Similarly, a compromised Map Server can accept invalid registration
610 or advertise invalid EID prefix to the indexing sub-system.
612 4.4.4. Attacks with Map-Notify messages
614 Map-Notify messages are sent by a Map Server to an ETR to acknowledge
615 the good reception and processing of a Map-Register message.
617 An compromised ETR using EID that it is not authoritative for can
618 send a Map-Register with the M-bit set and a spoofed source address
619 to force the Map Server to send a Map-Notify message to the spoofed
620 address and then succeed a relay attack. Similarly to the pair Map-
621 Request/Map-Reply, the pair Map-Register/Map-Notify is protected by a
622 nonce making it hard for an attacker to inject a falsified
623 notification to an ETR to make this ETR believe that the registration
624 succeeded while it has not.
626 5. Attack categories
628 5.1. Intrusion
630 5.1.1. Description
632 With an intrusion attack an attacker gains remote access to some
633 resources (e.g., a host, a router, or a network) that are normally
634 denied to her.
636 5.1.2. Vectors
638 Intrusion attacks can be mounted using:
640 o Spoofing EID or RLOCs
642 o Instance ID bits
644 5.2. Denial of Service (DoS)
646 5.2.1. Description
648 A Denial of Service (DoS) attack aims at disrupting a specific
649 targeted service either by exhausting the resources of the victim up
650 to the point that it is not able to provide a reliable service to
651 legit traffic and/or systems or by exploiting vulnerabilities to make
652 the targeted service unable to operate properly.
654 5.2.2. Vectors
656 Denial of Service attacks can be mounted using
658 o Gleaning
659 o Interworking
661 o Locator Status Bits
663 o Map-Version bit
665 o Nonce-Present and Echo-Nonce bits
667 o Map-Request message
669 o Map-Reply message
671 o Map-Register message
673 o Map-Notify message
675 5.3. Subversion
677 5.3.1. Description
679 With subversion an attacker can gain access (e.g., using
680 eavesdropping or impersonation) to restricted or sensitive
681 information such as passwords, session tokens, or any other
682 confidential information. This type of attack is usually carried out
683 in a way such that the target does not even notice the attack. When
684 the attacker is positioned on the path of the target traffic, it is
685 called a Man-in-the-Middle attack. However, this is not a
686 requirement to carry out and eavesdropping attack. Indeed the
687 attacker might be able, for instance through an intrusion attack on a
688 weaker system, either to duplicate or even re-direct the traffic, in
689 both cases having access to the raw packets.
691 5.3.2. Vectors
693 Subversion attacks can be mounted using
695 o Gleaning
697 o Locator Status Bits
699 o Nonce-Present and the Echo-Nonce bits
701 o Map-Request messages
703 o Map-Reply messages
705 6. IANA Considerations
706 This document makes no request to IANA.
708 7. Security Considerations
710 This document is devoted to threat analysis of the Locator/Identifier
711 Separation Protocol and is then a piece of choice to understand the
712 security risks at stake while deploying LISP in non-trustable
713 environment.
715 The purpose of this document is not to provide recommendations to
716 protect against attacks, however most of threats can be prevented
717 with careful deployment and configuration (e.g., filter) and also by
718 applying the general rules in security that consist in activating
719 only features that are necessary in the deployment and verifying the
720 validity of the information obtained from third parties. More
721 detailed recommendation are given in [book_chapter].
723 The control-plane is probably the most critical part of LISP from a
724 security viewpoint and it is worth to notice that the specifications
725 already offer authentication mechanism for Map-Register messages
726 ([RFC6833]) and that [I-D.ietf-lisp-sec] and [I-D.ietf-lisp-ddt] are
727 clearly going in the direction of a secure control-plane.
729 8. Acknowledgments
731 This document builds upon the draft of Marcelo Bagnulo
732 ([I-D.bagnulo-lisp-threat]), where the flooding attack and the
733 reference environment were first described.
735 The authors would like to thank Ronald Bonica, Albert Cabellos, Noel
736 Chiappa, Florin Coras, Vina Ermagan, Dino Farinacci, Joel Halpern,
737 Emily Hiltzik, Darrel Lewis, Edward Lopez, Fabio Maino, Terry
738 Manderson, and Jeff Wheeler for their comments.
740 This work has been partially supported by the INFSO-ICT-216372
741 TRILOGY Project (www.trilogy-project.org).
743 9. References
745 9.1. Normative References
747 [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security
748 Concerns with IP Tunneling", RFC 6169, April 2011.
750 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
751 Locator/ID Separation Protocol (LISP)", RFC 6830, January
752 2013.
754 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
755 "Interworking between Locator/ID Separation Protocol
756 (LISP) and Non-LISP Sites", RFC 6832, January 2013.
758 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation
759 Protocol (LISP) Map-Server Interface", RFC 6833, January
760 2013.
762 [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
763 Separation Protocol (LISP) Map-Versioning", RFC 6834,
764 January 2013.
766 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
767 "Locator/ID Separation Protocol Alternative Logical
768 Topology (LISP+ALT)", RFC 6836, January 2013.
770 [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to
771 Routing Locator (RLOC) Database", RFC 6837, January 2013.
773 9.2. Informative References
775 [Chu] Jerry Chu, H., "Tuning TCP Parameters for the 21st Century
776 ", 75th IETF, Stockholm, July 2009,
777 .
779 [I-D.bagnulo-lisp-threat]
780 Bagnulo, M., "Preliminary LISP Threat Analysis", draft-
781 bagnulo-lisp-threat-01 (work in progress), July 2007.
783 [I-D.ietf-lisp-ddt]
784 Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP
785 Delegated Database Tree", draft-ietf-lisp-ddt-01 (work in
786 progress), March 2013.
788 [I-D.ietf-lisp-sec]
789 Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D.,
790 and O. Bonaventure, "LISP-Security (LISP-SEC)", draft-
791 ietf-lisp-sec-04 (work in progress), October 2012.
793 [I-D.ietf-tcpm-tcp-security]
794 Gont, F., "Survey of Security Hardening Methods for
795 Transmission Control Protocol (TCP) Implementations",
796 draft-ietf-tcpm-tcp-security-03 (work in progress), March
797 2012.
799 [I-D.meyer-lisp-cons]
800 Brim, S., "LISP-CONS: A Content distribution Overlay
801 Network Service for LISP", draft-meyer-lisp-cons-04 (work
802 in progress), April 2008.
804 [I-D.saucez-lisp-mapping-security]
805 Saucez, D. and O. Bonaventure, "Securing LISP Mapping
806 replies", draft-saucez-lisp-mapping-security-00 (work in
807 progress), February 2011.
809 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
810 Networks", BCP 84, RFC 3704, March 2004.
812 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
813 Internet Protocol", RFC 4301, December 2005.
815 [RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing
816 Security: An Unauthenticated Mode of IPsec", RFC 5386,
817 November 2008.
819 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
820 Secure Internet Routing", RFC 6480, February 2012.
822 [SAVI] IETF, "Source Address Validation Improvements Working
823 Group ", 2013, .
825 [Saucez09]
826 Saucez, D. and L. Iannone, "How to mitigate the effect of
827 scans on mapping systems ", Trilogy Summer School on
828 Future Internet, 2009.
830 [book_chapter]
831 Saucez, D., Iannone, L., and O. Bonaventure, "The Map-and-
832 Encap Locator/Identifier separation paradigm: a Security
833 Analysis ", Solutions for Sustaining Scalability in
834 Internet Growth, IGI Global, 2013.
836 Appendix A. Document Change Log
838 o Version 07 Posted October 2013.
840 * This version is updated according to the thorough review made
841 during October 2013 LISP WG interim meeting.
843 * Brief recommendations put in the security consideration
844 section.
846 * Editorial changes
848 o Version 06 Posted October 2013.
850 * Complete restructuration, temporary version to be used at
851 October 2013 interim meeting.
853 o Version 05 Posted August 2013.
855 * Removal of severity levels to become a short recommendation to
856 reduce the risk of the discussed threat.
858 o Version 04 Posted February 2013.
860 * Clear statement that the document compares threats of public
861 LISP deployments with threats in the current Internet
862 architecture.
864 * Addition of a severity level discussion at the end of each
865 section.
867 * Addressed comments from V. Ermagan and D. Lewis' reviews.
869 * Updated References.
871 * Further editorial polishing.
873 o Version 03 Posted October 2012.
875 * Dropped Reference to RFC 2119 notation because it is not
876 actually used in the document.
878 * Deleted future plans section.
880 * Updated References
882 * Deleted/Modified sentences referring to the early status of the
883 LISP WG and documents at the time of writing early versions of
884 the document.
886 * Further editorial polishing.
888 * Fixed all ID nits.
890 o Version 02 Posted September 2012.
892 * Added a new attack that combines overclaiming and de-
893 aggregation (see Section 4.4.2).
895 * Editorial polishing.
897 o Version 01 Posted February 2012.
899 * Added discussion on LISP-DDT.
901 o Version 00 Posted July 2011.
903 * Added discussion on LISP-MS>.
905 * Added discussion on Instance ID in Section 4.3.2.
907 * Editorial polishing of the whole document.
909 * Added "Change Log" appendix to keep track of main changes.
911 * Renamed "draft-saucez-lisp-security-03.txt.
913 Authors' Addresses
915 Damien Saucez
916 INRIA
917 2004 route des Lucioles BP 93
918 06902 Sophia Antipolis Cedex
919 France
921 Email: damien.saucez@inria.fr
923 Luigi Iannone
924 Telecom ParisTech
925 23, Avenue d'Italie, CS 51327
926 75214 PARIS Cedex 13
927 France
929 Email: luigi.iannone@telecom-paristech.fr
931 Olivier Bonaventure
932 Universite catholique de Louvain
933 Place St. Barbe 2
934 Louvain la Neuve
935 Belgium
937 Email: olivier.bonaventure@uclouvain.be