idnits 2.17.1
draft-saucez-lisp-security-01.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 (July 12, 2010) is 5036 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Outdated reference: A later version (-24) exists of draft-ietf-lisp-07
== Outdated reference: A later version (-10) exists of
draft-ietf-lisp-alt-04
== Outdated reference: A later version (-06) exists of
draft-ietf-lisp-interworking-00
== Outdated reference: A later version (-16) exists of draft-ietf-lisp-ms-05
== Outdated reference: A later version (-14) exists of
draft-ietf-lisp-multicast-03
== Outdated reference: A later version (-02) exists of
draft-iannone-lisp-mapping-versioning-01
== Outdated reference: A later version (-13) exists of
draft-ietf-sidr-arch-09
== Outdated reference: A later version (-03) exists of
draft-ietf-tcpm-tcp-security-01
== 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: January 13, 2011 TU Berlin - Deutsche Telekom
6 Laboratories AG
7 O. Bonaventure
8 Universite catholique de Louvain
9 July 12, 2010
11 LISP Security Threats
12 draft-saucez-lisp-security-01
14 Abstract
16 This draft analyses 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 January 13, 2011.
43 Copyright Notice
45 Copyright (c) 2010 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. Reference Environment . . . . . . . . . . . . . . . . . . . . 4
64 4.1. On-path Attackers . . . . . . . . . . . . . . . . . . . . 5
65 5. Data-Plane Threats . . . . . . . . . . . . . . . . . . . . . . 6
66 5.1. LISP-Database Threats . . . . . . . . . . . . . . . . . . 6
67 5.2. LISP-Cache Threats . . . . . . . . . . . . . . . . . . . . 6
68 5.2.1. LISP-Cache poisoning . . . . . . . . . . . . . . . . . 6
69 5.2.2. LISP-Cache overflow . . . . . . . . . . . . . . . . . 8
70 5.3. Attacks not leveraging on the LISP header . . . . . . . . 8
71 5.4. Attacks leveraging on the LISP header . . . . . . . . . . 9
72 5.4.1. Attacks using the Locator Status Bits . . . . . . . . 9
73 5.4.2. Attacks using the Map-Version bit . . . . . . . . . . 10
74 5.4.3. Attacks using the Nonce-Present and the Echo-Nonce
75 bits . . . . . . . . . . . . . . . . . . . . . . . . . 11
76 6. Control Plane Threats . . . . . . . . . . . . . . . . . . . . 12
77 6.1. Attacks with Map-Request messages . . . . . . . . . . . . 12
78 6.2. Attacks with Map-Reply messages . . . . . . . . . . . . . 14
79 6.3. Gleaning Attacks . . . . . . . . . . . . . . . . . . . . . 14
80 7. Threats with Malicious xTRs . . . . . . . . . . . . . . . . . 16
81 8. Security of the ALT Mapping System . . . . . . . . . . . . . . 18
82 9. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 19
83 10. Document Status and Plans . . . . . . . . . . . . . . . . . . 21
84 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
85 12. Security Considerations . . . . . . . . . . . . . . . . . . . 21
86 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
87 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
88 14.1. Normative References . . . . . . . . . . . . . . . . . . . 22
89 14.2. Informative References . . . . . . . . . . . . . . . . . . 22
90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
92 1. Requirements notation
94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
96 document are to be interpreted as described in [RFC2119].
98 2. Introduction
100 The Locator/ID Separation Protocol (LISP) is defined in
101 [I-D.ietf-lisp]. The present document aims at identifying threats in
102 the current LISP specification. We also propose some recommendations
103 on mechanisms that could improve the security of LISP against off-
104 path attackers. This document builds upon [I-D.bagnulo-lisp-threat].
106 This document is split in two main parts. The first discusses the
107 LISP data-plane and the second the LISP control-plane.
109 The LISP data-plane consists of LISP packet encapsulation,
110 decapsulation, and forwarding and includes the LISP-Cache and LISP-
111 Database data structures used to perform these operations.
113 The LISP control-plane consists in the mapping distribution system,
114 which can be one of the mapping distribution systems proposed so far
115 (e.g., [I-D.ietf-lisp], [I-D.ietf-lisp-alt], [I-D.ietf-lisp-ms],
116 [I-D.meyer-lisp-cons], and [I-D.lear-lisp-nerd]), and the Map-Request
117 and Map-Reply messages.
119 This document does not consider all the possible utilizations of LISP
120 as discussed in [I-D.ietf-lisp]. In the current version, we focus on
121 LISP unicast and briefly consider the ALT mapping system described
122 [I-D.ietf-lisp-alt]. Later versions of this document will include a
123 deeper analysis of the ALT mapping system, as well as the analysis of
124 the security issues in multicast LISP ([I-D.ietf-lisp-multicast]),
125 interworking between LISP and the legacy IPv4 and IPv6 Internet
126 ([I-D.ietf-lisp-interworking]), and LISP-MS ([I-D.ietf-lisp-ms]).
128 Furthermore, here we assume a generic IP service and do not discuss
129 the difference from a security viewpoint between using IPv4 or IPv6.
131 3. Definition of Terms
133 The present document does not introduce any new term, compared to the
134 main LISP specification. For a complete list of terms please refer
135 to [I-D.ietf-lisp].
137 4. Reference Environment
139 Throughout this document we consider the reference environment shown
140 in the figure below. There are two hosts attached to LISP routers:
141 HA and HB. HA is attached to LISP xTR LR1 and LR2 that are attached
142 to two different ISPs. HB is attached to LISP xTR LR3 and LR4. HA
143 and HB are the EIDs of the two hosts. LR1, LR2, LR3 and LR4 are the
144 RLOCs of the xTRs.
146 +----+
147 | HA |
148 +----+
149 | EID: HA
150 |
151 -----------------
152 | |
153 +----+ +----+
154 |LR1 | |LR2 |
155 +----+ +----+
156 | |
157 | |
158 +----+ +----+
159 |ISP1| |ISP2|
160 +----+ +----+ +----+
161 | | +--| SA |
162 +----------------+ | +----+
163 | |--+
164 | Internet | +----+
165 | |-----| NSA|
166 +----------------+ +----+
167 | |
168 | |
169 +----+ +----+
170 |LR3 | | LR4|
171 +----+ +----+
172 | |
173 -------------------
174 |
175 | EID: HB
176 +---+
177 | HB|
178 +---+
180 Figure 1: Reference Network
182 We consider two off-path attackers with different capabilities:
184 SA is an off-path attacker that is able to send spoofed packets,
185 i.e., packets with a different source IP address than its
186 assigned IP address.
188 NSA is an off-path attacker that is only able to send packets whose
189 source address is its assigned IP address.
191 It should be noted that with LISP, packet spoofing is slightly
192 different than in the current Internet. Generally the term "spoofed
193 packet" indicates a packet containing a source IP address which is
194 not the one of the actual originator of the packet. Since LISP uses
195 encapsulation, this translates in two types of spoofing:
197 EID Spoofing: the originator of the packet puts in it a spoofed EID.
198 The packet will be normally encapsulated by the ITR of the
199 site.
201 RLOC Spoofing: the originator of the packet generates directly a
202 LISP-encapsulated packet with a spoofed source RLOC.
204 Note that the two types of spoofing are not mutually exclusive,
205 rather all combinations are possible and can be used to perform
206 several kind of attacks.
208 In our reference environment, SA is able to perform both RLOC and EID
209 spoofing while NSA can only perform EID spoofing. Both attackers are
210 capable of sending LISP encapsulated data packets and LISP control
211 packets. They may also send other types of IP packets such as ICMP
212 messages. We assume that both attackers can query the LISP mapping
213 system to obtain the mappings for both HA and HB.
215 4.1. On-path Attackers
217 Besides the off-path attackers that we consider in this document,
218 there are other types of attackers. On-path attackers are attackers
219 that are able to capture and modify all the packets exchanged between
220 an ITR and an ETR. To cope with such an attacker, cryptographic
221 techniques such as those used by IPSec are required. We do not
222 consider that LISP has to cope with such attackers.
224 Mobile IP has also considered time-shifted attacks from on-path
225 attackers. A time-shifted attack is an attack where the attacker is
226 temporarily on the path between two communicating hosts. While it is
227 on-path, the attacker sends specially crafted packets or modifies
228 packets exchanged by the communicating hosts in order to disturb the
229 packet flow (e.g., by performing a man in the middle attack). An
230 important issue for time-shifted attacks is the duration of the
231 attack once the attacker has left the path between the two
232 communicating hosts. We do not consider time-shifted attacks in this
233 document.
235 5. Data-Plane Threats
237 This section discusses threats and attacks related to the LISP data-
238 plane. More precisely, we discuss the operations of encapsulation,
239 decapsulation, and forwarding as well as the content of the LISP-
240 Cache and LISP-Database as specified in the original LISP document
241 ([I-D.ietf-lisp]).
243 We start considering the two main data structures of LISP, namely the
244 LISP Database and the LISP Cache. Then, we look at the data plane
245 attacks that can be performed by a spoofing off-path attacker (SA)
246 and discuss how they can be mitigated by the LISP xTRs. In this
247 analysis, we assume that the LR1 and LR2 (resp. LR3 and LR4) xTRs
248 maintain a LISP Cache that contains the required mapping entries to
249 allow HA and HB to exchange packets.
251 5.1. LISP-Database Threats
253 The LISP Database on each xTR maintains the set of mappings related
254 to the EID-Prefixes that are "behind" the xTR. Where "behind" means
255 that at least one of the xTR's globally-visible IP addresses is a
256 RLOC for those EID-Prefixes.
258 As described in [I-D.ietf-lisp], the LISP Database content is
259 determined by configuration. This means that the only way to attack
260 this data structure is by gaining privileged access to the xTR. As
261 such, it is out of the scope of LISP to propose any mechanism to
262 protect routers and, hence, it is no further analyzed in this
263 document.
265 5.2. LISP-Cache Threats
267 A key component of the overall LISP architecture is the LISP-Cache.
268 The LISP-Cache is the data structure that stores the bindings between
269 EID and RLOC (namely the "mappings") to be used later on. Attacks
270 against this data structure can happen either when the mappings are
271 first installed in the cache (see also Section 6) or by corrupting
272 (poisoning) the mappings already present in the cache.
274 5.2.1. LISP-Cache poisoning
276 The content of the LISP-Cache can be poisoned by spoofing LISP
277 encapsulated packets. Example of LISP-Cache poisoning are:
279 Fake mapping: The cache contains entirely fake mappings that do not
280 originate from an authoritative mapping server. This can be
281 achieved either through gleaning as described in Section 6.3 or
282 by attacking the control-plane as described in Section 6.
284 EID Poisoning: The EID-Prefix in a specific mapping is not owned by
285 the originator of the entry. Similarly to the previous case,
286 this can be achieved either through gleaning as described in
287 Section 6.3 or by attacking the control-plane as described in
288 Section 6.
290 EID redirection/RLOC poisoning: The EID-Prefix in the mapping is not
291 bound to (located by) the set of RLOCs present in the mapping.
292 This can result in packets being redirected elsewhere,
293 eavesdropped, or even blackholed. Note that not necessarily
294 all RLOCs are fake/spoofed. The attack works also if only part
295 of the RLOCs, the highest priority ones, are compromised.
296 Again, this can be achieved either through the gleaning as
297 described in Section 6.3 or by attacking the control-plane as
298 described in Section 6.
300 Reachability poisoning: The reachability information stored in the
301 mapping could be poisoned, redirecting the packets to a subset
302 of the RLOCs (or even stopping it if locator status bits are
303 all set to 0). If reachability information is not verified
304 through the control-plane this attack can be simply achieved by
305 sending a spoofed packet with swapped or all locator status
306 bits reset. The same result can be obtained by attacking the
307 control-plane as described in Section 6.
309 Traffic Engineering information poisoning: The LISP protocol defines
310 two attributes associated to each RLOC in order to perform
311 inbound Traffic Engineering: namely priority and weight. By
312 injecting fake TE attributes, the attacker is able to break
313 load balancing policies and concentrate all the traffic on a
314 single RLOC or put more load on a RLOC than what is expected,
315 creating congestion. Corrupting the TE attributes can be
316 achieved by attacking the control-plane as described in
317 Section 6.
319 Mapping TTL poisoning: The LISP protocol associates a Time-To-Live
320 to each mapping that, once expired, allows to delete a mapping
321 from the LISP-Cache (or forces a Map-Request/Map-Reply exchange
322 to refresh it if still needed). By injecting fake TTL values,
323 an attacker can either shrink the Cache (using very short TTL),
324 thus creating an excess of cache miss causing a DoS on the
325 mapping system, or it can increase the size of the cache by
326 putting very high TTL values, up to a cache overflow (see
327 Section 5.2.2). Corrupting the TTL can be achieved by
328 attacking the control-plane as described in Section 6.
330 Instance ID poisoning: The LISP protocol allows to use an 24-bit
331 identifier to select the forwarding table to use on the
332 decapsulating ETR to forward the decapsulated packet. By
333 spoofing this attribute the attacker is able to redirect or
334 blackhole inbound traffic. Corrupting the Instance ID
335 attribute can be achieved by attacking the control-plane as
336 described in Section 6.
338 Map-Version poisoning: The LISP protocol allows to associate a
339 version number to mappings
340 ([I-D.iannone-lisp-mapping-versioning]). The LISP header can
341 transport source and destination map-versions, describing which
342 version of the mapping have been used to select the source and
343 the destination RLOCs of the LISP encapsulated packet. By
344 spoofing this attribute the attacker is able to trigger Map-
345 Request on the receiving xTR. Corrupting the Map-Version
346 attribute can be achieved either by attacking the control-plane
347 as described in Section 6 or by using spoofed packets as
348 described in Section 5.4.2.
350 If the above listed attacks succeed, the attacker has the means of
351 controlling the traffic.
353 5.2.2. LISP-Cache overflow
355 Depending on how the LISP Cache is managed (e.g., LRU vs. LFU) and
356 depending on its size, an attacker can try to fill the cache with
357 fake mappings. Once the cache is full, some mappings will be
358 replaced by new fake ones, causing traffic disruption.
360 This can be achieved either through the gleaning as described in
361 Section 6.3 or by attacking the control-plane as described in
362 Section 6.
364 Another way to generate a LISP-Cache overflow is by injecting mapping
365 with a fake and very large TTL value. In this case the cache will
366 keep a large amount of mappings ending with a completely full cache.
367 This type of attack can also be performed through the control-plane.
369 5.3. Attacks not leveraging on the LISP header
371 We first consider an attacker that sends packets without exploiting
372 the LISP header, i.e., with the N, L, E, V, and I bits reset
373 ([I-D.ietf-lisp]).
375 To inject a packet in the HA-HB flow, a spoofing off-path attacker
376 (SA) can send a LISP encapsulated packet whose source is set to LR1
377 or LR2 and destination LR3 or LR4. The packet will reach HB as if
378 the packet was sent by host HA. This is not different from today's
379 Internet where a spoofing off-path attacker may inject data packets
380 in any flow. Several existing techniques can be used by hosts to
381 prevent such attacks from affecting established flows, e.g.,
382 [RFC4301] and [I-D.ietf-tcpm-tcp-security] .
384 On the other hand, a non-spoofing off-path attacker (NSA) can only
385 send a packet whose source address is set to its assigned IP address.
386 The destination address of the encapsulated packet can be LR3 or LR4.
387 When the LISP ETR that serves HB receives the encapsulated packet, it
388 can consult its LISP-cache and verify that NSA is not a valid source
389 address for LISP encapsulated packets containing a packet sent by HA.
390 This verification is only possible if the ETR already has a valid
391 mapping for HA. Otherwise, and to avoid such data packet injection
392 attacks, the LISP ETR should reject the packet and possibly query the
393 mapping system to obtain a mapping for the encapsulated source EID
394 (HA).
396 5.4. Attacks leveraging on the LISP header
398 The latest LISP draft [I-D.ietf-lisp] defines several flags that
399 modify the interpretation of the LISP header in data packets. In
400 this section, we discuss how an off-path attacker could exploit this
401 LISP header.
403 5.4.1. Attacks using the Locator Status Bits
405 When the L bit is set to 1, it indicates that the second 32-bits
406 longword of the LISP header contains the Locator Status Bits. In
407 this field, each bit position reflects the status of one of the RLOCs
408 mapped to the source EID found in the encapsulated packet. In
409 particular, a packet with the L bit set and all Locator Status Bits
410 set to zero indicates that none of the locators of the encapsulated
411 source EID are reachable. The reaction of a LISP ETR that receives
412 such a packet is not clearly described in [I-D.ietf-lisp].
414 A spoofing off-path attacker (SA) can send a data packet with the L
415 bit set to 1, all Locator Status Bits set to zero, a spoofed source
416 RLOC (e.g. LR1), destination LR3, and containing an encapsulated
417 packet whose source is HA. If LR3 blindly trust the Locator Status
418 Bits of the received packet it will set LR1 and LR2 as unreachable,
419 possibly disrupting ongoing communication.
421 Locator Status Bits can be blindly trusted only in secure
422 environments. In the general unsecured Internet environment, the
423 safest practice for xTRs is to confirm the reachability change
424 through the mapping system. In the above example, LR3 should note
425 that something as changed in the Locator Status Bits and query the
426 mapping system in order to confirm status of the RLOCs of the source
427 EID.
429 A similar attack could occur by setting only one Locator Status Bit
430 to 1, e.g., the one that corresponds to the source RLOC of the
431 packet.
433 If a non-spoofing off-path attacker (NSA) sends a data packet with
434 the L bit set to 1 and all Locator Status Bits set to zero, this
435 packet will contain the source address of the attacker. Similarly as
436 in Section 5.3, if the xTR accepts the packet without checking the
437 LISP Cache for a mapping that binds the source EID and the source
438 RLOC of the received packet, then the same observation like for the
439 the spoofing attacker (SA) apply.
441 Otherwise, if the xTR does make the check through the LISP Cache, it
442 should reject the packet because its source address is not one of the
443 addresses listed as RLOCs for the source EID. Nevertheless, in this
444 case a Map-Request should be sent, which can be used to perform
445 Denial of Service attacks. Indeed an attacker can frequently change
446 the Locator Status Bits in order to trigger a large amount of Map-
447 Requests. Rate limitation, as described in [I-D.ietf-lisp], does not
448 allow to send high number of such a request, resulting in the
449 attacker saturating the rate with these spoofed packets.
451 5.4.2. Attacks using the Map-Version bit
453 The Map-Version bit is used to indicate whether the low-order 24 bits
454 of the first 32 bits word of the LISP header contain an Source and
455 Destination Map-Version. When a LISP ETR receives a LISP
456 encapsulated packet with the Map-Version bit set to 1, the following
457 actions are taken:
459 o It compares the Destination Map-Version found in the header with
460 the current version of its own mapping, in the LISP Database, for
461 the destination EID found in the encapsulated packet. If the
462 received Destination Map-Version is smaller (i.e., older) than the
463 current version, the ETR should apply the SMR procedure described
464 in [I-D.ietf-lisp] and send a Map-Request with the SMR bit set.
466 o If a mapping exists in the LISP Cache for the source EID, then it
467 compares the Map-Version of that entry with the Source Map-Version
468 found in the header of the packet. If the stored mapping is older
469 (i.e., the Map-Version is smaller) than the source version of the
470 LISP encapsulated packet, the xTR should send a Map-Request for
471 the source EID.
473 A spoofing off-path attacker (SA) could use the Map-Version bit to
474 force an ETR to send Map-Request messages. The attacker can retrieve
475 the current source and destination Map-Version for both HA and HB.
476 Based on this information, it can send a spoofed packet with an older
477 Source Map-Version or Destination Map-Version. If the size of the
478 Map-Request message is larger than the size of the smallest LISP-
479 encapsulated packet that could trigger such a message, this could
480 lead to amplification attacks (see Section 6.1). Fortunately,
481 [I-D.ietf-lisp] recommends to rate limit the Map-Request messages
482 that are sent by an xTR. This prevents the amplification attack, but
483 there is a risk of Denial of Service attack if an attacker sends
484 packets with Source and Destination Map-Versions that frequently
485 change. In this case, the ETR could consume all its rate by sending
486 Map-Request messages in response to these spoofed packets.
488 A non-spoofing off-path attacker (NSA) cannot success in such an
489 attack if the destination xTR rejects the LISP encapsulated packets
490 that are not sent by one of the RLOCs mapped to the included source
491 EID. If it is not the case, the attacker can be able to perform
492 attacks concerning the Destination Map Version number as for the
493 spoofing off-path attacker (SA).
495 5.4.3. Attacks using the Nonce-Present and the Echo-Nonce bits
497 The Nonce-Present and Echo-Nonce bits are used when verifying the
498 reachability of a remote ETR. Assume that LR3 wants to verify that
499 LR1 receives the packets that it sends. LR3 can set the Echo-Nonce
500 and the Nonce-Present bits in LISP data encapsulated packets and
501 include a random nonce in these packets. Upon reception of this
502 packet, LR1 will store the nonce sent by LR3 and echo it when it
503 returns LISP encapsulated data packets to LR3.
505 A spoofing off-path attacker (SA) could interfere with this
506 reachability test by sending two different types of packets:
508 1. LISP data encapsulated packets with the Nonce-Present bit set and
509 a random nonce and the appropriate source and destination RLOCs.
511 2. LISP data encapsulated packets with the Nonce-Present and the
512 Echo-Nonce bits both set and the appropriate source and
513 destination RLOCs. These packets will force the receiving ETR to
514 store the received nonce and echo it in the LISP encapsulated
515 packets that it sends.
517 The first type of packet should not cause any major problem to ITRs.
518 As the reachability test uses a 24 bits nonce, it is unlikely that an
519 off-path attacker could send a packet that causes an ITR to believe
520 that the ETR it is testing is reachable while in reality it is not
521 reachable.
523 The second type of packet could be exploited to create a Denial of
524 Service attack against the nonce-based reachability test. Consider a
525 spoofing off-path attacker (SA) that sends a continuous flow of
526 spoofed LISP data encapsulated packets that contain the Nonce-Present
527 and the Echo-Nonce bit and each packet contains a different random
528 nonce. The ETR that receives such packets will continuously change
529 the nonce that it returns to the remote ITR. If the remote ITR
530 starts a nonce-reachability test, this test may fail because the ETR
531 has received a spoofed LISP data encapsulated packet with a different
532 random nonce and never echoes the real nonce. In this case the ITR
533 will consider the ETR not reachable. The success of this test will
534 of course depend on the ratio between the amount of packets sent by
535 the legitimate ITR and the spoofing off-path attacker (SA).
537 Packets sent by a non-spoofing off-path attacker (NSA) can cause
538 similar problem if no check is done with the LISP Cache (see
539 Section 5.3 for the LISP Cache check). Otherwise, if the check is
540 performed the packets will be rejected by the ETR that receives them
541 and cannot cause problems.
543 6. Control Plane Threats
545 In this section, we discuss the different types of attacks that can
546 occur when an off-path attacker sends control plane packets. We
547 focus on the packets that are sent directly to the ETR and do not
548 analyze the particularities of a LISP mapping system. The ALT
549 mapping system is discussed in Section 8.
551 6.1. Attacks with Map-Request messages
553 An off-path attacker could send Map-Request packets to a victim ETR.
554 In theory, a Map-Request packet is only used to solicit an answer and
555 as such it should not lead to security problems. However, the LISP
556 specification [I-D.ietf-lisp] contains several particularities that
557 could be exploited by an off-path attacker.
559 The first possible exploitation is the P bit. The P bit is used to
560 probe the reachability of remote ETRs in the control plane. In our
561 reference environment, LR3 could probe the reachability of LR1 by
562 sending a Map-Request with the P bit set. LR1 would reply by sending
563 a Map-Reply message with the P bit set and the same nonce as in the
564 Map-Request message.
566 A spoofing off-path attacker (SA) could use the P bit to force a
567 victim ETR to send a Map-Reply to the spoofed source address of the
568 Map-Request message. As the Map-Reply can be larger than the Map-
569 Request message, there is a risk of amplification attack.
570 Considering only IPv4 addresses, a Map-Request has a size of 32 bytes
571 at least, considering one single ITR address and no Mapping Protocol
572 Data. The Map-Reply instead has a size of 28+(N*12) bytes, where N
573 is the number of RLOCs. Since there is no hard limit in the number
574 of RLOCs that can be associated to an EID-Prefix, the packet can
575 easily grow large.
577 Any ISP with a large number of potential RLOCs for a given EID-Prefix
578 should carefully ponder the best trade-off between the number of
579 RLOCs through which it wants that the EID is reachable and the
580 consequences that an amplification attack can produce.
582 It should be noted that the maximum rate of Map-Reply messages should
583 apply to all Map-Replies and also be associated to each destination
584 that receives Map-Reply messages. Otherwise, a possible
585 amplification attack could be launched by a spoofing off-path
586 attacker (SA) as follows. Consider an attacker SA and and EID-Prefix
587 p/P and a victim ITR. To amplify a Denial of Service attack against
588 the victim ITR, SA could send spoofed Map-Request messages whose
589 source EID addresses are all the addresses inside p/P and source RLOC
590 address is the victim ITR. Upon reception of these Map-Request
591 messages, the ETR would send large Map-Reply messages for each of the
592 addresses inside p/P back to the victim ITR.
594 If a non-spoofing off-path attacker (NSA) sends a Map-Request with
595 the P bit set, it will receive a Map-Reply with the P bit set. This
596 does not raise security issues besides the usual risk of overloading
597 a victim ETR by sending too many Map-Request messages.
599 The Map-Request message may also contain the SMR bit. Upon reception
600 of a Map-Request message with the SMR bit, an ETR must return to the
601 source of the Map-Request message a Map-Request message to retrieve
602 the corresponding mapping. This raises similar problems as the P bit
603 discussed above except that as the Map-Request messages are smaller
604 than Map-Reply messages, the risk of amplification attacks is
605 reduced. This is not true anymore if the ETR append to the Map-
606 Request messages its own Map-Records. This mechanism is meant to
607 reduce the delay in mapping distribution since mapping information is
608 provided in the Map-Request message.
610 Furthermore, appending Map-Records to Map-Request messages represents
611 a major security risk since an off-path attacker could generate a
612 (spoofed or not) Map-Request message and include in the Map-Reply
613 portion of the message mapping for EID prefixes that it does not
614 serve. This could lead to various types of redirection and denial of
615 service attacks. An xTR should not process the Map-Records
616 information that it receives in a Map-Request message.
618 6.2. Attacks with Map-Reply messages
620 In this section we analyze the attacks that could occur when an off-
621 path attacker sends directly Map-Reply messages to ETRs without using
622 one of the proposed LISP mapping systems.
624 There are two different types of Map-Reply messages:
626 Positive Map-Reply: This messages contain a Map-Record binding an
627 EID-Prefix to one or more RLOCs.
629 Negative Map-Reply: This messages contain a Map-Record for an EID-
630 Prefix with an empty locator-set and specifying an action,
631 which may be either Drop, Natively forward, or Send Map-
632 Request.
634 Positive Map-Reply messages are used to map EID-Prefixes onto RLOCs.
635 Negative Map-Reply messages are used to support PTR and interconnect
636 the LISP Internet with the legacy Internet.
638 Most of the security of the Map-Reply messages depend on the 64 bits
639 nonce that is included in a Map-Request and returned in the Map-
640 Reply. An ETR must never accept a Map-Request message whose nonce
641 does not match one of the pending Map-Request messages. If an ETR
642 does not accept Map-Reply messages with an invalid nonce, the risk of
643 attack is very small given the size of the nonce (64 bits).
645 Note, however, that the nonce only confirms that the Map-Reply was
646 sent by the ETR that received the Map-Request. It does not validate
647 the content of the Map-Reply message.
649 6.3. Gleaning Attacks
651 A third type of attack involves the gleaning mechanism proposed in
652 [I-D.ietf-lisp] and discussed in [Saucez09]. In order to reduce the
653 time required to obtain a mapping, [I-D.ietf-lisp] allows an ITR to
654 learn a mapping from the LISP data encapsulated packets and the Map-
655 Request packets that it receives. LISP data encapsulated packet
656 contains a source RLOC, destination RLOC, source EID and destination
657 EID. When a ITR receives a data encapsulated packet coming from a
658 source EID for which it does not already know a mapping, it may
659 insert the mapping between the source RLOC and the source EID in its
660 LISP Cache. Gleaning can also be used when an ITR receives a Map-
661 Request as the Map-Request also contains a source EID address and a
662 source RLOC. Once a gleaned entry has been added to the cache, the
663 LISP ITR sends a Map-Request to retrieve the mapping for the gleaned
664 EID from the mapping system. [I-D.ietf-lisp] recommends to store the
665 gleaned entries for only a few seconds.
667 The first risk of gleaning is the ability to temporarily hijack an
668 identity. Consider an off-path attacker that wants to temporarily
669 hijack host HA's identity and send packets to host HB with host HA's
670 identity. If the xTRs that serve host HB do not store a mapping for
671 host HA, a non-spoofing off-path attacker (NSA) could send a LISP
672 encapsulated data packet to LR3 or LR4. The ETR will store the
673 gleaned entry and use it to return the packets sent by host HB to the
674 attacker. In parallel, the ETR will send a Map-Request to retrieve
675 the mapping for HA. During a few seconds or until the reception of
676 the Map-Reply, host HB will exchange packets with the attacker that
677 has hijacked HA's identity. Note that the attacker could in parallel
678 send lots of Map-Requests or lots of LISP data encapsulated packets
679 with random sources to force the xTR that is responsible for host HA
680 to send lots of Map-Request messages in order to force it to exceed
681 its rate limit for control plane messages. This could further delay
682 the arrival of the Map-Reply message on the requesting ETR.
684 Gleaning also introduces the possibility of a man-in-the-middle
685 attack. Consider an off-path attacker that knows that hosts HA and
686 HB that reside in different sites will exchange information at time
687 t. An off-path attacker could use this knowledge to launch a man-in-
688 the-middle attack if the xTRs that serve the two hosts do not have
689 mapping for the other EID. For this, the attacker sends to LR1
690 (resp. LR3) a LISP data encapsulated packet whose source RLOC is its
691 IP address and contains an IP packet whose source is set to HB (resp.
692 HA). The attacker chooses a packet that will not trigger an answer,
693 for example the last part of a fragmented packet. Upon reception of
694 these packets, LR1 and LR3 install gleaned entries that point to the
695 attacker. As explained above, the attacker could, at the same time,
696 send lots of packets to LR1 and LR3 to force them to exhaust their
697 control plane rate limit. This will extend the duration of the
698 gleaned entry. If host HA establishes a flow with host HB at that
699 time, the packets that they exchange will first pass through the
700 attacker.
702 In both cases, the attack only lasts for a few seconds (unless the
703 attacker is able to exhaust the rate limitation). However it should
704 be noted that today a large amount of packets may be exchanged during
705 even a small fraction of time.
707 7. Threats with Malicious xTRs
709 In this section, we discuss the threats that could be caused by
710 malicious xTRs. We consider the reference environment below where
711 EL1 is a malicious or compromised xTR. This malicious xTR serves a
712 set of hosts that includes HC. The other xTR and hosts in this
713 network play the same role as in the reference environment described
714 in Section 4.
716 +----+
717 | HA |
718 +----+
719 | EID: HA
720 |
721 -----------------
722 | |
723 +----+ +----+
724 |LR1 | |LR2 |
725 +----+ +----+
726 | |
727 | |
728 +----+ +----+
729 |ISP1| |ISP2| |
730 +----+ +----+ +----+ |
731 | | +--| EL1|--| EID: HC
732 +----------------+ | +----+ | +----+
733 | |--+ |----| HC |
734 | Internet | | +----+
735 | |
736 +----------------+
737 | |
738 | |
739 +----+ +----+
740 |LR3 | | LR4|
741 +----+ +----+
742 | |
743 --------------------
744 |
745 | EID: HB
746 +----+
747 | HB |
748 +----+
750 Figure 2: Malicious xTRs' Reference Environment
752 Malicious xTRs are probably the most serious threat to the LISP
753 control plane from a security viewpoint. To understand the problem,
754 let us consider the following scenario. Host HC and HB exchange
755 packets with host HA. As all these hosts reside in LISP sites, LR1
756 and LR2 store mappings for HB and HC. Thus, these xTRs may need to
757 exchange LISP control plane packets with EL1, e.g., to perform
758 reachability tests or to refresh expired mappings (e.g., if HC's
759 mapping has a small TTL).
761 A first threat against the LISP control plane is when EL1 replies to
762 a legitimate Map-Request message sent by LR1 or LR2 with a Map-Reply
763 message that contains an EID-Prefix that is larger than the prefix
764 owned by the site attached to EL1. This could allow EL1 to attract
765 packets destined to other EIDs than the EIDs that are attached to
766 EL1.
768 Another possible attack is a Denial of Service attack by sending a
769 Negative Map-Reply message for a coarser prefix without any locator
770 and with the Drop action. Such a Negative Map-Reply indicates that
771 the ETR that receives it should discard all packets. The current
772 LISP specification briefly discusses this problem [I-D.ietf-lisp],
773 but the proposed solutions does not solve the problem.
775 Another concern with malicious xTRs is the possibility of Denial of
776 Service attacks. A first attack is the flooding attack that was
777 described in [I-D.bagnulo-lisp-threat]. This attack allows a
778 malicious xTR to redirect traffic to a victim. The malicious xTR
779 first defines a mapping for HC with two RLOCs: its own RLOC (EL1) and
780 the RLOC of the victim (e.g., LR3). The victim's RLOC is set as
781 unreachable in the mapping. HC starts a large download from host HA.
782 Once the download starts, the malicious xTR updates its Locator
783 Status Bits, changes the mapping's version number or sets the SMR bit
784 such that LR1 updates its LISP Cache to send all packets destined to
785 HC to the victim's RLOC. Instead of downloading from HA, the
786 attacker could also send packets that trigger a response (e.g., ICMP,
787 TCP SYN, DNS request, ...) to HA. HA would then send its response
788 and its xTR would forward it to the victim's RLOC.
790 An important point to note about this flooding attack is that it
791 reveals a potential problem in the LISP architecture. A LISP ITR
792 relies on the received mapping and possible reachability information
793 to select the RLOC of the ETR that it uses to reach a given EID or
794 block of EIDs. However, if the ITR made a mistake, e.g., due to
795 configuration, implementation or other types of errors and has chosen
796 a RLOC that does not serve the destination EID, there is no easy way
797 for the LISP ETR to inform the ITR of its mistake. A possible
798 solution could be to force a ETR to perform a reachability test with
799 the selected ITR as soon as it selects it. This will be analyzed in
800 the next version of this document.
802 8. Security of the ALT Mapping System
804 One of the assumptions in [I-D.ietf-lisp] is that the mapping system
805 is more secure than sending Map-Request and Map-Reply messages
806 directly. We analyze this assumption in this section by analyzing
807 the security of the ALT mapping system.
809 The ALT mapping system is basically a manually configured overlay of
810 GRE tunnels between ALT routers. BGP sessions are established
811 between ALT routers that are connected through such a tunnel. An ALT
812 router advertises the EID prefixes that it serves over its BGP
813 sessions with neighboring ALT routers and the EID-Prefixes that it
814 has learned from neighboring ALT routers.
816 The ALT mapping system is in fact a discovery system that allows any
817 ALT router to discover the ALT router that is responsible for a given
818 EID-Prefix. To obtain a mapping from the ALT system, an ITR sends a
819 packet containing a Map-Request on the overlay. This Map-Request is
820 sent inside a packet whose destination is the requested EID. The
821 Map-Request is routed on the overlay until it reaches the ALT router
822 that advertised initially the prefix that contains the requested EID.
823 This ALT router then replies directly by sending a Map-Reply to the
824 RLOC of the requesting ITR.
826 The security of the ALT mapping system depends on many factors,
827 including:
829 o The security of the intermediate ALT routers.
831 o The validity of the BGP advertisements sent on the ALT overlay.
833 Unfortunately, experience with BGP on the global Internet has shown
834 that BGP is subject to various types of misconfiguration problems and
835 security attacks. The SIDR working group is developing a more secure
836 inter-domain routing architecture to solve this problem
837 ([I-D.ietf-sidr-arch]).
839 The security of the intermediate ALT routers is another concern. A
840 malicious intermediate ALT router could manipulate the received BGP
841 advertisements and also answer to received Map-Requests without
842 forwarding them to their final destination on the overlay. This
843 could lead to various types of redirection attacks. Note that in
844 contrast with a regular IP router that could also manipulate in
845 transit packets, when a malicious or compromised ALT router replies
846 to a Map-Request, it can redirect legitimate traffic for a long
847 period of time by sending an invalid Map-Reply message. Thus, the
848 impact of a malicious ALT router could be much more severe than a
849 malicious router in today's Internet.
851 9. Discussion
853 To mitigate the impact of attacks against LISP, the following
854 recommendations should be followed.
856 First, the use of some form of filtering can help in avoid or at
857 least mitigate some types of attacks.
859 o On ETRs, packets should be decapsulated only if the destination
860 EID is effectively part of the EID-Prefix downstream the ETR.
861 Further, still on ETRs, packets should be decapsulated only if a
862 mapping for the source EID is present in the LISP-Cache and has
863 been obtained through the mapping system (not gleaned).
865 o On ITRs, packets should be encapsulated only if the source EID is
866 effectively part of the EID-Prefix downstream the ITR. Further,
867 still on ITRs, packets should be encapsulated only if a mapping
868 obtained from the mapping system is present in the LISP Cache (no
869 Data-Probing).
871 Note that this filtering, since complete mappings need to be
872 installed in both ITRs and ETRs, can introduce a higher connection
873 setup latency and hence potentially more packets drops due to the
874 lack of mappings in the LISP Cache.
876 While the gleaning mechanism allows to start encapsulating packets to
877 a certain EID in parallel with the Map-Request to obtain a mapping
878 when a new flow is established, it creates important security risks
879 since it allows attackers to perform identity hijacks. Although the
880 duration of these identity hijacks is limited (except the case of
881 rate limitation exhaustion), their impact can be severe. A first
882 option would be to disable gleaning until the security concerns are
883 solved. A second option would be to strictly limit the number of
884 packets that can be forwarded via a gleaned entry. Overall the
885 benefits of gleaning, i.e., avoiding the loss of the first packet of
886 a flow, seems very small compared to the associated security risks.
887 Furthermore, measurements performed in data centers show that today's
888 Internet often operate with packet loss ratio of 1 or 2 percentage
889 ([Chu]). These packet loss ratio are probably already orders of
890 magnitude larger than the improvement provided by the gleaning
891 mechanism.
893 With the increasing deployment of spoofing prevention techniques such
894 as [RFC3704] or SAVI [SAVI], it can be expected that attackers will
895 become less capable of sending packets with a spoofed source address.
896 To prevent packet injection attacks from non-spoofing attackers
897 (NSA), ETRs should always verify that the source RLOC of each
898 received LISP data encapsulated packet corresponds to one of the
899 RLOCs listed in the mappings for the source EID found in the inner
900 packet. An alternative could be to use existing IPSec techniques
901 [RFC4301]and when necessary including perhaps [RFC5386] to establish
902 an authenticated tunnel between the ITR and the ETR.
904 [I-D.ietf-lisp] recommends to rate limit the control messages that
905 are sent by a xTR. This limit is important to deal with denial of
906 service attacks. However, a strict limit, e.g., implemented with a
907 token bucket, on all the Map-Request and Map-Reply messages sent by a
908 xTR is not sufficient. A xTR should distinguish between different
909 types of control plane packets:
911 1. The Map-Request messages that it sends to refresh expired mapping
912 information.
914 2. The Map-Request messages that it sends to obtain mapping
915 information because one of the served hosts tried to contact an
916 external EID.
918 3. The Map-Request messages that it sends as reachability probes.
920 4. The Map-Reply messages that it sends as response to reachability
921 probes.
923 5. The Map-Request messages that it sends to support gleaning.
925 These control plane messages are used for different purposes. Fixing
926 a global rate limit for all control plane messages increases the risk
927 of Denial of Service attacks if a single type of control plane
928 message can exceed the configured limit. This risk could be
929 mitigated by either specifying a rate for each of the five types of
930 control plane messages. Another option could be to define a maximum
931 rate for all control plane messages, and prioritize the control plane
932 messages according to the list above (with the highest priority for
933 message type 1).
935 In [I-D.ietf-lisp], there is no mechanism that allows a xTR to verify
936 the validity of the content a Map-Reply message that it receives.
937 Besides the attacks discussed earlier in the document, a time-shifted
938 attack where an attacker is able to modify the content of a Map-Reply
939 message but then needs to move off-path could also create redirection
940 attacks. The nonce only allows a xTR to verify that a Map-Reply
941 responds to a previously sent Map-Request message. The LISP Working
942 Group should explore solutions that allow to verify the binding
943 between EID-Prefixes and their RLOCS. Having such kind of mechanism
944 would allow ITRs to ignore non-verified mappings, thus increasing
945 security.
947 LISP Working Group should consider developing secure mechanisms to
948 allow an ETR to indicate to an ITR that it does not serve a
949 particular EID or block of EIDs in order to mitigate the flooding
950 attacks.
952 Finally, there is also the risk of Denial of Service attack against
953 the LISP Cache. We have discussed these attacks when considering
954 external attackers with, e.g., the gleaning mechanism and in
955 Section 5.2. If an ITR has a limited LISP Cache, a malicious or
956 compromised host residing in the site that it serves could generate
957 packets to random destinations to force the ITR to issue a large
958 number of Map-Requests whose answers could fill its cache. Faced
959 with such misbehaving hosts, LISP ITR should be able to limit the
960 percent of Map-Requests that it sends for a given source EID.
962 10. Document Status and Plans
964 In this document, we have analyzed some of the security threats that
965 affect the Locator/Identifier Separation Protocol (LISP). We have
966 focused our analysis on unicast traffic and considered both the LISP
967 data and control planes and provided some recommendations to improve
968 the security of LISP.
970 Revisions of this document will document the security threats of
971 other parts of the LISP architecture, including but not limited to:
973 o Instance ID attribute.
975 o LISP Multicast.
977 o LISP Map-Server.
979 11. IANA Considerations
981 This document makes no request to IANA.
983 12. Security Considerations
985 Security considerations are the core of this document and do not need
986 to be further discussed in this section.
988 13. Acknowledgements
990 The flooding attack and the reference environment were first
991 described in Marcelo Bagnulo's draft [I-D.bagnulo-lisp-threat].
993 This work has been partially supported by the INFSO-ICT-216372
994 TRILOGY Project (www.trilogy-project.org).
996 14. References
998 14.1. Normative References
1000 [I-D.ietf-lisp]
1001 Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
1002 "Locator/ID Separation Protocol (LISP)",
1003 draft-ietf-lisp-07 (work in progress), April 2010.
1005 [I-D.ietf-lisp-alt]
1006 Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP
1007 Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-04
1008 (work in progress), April 2010.
1010 [I-D.ietf-lisp-interworking]
1011 Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
1012 "Interworking LISP with IPv4 and IPv6",
1013 draft-ietf-lisp-interworking-00 (work in progress),
1014 May 2009.
1016 [I-D.ietf-lisp-ms]
1017 Fuller, V. and D. Farinacci, "LISP Map Server",
1018 draft-ietf-lisp-ms-05 (work in progress), April 2010.
1020 [I-D.ietf-lisp-multicast]
1021 Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas,
1022 "LISP for Multicast Environments",
1023 draft-ietf-lisp-multicast-03 (work in progress),
1024 April 2010.
1026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1027 Requirement Levels", BCP 14, RFC 2119, March 1997.
1029 14.2. Informative References
1031 [Chu] Jerry Chu, H., "Tuning TCP Parameters for the 21st
1032 Century", 75th IETF, Stockholm, July 2009,
1033 .
1035 [I-D.bagnulo-lisp-threat]
1036 Bagnulo, M., "Preliminary LISP Threat Analysis",
1037 draft-bagnulo-lisp-threat-01 (work in progress),
1038 July 2007.
1040 [I-D.iannone-lisp-mapping-versioning]
1041 Iannone, L., Saucez, D., and O. Bonaventure, "LISP Mapping
1042 Versioning", draft-iannone-lisp-mapping-versioning-01
1043 (work in progress), March 2010.
1045 [I-D.ietf-sidr-arch]
1046 Lepinski, M. and S. Kent, "An Infrastructure to Support
1047 Secure Internet Routing", draft-ietf-sidr-arch-09 (work in
1048 progress), October 2009.
1050 [I-D.ietf-tcpm-tcp-security]
1051 Gont, F., "Security Assessment of the Transmission Control
1052 Protocol (TCP)", draft-ietf-tcpm-tcp-security-01 (work in
1053 progress), February 2010.
1055 [I-D.lear-lisp-nerd]
1056 Lear, E., "NERD: A Not-so-novel EID to RLOC Database",
1057 draft-lear-lisp-nerd-08 (work in progress), March 2010.
1059 [I-D.meyer-lisp-cons]
1060 Brim, S., "LISP-CONS: A Content distribution Overlay
1061 Network Service for LISP", draft-meyer-lisp-cons-04 (work
1062 in progress), April 2008.
1064 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
1065 Networks", BCP 84, RFC 3704, March 2004.
1067 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
1068 Internet Protocol", RFC 4301, December 2005.
1070 [RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing
1071 Security: An Unauthenticated Mode of IPsec", RFC 5386,
1072 November 2008.
1074 [SAVI] IETF, "Source Address Validation Improvements Working
1075 Group", .
1077 [Saucez09]
1078 Saucez, D. and L. Iannone, "How to mitigate the effect of
1079 scans on mapping systems", Submitted to the Trilogy
1080 Summer School on Future Internet.
1082 Authors' Addresses
1084 Damien Saucez
1085 Universite catholique de Louvain
1086 Place St. Barbe 2
1087 Louvain la Neuve
1088 Belgium
1090 Email: damien.saucez@uclouvain.be
1092 Luigi Iannone
1093 TU Berlin - Deutsche Telekom Laboratories AG
1094 Ernst-Reuter Platz 7
1095 Berlin
1096 Germany
1098 Email: luigi@net.t-labs.tu-berlin.de
1100 Olivier Bonaventure
1101 Universite catholique de Louvain
1102 Place St. Barbe 2
1103 Louvain la Neuve
1104 Belgium
1106 Email: olivier.bonaventure@uclouvain.be