idnits 2.17.1
draft-ietf-lisp-threats-08.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 21, 2013) is 3841 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Unused Reference: 'Chu' is defined on line 793, but no explicit
reference was found in the text
== Unused Reference: 'I-D.ietf-tcpm-tcp-security' is defined on line 811,
but no explicit reference was found in the text
== Unused Reference: 'I-D.saucez-lisp-mapping-security' is defined on line
822, but no explicit reference was found in the text
== Unused Reference: 'RFC3704' is defined on line 827, but no explicit
reference was found in the text
== Unused Reference: 'RFC5386' is defined on line 833, but no explicit
reference was found in the text
== Unused Reference: 'RFC6480' is defined on line 837, but no explicit
reference was found in the text
== Unused Reference: 'SAVI' is defined on line 840, but no explicit
reference was found in the text
== Unused Reference: 'Saucez09' is defined on line 843, 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 24, 2014 Telecom ParisTech
6 O. Bonaventure
7 Universite catholique de Louvain
8 October 21, 2013
10 LISP Threats Analysis
11 draft-ietf-lisp-threats-08.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 24, 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 . . . . . . . . . . 4
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 . . . . . . 6
60 4.3.2. Attacks leveraging on the LISP header . . . . . . . . 8
61 4.4. Attacks using the control-plane . . . . . . . . . . . . . 11
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 . . . . . . . . . . . . . . . . . . . . . . . 15
73 5.3. Subversion . . . . . . . . . . . . . . . . . . . . . . . 15
74 5.3.1. Description . . . . . . . . . . . . . . . . . . . . . 15
75 5.3.2. Vectors . . . . . . . . . . . . . . . . . . . . . . . 15
76 6. Note on privacy . . . . . . . . . . . . . . . . . . . . . . . 16
77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
79 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
81 10.1. Normative References . . . . . . . . . . . . . . . . . . 17
82 10.2. Informative References . . . . . . . . . . . . . . . . . 18
83 Appendix A. Document Change Log . . . . . . . . . . . . . . . . 19
84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
86 1. Introduction
88 The Locator/ID Separation Protocol (LISP) is defined in [RFC6830].
89 The present document assesses the security level and identifies
90 security threats in the LISP specification if LISP is deployed in the
91 Internet (i.e., a public non-trustable environment). As a result of
92 the performed analysis, the document discusses the severity of the
93 threats and proposes recommendations to reach the same level of
94 security in LISP than in Internet today (e.g., without LISP).
96 The document is composed of three main parts: the first discussing
97 the LISP data-plane; while the second discussing the LISP control-
98 plane. The final part summarizes the recommendations to prevent the
99 identified threats.
101 The LISP data-plane consists of LISP packet encapsulation,
102 decapsulation, and forwarding and includes the map cache data
103 structures used to perform these operations.
105 The LISP control-plane consists in the mapping distribution system,
106 which can be one of the mapping distribution systems proposed so far
107 (e.g., [RFC6830], [I-D.ietf-lisp-ddt], [RFC6836], [RFC6833],
108 [I-D.meyer-lisp-cons], and [RFC6837]), and the Map-Request, Map-
109 Reply, Map-Register, and Map-Notification messages.
111 This document does not consider all the possible uses of LISP as
112 discussed in [RFC6830]. The document focuses on LISP unicast,
113 including as well LISP Interworking [RFC6832], LISP-MS [RFC6833], and
114 LISP Map-Versioning [RFC6834]. The reading of these documents is a
115 prerequisite for understanding the present document.
117 Unless otherwise stated, the document assumes a generic IP service
118 and does not discuss the difference, from a security viewpoint,
119 between using IPv4 or IPv6.
121 2. On-path Attackers
123 On-path attackers are attackers that are able to capture and modify
124 all the packets exchanged between an Ingress Tunnel Router (ITR) and
125 an Egress Tunnel Router (ETR). To cope with such an attacker,
126 cryptographic techniques such as those used by IPSec ([RFC4301]) are
127 required. As with IP, LISP relies on higher layer cryptography to
128 secure packet payloads from on path attacks, so this document does
129 not consider on-path attackers in this document.
131 Similarly, a time-shifted attack is an attack where the attacker is
132 temporarily on the path between two communicating hosts. While it is
133 on-path, the attacker sends specially crafted packets or modifies
134 packets exchanged by the communicating hosts in order to disturb the
135 packet flow (e.g., by performing a man in the middle attack). An
136 important issue for time-shifted attacks is the duration of the
137 attack once the attacker has left the path between the two
138 communicating hosts. We do not consider time-shifted attacks in this
139 document.
141 3. Off-Path Attackers: Reference Environment
143 The reference environment shown in the figure below is considered
144 throughout this document. There are two hosts attached to LISP
145 routers: HA and HB. HA is attached to the two LISP xTRs LR1 and LR2,
146 which in turn are attached to two different ISPs. HB is attached to
147 the two LISP xTRs LR3 and LR4. HA and HB are the EIDs of the two
148 hosts. LR1, LR2, LR3, and LR4 are the RLOCs of the xTRs. PxTR is a
149 proxy xTR and MR/MS plays the roles of Map Server and/or Map
150 Resolver.
152 +-----+
153 | HA |
154 +-----+
155 | EID: HA
156 |
157 -----------------
158 | |
159 +-----+ +-----+
160 | LR1 | | LR2 |
161 +-----+ +-----+
162 | |
163 | |
164 +-----+ +-----+
165 |ISP1 | |ISP2 |
166 +-----+ +-----+
167 | |
168 +------+ +----------------+ +-----+
169 | PxTR |-----| |-----| SA |
170 +------+ | | +-----+
171 | Internet |
172 +-------+ | | +-----+
173 | MR/MS |----| |-----| NSA |
174 +-------+ +----------------+ +-----+
175 | |
176 +-----+ +-----+
177 | LR3 | | LR4 |
178 +-----+ +-----+
179 | |
180 -------------------
181 |
182 | EID: HB
183 +-----+
184 | HB |
185 +-----+
187 Figure 1: Reference Network
189 We consider two off-path attackers with different capabilities:
191 SA is an off-path attacker that is able to send spoofed packets,
192 i.e., packets with a different source IP address than its
193 assigned IP address. SA stands for Spoofing Attacker.
195 NSA is an off-path attacker that is only able to send packets whose
196 source address is its assigned IP address. NSA stands for Non
197 Spoofing Attacker.
199 It should be noted that with LISP, packet spoofing is slightly
200 different than in the current Internet. Generally the term "spoofed
201 packet" indicates a packet containing a source IP address that is not
202 the one of the actual originator of the packet. Since LISP uses
203 encapsulation, the spoofed address could be in the outer header as
204 well as in the inner header, this translates in two types of
205 spoofing:
207 EID Spoofing: the originator of the packet puts in it a spoofed EID.
208 The packet will be normally encapsulated by the ITR of the site
209 (or a PITR if the source site is not LISP enabled).
211 RLOC Spoofing: the originator of the packet generates directly a
212 LISP-encapsulated packet with a spoofed source RLOC.
214 Note that the two types of spoofing are not mutually exclusive,
215 rather all combinations are possible and could be used to perform
216 different kind of attacks.
218 In the reference environment, both SA and NSA attackers are capable
219 of sending LISP encapsulated data packets and LISP control packets.
220 This means that SA is able to perform both RLOC and EID spoofing
221 while NSA can only perform EID spoofing. They may also send other
222 types of IP packets such as ICMP messages. We assume that both
223 attackers can query the LISP mapping system (e.g., through a public
224 Map Resolver) to obtain the mappings for both HA and HB.
226 4. Attack vectors
228 This section presents techniques that can be used by attackers to
229 succeed attacks leveraging the LISP protocol and architecture. This
230 section focuses on the techniques while Section 5 presents the
231 attacks that can be succeeded while using these techniques.
233 4.1. Configured EID-to-RLOC mappings
235 Each xTR maintains a set of configured mappings related to the EID-
236 Prefixes that are "behind" the xTR [RFC6830]. Where "behind" means
237 that at least one of the xTR's globally visible IP addresses is a
238 RLOC for those EID-Prefixes.
240 As these mappings are determined by configuration. This means that
241 the only way to attack this data structure is by gaining privileged
242 access to the xTR. As such, it is out of the scope of LISP to
243 propose any mechanism to protect routers and, hence, it is no further
244 analyzed in this document.
246 4.2. EID-to-RLOC Cache
248 The EID-to-RLOC Cache (also called the Map-Cache) is the data
249 structure that stores a copy of the mappings retrieved from a remote
250 ETR's mapping via the LISP control-plane. Attacks against this data
251 structure could happen either when the mappings are first installed
252 in the cache or by corrupting (poisoning) the mappings already
253 present in the cache.
255 This document calls "cache poisoning attack", any attack that alters
256 the EID-to-RLOC Cache. Cache poisoning attacks are use to alter (any
257 combination of) the following parts of mapping installed in the EID-
258 to-RLOC Cache:
260 o EID prefix
262 o RLOC list
264 o RLOC priority
266 o RLOC weight
268 o RLOC reachability
270 o Mapping TTL
272 o Mapping version
274 o Mapping Instance ID
276 4.3. Attacks using the data-plane
278 The data-plane is constituted of the operations of encapsulation,
279 decapsulation, and forwarding as well as the content of the EID-to-
280 RLOC Cache and configured EID-to-RLOC mappings as specified in the
281 original LISP document ([RFC6830]).
283 4.3.1. Attacks not leveraging on the LISP header
284 An attacker can inject packets into flows without using the LISP
285 header, i.e., with the N, L, E, V, and I bits ([RFC6830]).
287 Taking notation of the reference environment notation (Figure 1), to
288 inject a packet in the HA->HB flow, a spoofing off-path attacker (SA)
289 could send a LISP encapsulated packet whose source is set to LR1 or
290 LR2 and destination LR3 or LR4. The packet will reach HB as if the
291 packet was sent by host HA. This is not different from today's
292 Internet where a spoofing off-path attacker may inject data packets
293 in any flow. A non-spoofing off-path attacker (NSA) could only send
294 a packet whose source address is set to its assigned IP address. The
295 destination address of the encapsulated packet could be LR3 or LR4.
297 4.3.1.1. Gleaning Attacks
299 In order to reduce the time required to obtain a mapping, [RFC6830]
300 proposes the gleaning mechanism that allows an ITR to learn a mapping
301 from the LISP data encapsulated packets and the Map-Request packets
302 that it receives. LISP data encapsulated packet contains a source
303 RLOC, destination RLOC, source EID and destination EID. When an ITR
304 receives a data encapsulated packet coming from a source EID for
305 which it does not already know a mapping, it may insert the mapping
306 between the source RLOC and the source EID in its EID-to-RLOC Cache.
307 Gleaning could also be used when an ITR receives a Map-Request as the
308 Map-Request also contains a source EID address and a source RLOC.
309 Once a gleaned entry has been added to the EID-to-RLOC cache, the
310 LISP ITR sends a Map-Request to retrieve the mapping for the gleaned
311 EID from the mapping system. [RFC6830] recommends storing the
312 gleaned entries for only a few seconds.
314 An attacker can send LISP encapsulated packets to host HB with host
315 HA's EID and if the xTRs that serve host HB do not store a mapping
316 for host HA at that time. The xTR will store the gleaned entry and
317 use it to return the packets sent by host HB. In parallel, the ETR
318 will send a Map-Request to retrieve the mapping for HA but until the
319 reception of the Map-Reply, host HB will exchange packets with the
320 attacker instead of HA.
322 Similarly, if an off-path attacker knows that hosts HA and HB that
323 resides in different sites will exchange information at time t the
324 attacker could send to LR1 (resp. LR3) a LISP data encapsulated
325 packet whose source RLOC is its IP address and contains an IP packet
326 whose source is set to HB (resp. HA). The attacker chooses a packet
327 that will not trigger an answer, for example the last part of a
328 fragmented packet. Upon reception of these packets, LR1 and LR3
329 install gleaned entries that point to the attacker. If host HA is
330 willing to establishes a flow with host HB at that time, the packets
331 that they exchange will pass through the attacker as long as the
332 gleaned entry is active on the xTRs.
334 By itself, an attack made solely using gleaning cannot last long,
335 however it should be noted that with current network capacities, a
336 large amount of packets might be exchanged during even a small
337 fraction of time.
339 4.3.1.2. Threats concerning Interworking
341 [RFC6832] defines Proxy-ITR And Proxy-ETR network elements to allow
342 LISP and non-LISP sites to communicate. The Proxy-ITR has
343 functionality similar to the ITR, however, its main purpose is to
344 encapsulate packets arriving from the DFZ in order to reach LISP
345 sites. A Proxy-ETR has functionality similar to the ETR, however,
346 its main purpose is to inject de-encapsulated packets in the DFZ in
347 order to reach non-LISP Sites from LISP sites. As a PITR (resp.
348 PETR) is a particular case of ITR (resp. ETR), it is subject to same
349 attacks than ITRs (resp. ETR).
351 PxTRs can be targeted by attacks aiming to influence traffic between
352 LISP and non-LISP sites but also to launch relay attacks.
354 It is worth to notice that when PITR and PETR functions are
355 separated, attacks targeting nodes that collocate PITR and PETR
356 functionality are ineffective.
358 4.3.2. Attacks leveraging on the LISP header
360 The main LISP document [RFC6830] defines several flags that modify
361 the interpretation of the LISP header in data packets. In this
362 section, we discuss how an off-path attacker could exploit this LISP
363 header.
365 4.3.2.1. Attacks using the Locator Status Bits
367 When the L bit is set to 1, it indicates that the second 32-bits
368 longword of the LISP header contains the Locator Status Bits. In
369 this field, each bit position reflects the status of one of the RLOCs
370 mapped to the source EID found in the encapsulated packet. In
371 particular, a packet with the L bit set and all Locator Status Bits
372 set to zero indicates that none of the locators of the encapsulated
373 source EID are reachable. The reaction of a LISP ETR that receives
374 such a packet is not clearly described in [RFC6830].
376 An attacker can send a data packet with the L bit set to 1 and some
377 or all Locator Status Bits set to zero. Therefore, by blindly
378 trusting the Locator Status Bits communication going on can be
379 altered or forced to go through a particular set of locators.
381 4.3.2.2. Attacks using the Map-Version bit
383 The optional Map-Version bit is used to indicate whether the low-
384 order 24 bits of the first 32 bits longword of the LISP header
385 contain a Source and Destination Map-Version. When a LISP ETR
386 receives a LISP encapsulated packet with the Map-Version bit set to
387 1, the following actions are taken:
389 o It compares the Destination Map-Version found in the header with
390 the current version of its own configured EID-to-RLOC mapping, for
391 the destination EID found in the encapsulated packet. If the
392 received Destination Map-Version is smaller (i.e., older) than the
393 current version, the ETR should apply the SMR procedure described
394 in [RFC6830] and send a Map-Request with the SMR bit set.
396 o If a mapping exists in the EID-to-RLOC Cache for the source EID,
397 then it compares the Map-Version of that entry with the Source
398 Map-Version found in the header of the packet. If the stored
399 mapping is older (i.e., the Map-Version is smaller) than the
400 source version of the LISP encapsulated packet, the xTR should
401 send a Map-Request for the source EID.
403 An off-path attacker could use the Map-Version bit to force an ETR to
404 send Map-Request messages. The attacker could retrieve the current
405 source and destination Map-Version for both HA and HB. Based on this
406 information, it could send a spoofed packet with an older Source Map-
407 Version or Destination Map-Version. If the size of the Map-Request
408 message is larger than the size of the smallest LISP-encapsulated
409 packet that could trigger such a message, this could lead to
410 amplification attacks (see Section 4.4.1) so that more bandwidth is
411 consumed on the target than the bandwidth necessary at the attacker
412 side.
414 4.3.2.3. Attacks using the Nonce-Present and the Echo-Nonce bits
416 The Nonce-Present and Echo-Nonce bits are used when verifying the
417 reachability of a remote ETR. Assume that LR3 wants to verify that
418 LR1 receives the packets that it sends. LR3 can set the Echo-Nonce
419 and the Nonce-Present bits in LISP data encapsulated packets and
420 include a random nonce in these packets. Upon reception of these
421 packets, LR1 will store the nonce sent by LR3 and echo it when it
422 returns LISP encapsulated data packets to LR3.
424 A spoofing off-path attacker (SA) could interfere with this
425 reachability test by sending two different types of packets:
427 1. LISP data encapsulated packets with the Nonce-Present bit set and
428 a random nonce and the appropriate source and destination RLOCs.
430 2. LISP data encapsulated packets with the Nonce-Present and the
431 Echo-Nonce bits both set and the appropriate source and
432 destination RLOCs. These packets will force the receiving ETR to
433 store the received nonce and echo it in the LISP encapsulated
434 packets that it sends.
436 The first type of packet should not cause any major problem to ITRs.
437 As the reachability test uses a 24 bits nonce, it is unlikely that an
438 off-path attacker could send a single packet that causes an ITR to
439 believe that the ETR it is testing is reachable while in reality it
440 is not reachable. To increase the success likelihood of such attack,
441 the attacker should created a massive amount of packets carrying all
442 possible nonce values.
444 The second type of packet could be exploited to attack the nonce-
445 based reachability test. Consider a spoofing off-path attacker (SA)
446 that sends a continuous flow of spoofed LISP data encapsulated
447 packets that contain the Nonce-Present and the Echo-Nonce bit and
448 each packet contains a different random nonce. The ETR that receives
449 such packets will continuously change the nonce that it returns to
450 the remote ITR. If the remote ITR starts a nonce-reachability test,
451 this test may fail because the ETR has received a spoofed LISP data
452 encapsulated packet with a different random nonce and never echoes
453 the real nonce. In this case the ITR will consider the ETR not
454 reachable. The success of this test depends on the ratio between the
455 amount of packets sent by the legitimate ITR and the spoofing off-
456 path attacker (SA).
458 4.3.2.4. Attacks using the Instance ID bits
460 LISP allows to carry in its header a 24-bits value called "Instance
461 ID" and used on the ITR to indicate which local Instance ID has been
462 used for encapsulation, while on the ETR can be used to select the
463 forwarding table used for forwarding the decapsulated packet.
465 The Instance ID increases exposure to attacks ([RFC6169]) as if an
466 off-path attacker can randomly guess a valid Instance ID value to get
467 access to network that might not been accessible in normal
468 conditions. However, the impact of such attack is directly on end-
469 systems which is is out of the scope of this document.
471 4.4. Attacks using the control-plane
473 In this section, we discuss the different types of attacks that could
474 occur when an off-path attacker sends control-plane packets. We
475 focus on the packets that are sent directly to the ETR and do not
476 analyze the particularities of the different LISP indexing sub-
477 system.
479 4.4.1. Attacks with Map-Request messages
481 An off-path attacker could send Map-Request packets to a victim ETR.
482 In theory, a Map-Request packet is only used to solicit an answer and
483 as such it should not lead to security problems. However, the LISP
484 specification [RFC6830] contains several particularities that could
485 be exploited by an off-path attacker.
487 The first possible exploitation is the RLOC record P bit. The RLOC
488 record P bit is used to probe the reachability of remote ETRs. In
489 our reference environment, LR3 could probe the reachability of LR1 by
490 sending a Map-Request with the RLOC record P bit set. LR1 would
491 reply by sending a Map-Reply message with the RLOC record P bit set
492 and the same nonce as in the Map-Request message.
494 A spoofing off-path attacker (SA) could use the RLOC record P bit to
495 force a victim ETR to send a Map-Reply to the spoofed source address
496 of the Map-Request message. As the Map-Reply can be larger than the
497 Map-Request message, there is a risk of amplification attack.
498 Considering only IPv6 addresses, a Map-Request can be as small as 40
499 bytes, considering one single ITR address and no Mapping Protocol
500 Data. The Map-Reply instead has a proportional to the maximum number
501 of RLOCs in a mapping and maximum number of records in a Map-Reply.
502 Since up to 255 RLOCs can be associated to an EID-Prefix and 255
503 records can be stored in a Map-Reply, the maximum size of a Map-Reply
504 is thus above 1 MB, largely bigger than the message sent by the
505 attacker. These numbers are however theoretical values not
506 considering transport layer limitations and it is more likely that
507 the reply will contain only one record with at most a dozen of
508 locators, limiting so the amplification factor.
510 Similarly, if a non-spoofing off-path attacker (NSA) sends a Map-
511 Request with the RLOC record P bit set, it will receive a Map-Reply
512 with the RLOC record P bit set.
514 An amplification attack could be launched by a spoofing off-path
515 attacker (SA) as follows. Consider an attacker SA and EID-Prefix
516 192.0.2.0/24 and a victim ITR, SA could send spoofed Map-Request
517 messages whose source EID addresses are all the addresses inside
518 192.0.2.0/24 and source RLOC address is the victim ITR. Upon
519 reception of these Map-Request messages, the ETR would send large
520 Map-Reply messages for each of the addresses inside p/P back to the
521 victim ITR.
523 The Map-Request message may also contain the SMR bit. Upon reception
524 of a Map-Request message with the SMR bit, an ETR must return to the
525 source of the Map-Request message a Map-Request message to retrieve
526 the corresponding mapping. This raises similar problems as the RLOC
527 record P bit discussed above except that as the Map-Request messages
528 are smaller than Map-Reply messages, the risk of amplification
529 attacks is reduced. This is not true anymore if the ETR append to
530 the Map-Request messages its own Map-Records. This mechanism is
531 meant to reduce the delay in mapping distribution since mapping
532 information is provided in the Map-Request message.
534 Furthermore, appending Map-Records to Map-Request messages allows an
535 off-path attacker to generate a (spoofed or not) Map-Request message
536 and include in the Map-Reply portion of the message mapping for EID
537 prefixes that it does not serve.
539 Moreover, attackers can use Map Resolver and/or Map Server network
540 elements to perform relay attacks. Indeed, on the one hand, a Map
541 Resolver is used to dispatch Map-Request to the mapping system and,
542 on the other hand, a Map Server is used to dispatch Map-Requests
543 coming from the mapping system to ETRs that are authoritative for the
544 EID in the Map-Request.
546 4.4.2. Attacks with Map-Reply messages
548 In this section we analyze the attacks that could occur when an off-
549 path attacker sends directly Map-Reply messages to ETRs without using
550 one of the proposed LISP mapping systems.
552 There are two different types of Map-Reply messages:
554 Positive Map-Reply: These messages contain a Map-Record binding an
555 EID-Prefix to one or more RLOCs.
557 Negative Map-Reply: These messages contain a Map-Record for an EID-
558 Prefix with an empty locator-set and specifying an action,
559 which may be either Drop, natively forward, or Send Map-
560 Request.
562 Positive Map-Reply messages are used to map EID-Prefixes onto RLOCs.
563 Negative Map-Reply messages are used to indicate non-LISP prefixes.
564 ITRs can, if needed, be configured to send all traffic destined for
565 non-LISP prefixes to a Proxy-ETR.
567 Most of the security of the Map-Reply messages depends on the 64 bits
568 nonce that is included in a Map-Request and returned in the Map-
569 Reply. If an ETR does not accept Map-Reply messages with an invalid
570 nonce, the risk of attack is acceptable given the size of the nonce
571 (64 bits). However, the nonce only confirms that the Map-Reply
572 received was sent in response to a Map-Request sent, it does not
573 validate the contents of that Map-Reply.
575 In addition, an attacker could perform EID-to-RLOC Cache overflow
576 attack by de-aggregating (i.e., splitting an EID prefix into
577 artificially smaller EID prefixes) either positive or negative
578 mappings.
580 In presence of malicious ETRs, overclaiming attacks are possible.
581 Such an attack happens when and ETR replies to a legitimate Map-
582 Request message it received with a Map-Reply message that contains an
583 EID-Prefix that is larger than the prefix owned by the site that
584 encompasses the EID of the Map-Request. For instance if the prefix
585 owned by the site is 192.0.2.0/25 but the Map-Reply contains a
586 mapping for 192.0.2.0/24, then the mapping will influence packets
587 destined to other EIDs than the one the LISP site has authority on.
589 A malicious ETR might also fragment its configured EID-to-RLOC
590 mappings so that ITR's might have to install much more mappings than
591 really necessary. This attack is called de-aggregation attack.
593 4.4.3. Attacks with Map-Register messages
595 Map-Register messages are sent by ETRs to indicate to the mapping
596 system the EID prefixes associated to them. The Map-Register message
597 provides an EID prefix and the list of ETRs that are able to provide
598 Map-Replies for the EID covered by the EID prefix.
600 As Map-Register messages are protected by an authentication
601 mechanism, only a compromised ETR can register itself to its
602 allocated Map Server.
604 A compromised ETR can perform an overclaiming attack in order to
605 influence the route followed by Map-Requests for EIDs outside the
606 scope of its legitimate EID prefix.
608 A compromised ETR can also perform a deaggregation attack in order to
609 register more EID prefixes than necessary to its Map Servers.
611 Similarly, a compromised Map Server can accept invalid registration
612 or advertise invalid EID prefix to the indexing sub-system.
614 4.4.4. Attacks with Map-Notify messages
616 Map-Notify messages are sent by a Map Server to an ETR to acknowledge
617 the good reception and processing of a Map-Register message.
619 An compromised ETR using EID that it is not authoritative for can
620 send a Map-Register with the M-bit set and a spoofed source address
621 to force the Map Server to send a Map-Notify message to the spoofed
622 address and then succeed a relay attack. Similarly to the pair Map-
623 Request/Map-Reply, the pair Map-Register/Map-Notify is protected by a
624 nonce making it hard for an attacker to inject a falsified
625 notification to an ETR to make this ETR believe that the registration
626 succeeded while it has not.
628 5. Attack categories
630 5.1. Intrusion
632 5.1.1. Description
634 With an intrusion attack an attacker gains remote access to some
635 resources (e.g., a host, a router, or a network) that are normally
636 denied to her.
638 5.1.2. Vectors
640 Intrusion attacks can be mounted using:
642 o Spoofing EID or RLOCs
644 o Instance ID bits
646 5.2. Denial of Service (DoS)
648 5.2.1. Description
650 A Denial of Service (DoS) attack aims at disrupting a specific
651 targeted service either by exhausting the resources of the victim up
652 to the point that it is not able to provide a reliable service to
653 legit traffic and/or systems or by exploiting vulnerabilities to make
654 the targeted service unable to operate properly.
656 5.2.2. Vectors
658 Denial of Service attacks can be mounted using
660 o Gleaning
662 o Interworking
664 o Locator Status Bits
666 o Map-Version bit
668 o Nonce-Present and Echo-Nonce bits
670 o Map-Request message
672 o Map-Reply message
674 o Map-Register message
676 o Map-Notify message
678 5.3. Subversion
680 5.3.1. Description
682 With subversion an attacker can gain access (e.g., using
683 eavesdropping or impersonation) to restricted or sensitive
684 information such as passwords, session tokens, or any other
685 confidential information. This type of attack is usually carried out
686 in a way such that the target does not even notice the attack. When
687 the attacker is positioned on the path of the target traffic, it is
688 called a Man-in-the-Middle attack. However, this is not a
689 requirement to carry out and eavesdropping attack. Indeed the
690 attacker might be able, for instance through an intrusion attack on a
691 weaker system, either to duplicate or even re-direct the traffic, in
692 both cases having access to the raw packets.
694 5.3.2. Vectors
696 Subversion attacks can be mounted using
698 o Gleaning
699 o Locator Status Bits
701 o Nonce-Present and the Echo-Nonce bits
703 o Map-Request messages
705 o Map-Reply messages
707 6. Note on privacy
709 As presented by [RFC6973], universal privacy considerations are
710 impossible to establish as the privacy definition may vary from one
711 to another. As a consequence, this document does not aim at
712 identifying privacy issues related to the LISP protocol but it is
713 necessary to highlight that security threats identified in this
714 document could play a role in privacy threats as defined in section 5
715 of [RFC6973].
717 7. IANA Considerations
719 This document makes no request to IANA.
721 8. Security Considerations
723 This document is devoted to threat analysis of the Locator/Identifier
724 Separation Protocol and is then a piece of choice to understand the
725 security risks at stake while deploying LISP in non-trustable
726 environment.
728 The purpose of this document is not to provide recommendations to
729 protect against attacks, however most of threats can be prevented
730 with careful deployment and configuration (e.g., filter) and also by
731 applying the general rules in security that consist in activating
732 only features that are necessary in the deployment and verifying the
733 validity of the information obtained from third parties. More
734 detailed recommendation are given in [book_chapter].
736 The control-plane is probably the most critical part of LISP from a
737 security viewpoint and it is worth to notice that the specifications
738 already offer authentication mechanism for Map-Register messages
739 ([RFC6833]) and that [I-D.ietf-lisp-sec] and [I-D.ietf-lisp-ddt] are
740 clearly going in the direction of a secure control-plane.
742 9. Acknowledgments
744 This document builds upon the draft of Marcelo Bagnulo
745 ([I-D.bagnulo-lisp-threat]), where the flooding attack and the
746 reference environment were first described.
748 The authors would like to thank Ronald Bonica, Albert Cabellos, Noel
749 Chiappa, Florin Coras, Vina Ermagan, Dino Farinacci, Stephen Farrell,
750 Joel Halpern, Emily Hiltzik, Darrel Lewis, Edward Lopez, Fabio Maino,
751 Terry Manderson, and Jeff Wheeler for their comments.
753 This work has been partially supported by the INFSO-ICT-216372
754 TRILOGY Project (www.trilogy-project.org).
756 10. References
758 10.1. Normative References
760 [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security
761 Concerns with IP Tunneling", RFC 6169, April 2011.
763 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
764 Locator/ID Separation Protocol (LISP)", RFC 6830, January
765 2013.
767 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
768 "Interworking between Locator/ID Separation Protocol
769 (LISP) and Non-LISP Sites", RFC 6832, January 2013.
771 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation
772 Protocol (LISP) Map-Server Interface", RFC 6833, January
773 2013.
775 [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
776 Separation Protocol (LISP) Map-Versioning", RFC 6834,
777 January 2013.
779 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
780 "Locator/ID Separation Protocol Alternative Logical
781 Topology (LISP+ALT)", RFC 6836, January 2013.
783 [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to
784 Routing Locator (RLOC) Database", RFC 6837, January 2013.
786 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
787 Morris, J., Hansen, M., and R. Smith, "Privacy
788 Considerations for Internet Protocols", RFC 6973, July
789 2013.
791 10.2. Informative References
793 [Chu] Jerry Chu, H., "Tuning TCP Parameters for the 21st Century
794 ", 75th IETF, Stockholm, July 2009,
795 .
797 [I-D.bagnulo-lisp-threat]
798 Bagnulo, M., "Preliminary LISP Threat Analysis", draft-
799 bagnulo-lisp-threat-01 (work in progress), July 2007.
801 [I-D.ietf-lisp-ddt]
802 Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP
803 Delegated Database Tree", draft-ietf-lisp-ddt-01 (work in
804 progress), March 2013.
806 [I-D.ietf-lisp-sec]
807 Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D.,
808 and O. Bonaventure, "LISP-Security (LISP-SEC)", draft-
809 ietf-lisp-sec-04 (work in progress), October 2012.
811 [I-D.ietf-tcpm-tcp-security]
812 Gont, F., "Survey of Security Hardening Methods for
813 Transmission Control Protocol (TCP) Implementations",
814 draft-ietf-tcpm-tcp-security-03 (work in progress), March
815 2012.
817 [I-D.meyer-lisp-cons]
818 Brim, S., "LISP-CONS: A Content distribution Overlay
819 Network Service for LISP", draft-meyer-lisp-cons-04 (work
820 in progress), April 2008.
822 [I-D.saucez-lisp-mapping-security]
823 Saucez, D. and O. Bonaventure, "Securing LISP Mapping
824 replies", draft-saucez-lisp-mapping-security-00 (work in
825 progress), February 2011.
827 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
828 Networks", BCP 84, RFC 3704, March 2004.
830 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
831 Internet Protocol", RFC 4301, December 2005.
833 [RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing
834 Security: An Unauthenticated Mode of IPsec", RFC 5386,
835 November 2008.
837 [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
838 Secure Internet Routing", RFC 6480, February 2012.
840 [SAVI] IETF, "Source Address Validation Improvements Working
841 Group ", 2013, .
843 [Saucez09]
844 Saucez, D. and L. Iannone, "How to mitigate the effect of
845 scans on mapping systems ", Trilogy Summer School on
846 Future Internet, 2009.
848 [book_chapter]
849 Saucez, D., Iannone, L., and O. Bonaventure, "The Map-and-
850 Encap Locator/Identifier separation paradigm: a Security
851 Analysis ", Solutions for Sustaining Scalability in
852 Internet Growth, IGI Global, 2013.
854 Appendix A. Document Change Log
856 o Version 08 Posted October 2013.
858 * Addition of a privacy consideration note.
860 * Editorial changes
862 o Version 07 Posted October 2013.
864 * This version is updated according to the thorough review made
865 during October 2013 LISP WG interim meeting.
867 * Brief recommendations put in the security consideration
868 section.
870 * Editorial changes
872 o Version 06 Posted October 2013.
874 * Complete restructuration, temporary version to be used at
875 October 2013 interim meeting.
877 o Version 05 Posted August 2013.
879 * Removal of severity levels to become a short recommendation to
880 reduce the risk of the discussed threat.
882 o Version 04 Posted February 2013.
884 * Clear statement that the document compares threats of public
885 LISP deployments with threats in the current Internet
886 architecture.
888 * Addition of a severity level discussion at the end of each
889 section.
891 * Addressed comments from V. Ermagan and D. Lewis' reviews.
893 * Updated References.
895 * Further editorial polishing.
897 o Version 03 Posted October 2012.
899 * Dropped Reference to RFC 2119 notation because it is not
900 actually used in the document.
902 * Deleted future plans section.
904 * Updated References
906 * Deleted/Modified sentences referring to the early status of the
907 LISP WG and documents at the time of writing early versions of
908 the document.
910 * Further editorial polishing.
912 * Fixed all ID nits.
914 o Version 02 Posted September 2012.
916 * Added a new attack that combines overclaiming and de-
917 aggregation (see Section 4.4.2).
919 * Editorial polishing.
921 o Version 01 Posted February 2012.
923 * Added discussion on LISP-DDT.
925 o Version 00 Posted July 2011.
927 * Added discussion on LISP-MS>.
929 * Added discussion on Instance ID in Section 4.3.2.
931 * Editorial polishing of the whole document.
933 * Added "Change Log" appendix to keep track of main changes.
935 * Renamed "draft-saucez-lisp-security-03.txt.
937 Authors' Addresses
939 Damien Saucez
940 INRIA
941 2004 route des Lucioles BP 93
942 06902 Sophia Antipolis Cedex
943 France
945 Email: damien.saucez@inria.fr
947 Luigi Iannone
948 Telecom ParisTech
949 23, Avenue d'Italie, CS 51327
950 75214 PARIS Cedex 13
951 France
953 Email: luigi.iannone@telecom-paristech.fr
955 Olivier Bonaventure
956 Universite catholique de Louvain
957 Place St. Barbe 2
958 Louvain la Neuve
959 Belgium
961 Email: olivier.bonaventure@uclouvain.be