idnits 2.17.1
draft-saucez-lisp-security-03.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** You're using the IETF Trust Provisions' Section 6.b License Notice from
12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See
https://trustee.ietf.org/license-info/)
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== The document doesn't use any RFC 2119 keywords, yet seems to have RFC
2119 boilerplate text.
-- The document date (March 12, 2011) is 4765 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Outdated reference: A later version (-24) exists of draft-ietf-lisp-10
== Outdated reference: A later version (-10) exists of
draft-ietf-lisp-alt-06
== Outdated reference: A later version (-06) exists of
draft-ietf-lisp-interworking-02
== Outdated reference: A later version (-09) exists of
draft-ietf-lisp-map-versioning-01
== Outdated reference: A later version (-16) exists of draft-ietf-lisp-ms-07
== Outdated reference: A later version (-14) exists of
draft-ietf-lisp-multicast-04
== Outdated reference: A later version (-13) exists of
draft-ietf-sidr-arch-12
== Outdated reference: A later version (-03) exists of
draft-ietf-tcpm-tcp-security-02
== Outdated reference: A later version (-09) exists of
draft-lear-lisp-nerd-08
Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group D. Saucez
3 Internet-Draft Universite catholique de Louvain
4 Intended status: Informational L. Iannone
5 Expires: September 13, 2011 TU Berlin - Deutsche Telekom
6 Laboratories AG
7 O. Bonaventure
8 Universite catholique de Louvain
9 March 12, 2011
11 LISP Security Threats
12 draft-saucez-lisp-security-03.txt
14 Abstract
16 This draft analyzes some of the threats against the security of the
17 Locator/Identifier Separation Protocol and proposes a set of
18 recommendations to mitigate some of the identified security risks.
20 Status of this Memo
22 This Internet-Draft is submitted to IETF in full conformance with the
23 provisions of BCP 78 and BCP 79.
25 Internet-Drafts are working documents of the Internet Engineering
26 Task Force (IETF), its areas, and its working groups. Note that
27 other groups may also distribute working documents as Internet-
28 Drafts.
30 Internet-Drafts are draft documents valid for a maximum of six months
31 and may be updated, replaced, or obsoleted by other documents at any
32 time. It is inappropriate to use Internet-Drafts as reference
33 material or to cite them other than as "work in progress."
35 The list of current Internet-Drafts can be accessed at
36 http://www.ietf.org/ietf/1id-abstracts.txt.
38 The list of Internet-Draft Shadow Directories can be accessed at
39 http://www.ietf.org/shadow.html.
41 This Internet-Draft will expire on September 13, 2011.
43 Copyright Notice
45 Copyright (c) 2011 IETF Trust and the persons identified as the
46 document authors. All rights reserved.
48 This document is subject to BCP 78 and the IETF Trust's Legal
49 Provisions Relating to IETF Documents
50 (http://trustee.ietf.org/license-info) in effect on the date of
51 publication of this document. Please review these documents
52 carefully, as they describe your rights and restrictions with respect
53 to this document. Code Components extracted from this document must
54 include Simplified BSD License text as described in Section 4.e of
55 the Trust Legal Provisions and are provided without warranty as
56 described in the BSD License.
58 Table of Contents
60 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
61 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
62 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3
63 4. On-path Attackers . . . . . . . . . . . . . . . . . . . . . . 4
64 5. Off-Path Attackers: Reference Environment . . . . . . . . . . 4
65 6. Data-Plane Threats . . . . . . . . . . . . . . . . . . . . . . 6
66 6.1. EID-to-RLOC Database Threats . . . . . . . . . . . . . . . 6
67 6.2. EID-to-RLOC Cache Threats . . . . . . . . . . . . . . . . 7
68 6.2.1. EID-to-RLOC Cache poisoning . . . . . . . . . . . . . 7
69 6.2.2. EID-to-RLOC Cache overflow . . . . . . . . . . . . . . 9
70 6.3. Attacks not leveraging on the LISP header . . . . . . . . 9
71 6.4. Attacks leveraging on the LISP header . . . . . . . . . . 10
72 6.4.1. Attacks using the Locator Status Bits . . . . . . . . 10
73 6.4.2. Attacks using the Map-Version bit . . . . . . . . . . 11
74 6.4.3. Attacks using the Nonce-Present and the Echo-Nonce
75 bits . . . . . . . . . . . . . . . . . . . . . . . . . 12
76 7. Control Plane Threats . . . . . . . . . . . . . . . . . . . . 13
77 7.1. Attacks with Map-Request messages . . . . . . . . . . . . 13
78 7.2. Attacks with Map-Reply messages . . . . . . . . . . . . . 14
79 7.3. Gleaning Attacks . . . . . . . . . . . . . . . . . . . . . 15
80 8. Threats concerning Interworking . . . . . . . . . . . . . . . 16
81 9. Threats with Malicious xTRs . . . . . . . . . . . . . . . . . 17
82 10. Security of the ALT Mapping System . . . . . . . . . . . . . . 19
83 11. Suggested Recommendations . . . . . . . . . . . . . . . . . . 20
84 12. Document Status and Plans . . . . . . . . . . . . . . . . . . 23
85 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
86 14. Security Considerations . . . . . . . . . . . . . . . . . . . 23
87 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
88 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
89 16.1. Normative References . . . . . . . . . . . . . . . . . . . 24
90 16.2. Informative References . . . . . . . . . . . . . . . . . . 24
91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
93 1. Requirements notation
95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
97 document are to be interpreted as described in [RFC2119].
99 2. Introduction
101 The Locator/ID Separation Protocol (LISP) is defined in
102 [I-D.ietf-lisp]. The present document aims at identifying threats in
103 the current LISP specification. We also propose some recommendations
104 on mechanisms that could improve the security of LISP against off-
105 path attackers. This document builds upon [I-D.bagnulo-lisp-threat].
107 This document is split in two parts. The first discusses the LISP
108 data-plane and the second the LISP control-plane.
110 The LISP data-plane consists of LISP packet encapsulation,
111 decapsulation, and forwarding and includes the EID-to-RLOC Cache and
112 EID-to-RLOC Database data structures used to perform these
113 operations.
115 The LISP control-plane consists in the mapping distribution system,
116 which can be one of the mapping distribution systems proposed so far
117 (e.g., [I-D.ietf-lisp], [I-D.ietf-lisp-alt], [I-D.ietf-lisp-ms],
118 [I-D.meyer-lisp-cons], and [I-D.lear-lisp-nerd]), and the Map-
119 Request, Map-Reply, Map-Register messages.
121 This document does not consider all the possible uses of LISP as
122 discussed in [I-D.ietf-lisp]. In the current version, the document
123 focuses on LISP unicast, including as well LISP Interworking, and
124 briefly considers the ALT mapping system described in
125 [I-D.ietf-lisp-alt]. Later versions of this document will include a
126 deeper analysis of the ALT mapping system, as well as the analysis of
127 the security issues in multicast LISP ([I-D.ietf-lisp-multicast]),
128 interworking between LISP and the legacy IPv4 and IPv6 Internet
129 ([I-D.ietf-lisp-interworking]), and LISP-MS ([I-D.ietf-lisp-ms]).
131 Furthermore, here we assume a generic IP service and do not discuss
132 the difference from a security viewpoint between using IPv4 or IPv6.
134 3. Definition of Terms
136 The present document does not introduce any new term, compared to the
137 main LISP specification. For a complete list of terms please refer
138 to [I-D.ietf-lisp].
140 4. On-path Attackers
142 On-path attackers are attackers that are able to capture and modify
143 all the packets exchanged between an ITR and an ETR. To cope with
144 such an attacker, cryptographic techniques such as those used by
145 IPSec are required. We do not consider that LISP has to cope with
146 such attackers.
148 Mobile IP has also considered time-shifted attacks from on-path
149 attackers. A time-shifted attack is an attack where the attacker is
150 temporarily on the path between two communicating hosts. While it is
151 on-path, the attacker sends specially crafted packets or modifies
152 packets exchanged by the communicating hosts in order to disturb the
153 packet flow (e.g., by performing a man in the middle attack). An
154 important issue for time-shifted attacks is the duration of the
155 attack once the attacker has left the path between the two
156 communicating hosts. We do not consider time-shifted attacks in this
157 document.
159 5. Off-Path Attackers: Reference Environment
161 Throughout this document we consider the reference environment shown
162 in the figure below. There are two hosts attached to LISP routers:
163 HA and HB. HA is attached to the two LISP xTRs LR1 and LR2, which
164 are attached to two different ISPs. HB is attached to the two LISP
165 xTRs LR3 and LR4. HA and HB are the EIDs of the two hosts. LR1,
166 LR2, LR3, and LR4 are the RLOCs of the xTRs.
168 +-----+
169 | HA |
170 +-----+
171 | EID: HA
172 |
173 -----------------
174 | |
175 +-----+ +-----+
176 | LR1 | | LR2 |
177 +-----+ +-----+
178 | |
179 | |
180 +-----+ +-----+
181 |ISP1 | |ISP2 |
182 +-----+ +-----+
183 | |
184 +----------------+ +-----+
185 | |-----| SA |
186 | | +-----+
187 | Internet |
188 | | +-----+
189 | |-----| NSA |
190 +----------------+ +-----+
191 | |
192 +-----+ +-----+
193 | LR3 | | LR4 |
194 +-----+ +-----+
195 | |
196 -------------------
197 |
198 | EID: HB
199 +-----+
200 | HB |
201 +-----+
203 Figure 1: Reference Network
205 We consider two off-path attackers with different capabilities:
207 SA is an off-path attacker that is able to send spoofed packets,
208 i.e., packets with a different source IP address than its
209 assigned IP address.
211 NSA is an off-path attacker that is only able to send packets whose
212 source address is its assigned IP address.
214 It should be noted that with LISP, packet spoofing is slightly
215 different than in the current Internet. Generally the term "spoofed
216 packet" indicates a packet containing a source IP address which is
217 not the one of the actual originator of the packet. Since LISP uses
218 encapsulation, the spoofed address can be in the outer header as well
219 as in the inner header, this translates in two types of spoofing:
221 EID Spoofing: the originator of the packet puts in it a spoofed EID.
222 The packet will be normally encapsulated by the ITR of the
223 site.
225 RLOC Spoofing: the originator of the packet generates directly a
226 LISP-encapsulated packet with a spoofed source RLOC.
228 Note that the two types of spoofing are not mutually exclusive,
229 rather all combinations are possible and can be used to perform
230 different kind of attacks.
232 In our reference environment, both SA and NSA attackers are capable
233 of sending LISP encapsulated data packets and LISP control packets.
234 This means that SA is able to perform both RLOC and EID spoofing
235 while NSA can only perform EID spoofing. They may also send other
236 types of IP packets such as ICMP messages. We assume that both
237 attackers can query the LISP mapping system to obtain the mappings
238 for both HA and HB.
240 6. Data-Plane Threats
242 This section discusses threats and attacks related to the LISP data-
243 plane. More precisely, we discuss the operations of encapsulation,
244 decapsulation, and forwarding as well as the content of the EID-to-
245 RLOC Cache and EID-to-RLOC Database as specified in the original LISP
246 document ([I-D.ietf-lisp]).
248 We start considering the two main data structures of LISP, namely the
249 EID-to-RLOC Database and the EID-to-RLOC Cache. Then, we look at the
250 data plane attacks that can be performed by a spoofing off-path
251 attacker (SA) and discuss how they can be mitigated by the LISP xTRs.
252 In this analysis, we assume that the LR1 and LR2 (resp. LR3 and LR4)
253 xTRs maintain a EID-to-RLOC Cache that contains the required mapping
254 entries to allow HA and HB to exchange packets.
256 6.1. EID-to-RLOC Database Threats
258 The EID-to-RLOC Database on each xTR maintains the set of mappings
259 related to the EID-Prefixes that are "behind" the xTR. Where
260 "behind" means that at least one of the xTR's globally-visible IP
261 addresses is a RLOC for those EID-Prefixes.
263 As described in [I-D.ietf-lisp], the EID-to-RLOC Database content is
264 determined by configuration. This means that the only way to attack
265 this data structure is by gaining privileged access to the xTR. As
266 such, it is out of the scope of LISP to propose any mechanism to
267 protect routers and, hence, it is no further analyzed in this
268 document.
270 6.2. EID-to-RLOC Cache Threats
272 A key component of the overall LISP architecture is the EID-to-RLOC
273 Cache. The EID-to-RLOC Cache is the data structure that stores the
274 bindings between EID and RLOC (namely the "mappings") to be used
275 later on. Attacks against this data structure can happen either when
276 the mappings are first installed in the cache (see also Section 7) or
277 by corrupting (poisoning) the mappings already present in the cache.
279 6.2.1. EID-to-RLOC Cache poisoning
281 The content of the EID-to-RLOC Cache can be poisoned by spoofing LISP
282 encapsulated packets. Example of EID-to-RLOC Cache poisoning are:
284 Fake mapping: The cache contains entirely fake mappings that do not
285 originate from an authoritative mapping server. This can be
286 achieved either through gleaning as described in Section 7.3 or
287 by attacking the control-plane as described in Section 7.
289 EID Poisoning: The EID-Prefix in a specific mapping is not owned by
290 the originator of the entry. Similarly to the previous case,
291 this can be achieved either through gleaning as described in
292 Section 7.3 or by attacking the control-plane as described in
293 Section 7.
295 EID redirection/RLOC poisoning: The EID-Prefix in the mapping is not
296 bound to (located by) the set of RLOCs present in the mapping.
297 This can result in packets being redirected elsewhere,
298 eavesdropped, or even blackholed. Note that not necessarily
299 all RLOCs are fake/spoofed. The attack works also if only part
300 of the RLOCs, the highest priority ones, are compromised.
301 Again, this can be achieved either through the gleaning as
302 described in Section 7.3 or by attacking the control-plane as
303 described in Section 7.
305 Reachability poisoning: The reachability information stored in the
306 mapping could be poisoned, redirecting the packets to a subset
307 of the RLOCs (or even stopping it if locator status bits are
308 all set to 0). If reachability information is not verified
309 through the control-plane this attack can be simply achieved by
310 sending a spoofed packet with swapped or all locator status
311 bits reset. The same result can be obtained by attacking the
312 control-plane as described in Section 7. Depending on how the
313 RLOC reachability information is stored on the router, the
314 attack can impact only one mapping or all the mappings that
315 share the same RLOC.
317 Traffic Engineering information poisoning: The LISP protocol defines
318 two attributes associated to each RLOC in order to perform
319 inbound Traffic Engineering: namely priority and weight. By
320 injecting fake TE attributes, the attacker is able to break
321 load balancing policies and concentrate all the traffic on a
322 single RLOC or put more load on a RLOC than what is expected,
323 creating congestion. It is even possible to block the traffic
324 if all the priorities are set to 255. Corrupting the TE
325 attributes can be achieved by attacking the control-plane as
326 described in Section 7.
328 Mapping TTL poisoning: The LISP protocol associates a Time-To-Live
329 to each mapping that, once expired, allows to delete a mapping
330 from the EID-to-RLOC Cache (or forces a Map-Request/Map-Reply
331 exchange to refresh it if still needed). By injecting fake TTL
332 values, an attacker can either shrink the EID-to-RLOC Cache
333 (using very short TTL), thus creating an excess of cache miss
334 causing a DoS on the mapping system, or it can increase the
335 size of the cache by putting very high TTL values, up to a
336 cache overflow (see Section 6.2.2). Corrupting the TTL can be
337 achieved by attacking the control-plane as described in
338 Section 7. Long TTL can be use in fake mappings to increase an
339 attack duration.
341 Instance ID poisoning: The LISP protocol allows to use a 24-bit
342 identifier to select the forwarding table to use on the
343 decapsulating ETR to forward the decapsulated packet. By
344 spoofing this attribute the attacker is able to redirect or
345 blackhole inbound traffic. Corrupting the Instance ID
346 attribute can be achieved by attacking the control-plane as
347 described in Section 7.
349 Map-Version poisoning: The LISP protocol allows to associate a
350 version number to mappings ([I-D.ietf-lisp-map-versioning]).
351 The LISP header can transport source and destination map-
352 versions, describing which version of the mapping have been
353 used to select the source and the destination RLOCs of the LISP
354 encapsulated packet. By spoofing this attribute the attacker
355 is able to trigger Map-Request on the receiving ETR.
356 Corrupting the Map-Version attribute can be achieved either by
357 attacking the control-plane as described in Section 7 or by
358 using spoofed packets as described in Section 6.4.2.
360 If the above listed attacks succeed, the attacker has the means of
361 controlling the traffic.
363 6.2.2. EID-to-RLOC Cache overflow
365 Depending on how the EID-to-RLOC Cache is managed (e.g., LRU vs. LFU)
366 and depending on its size, an attacker can try to fill the cache with
367 fake mappings. Once the cache is full, some mappings will be
368 replaced by new fake ones, causing traffic disruption.
370 This can be achieved either through the gleaning as described in
371 Section 7.3 or by attacking the control-plane as described in
372 Section 7.
374 Another way to generate a EID-to-RLOC Cache overflow is by injecting
375 mapping with a fake and very large TTL value. In this case the cache
376 will keep a large amount of mappings ending with a completely full
377 cache. This type of attack can also be performed through the
378 control-plane.
380 6.3. Attacks not leveraging on the LISP header
382 We first consider an attacker that sends packets without exploiting
383 the LISP header, i.e., with the N, L, E, V, and I bits reset
384 ([I-D.ietf-lisp]).
386 To inject a packet in the HA-HB flow, a spoofing off-path attacker
387 (SA) can send a LISP encapsulated packet whose source is set to LR1
388 or LR2 and destination LR3 or LR4. The packet will reach HB as if
389 the packet was sent by host HA. This is not different from today's
390 Internet where a spoofing off-path attacker may inject data packets
391 in any flow. Several existing techniques can be used by hosts to
392 prevent such attacks from affecting established flows, e.g.,
393 [RFC4301] and [I-D.ietf-tcpm-tcp-security] .
395 On the other hand, a non-spoofing off-path attacker (NSA) can only
396 send a packet whose source address is set to its assigned IP address.
397 The destination address of the encapsulated packet can be LR3 or LR4.
398 When the LISP ETR that serves HB receives the encapsulated packet, it
399 can consult its EID-to-RLOC Cache and verify that NSA is not a valid
400 source address for LISP encapsulated packets containing a packet sent
401 by HA. This verification is only possible if the ETR already has a
402 valid mapping for HA. Otherwise, and to avoid such data packet
403 injection attacks, the LISP ETR should reject the packet and possibly
404 query the mapping system to obtain a mapping for the encapsulated
405 source EID (HA).
407 6.4. Attacks leveraging on the LISP header
409 The latest LISP draft [I-D.ietf-lisp] defines several flags that
410 modify the interpretation of the LISP header in data packets. In
411 this section, we discuss how an off-path attacker could exploit this
412 LISP header.
414 6.4.1. Attacks using the Locator Status Bits
416 When the L bit is set to 1, it indicates that the second 32-bits
417 longword of the LISP header contains the Locator Status Bits. In
418 this field, each bit position reflects the status of one of the RLOCs
419 mapped to the source EID found in the encapsulated packet. In
420 particular, a packet with the L bit set and all Locator Status Bits
421 set to zero indicates that none of the locators of the encapsulated
422 source EID are reachable. The reaction of a LISP ETR that receives
423 such a packet is not clearly described in [I-D.ietf-lisp].
425 A spoofing off-path attacker (SA) can send a data packet with the L
426 bit set to 1, all Locator Status Bits set to zero, a spoofed source
427 RLOC (e.g. LR1), destination LR3, and containing an encapsulated
428 packet whose source is HA. If LR3 blindly trust the Locator Status
429 Bits of the received packet it will set LR1 and LR2 as unreachable,
430 possibly disrupting ongoing communication.
432 Locator Status Bits can be blindly trusted only in secure
433 environments. In the general unsecured Internet environment, the
434 safest practice for xTRs is to confirm the reachability change
435 through the mapping system. In the above example, LR3 should note
436 that something as changed in the Locator Status Bits and query the
437 mapping system in order to confirm status of the RLOCs of the source
438 EID.
440 A similar attack could occur by setting only one Locator Status Bit
441 to 1, e.g., the one that corresponds to the source RLOC of the
442 packet.
444 If a non-spoofing off-path attacker (NSA) sends a data packet with
445 the L bit set to 1 and all Locator Status Bits set to zero, this
446 packet will contain the source address of the attacker. Similarly as
447 in Section 6.3, if the xTR accepts the packet without checking the
448 EID-to-RLOC Cache for a mapping that binds the source EID and the
449 source RLOC of the received packet, then the same observation like
450 for the the spoofing attacker (SA) apply.
452 Otherwise, if the xTR does make the check through the EID-to-RLOC
453 Cache, it should reject the packet because its source address is not
454 one of the addresses listed as RLOCs for the source EID.
456 Nevertheless, in this case a Map-Request should be sent, which can be
457 used to perform Denial of Service attacks. Indeed an attacker can
458 frequently change the Locator Status Bits in order to trigger a large
459 amount of Map-Requests. Rate limitation, as described in
460 [I-D.ietf-lisp], does not allow to send high number of such a
461 request, resulting in the attacker saturating the rate with these
462 spoofed packets.
464 6.4.2. Attacks using the Map-Version bit
466 The Map-Version bit is used to indicate whether the low-order 24 bits
467 of the first 32 bits word of the LISP header contain an Source and
468 Destination Map-Version. When a LISP ETR receives a LISP
469 encapsulated packet with the Map-Version bit set to 1, the following
470 actions are taken:
472 o It compares the Destination Map-Version found in the header with
473 the current version of its own mapping, in the EID-to-RLOC
474 Database, for the destination EID found in the encapsulated
475 packet. If the received Destination Map-Version is smaller (i.e.,
476 older) than the current version, the ETR should apply the SMR
477 procedure described in [I-D.ietf-lisp] and send a Map-Request with
478 the SMR bit set.
480 o If a mapping exists in the EID-to-RLOC Cache for the source EID,
481 then it compares the Map-Version of that entry with the Source
482 Map-Version found in the header of the packet. If the stored
483 mapping is older (i.e., the Map-Version is smaller) than the
484 source version of the LISP encapsulated packet, the xTR should
485 send a Map-Request for the source EID.
487 A spoofing off-path attacker (SA) could use the Map-Version bit to
488 force an ETR to send Map-Request messages. The attacker can retrieve
489 the current source and destination Map-Version for both HA and HB.
490 Based on this information, it can send a spoofed packet with an older
491 Source Map-Version or Destination Map-Version. If the size of the
492 Map-Request message is larger than the size of the smallest LISP-
493 encapsulated packet that could trigger such a message, this could
494 lead to amplification attacks (see Section 7.1). Fortunately,
495 [I-D.ietf-lisp] recommends to rate limit the Map-Request messages
496 that are sent by an xTR. This prevents the amplification attack, but
497 there is a risk of Denial of Service attack if an attacker sends
498 packets with Source and Destination Map-Versions that frequently
499 change. In this case, the ETR could consume all its rate by sending
500 Map-Request messages in response to these spoofed packets.
502 A non-spoofing off-path attacker (NSA) cannot success in such an
503 attack if the destination xTR rejects the LISP encapsulated packets
504 that are not sent by one of the RLOCs mapped to the included source
505 EID. If it is not the case, the attacker can be able to perform
506 attacks concerning the Destination Map Version number as for the
507 spoofing off-path attacker (SA).
509 6.4.3. Attacks using the Nonce-Present and the Echo-Nonce bits
511 The Nonce-Present and Echo-Nonce bits are used when verifying the
512 reachability of a remote ETR. Assume that LR3 wants to verify that
513 LR1 receives the packets that it sends. LR3 can set the Echo-Nonce
514 and the Nonce-Present bits in LISP data encapsulated packets and
515 include a random nonce in these packets. Upon reception of this
516 packet, LR1 will store the nonce sent by LR3 and echo it when it
517 returns LISP encapsulated data packets to LR3.
519 A spoofing off-path attacker (SA) could interfere with this
520 reachability test by sending two different types of packets:
522 1. LISP data encapsulated packets with the Nonce-Present bit set and
523 a random nonce and the appropriate source and destination RLOCs.
525 2. LISP data encapsulated packets with the Nonce-Present and the
526 Echo-Nonce bits both set and the appropriate source and
527 destination RLOCs. These packets will force the receiving ETR to
528 store the received nonce and echo it in the LISP encapsulated
529 packets that it sends.
531 The first type of packet should not cause any major problem to ITRs.
532 As the reachability test uses a 24 bits nonce, it is unlikely that an
533 off-path attacker could send a packet that causes an ITR to believe
534 that the ETR it is testing is reachable while in reality it is not
535 reachable.
537 The second type of packet could be exploited to create a Denial of
538 Service attack against the nonce-based reachability test. Consider a
539 spoofing off-path attacker (SA) that sends a continuous flow of
540 spoofed LISP data encapsulated packets that contain the Nonce-Present
541 and the Echo-Nonce bit and each packet contains a different random
542 nonce. The ETR that receives such packets will continuously change
543 the nonce that it returns to the remote ITR. If the remote ITR
544 starts a nonce-reachability test, this test may fail because the ETR
545 has received a spoofed LISP data encapsulated packet with a different
546 random nonce and never echoes the real nonce. In this case the ITR
547 will consider the ETR not reachable. The success of this test will
548 of course depend on the ratio between the amount of packets sent by
549 the legitimate ITR and the spoofing off-path attacker (SA).
551 Packets sent by a non-spoofing off-path attacker (NSA) can cause
552 similar problem if no check is done with the EID-to-RLOC Cache (see
553 Section 6.3 for the EID-to-RLOC Cache check). Otherwise, if the
554 check is performed the packets will be rejected by the ETR that
555 receives them and cannot cause problems.
557 7. Control Plane Threats
559 In this section, we discuss the different types of attacks that can
560 occur when an off-path attacker sends control plane packets. We
561 focus on the packets that are sent directly to the ETR and do not
562 analyze the particularities of a LISP mapping system. The ALT
563 mapping system is discussed in Section 10.
565 7.1. Attacks with Map-Request messages
567 An off-path attacker could send Map-Request packets to a victim ETR.
568 In theory, a Map-Request packet is only used to solicit an answer and
569 as such it should not lead to security problems. However, the LISP
570 specification [I-D.ietf-lisp] contains several particularities that
571 could be exploited by an off-path attacker.
573 The first possible exploitation is the P bit. The P bit is used to
574 probe the reachability of remote ETRs in the control plane. In our
575 reference environment, LR3 could probe the reachability of LR1 by
576 sending a Map-Request with the P bit set. LR1 would reply by sending
577 a Map-Reply message with the P bit set and the same nonce as in the
578 Map-Request message.
580 A spoofing off-path attacker (SA) could use the P bit to force a
581 victim ETR to send a Map-Reply to the spoofed source address of the
582 Map-Request message. As the Map-Reply can be larger than the Map-
583 Request message, there is a risk of amplification attack.
584 Considering only IPv6 addresses, a Map-Request can be as small as 40
585 bytes, considering one single ITR address and no Mapping Protocol
586 Data. The Map-Reply instead has a size of O(12 + (R * (28 + N *
587 24))) bytes, where N is the maximum number of RLOCs in a mapping and
588 R the maximum number of records in a Map-Reply. Since up to 255
589 RLOCs can be associated to an EID-Prefix and 255 records can be
590 stored in a Map-Reply, the maximum size of a Map-Reply is thus above
591 1 MB showing a size factor of up to 39,193 between the message sent
592 by the attacker and the message sent by the ETR. These numbers are
593 however theoretical values not considering transport layer
594 limitations and it is more likely that the reply will contain only on
595 record with at most a dozen of locators, giving an amplification
596 factor around 8.
598 Any ISP with a large number of potential RLOCs for a given EID-Prefix
599 should carefully ponder the best trade-off between the number of
600 RLOCs through which it wants that the EID is reachable and the
601 consequences that an amplification attack can produce.
603 It should be noted that the maximum rate of Map-Reply messages should
604 apply to all Map-Replies and also be associated to each destination
605 that receives Map-Reply messages. Otherwise, a possible
606 amplification attack could be launched by a spoofing off-path
607 attacker (SA) as follows. Consider an attacker SA and and EID-Prefix
608 p/P and a victim ITR. To amplify a Denial of Service attack against
609 the victim ITR, SA could send spoofed Map-Request messages whose
610 source EID addresses are all the addresses inside p/P and source RLOC
611 address is the victim ITR. Upon reception of these Map-Request
612 messages, the ETR would send large Map-Reply messages for each of the
613 addresses inside p/P back to the victim ITR.
615 If a non-spoofing off-path attacker (NSA) sends a Map-Request with
616 the P bit set, it will receive a Map-Reply with the P bit set. This
617 does not raise security issues besides the usual risk of overloading
618 a victim ETR by sending too many Map-Request messages.
620 The Map-Request message may also contain the SMR bit. Upon reception
621 of a Map-Request message with the SMR bit, an ETR must return to the
622 source of the Map-Request message a Map-Request message to retrieve
623 the corresponding mapping. This raises similar problems as the P bit
624 discussed above except that as the Map-Request messages are smaller
625 than Map-Reply messages, the risk of amplification attacks is
626 reduced. This is not true anymore if the ETR append to the Map-
627 Request messages its own Map-Records. This mechanism is meant to
628 reduce the delay in mapping distribution since mapping information is
629 provided in the Map-Request message.
631 Furthermore, appending Map-Records to Map-Request messages represents
632 a major security risk since an off-path attacker could generate a
633 (spoofed or not) Map-Request message and include in the Map-Reply
634 portion of the message mapping for EID prefixes that it does not
635 serve. This could lead to various types of redirection and denial of
636 service attacks. An xTR should not process the Map-Records
637 information that it receives in a Map-Request message.
639 7.2. Attacks with Map-Reply messages
641 In this section we analyze the attacks that could occur when an off-
642 path attacker sends directly Map-Reply messages to ETRs without using
643 one of the proposed LISP mapping systems.
645 There are two different types of Map-Reply messages:
647 Positive Map-Reply: This messages contain a Map-Record binding an
648 EID-Prefix to one or more RLOCs.
650 Negative Map-Reply: This messages contain a Map-Record for an EID-
651 Prefix with an empty locator-set and specifying an action,
652 which may be either Drop, Natively forward, or Send Map-
653 Request.
655 Positive Map-Reply messages are used to map EID-Prefixes onto RLOCs.
656 Negative Map-Reply messages are used to support PTR and interconnect
657 the LISP Internet with the legacy Internet.
659 Most of the security of the Map-Reply messages depend on the 64 bits
660 nonce that is included in a Map-Request and returned in the Map-
661 Reply. An ETR must never accept a Map-Request message whose nonce
662 does not match one of the pending Map-Request messages. If an ETR
663 does not accept Map-Reply messages with an invalid nonce, the risk of
664 attack is very small given the size of the nonce (64 bits).
666 Note, however, that the nonce only confirms that the Map-Reply was
667 sent by the ETR that received the Map-Request. It does not validate
668 the content of the Map-Reply message.
670 7.3. Gleaning Attacks
672 A third type of attack involves the gleaning mechanism proposed in
673 [I-D.ietf-lisp] and discussed in [Saucez09]. In order to reduce the
674 time required to obtain a mapping, [I-D.ietf-lisp] allows an ITR to
675 learn a mapping from the LISP data encapsulated packets and the Map-
676 Request packets that it receives. LISP data encapsulated packet
677 contains a source RLOC, destination RLOC, source EID and destination
678 EID. When a ITR receives a data encapsulated packet coming from a
679 source EID for which it does not already know a mapping, it may
680 insert the mapping between the source RLOC and the source EID in its
681 EID-to-RLOC Cache. Gleaning can also be used when an ITR receives a
682 Map-Request as the Map-Request also contains a source EID address and
683 a source RLOC. Once a gleaned entry has been added to the cache, the
684 LISP ITR sends a Map-Request to retrieve the mapping for the gleaned
685 EID from the mapping system. [I-D.ietf-lisp] recommends to store the
686 gleaned entries for only a few seconds.
688 The first risk of gleaning is the ability to temporarily hijack an
689 identity. Consider an off-path attacker that wants to temporarily
690 hijack host HA's identity and send packets to host HB with host HA's
691 identity. If the xTRs that serve host HB do not store a mapping for
692 host HA, a non-spoofing off-path attacker (NSA) could send a LISP
693 encapsulated data packet to LR3 or LR4. The ETR will store the
694 gleaned entry and use it to return the packets sent by host HB to the
695 attacker. In parallel, the ETR will send a Map-Request to retrieve
696 the mapping for HA. During a few seconds or until the reception of
697 the Map-Reply, host HB will exchange packets with the attacker that
698 has hijacked HA's identity. Note that the attacker could in parallel
699 send lots of Map-Requests or lots of LISP data encapsulated packets
700 with random sources to force the xTR that is responsible for host HA
701 to send lots of Map-Request messages in order to force it to exceed
702 its rate limit for control plane messages. This could further delay
703 the arrival of the Map-Reply message on the requesting ETR.
705 Gleaning also introduces the possibility of a man-in-the-middle
706 attack. Consider an off-path attacker that knows that hosts HA and
707 HB that reside in different sites will exchange information at time
708 t. An off-path attacker could use this knowledge to launch a man-in-
709 the-middle attack if the xTRs that serve the two hosts do not have
710 mapping for the other EID. For this, the attacker sends to LR1
711 (resp. LR3) a LISP data encapsulated packet whose source RLOC is its
712 IP address and contains an IP packet whose source is set to HB (resp.
713 HA). The attacker chooses a packet that will not trigger an answer,
714 for example the last part of a fragmented packet. Upon reception of
715 these packets, LR1 and LR3 install gleaned entries that point to the
716 attacker. As explained above, the attacker could, at the same time,
717 send lots of packets to LR1 and LR3 to force them to exhaust their
718 control plane rate limit. This will extend the duration of the
719 gleaned entry. If host HA establishes a flow with host HB at that
720 time, the packets that they exchange will first pass through the
721 attacker.
723 In both cases, the attack only lasts for a few seconds (unless the
724 attacker is able to exhaust the rate limitation). However it should
725 be noted that today a large amount of packets may be exchanged during
726 even a small fraction of time.
728 8. Threats concerning Interworking
730 [I-D.ietf-lisp-interworking] defines two network elements to allow
731 LISP and non-LISP sites to communicate, namely the Proxy-ITR and the
732 Proxy-ETR. The Proxy-ITR encapsulates traffic from non-LISP sites in
733 order to forward it toward LISP sites, while the Proxy-ETR
734 decapsulates traffic arriving from LISP sites in order to forward it
735 toward non-LISP sites. For these elements some of the attack based
736 on the LISP specific header are not possible, for the simple reason
737 that some of the fields cannot be used due to the unidirectional
738 nature of the traffic.
740 The Proxy-ITR has functionalities similar to the ITR, however, its
741 main purpose is to encapsulate packets arriving from the DFZ in order
742 to reach LISP sites. This means that it is no bound to any
743 particular EID-Prefix, hence no mapping exists and no mapping can be
744 configured in the EID-to-RLOC Database. This means that the Proxy-
745 ITR element itself is not able, to check whether or not the arriving
746 traffic has the right to be encapsulated or not. To limit such an
747 issue it is recommended to use the current practice based on
748 firewalls and ACLs on the machine running the Proxy-ITR service. On
749 the other side, the Proxy-ITR is meant to encapsulate only packets
750 that are destined to one of the LISP sites it is serving. This is
751 the case for instance for a service provider selling Proxy-ITR
752 services. For this purpose a static EID-to-RLOC Cache can be
753 configured in order to encapsulate only valid packets. In case of a
754 cache-miss no Map-Request needs to be sent and the packet can be
755 silently dropped.
757 The Proxy-ETR has functionalities similar to the ETR, however, its
758 main purpose is to inject un-encapsulated packet in the DFZ in order
759 to reach non-LISP-Sites. This means that since there is no specific
760 EID-Prefix downstream, it has no EID-to-RLOC Database that can be
761 used to check whether or not the destination EID is part of its
762 domain. In order to avoid for the Proxy-ETR to be used as relay in a
763 DoS attack it is preferable to configure the EID-to-RLOC Cache with
764 static entries used to check if an encapsulated packet coming from a
765 specific RLOC and having a specific source EID is actually allowed to
766 transit through the Proxy-ETR. This is also important for services
767 provider selling Proxy-ETR service to actually process only packets
768 arriving from its customers. However, in case of cache-miss no Map-
769 Request needs to be sent, rather the packet can be silently dropped
770 since it is not originating from a valid site. The same drop policy
771 should be used for packets with an invalid source RLOC or a valid
772 source RLOC but an invalid EID.
774 9. Threats with Malicious xTRs
776 In this section, we discuss the threats that could be caused by
777 malicious xTRs. We consider the reference environment below where
778 EL1 is a malicious or compromised xTR. This malicious xTR serves a
779 set of hosts that includes HC. The other xTR and hosts in this
780 network play the same role as in the reference environment described
781 in Section 5.
783 +-----+
784 | HA |
785 +-----+
786 | EID: HA
787 |
788 -----------------
789 | |
790 +-----+ +-----+
791 | LR1 | | LR2 |
792 +-----+ +-----+
793 | |
794 | |
795 +-----+ +-----+
796 |ISP1 | |ISP2 |
797 +-----+ +-----+
798 | |
799 +----------------+ +-----+ |
800 | |-----| EL1 |--|
801 | | +-----+ |
802 | Internet | | +-----+
803 | | |--| HC |
804 | | | +-----+
805 +----------------+ EID: HC
806 | |
807 +-----+ +-----+
808 | LR3 | | LR4 |
809 +-----+ +-----+
810 | |
811 -------------------
812 |
813 | EID: HB
814 +-----+
815 | HB |
816 +-----+
818 Figure 2: Malicious xTRs' Reference Environment
820 Malicious xTRs are probably the most serious threat to the LISP
821 control plane from a security viewpoint. To understand the problem,
822 let us consider the following scenario. Host HC and HB exchange
823 packets with host HA. As all these hosts reside in LISP sites, LR1
824 and LR2 store mappings for HB and HC. Thus, these xTRs may need to
825 exchange LISP control plane packets with EL1, e.g., to perform
826 reachability tests or to refresh expired mappings (e.g., if HC's
827 mapping has a small TTL).
829 A first threat against the LISP control plane is when EL1 replies to
830 a legitimate Map-Request message sent by LR1 or LR2 with a Map-Reply
831 message that contains an EID-Prefix that is larger than the prefix
832 owned by the site attached to EL1. This could allow EL1 to attract
833 packets destined to other EIDs than the EIDs that are attached to
834 EL1.
836 Another possible attack is a Denial of Service attack by sending a
837 Negative Map-Reply message for a coarser prefix without any locator
838 and with the Drop action. Such a Negative Map-Reply indicates that
839 the ETR that receives it should discard all packets. The current
840 LISP specification briefly discusses this problem [I-D.ietf-lisp],
841 but the proposed solutions does not solve the problem.
843 Another concern with malicious xTRs is the possibility of Denial of
844 Service attacks. A first attack is the flooding attack that was
845 described in [I-D.bagnulo-lisp-threat]. This attack allows a
846 malicious xTR to redirect traffic to a victim. The malicious xTR
847 first defines a mapping for HC with two RLOCs: its own RLOC (EL1) and
848 the RLOC of the victim (e.g., LR3). The victim's RLOC is set as
849 unreachable in the mapping. HC starts a large download from host HA.
850 Once the download starts, the malicious xTR updates its Locator
851 Status Bits, changes the mapping's version number or sets the SMR bit
852 such that LR1 updates its EID-to-RLOC Cache to send all packets
853 destined to HC to the victim's RLOC. Instead of downloading from HA,
854 the attacker could also send packets that trigger a response (e.g.,
855 ICMP, TCP SYN, DNS request, ...) to HA. HA would then send its
856 response and its xTR would forward it to the victim's RLOC.
858 An important point to note about this flooding attack is that it
859 reveals a potential problem in the LISP architecture. A LISP ITR
860 relies on the received mapping and possible reachability information
861 to select the RLOC of the ETR that it uses to reach a given EID or
862 block of EIDs. However, if the ITR made a mistake, e.g., due to
863 configuration, implementation or other types of errors and has chosen
864 a RLOC that does not serve the destination EID, there is no easy way
865 for the LISP ETR to inform the ITR of its mistake. A possible
866 solution could be to force a ETR to perform a reachability test with
867 the selected ITR as soon as it selects it. This will be analyzed in
868 the next version of this document.
870 10. Security of the ALT Mapping System
872 One of the assumptions in [I-D.ietf-lisp] is that the mapping system
873 is more secure than sending Map-Request and Map-Reply messages
874 directly. We analyze this assumption in this section by analyzing
875 the security of the ALT mapping system.
877 The ALT mapping system is basically a manually configured overlay of
878 GRE tunnels between ALT routers. BGP sessions are established
879 between ALT routers that are connected through such a tunnel. An ALT
880 router advertises the EID prefixes that it serves over its BGP
881 sessions with neighboring ALT routers and the EID-Prefixes that it
882 has learned from neighboring ALT routers.
884 The ALT mapping system is in fact a discovery system that allows any
885 ALT router to discover the ALT router that is responsible for a given
886 EID-Prefix. To obtain a mapping from the ALT system, an ITR sends a
887 packet containing a Map-Request on the overlay. This Map-Request is
888 sent inside a packet whose destination is the requested EID. The
889 Map-Request is routed on the overlay until it reaches the ALT router
890 that advertised initially the prefix that contains the requested EID.
891 This ALT router then replies directly by sending a Map-Reply to the
892 RLOC of the requesting ITR.
894 The security of the ALT mapping system depends on many factors,
895 including:
897 o The security of the intermediate ALT routers.
899 o The validity of the BGP advertisements sent on the ALT overlay.
901 Unfortunately, experience with BGP on the global Internet has shown
902 that BGP is subject to various types of misconfiguration problems and
903 security attacks. The SIDR working group is developing a more secure
904 inter-domain routing architecture to solve this problem
905 ([I-D.ietf-sidr-arch]).
907 The security of the intermediate ALT routers is another concern. A
908 malicious intermediate ALT router could manipulate the received BGP
909 advertisements and also answer to received Map-Requests without
910 forwarding them to their final destination on the overlay. This
911 could lead to various types of redirection attacks. Note that in
912 contrast with a regular IP router that could also manipulate in
913 transit packets, when a malicious or compromised ALT router replies
914 to a Map-Request, it can redirect legitimate traffic for a long
915 period of time by sending an invalid Map-Reply message. Thus, the
916 impact of a malicious ALT router could be much more severe than a
917 malicious router in today's Internet.
919 11. Suggested Recommendations
921 To mitigate the impact of attacks against LISP, the following
922 recommendations should be followed.
924 First, the use of some form of filtering can help in avoid or at
925 least mitigate some types of attacks.
927 o On ETRs, packets should be decapsulated only if the destination
928 EID is effectively part of the EID-Prefix downstream the ETR.
929 Further, still on ETRs, packets should be decapsulated only if a
930 mapping for the source EID is present in the EID-to-RLOC Cache and
931 has been obtained through the mapping system (not gleaned).
933 o On ITRs, packets should be encapsulated only if the source EID is
934 effectively part of the EID-Prefix downstream the ITR. Further,
935 still on ITRs, packets should be encapsulated only if a mapping
936 obtained from the mapping system is present in the EID-to-RLOC
937 Cache (no Data-Probing).
939 Note that this filtering, since complete mappings need to be
940 installed in both ITRs and ETRs, can introduce a higher connection
941 setup latency and hence potentially more packets drops due to the
942 lack of mappings in the EID-to-RLOC Cache.
944 While the gleaning mechanism allows to start encapsulating packets to
945 a certain EID in parallel with the Map-Request to obtain a mapping
946 when a new flow is established, it creates important security risks
947 since it allows attackers to perform identity hijacks. Although the
948 duration of these identity hijacks is limited (except the case of
949 rate limitation exhaustion), their impact can be severe. A first
950 option would be to disable gleaning until the security concerns are
951 solved. A second option would be to strictly limit the number of
952 packets that can be forwarded via a gleaned entry. Overall the
953 benefits of gleaning, i.e., avoiding the loss of the first packet of
954 a flow, seems very small compared to the associated security risks.
955 Furthermore, measurements performed in data centers show that today's
956 Internet often operate with packet loss ratio of 1 or 2 percentage
957 ([Chu]). These packet loss ratio are probably already orders of
958 magnitude larger than the improvement provided by the gleaning
959 mechanism.
961 With the increasing deployment of spoofing prevention techniques such
962 as [RFC3704] or SAVI [SAVI], it can be expected that attackers will
963 become less capable of sending packets with a spoofed source address.
964 To prevent packet injection attacks from non-spoofing attackers
965 (NSA), ETRs should always verify that the source RLOC of each
966 received LISP data encapsulated packet corresponds to one of the
967 RLOCs listed in the mappings for the source EID found in the inner
968 packet. An alternative could be to use existing IPSec techniques
969 [RFC4301]and when necessary including perhaps [RFC5386] to establish
970 an authenticated tunnel between the ITR and the ETR.
972 [I-D.ietf-lisp] recommends to rate limit the control messages that
973 are sent by a xTR. This limit is important to deal with denial of
974 service attacks. However, a strict limit, e.g., implemented with a
975 token bucket, on all the Map-Request and Map-Reply messages sent by a
976 xTR is not sufficient. A xTR should distinguish between different
977 types of control plane packets:
979 1. The Map-Request messages that it sends to refresh expired mapping
980 information.
982 2. The Map-Request messages that it sends to obtain mapping
983 information because one of the served hosts tried to contact an
984 external EID.
986 3. The Map-Request messages that it sends as reachability probes.
988 4. The Map-Reply messages that it sends as response to reachability
989 probes.
991 5. The Map-Request messages that it sends to support gleaning.
993 These control plane messages are used for different purposes. Fixing
994 a global rate limit for all control plane messages increases the risk
995 of Denial of Service attacks if a single type of control plane
996 message can exceed the configured limit. This risk could be
997 mitigated by either specifying a rate for each of the five types of
998 control plane messages. Another option could be to define a maximum
999 rate for all control plane messages, and prioritize the control plane
1000 messages according to the list above (with the highest priority for
1001 message type 1).
1003 In [I-D.ietf-lisp], there is no mechanism that allows a xTR to verify
1004 the validity of the content a Map-Reply message that it receives.
1005 Besides the attacks discussed earlier in the document, a time-shifted
1006 attack where an attacker is able to modify the content of a Map-Reply
1007 message but then needs to move off-path could also create redirection
1008 attacks. The nonce only allows a xTR to verify that a Map-Reply
1009 responds to a previously sent Map-Request message. The LISP Working
1010 Group should explore solutions that allow to verify the validity and
1011 integrity of bindings between EID-Prefixes and their RLOCS (e.g.,
1012 [I-D.saucez-lisp-mapping-security] and [I-D.maino-lisp-sec]). Having
1013 such kind of mechanism would allow ITRs to ignore non-verified
1014 mappings, thus increasing security.
1016 LISP Working Group should consider developing secure mechanisms to
1017 allow an ETR to indicate to an ITR that it does not serve a
1018 particular EID or block of EIDs in order to mitigate the flooding
1019 attacks.
1021 Finally, there is also the risk of Denial of Service attack against
1022 the EID-to-RLOC Cache. We have discussed these attacks when
1023 considering external attackers with, e.g., the gleaning mechanism and
1024 in Section 6.2. If an ITR has a limited EID-to-RLOC Cache, a
1025 malicious or compromised host residing in the site that it serves
1026 could generate packets to random destinations to force the ITR to
1027 issue a large number of Map-Requests whose answers could fill its
1028 cache. Faced with such misbehaving hosts, LISP ITR should be able to
1029 limit the percent of Map-Requests that it sends for a given source
1030 EID.
1032 12. Document Status and Plans
1034 In this document, we have analyzed some of the security threats that
1035 affect the Locator/Identifier Separation Protocol (LISP). We have
1036 focused our analysis on unicast traffic and considered both the LISP
1037 data and control planes, and provided some recommendations to improve
1038 the security of LISP.
1040 Revisions of this document will document the security threats of
1041 other parts of the LISP architecture, including but not limited to:
1043 o Instance ID attribute.
1045 o LISP Multicast.
1047 o LISP Map-Server.
1049 13. IANA Considerations
1051 This document makes no request to IANA.
1053 14. Security Considerations
1055 Security considerations are the core of this document and do not need
1056 to be further discussed in this section.
1058 15. Acknowledgments
1060 The flooding attack and the reference environment were first
1061 described in Marcelo Bagnulo's draft [I-D.bagnulo-lisp-threat].
1063 This work has been partially supported by the INFSO-ICT-216372
1064 TRILOGY Project (www.trilogy-project.org).
1066 16. References
1068 16.1. Normative References
1070 [I-D.ietf-lisp]
1071 Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
1072 "Locator/ID Separation Protocol (LISP)",
1073 draft-ietf-lisp-10 (work in progress), March 2011.
1075 [I-D.ietf-lisp-alt]
1076 Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP
1077 Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-06
1078 (work in progress), March 2011.
1080 [I-D.ietf-lisp-interworking]
1081 Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
1082 "Interworking LISP with IPv4 and IPv6",
1083 draft-ietf-lisp-interworking-02 (work in progress),
1084 March 2011.
1086 [I-D.ietf-lisp-map-versioning]
1087 Iannone, L., Saucez, D., and O. Bonaventure, "LISP Map-
1088 Versioning", draft-ietf-lisp-map-versioning-01 (work in
1089 progress), March 2011.
1091 [I-D.ietf-lisp-ms]
1092 Fuller, V. and D. Farinacci, "LISP Map Server",
1093 draft-ietf-lisp-ms-07 (work in progress), March 2011.
1095 [I-D.ietf-lisp-multicast]
1096 Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas,
1097 "LISP for Multicast Environments",
1098 draft-ietf-lisp-multicast-04 (work in progress),
1099 October 2010.
1101 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1102 Requirement Levels", BCP 14, RFC 2119, March 1997.
1104 16.2. Informative References
1106 [Chu] Jerry Chu, H., "Tuning TCP Parameters for the 21st
1107 Century", 75th IETF, Stockholm, July 2009,
1108 .
1110 [I-D.bagnulo-lisp-threat]
1111 Bagnulo, M., "Preliminary LISP Threat Analysis",
1112 draft-bagnulo-lisp-threat-01 (work in progress),
1113 July 2007.
1115 [I-D.ietf-sidr-arch]
1116 Lepinski, M. and S. Kent, "An Infrastructure to Support
1117 Secure Internet Routing", draft-ietf-sidr-arch-12 (work in
1118 progress), February 2011.
1120 [I-D.ietf-tcpm-tcp-security]
1121 Gont, F., "Security Assessment of the Transmission Control
1122 Protocol (TCP)", draft-ietf-tcpm-tcp-security-02 (work in
1123 progress), January 2011.
1125 [I-D.lear-lisp-nerd]
1126 Lear, E., "NERD: A Not-so-novel EID to RLOC Database",
1127 draft-lear-lisp-nerd-08 (work in progress), March 2010.
1129 [I-D.maino-lisp-sec]
1130 Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D.,
1131 and O. Bonaventure, "LISP-Security (LISP-SEC)",
1132 draft-maino-lisp-sec-00 (work in progress), March 2011.
1134 [I-D.meyer-lisp-cons]
1135 Brim, S., "LISP-CONS: A Content distribution Overlay
1136 Network Service for LISP", draft-meyer-lisp-cons-04 (work
1137 in progress), April 2008.
1139 [I-D.saucez-lisp-mapping-security]
1140 Saucez, D. and O. Bonaventure, "Securing LISP Mapping
1141 replies", draft-saucez-lisp-mapping-security-00 (work in
1142 progress), February 2011.
1144 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
1145 Networks", BCP 84, RFC 3704, March 2004.
1147 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
1148 Internet Protocol", RFC 4301, December 2005.
1150 [RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing
1151 Security: An Unauthenticated Mode of IPsec", RFC 5386,
1152 November 2008.
1154 [SAVI] IETF, "Source Address Validation Improvements Working
1155 Group", .
1157 [Saucez09]
1158 Saucez, D. and L. Iannone, "How to mitigate the effect of
1159 scans on mapping systems", Submitted to the Trilogy
1160 Summer School on Future Internet.
1162 Authors' Addresses
1164 Damien Saucez
1165 Universite catholique de Louvain
1166 Place St. Barbe 2
1167 Louvain la Neuve
1168 Belgium
1170 Email: damien.saucez@uclouvain.be
1172 Luigi Iannone
1173 TU Berlin - Deutsche Telekom Laboratories AG
1174 Ernst-Reuter Platz 7
1175 Berlin
1176 Germany
1178 Email: luigi@net.t-labs.tu-berlin.de
1180 Olivier Bonaventure
1181 Universite catholique de Louvain
1182 Place St. Barbe 2
1183 Louvain la Neuve
1184 Belgium
1186 Email: olivier.bonaventure@uclouvain.be