wdiff draft-ietf-lisp-threats-05.txt draft-ietf-lisp-threats-06.txt

Network Working Group D. Saucez
Internet-Draft INRIA
Intended status: Informational L. Iannone
Expires: March 2, April 05, 2014 Telecom ParisTech
O. Bonaventure
Universite catholique de Louvain
August 29,
October 02, 2013

LISP Threats Analysis
draft-ietf-lisp-threats-05.txt
draft-ietf-lisp-threats-06.txt

Abstract

This document discusses potential security concerns with the Locator/
Identifier Separation Protocol (LISP) if deployed in the Internet and
proposes a set of recommendations to mitigate the identified threats
and to reach a level of security equivalent to what is observed in
the Internet today (i.e., without LISP). By following the
recommendations of this draft a LISP deployment can achieve a
security level that is comparable to the existing Internet
architecture.

Status of this This Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on March 2, April 05, 2014.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 3
3. On-path Attackers . . . . . . . . . . . . . . . . . . . . . . 4
4. Off-Path Attackers: Reference Environment . . . . . . . . . . 4
5. Data-Plane Threats Attack vectors . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. EID-to-RLOC Database Threats . . . . . . . . . . . . . . . . . . 6
5.2. EID-to-RLOC Cache Threats . . . . . . . . . . . . . . . . 7
5.2.1. EID-to-RLOC Cache poisoning . . . . . . . . . . . . 6
5.3. Attack using the data-plane . 7
5.2.2. EID-to-RLOC Cache overflow . . . . . . . . . . . . . . 9
5.3. 7
5.3.1. Attacks not leveraging on the LISP header . . . . . . . . 9
5.4. 7
5.3.2. Attacks leveraging on the LISP header . . . . . . . . . . 10
5.4.1. Attacks 9
5.4. Attack using the Locator Status Bits control-plane . . . . . . . . 10
5.4.2. Attacks using the Map-Version bit . . . . . 11
5.4.1. Attacks with Map-Request messages . . . . . 11
5.4.3. Attacks using the Nonce-Present and the Echo-Nonce
bits . . . . . 11
5.4.2. Attacks with Map-Reply messages . . . . . . . . . . . 13
5.4.3. Attacks with Map-Register messages . . . . . . . . . 12 14
5.4.4. Attacks using the Instance ID bits with Map-Notify messages . . . . . . . . . . 14
6. Control Plane Threats . Attack categories . . . . . . . . . . . . . . . . . . . 14
6.1. Attacks with Map-Request messages . . . . . 14
6.1. Intrusion . . . . . . . 14
6.2. Attacks with Map-Reply messages . . . . . . . . . . . . . 16
6.3. Gleaning Attacks . . . . 14
6.1.1. Description . . . . . . . . . . . . . . . . . 17
7. Threats concerning Interworking . . . . 14
6.1.2. Vectors . . . . . . . . . . . 18
8. Threats with Malicious xTRs . . . . . . . . . . . . 14
6.2. Denial of Service (DoS) . . . . . 19
9. Security of the Proposed Mapping Systems . . . . . . . . . . . 22
9.1. LISP+ALT . 15
6.2.1. Description . . . . . . . . . . . . . . . . . . . . . 15
6.2.2. Vectors . . . 22
9.2. LISP-DDT . . . . . . . . . . . . . . . . . . . . 15
6.3. Eavesdropping . . . . . 24
10. Threats concerning LISP-MS . . . . . . . . . . . . . . . . . 15
6.3.1. Description . 25
10.1. Map Server . . . . . . . . . . . . . . . . . . . . 15
6.3.2. Vectors . . . . 25
10.2. Map Resolver . . . . . . . . . . . . . . . . . . . 16
7. Recommendations . . . . 26
11. Security Recommendations . . . . . . . . . . . . . . . . . . . 27
12. 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
13. 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 30
14. 16
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
15. 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
15.1. 16
11.1. Normative References . . . . . . . . . . . . . . . . . . . 30
15.2. 16
11.2. Informative References . . . . . . . . . . . . . . . . . . 31 17
Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 32 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 20

1. Introduction

The Locator/ID Separation Protocol (LISP) is defined in [RFC6830].
The present document assesses the security level and identifies
security threats in the LISP specification if LISP is deployed in the
Internet (i.e., a public non-trustable environment). As a result of
the performed analysis, the document discusses the severity of the
threats and proposes recommendations to reach the same level of
security in LISP than in Internet today (e.g., without LISP).

The document is composed of three main parts: the first discussing
the LISP data-plane; while the second discussing the LISP control-
plane. The final part summarizes the recommendations to prevent the
identified threats.

The LISP data-plane consists of LISP packet encapsulation,
decapsulation, and forwarding and includes the EID-to-RLOC Cache and
EID-to-RLOC Database data structures used to perform these
operations.

The LISP control-plane consists in the mapping distribution system,
which can be one of the mapping distribution systems proposed so far
(e.g., [RFC6830], [I-D.ietf-lisp-ddt], [RFC6836], [RFC6833],
[I-D.meyer-lisp-cons], and [RFC6837]), and the Map-Request, Map-
Reply, Map-Register, and Map-Notification messages.

This document does not consider all the possible uses of LISP as
discussed in [RFC6830]. The document focuses on LISP unicast,
including as well LISP Interworking [RFC6832], LISP-MS [RFC6833],
LISP Map-Versioning [RFC6834], and briefly considering the ALT
mapping system described in [RFC6836] and the Delegated Database Tree
mapping system described in [I-D.ietf-lisp-ddt]. The reading of
these documents is a prerequisite for understanding the present
document.

Unless otherwise stated, the document assumes a generic IP service
and does not discuss the difference, from a security viewpoint,
between using IPv4 or IPv6.

This document has identified several threats on LISP in the case of
public deployments. However, most of the threats can be prevented
with careful deployment and configuration. A configuration and general recommendation
is to deactivate every feature rules in
security that is not consist in activating only features that are necessary
in the deployment of interest and to carefully verify verifying the validity of the
information obtained from third parties. parties also applies in the case of
LISP. Finally, this document has not identified any threats that
would require a change in the LISP protocol or architecture.

2. Definition of Terms
The present document does not introduce any other new term, compared
to the main LISP specification. For a complete list of terms please
refer to [RFC6830].

3. On-path Attackers

On-path attackers are attackers that are able to capture and modify
all the packets exchanged between an Ingress Tunnel Router (ITR) and
an Egress Tunnel Router (ETR). To cope with such an attacker,
cryptographic techniques such as those used by IPSec ([RFC4301]) are
required. As with IP, LISP relies on higher layer cryptography to
secure packet payloads from on path attacks, so we do not consider
on-path attackers in this document.

Mobile IP has also considered time-shifted attacks from on-path
attackers. A

Similarly, a time-shifted attack is an attack where the attacker is
temporarily on the path between two communicating hosts. While it is
on-path, the attacker sends specially crafted packets or modifies
packets exchanged by the communicating hosts in order to disturb the
packet flow (e.g., by performing a man in the middle attack). An
important issue for time-shifted attacks is the duration of the
attack once the attacker has left the path between the two
communicating hosts. We do not consider time-shifted attacks in this
document.

4. Off-Path Attackers: Reference Environment

Throughout this document we consider the reference environment shown
in the figure below. There are two hosts attached to LISP routers:
HA and HB. HA is attached to the two LISP xTRs LR1 and LR2, which in
turn are attached to two different ISPs. HB is attached to the two
LISP xTRs LR3 and LR4. HA and HB are the EIDs of the two hosts.
LR1, LR2, LR3, and LR4 are the RLOCs of the xTRs. PxTR is a proxy
xTR and MR/MS plays the roles of Map Server and/or Map Resolver.

+-----+
| HA |
+-----+
| EID: HA
|
-----------------
| |
+-----+ +-----+
| LR1 | | LR2 |
+-----+ +-----+
| |
| |
+-----+ +-----+
|ISP1 | |ISP2 |
+-----+ +-----+
| |
+------+ +----------------+ +-----+
| PxTR |-----| |-----| SA |
+------+ | | +-----+
| Internet |
+-------+ | | +-----+
| MR/MS |----| |-----| NSA |
+-------+ +----------------+ +-----+
| |
+-----+ +-----+
| LR3 | | LR4 |
+-----+ +-----+
| |
-------------------
|
| EID: HB
+-----+
| HB |
+-----+

Figure 1: Reference Network

We consider two off-path attackers with different capabilities:

SA is an off-path attacker that is able to send spoofed packets,
i.e., packets with a different source IP address than its
assigned IP address. SA stands for Spoofing Attacker.

NSA is an off-path attacker that is only able to send packets whose
source address is its assigned IP address. NSA stands for Non
Spoofing Attacker.

It should be noted that with LISP, packet spoofing is slightly
different than in the current Internet. Generally the term "spoofed
packet" indicates a packet containing a source IP address that is not
the one of the actual originator of the packet. Since LISP uses
encapsulation, the spoofed address could be in the outer header as
well as in the inner header, this translates in two types of
spoofing:

EID Spoofing: the originator of the packet puts in it a spoofed EID.
The packet will be normally encapsulated by the ITR of the site
(or a PITR if the source site is not LISP enabled).

RLOC Spoofing: the originator of the packet generates directly a
LISP-encapsulated packet with a spoofed source RLOC.

Note that the two types of spoofing are not mutually exclusive,
rather all combinations are possible and could be used to perform
different kind of attacks.

In the reference environment, both SA and NSA attackers are capable
of sending LISP encapsulated data packets and LISP control packets.
This means that SA is able to perform both RLOC and EID spoofing
while NSA can only perform EID spoofing. They may also send other
types of IP packets such as ICMP messages. We assume that both
attackers can query the LISP mapping system (e.g., through a public
Map Resolver) to obtain the mappings for both HA and HB.

5. Data-Plane Threats Attack vectors

This section discusses threats and attacks related presents techniques that can be used by attackers to
succeed attacks leveraging the LISP data-
plane. More precisely, we discuss the operations of encapsulation,
decapsulation, and forwarding as well as the content of the EID-to-
RLOC Cache and EID-to-RLOC Database as specified in the original LISP
document ([RFC6830]).

We start considering the two main data structures of LISP, namely the
EID-to-RLOC Database protocol and architecture. This
section focuses on the EID-to-RLOC Cache. Then, we look at techniques while Section 6 presents the
data plane
attacks that can be performed by a spoofing off-path
attacker (SA) and discuss how they can be mitigated by LISP xTRs. In
this analysis, we assume that the LR1 and LR2 (resp. LR3 and LR4)
xTRs maintain an EID-to-RLOC Cache that contains the required mapping
entries to allow HA and HB to exchange packets. succeeded while using these techniques.

5.1. EID-to-RLOC Database Threats

The EID-to-RLOC Database on each xTR maintains the set of mappings
related to the EID-Prefixes that are "behind" the xTR. Where
"behind" means that at least one of the xTR's globally visible IP
addresses is a RLOC for those EID-Prefixes.

As described in [RFC6830], the EID-to-RLOC Database content is
determined by configuration. This means that the only way to attack
this data structure is by gaining privileged access to the xTR. As
such, it is out of the scope of LISP to propose any mechanism to
protect routers and, hence, it is no further analyzed in this
document.

5.2. EID-to-RLOC Cache Threats

The EID-to-RLOC Cache (also called the Map-Cache) is the data
structure that stores a copy of the mappings retrieved from a remote
ETR's mapping database via the LISP control plane. control-plane. Attacks against
this data structure could happen either when the mappings are first
installed in the cache (see also Section 6) or by corrupting (poisoning) the mappings
already present in the cache.

The severity level of EID-to-RLOC Cache Threats depends on

In this document we call "cache poisoning attack", any attach that
alters the attack
vector as described below.

5.2.1. EID-to-RLOC Cache. Cache poisoning

The content of attacks are use to
alter (any combination of) the EID-to-RLOC Cache could be poisoned by spoofing
LISP encapsulated packets. Examples following parts of EID-to-RLOC Cache poisoning
are:

Fake mapping: The cache contains entirely fake mappings that do not
originate from an authoritative mapping server. This could be
achieved either through gleaning as described installed
in Section 6.3 or
by attacking the control-plane as described in Section 6. EID-to-RLOC Cache:

o EID Poisoning: prefix
o RLOC list

o RLOC priority

o RLOC weight

o RLOC reachability

o Mapping TTL

o Mapping version

o Mapping Instance ID

5.3. Attack using the data-plane

The EID-Prefix in a specific mapping data-plane is not owned by
the originator constituted of the entry. Similarly to the previous case,
this could be achieved either through gleaning operations of encapsulation,
decapsulation, and forwarding as described in
Section 6.3 or by attacking the control-plane well as described in
Section 6.

EID redirection/RLOC poisoning: The EID-Prefix in the mapping is not
bound to (located by) the set content of RLOCs present in the mapping.
This could result EID-to-
RLOC Cache and EID-to-RLOC Database as specified in packets being redirected elsewhere,
eavesdropped, or even black-holed. Note that not necessarily
all RLOCs are fake/spoofed. The attack works also if only part
of the RLOCs, original LISP
document ([RFC6830]).

5.3.1. Attacks not leveraging on the highest priority ones, is compromised.
Again, this could be achieved either through LISP header

An attacker can inject packets into flows without using the gleaning as
described in Section 6.3 or by attacking LISP
header, i.e., with the control-plane as
described in Section 6.

Reachability poisoning: The reachability information stored N, L, E, V, and I bits ([RFC6830]).

To inject a packet in the
mapping HA-HB flow, a spoofing off-path attacker
(SA) could be poisoned, redirecting the packets to send a subset
of the RLOCs (or even stopping it if locator status bits are
all LISP encapsulated packet whose source is set to 0). If reachability information LR1
or LR2 and destination LR3 or LR4. The packet will reach HB as if
the packet was sent by host HA. This is not verified
through the control-plane this attack different from today's
Internet where a spoofing off-path attacker may inject data packets
in any flow. A non-spoofing off-path attacker (NSA) could be achieved by
sending only send
a spoofed packet with swapped or all locator status
bits reset. The same result could be obtained by attacking the
control-plane as described in Section 6. Depending on how the
RLOC reachability information whose source address is stored on the router, set to its assigned IP address. The
destination address of the
attack encapsulated packet could impact only one mapping be LR3 or all the mappings that
share the same RLOC.

Traffic Engineering information poisoning: The LISP protocol defines
two attributes associated to each RLOC in LR4.

5.3.1.1. Gleaning Attacks

In order to perform
inbound Traffic Engineering (TE), namely priority and weight.
By injecting fake TE attributes, reduce the attacker is able time required to break
load balancing policies and concentrate all the traffic on a
single RLOC or put more load on obtain a RLOC than what is expected,
creating congestion. It is even possible to block the traffic
if all mapping, [RFC6830]
proposes the priorities are set to 255 (special value indicating
not gleaning mechanism that allows an ITR to use the RLOC). Corrupting learn a mapping
from the TE attributes could be
achieved by attacking LISP data encapsulated packets and the control-plane as described in
Section 6.

Mapping TTL poisoning: The Map-Request packets
that it receives. LISP protocol associates data encapsulated packet contains a Time-To-Live
to each mapping that, once expired, allows to delete source
RLOC, destination RLOC, source EID and destination EID. When an ITR
receives a mapping data encapsulated packet coming from the EID-to-RLOC Cache (or forces a Map-Request/Map-Reply
exchange to refresh source EID for
which it if still needed). By injecting fake TTL
values, an attacker could either shrink the EID-to-RLOC Cache
(using very short TTL), thus creating an excess of cache miss
causing does not already know a DoS on the mapping system, or mapping, it could increase the
size of may insert the cache by putting very high TTL values, up to a
cache overflow (see Section 5.2.2). Corrupting mapping
between the TTL could
be achieved by attacking source RLOC and the control-plane as described source EID in
Section 6. Long TTL its EID-to-RLOC Cache.
Gleaning could also be used in fake mappings when an ITR receives a Map-Request as the
Map-Request also contains a source EID address and a source RLOC.
Once a gleaned entry has been added to increase
attack duration.

Instance ID poisoning: The the EID-to-RLOC cache, the
LISP protocol allows using ITR sends a 24-bit
identifier Map-Request to select retrieve the forwarding table to use on mapping for the
decapsulating ETR to forward gleaned
EID from the decapsulated packet. By
spoofing this attribute mapping system. [RFC6830] recommends storing the
gleaned entries for only a few seconds.

An attacker might cause traffic can send LISP encapsulated packets to be
either dropped or decapsulated host HB with host
HA's EID and then placed into if the
incorrect VRF xTRs that serve host HB do not store a mapping
for host HA at that time The xTR will store the destination ETR. Corrupting gleaned entry and use
it to return the Instance
ID attribute could be achieved packets sent by attacking the control-plane
as described in Section 6.

Map-Version poisoning: The LISP protocol offers host HB. In parallel, the option to
associate ETR will
send a version number Map-Request to mappings ([RFC6834]). The LISP
header can transport source and destination map-versions,
describing which version of retrieve the mapping have been used to
select for HA but until the source and
reception of the destination RLOCs Map-Reply, host HB will exchange packets with the
attacker instead of HA.

Similarly, if an off-path attacker knows that hosts HA and HB that
resides in different sites will exchange information at time t the
attacker could send to LR1 (resp. LR3) a LISP data encapsulated packet. By spoofing this attribute the attacker
packet whose source RLOC is able its IP address and contains an IP packet
whose source is set to HB (resp. HA). The attacker chooses a packet
that will not trigger Map-Request on the receiving ETR.
Corrupting an answer, for example the Map-Version attribute could be achieved either
by attacking last part of a
fragmented packet. Upon reception of these packets, LR1 and LR3
install gleaned entries that point to the control-plane as described in Section 6 or by
using spoofed packets as described in Section 5.4.2. attacker. If the ITR's map-cache host HA is compromised (likely via compromising
willing to establishes a flow with host HB at that time, the
LISP control-plane) it is possible packets
that traffic in they exchange will pass through the data-plane may
be redirected (encapsulated to attacker as long as the wrong destination) a or dropped by
the ITR.

If data-plane redirection
gleaned entry is of active on the xTRs.

By itself, an attack made solely using gleaning cannot last long,
however it should be noted that with current network capacities, a critical concern, then deploying
some sort
large amount of IPSEC or TLS based security on packets might be exchanged during even a layer above LISP (just
like you would on top small
fraction of IP) is recommended.

5.2.2. EID-to-RLOC Cache overflow

Depending on how the EID-to-RLOC Cache is managed (e.g., Least
Recently Used - LRU vs. Least Frequently Used - LFU) time.

5.3.1.2. Threats concerning Interworking

[RFC6832] defines Proxy-ITR And Proxy-ETR network elements to allow
LISP and depending on non-LISP sites to communicate. The Proxy-ITR has
functionality similar to the ITR, however, its size, an attacker could try main purpose is to fill
encapsulate packets arriving from the cache with fake mappings.
Once DFZ in order to reach LISP
sites. A Proxy-ETR has functionality similar to the cache ETR, however,
its main purpose is full, some mappings will be replaced by new fake
ones, causing traffic disruption.

This could be achieved either through gleaning as described to inject de-encapsulated packets in
Section 6.3 or by attacking the control-plane as described DFZ in
Section 6.

Another way
order to generate an EID-to-RLOC Cache overflow reach non-LISP Sites from LISP sites. As a PITR (resp.
PETR) is by injecting
mapping with a fake and very large TTL value. In this particular case the cache
will keep a large amount of mappings ending with a completely full
cache. This type of attack could also ITR (resp. ETR), it is subject to same
attacks than ITRs (resp. ETR).

PxTRs can be performed through the
control-plane.

5.3. targeted by attacks aiming to influence traffic between
LISP and non-LISP sites but also to launch relay attacks.

It is worth to notice that when PITR and PETR functions are
separated, attacks targeting xTRs are ineffective.

5.3.2. Attacks not leveraging on the LISP header

We first consider an attacker

The main LISP document [RFC6830] defines several flags that sends packets without exploiting modify
the LISP header, i.e., with interpretation of the N, L, E, V, and I bits reset
([RFC6830]).

To inject a packet LISP header in the HA-HB flow, a spoofing data packets. In this
section, we discuss how an off-path attacker
(SA) could send a exploit this LISP encapsulated packet whose source
header.

5.3.2.1. Attacks using the Locator Status Bits

When the L bit is set to LR1
or LR2 and destination LR3 or LR4. The packet will reach HB as if 1, it indicates that the packet was sent by host HA. This is not different from today's
Internet where a spoofing off-path attacker may inject data packets
in any flow. Several existing techniques could be used by hosts second 32-bits
longword of the LISP header contains the Locator Status Bits. In
this field, each bit position reflects the status of one of the RLOCs
mapped to
prevent such attacks from affecting established flows, e.g.,
[RFC4301] and [I-D.ietf-tcpm-tcp-security].

On the other hand, a non-spoofing off-path attacker (NSA) could only
send source EID found in the encapsulated packet. In
particular, a packet whose source address is with the L bit set and all Locator Status Bits
set to its assigned IP address.
The destination address zero indicates that none of the encapsulated packet could be LR3 or
LR4. When locators of the encapsulated
source EID are reachable. The reaction of a LISP ETR that serves HB receives the encapsulated
packet, it can consult its EID-to-RLOC Cache and verify that NSA is
not a valid source address for LISP encapsulated packets containing
such a packet sent by HA. This verification is only possible if the ETR
already has not clearly described in [RFC6830].

An attacker can send a valid mapping for HA. Otherwise, and to avoid such data packet injection attacks, with the LISP ETR should reject the packet L bit set to 1 and possibly query the mapping system some
or all Locator Status Bits set to obtain a mapping for zero. Therefore, by blindly
trusting the
encapsulated source EID (HA).

The risk Locator Status Bits communication going on can be reduced by using well known anti-spoofing techniques
and configuring ETRs
altered or forced to verify the that RLOCs and EIDs are consistent
with the entries in the EID-to-RLOC Cache.

5.4. go through a particular set of locators.

5.3.2.2. Attacks leveraging on using the LISP header Map-Version bit

The main LISP document [RFC6830] defines several flags that modify optional Map-Version bit is used to indicate whether the interpretation low-
order 24 bits of the LISP header in data packets. In this
section, we discuss how an off-path attacker could exploit this LISP
header.

The severity level first 32 bits longword of attacks leveraging on the LISP header depends
on the attack vector as described below.

5.4.1. Attacks using the Locator Status Bits
contain a Source and Destination Map-Version. When a LISP ETR
receives a LISP encapsulated packet with the L Map-Version bit is set to
1, it indicates that the second 32-bits
longword of following actions are taken:

o It compares the LISP header contains Destination Map-Version found in the Locator Status Bits. In
this field, each bit position reflects header with
the status of one current version of its own mapping, in the RLOCs
mapped to EID-to-RLOC
Database, for the source destination EID found in the encapsulated
packet. In
particular, If the received Destination Map-Version is smaller (i.e.,
older) than the current version, the ETR should apply the SMR
procedure described in [RFC6830] and send a packet Map-Request with the L
SMR bit set and all Locator Status Bits
set to zero indicates that none of the locators of set.

o If a mapping exists in the EID-to-RLOC Cache for the encapsulated source EID are reachable. The reaction EID,
then it compares the Map-Version of a LISP ETR that receives
such a packet is not clearly described entry with the Source
Map-Version found in [RFC6830].

A spoofing the header of the packet. If the stored
mapping is older (i.e., the Map-Version is smaller) than the
source version of the LISP encapsulated packet, the xTR should
send a Map-Request for the source EID.

An off-path attacker (SA) could send a data packet with use the L Map-Version bit set to 1, all Locator Status Bits set force an ETR to zero, a spoofed
send Map-Request messages. The attacker could retrieve the current
source
RLOC (e.g. LR1), and destination LR3, Map-Version for both HA and containing an encapsulated HB. Based on this
information, it could send a spoofed packet whose source is HA. with an older Source Map-
Version or Destination Map-Version. If LR3 blindly trusts the Locator Status
Bits size of the received packet it will set LR1 and LR2 as unreachable,
possibly disrupting ongoing communication.

Locator Status Bits could be blindly trusted only in secure
environments. In Map-Request
message is larger than the general unsecured Internet environment, size of the
safest practice for xTRs is smallest LISP-encapsulated
packet that could trigger such a message, this could lead to confirm
amplification attacks (see Section 5.4.1).

5.3.2.3. Attacks using the reachability change
through Nonce-Present and the control plane (e.g., RLOC probing). In Echo-Nonce bits

The Nonce-Present and Echo-Nonce bits are used when verifying the above
example,
reachability of a remote ETR. Assume that LR3 should note wants to verify that something has changed in the Locator
Status Bits and query
LR1 receives the mapping system (assuming packets that it is trusted) in
order to confirm status of sends. LR3 can set the RLOCs of Echo-Nonce
and the source EID.

A similar attack could occur by setting only one Locator Status Bit
to 1, e.g., the one that corresponds to the source RLOC Nonce-Present bits in LISP data encapsulated packets and
include a random nonce in these packets. Upon reception of these
packets, LR1 will store the
packet.

If a non-spoofing nonce sent by LR3 and echo it when it
returns LISP encapsulated data packets to LR3.

A spoofing off-path attacker (NSA) sends a (SA) could interfere with this
reachability test by sending two different types of packets:

1. LISP data packet encapsulated packets with the L Nonce-Present bit set to 1 and all Locator Status Bits set to zero, this
packet will contain
a random nonce and the appropriate source address of the attacker. Similarly as
in Section 5.3, if the xTR accepts and destination RLOCs.

2. LISP data encapsulated packets with the packet without checking Nonce-Present and the
EID-to-RLOC Cache for a mapping that binds
Echo-Nonce bits both set and the appropriate source EID and
destination RLOCs. These packets will force the
source RLOC of receiving ETR to
store the received packet, then the same observation like
for the spoofing attacker (SA) apply with nonce and echo it in the difference LISP encapsulated
packets that instead it sends.

The first type of complete disruption, packet should not cause any major problem to ITRs.
As the traffic will flow through only one RLOC,
possibly resulting in reachability test uses a DoS attack.

Otherwise, if the xTR does make the check through the EID-to-RLOC
Cache, 24 bits nonce, it should reject the is unlikely that an
off-path attacker could send a single packet because its source address that causes an ITR to
believe that the ETR it is testing is reachable while in reality it
is not
one reachable. To increase the success likelihood of such attach,
the addresses listed as RLOCs for the source EID.
Nevertheless, in this case a Map-Request should be sent, which could
be used to perform Denial of Service attacks. Indeed an attacker
could frequently change the Locator Status Bits in order to trigger should created a
large massive amount of Map-Requests. Rate limitation, as described in
[RFC6830], if implemented in a very simple way a single bucket for packets carrying all triggered control plane messages, does not allow sending high
number
possible nonce values.

The second type of such a request, resulting in packet could be exploited to attack the nonce-
based reachability test. Consider a spoofing off-path attacker saturating the
rate with these (SA)
that sends a continuous flow of spoofed packets.

Assuming LISP data encapsulated
packets that contain the correct deployment of anti-spoofing techniques, every
reachability change discovered with LSB SHOULD be verified (e.g.,
using routing information base, or low frequency probing).

5.4.2. Attacks using Nonce-Present and the Map-Version Echo-Nonce bit and
each packet contains a different random nonce. The optional Map-Version bit is used to indicate whether ETR that receives
such packets will continuously change the low-
order 24 bits of nonce that it returns to
the first 32 bits longword of remote ITR. If the LISP header
contain a Source and Destination Map-Version. When remote ITR starts a LISP nonce-reachability test,
this test may fail because the ETR
receives has received a spoofed LISP data
encapsulated packet with a different random nonce and never echoes
the Map-Version bit set to
1, the following actions are taken:

o It compares the Destination Map-Version found in real nonce. In this case the header with ITR will consider the current version ETR not
reachable. The success of its own mapping, in this test depends on the EID-to-RLOC
Database, for ratio between the destination EID found in
amount of packets sent by the encapsulated
packet. If legitimate ITR and the received Destination Map-Version is smaller (i.e.,
older) than the current version, the ETR should apply spoofing off-
path attacker (SA).

5.3.2.4. Attacks using the SMR
procedure described Instance ID bits

LISP allows to carry in [RFC6830] and send a Map-Request with the
SMR bit set.

o If its header a mapping exists in 24-bits value called "Instance
ID" and used on the EID-to-RLOC Cache ITR to indicate which local Instance ID has been
used for encapsulation, while on the source EID,
then it compares the Map-Version of that entry with the Source
Map-Version found in ETR can be used to select the header of
forwarding table used for forwarding the decapsulated packet. If

The Instance ID increases exposure to attacks ([RFC6169]) as if an
off-path attacker can randomly guess a valid Instance ID value she
gets access to network that she might not have access. However, the stored
mapping
impact of such attack is older (i.e., the Map-Version directly on end-systems which is smaller) than the
source version is out of
the LISP encapsulated packet, scope of this document.

5.4. Attack using the xTR should
send a Map-Request for control-plane

In this section, we discuss the source EID.

A spoofing different types of attacks that could
occur when an off-path attacker (SA) could use sends control-plane packets. We
focus on the Map-Version bit packets that are sent directly to
force an the ETR to send and do not
analyze the particularities of a LISP mapping system.

5.4.1. Attacks with Map-Request messages. The messages

An off-path attacker could
retrieve the current source and destination Map-Version for both HA
and HB. Based on this information, it could send Map-Request packets to a spoofed victim ETR.
In theory, a Map-Request packet
with an older Source Map-Version or Destination Map-Version. If the
size of the Map-Request message is larger than the size of the
smallest LISP-encapsulated packet that could trigger only used to solicit an answer and
as such a message,
this could it should not lead to amplification attacks (see Section 6.1). security problems. However,
[RFC6830] recommends to rate limit the Map-Request messages LISP
specification [RFC6830] contains several particularities that are
sent could
be exploited by an xTR. This prevents off-path attacker.

The first possible exploitation is the amplification attack, but there P bit. The P bit is
a risk of Denial used to
probe the reachability of Service attack if an attacker sends packets with
Source and Destination Map-Versions that frequently change. remote ETRs. In this
case, and depending on our reference environment,
LR3 could probe the implementation reachability of the rate limitation
policy, the ETR might consume its entire rate LR1 by sending a Map-Request
messages with
the P bit set. LR1 would reply by sending a Map-Reply message with
the P bit set and the same nonce as in response to these spoofed packets. the Map-Request message.

A non-spoofing spoofing off-path attacker (NSA) (SA) could not success in such an
attack if the destination xTR rejects the LISP encapsulated packets
that are not sent by one of use the RLOCs mapped P bit to force a
victim ETR to send a Map-Reply to the included spoofed source
EID. If it is not address of the case,
Map-Request message. As the attacker could Map-Reply can be able to perform
attacks concerning the Destination Map Version number as for larger than the
spoofing off-path attacker (SA).

The correct deployment Map-
Request message, there is a risk of anti-spoofing amplification attack.
Considering only IPv6 addresses, a Map-Request can be as small as 40
bytes, considering one single ITR address and rate limitation
techniques prevents the attacks leveraging on the Map-Version.

5.4.3. Attacks using the Nonce-Present and the Echo-Nonce bits no Mapping Protocol
Data. The Nonce-Present Map-Reply instead has a size of O(12 + (R * (28 + N *
24))) bytes, where N is the maximum number of RLOCs in a mapping and Echo-Nonce bits are used when verifying
R the
reachability maximum number of records in a remote ETR. Assume that LR3 wants Map-Reply. Since up to verify that
LR1 receives the packets that it sends. LR3 255
RLOCs can set the Echo-Nonce be associated to an EID-Prefix and the Nonce-Present bits 255 records can be
stored in LISP data encapsulated packets and
include a random nonce in these packets. Upon reception Map-Reply, the maximum size of these
packets, LR1 will store a Map-Reply is thus above
1 MB showing a size factor of up to 39,193 between the nonce message sent
by LR3 the attacker and the message sent by the ETR. These numbers are
however theoretical values not considering transport layer
limitations and echo it when it
returns LISP encapsulated data packets to LR3.

A spoofing is more likely that the reply will contain only
one record with at most a dozen of locators, giving an amplification
factor around 8.

Similarly, if a non-spoofing off-path attacker (SA) could interfere (NSA) sends a Map-
Request with this
reachability test by sending two different types of packets:

1. LISP data encapsulated packets the P bit set, it will receive a Map-Reply with the Nonce-Present P
bit set and set.

An amplification attack could be launched by a random nonce spoofing off-path
attacker (SA) as follows. Consider an attacker SA and the appropriate source EID-Prefix
192.0.2.0/24 and destination RLOCs.

2. LISP data encapsulated packets with the Nonce-Present and the
Echo-Nonce bits both set and the appropriate source and
destination RLOCs. These packets will force the receiving ETR to
store the received nonce and echo it in the LISP encapsulated
packets that it sends.

The first type of packet should not cause any major problem to ITRs.
As the reachability test uses a 24 bits nonce, it is unlikely that an
off-path attacker could send a single packet that causes an ITR to
believe that the ETR it is testing is reachable while in reality it
is not reachable. To increase the success likelihood of such attach,
the attacker should created a massive amount of packets carrying all
possible nonce values. However, "flood attack" can be easily
detected and blocked.

The second type of packet could be exploited to create a Denial of
Service attack against the nonce-based reachability test. Consider a
spoofing off-path attacker (SA) that sends a continuous flow of
spoofed LISP data encapsulated packets that contain the Nonce-Present
and the Echo-Nonce bit and each packet contains a different random
nonce. The ETR that receives such packets will continuously change
the nonce that it returns to the remote ITR. If the remote ITR
starts a nonce-reachability test, this test may fail because the ETR
has received a spoofed LISP data encapsulated packet with a different
random nonce and never echoes the real nonce. In this case the ITR
will consider the ETR not reachable. The success of this test will
of course depend on the ratio between the amount of packets sent by
the legitimate ITR and the spoofing off-path attacker (SA).

Packets sent by a non-spoofing off-path attacker (NSA) can cause
similar problem if no check is done with the EID-to-RLOC Cache (see
Section 5.3 for the EID-to-RLOC Cache check). Otherwise, if the
check is performed the packets will be rejected by the ETR that
receives them and cannot cause problems.

Assuming the correct deployment of anti-spoofing techniques, every
reachability change discovered with echo-nonce SHOULD be verified
(e.g., using routing information base, or low frequency probing).

5.4.4. Attacks using the Instance ID bits

LISP allows to carry in its header a 24-bits value called "Instance
ID" and used on the ITR to indicate which private Instance ID has
been used for encapsulation, while on the ETR can be used to select
the forwarding table used for forwarding the decapsulated packet.

Even if an off-path attacker could randomly guess a valid Instance ID
value, there is no LISP specific problem. Obviously the attacker
could be now able to reach hosts that are only reachable through the
routing table identified by the attacked Instance ID, however, end-
system security is out of the scope of this document. Nevertheless,
access lists can be configured to protect the network from Instance
ID based attacks.

The correct deployment of access control lists and firewalls prevent
the attacks leveraging on the Instance ID.

6. Control Plane Threats

In this section, we discuss the different types of attacks that could
occur when an off-path attacker sends control plane packets. We
focus on the packets that are sent directly to the ETR and do not
analyze the particularities of a LISP mapping system. The LISP+ALT
and LISP-DDT mapping systems are discussed in Section 9.

The severity of attacks on the LISP control-plane depends on the
attack vector as described below.

6.1. Attacks with Map-Request messages

An off-path attacker could send Map-Request packets to a victim ETR.
In theory, a Map-Request packet is only used to solicit an answer and
as such it should not lead to security problems. However, the LISP
specification [RFC6830] contains several particularities that could
be exploited by an off-path attacker.

The first possible exploitation is the P bit. The P bit is used to
probe the reachability of remote ETRs. In our reference environment,
LR3 could probe the reachability of LR1 by sending a Map-Request with
the P bit set. LR1 would reply by sending a Map-Reply message with
the P bit set and the same nonce as in the Map-Request message.

A spoofing off-path attacker (SA) could use the P bit to force a
victim ETR to send a Map-Reply to the spoofed source address of the
Map-Request message. As the Map-Reply can be larger than the Map-
Request message, there is a risk of amplification attack.

Considering only IPv6 addresses, a Map-Request can be as small as 40
bytes, considering one single ITR address and no Mapping Protocol
Data. The Map-Reply instead has a size of O(12 + (R * (28 + N *
24))) bytes, where N is the maximum number of RLOCs in a mapping and
R the maximum number of records in a Map-Reply. Since up to 255
RLOCs can be associated to an EID-Prefix and 255 records can be
stored in a Map-Reply, the maximum size of a Map-Reply is thus above
1 MB showing a size factor of up to 39,193 between the message sent
by the attacker and the message sent by the ETR. These numbers are
however theoretical values not considering transport layer
limitations and it is more likely that the reply will contain only
one record with at most a dozen of locators, giving an amplification
factor around 8.

Any ISP with a large number of potential RLOCs for a given EID-Prefix
should carefully ponder the best trade-off between the number of
RLOCs through which it wants that the EID is reachable and the
consequences that an amplification attack can produce.

It should be noted that the maximum rate of Map-Reply messages should
apply to all Map-Replies and also be associated to each destination
that receives Map-Reply messages. Otherwise, a possible
amplification attack could be launched by a spoofing off-path
attacker (SA) as follows. Consider an attacker SA and EID-Prefix
192.0.2.0/24 and a victim ITR. To amplify a Denial of Service attack
against the victim ITR, SA could send spoofed Map-Request messages
whose source EID addresses are all the addresses inside 192.0.2.0/24
and source RLOC address is the victim ITR. Upon reception of these
Map-Request messages, the ETR would send large Map-Reply messages for
each of the addresses inside p/P back to the victim ITR.

If a non-spoofing off-path attacker (NSA) sends a Map-Request with
the P bit set, it will receive a Map-Reply with the P bit set. This
does not raise security issues besides the usual risk of overloading
a victim ETR by sending too many Map-Request messages.

The Map-Request message may also contain the SMR bit. Upon reception
of a Map-Request message with the SMR bit, an ETR must return to the
source of the Map-Request message a Map-Request message to retrieve
the corresponding mapping. This raises similar problems as the P bit
discussed above except that as the Map-Request messages are smaller
than Map-Reply messages, the risk of amplification attacks is
reduced. This is not true anymore if the ETR append to the Map-
Request messages its own Map-Records. This mechanism is meant to
reduce the delay in mapping distribution since mapping information is
provided in the Map-Request message.

The correct deployment of anti-spoofing and rate limitation
techniques prevents the attacks leveraging the Map-Request message.

Furthermore, appending Map-Records to Map-Request messages represents
a major security risk since an off-path attacker could generate a
(spoofed or not) Map-Request message and include in the Map-Reply
portion of the message mapping for EID prefixes that it does not
serve. This could lead to various types of redirection and denial of
service attacks.

A mappings learned from a Map-Request message appending Map-Records
SHOULD be verified, particularly if it overrides mappings previously
installed in the EID-to-RLOC cache of the ITR.

6.2. Attacks with Map-Reply messages

In this section we analyze the attacks that could occur when an off-
path attacker sends directly Map-Reply messages to ETRs without using
one of the proposed LISP mapping systems.

There are two different types of Map-Reply messages:

Positive Map-Reply: These messages contain a Map-Record binding an
EID-Prefix to one or more RLOCs.

Negative Map-Reply: These messages contain a Map-Record for an EID-
Prefix with an empty locator-set and specifying an action,
which may be either Drop, natively forward, or Send Map-
Request.

Positive Map-Reply messages are used to map EID-Prefixes onto RLOCs.
Negative map-reply messages are used to indicate non-lisp prefixes.
ITRs can, if needed, be configured to send all traffic destined for
non-lisp prefixes to a Proxy-ETR.

Most of the security of the Map-Reply messages depends on the 64 bits
nonce that is included in a Map-Request and returned in the Map-
Reply. An ETR must never accept a Map-Reply message whose nonce does
not match one of the pending Map-Request messages. If an ETR does
not accept Map-Reply messages with an invalid nonce, the risk of
attack is acceptable given the size of the nonce (64 bits).

The nonce only confirms that the map-reply received was sent in
response to a map-request sent, it does not validate the contents of
that map-reply.

In addition, an attacker could perform EID-to-RLOC Cache overflow
attack by de-aggregating (i.e., splitting an EID prefix into
artificially smaller EID prefixes) either positive or negative
mappings.

The correct deployment of anti-spoofing techniques prevents attacks
leveraging the Map-Reply message.

6.3. Gleaning Attacks

A third type of attack involves the gleaning mechanism proposed in
[RFC6830] and discussed in [Saucez09]. In order to reduce the time
required to obtain a mapping, [RFC6830] allows an ITR to learn a
mapping from the LISP data encapsulated packets and the Map-Request
packets that it receives. LISP data encapsulated packet contains a
source RLOC, destination RLOC, source EID and destination EID. When
an ITR receives a data encapsulated packet coming from a source EID
for which it does not already know a mapping, it may insert the
mapping between the source RLOC and the source EID in its EID-to-RLOC
Cache. Gleaning could also be used when an ITR receives a Map-
Request as the Map-Request also contains a source EID address and a
source RLOC. Once a gleaned entry has been added to the EID-to-RLOC
cache, the LISP ITR sends a Map-Request to retrieve the mapping for
the gleaned EID from the mapping system. [RFC6830] recommends
storing the gleaned entries for only a few seconds.

The first risk of gleaning is the ability to temporarily hijack an
identity. Consider an off-path attacker that wants to temporarily
hijack host HA's identity and send packets to host HB with host HA's
identity. If the xTRs that serve host HB do not store a mapping for
host HA, a non-spoofing off-path attacker (NSA) could send a LISP
encapsulated data packet to LR3 or LR4. The ETR will store the
gleaned entry and use it to return the packets sent by host HB to the
attacker. In parallel, the ETR will send a Map-Request to retrieve
the mapping for HA. During a few seconds or until the reception of
the Map-Reply, host HB will exchange packets with the attacker that
has hijacked HA's identity. Note that the attacker could in parallel
send lots of Map-Requests or lots of LISP data encapsulated packets
with random sources to force the xTR that is responsible for host HA
to send lots of Map-Request messages in order to force it to exceed
its rate limit for control plane messages. This could further delay
the arrival of the Map-Reply message on the requesting ETR.

Gleaning also introduces the possibility of a man-in-the-middle
attack. Consider an off-path attacker that knows that hosts HA and
HB that resides in different sites will exchange information at time
t. An off-path attacker could use this knowledge to launch a man-in-
the-middle attack if the xTRs that serve the two hosts do not have
mapping for the other EID. For this, the attacker sends to LR1
(resp. LR3) a LISP data encapsulated packet whose source RLOC is its
IP address and contains an IP packet whose source is set to HB (resp.

HA). The attacker chooses a packet that will not trigger an answer,
for example the last part of a fragmented packet. Upon reception of
these packets, LR1 and LR3 install gleaned entries that point to the
attacker. As explained above, the attacker could, at the same time,
send lots of packets to LR1 and LR3 to force them to exhaust their
control plane rate limit. This will extend the duration of the
gleaned entry. If host HA establishes a flow with host HB at that
time, the packets that they exchange will first pass through the
attacker.

In both cases, the attack only lasts for a few seconds (unless the
attacker is able to exhaust the rate limitation). However it should
be noted that today a large amount of packets might be exchanged
during even a small fraction of time.

To limit the risk of attacks leveraging gleaning, the scope of a
gleaned mapping should be limited to the flow that triggered the
gleaned mapping as proposed in [Saucez09].

7. Threats concerning Interworking

[RFC6832] defines two network elements to allow LISP and non-LISP
sites to communicate, namely the Proxy-ITR and the Proxy-ETR. The
Proxy-ITR encapsulates traffic from non-LISP sites in order to
forward it toward LISP sites, while the Proxy-ETR decapsulates
traffic arriving from LISP sites in order to forward it toward non-
LISP sites. For these elements some of the attack based on the LISP
specific header are not possible, for the simple reason that some of
the fields cannot be used due to the unidirectional nature of the
traffic.

The Proxy-ITR has functionality similar to the ITR, however, its main
purpose is to encapsulate packets arriving from the DFZ in order to
reach LISP sites. This means that it is no bound to any particular
EID-Prefix, hence no mapping exists and no mapping can be configured
in the EID-to-RLOC Database. This means that the Proxy-ITR element
itself is not able to check whether or not the arriving traffic has
the right to be encapsulated or not. To limit Proxy-ITRs being used
as relays for attacks, Proxy-ITRs operators are encouraged to
implement best practices for data plane access control on the Proxy-
ITRs and the border of the network, that is the edge of the scope of
the Proxy-ITR's announcement of the EID-Prefix. On the other side,
the Proxy-ITR is meant to encapsulate only packets that are destined
to one of the LISP sites it is serving. This is the case for
instance for a service provider selling Proxy-ITR services. For this
purpose a static EID-to-RLOC Cache can be configured in order to
encapsulate only valid packets. In case of a cache-miss no Map-
Request needs to be sent and the packet can be silently dropped.

The Proxy-ETR has functionality similar to the ETR, however, its main
purpose is to inject un-encapsulated packet in the DFZ in order to
reach non-LISP-Sites. This means that since there is no specific
EID-Prefix downstream, it has no EID-to-RLOC Database that can be
used to check whether or not the destination EID is part of its
domain. In order to avoid for the Proxy-ETR to be used as relay in a
DoS attack it is preferable to configure the EID-to-RLOC Cache with
static entries used to check if an encapsulated packet coming from a
specific RLOC and having a specific source EID is actually allowed to
transit through the Proxy-ETR. This is also important for services
provider selling Proxy-ETR service to actually process only packets
arriving from its customers. However, in case of cache-miss no Map-
Request needs to be sent, rather the packet can be silently dropped
since it is not originating from a valid site. The same drop policy
should be used for packets with an invalid source RLOC or a valid
source RLOC but an invalid EID.

As it is the case without LISP, the addition of public proxies offers
opportunities to attackers to commit attacks. LISP interworking does
not open new threats compared to other interworking techniques based
on public proxies.

The careful configuration of PETR and PITR combined with the
deployment of anti-spoofing techniques mitigates the attacks
leveraging interworking and provides the same level of severity as
interworking techniques in the Internet.

8. Threats with Malicious xTRs

In this section, we discuss the threats that could be caused by
malicious xTRs. We consider the reference environment below where
EL1 is a malicious or compromised xTR. This malicious xTR serves a
set of hosts that includes HC. The other xTRs and hosts in this
network play the same role as in the reference environment described
in Section 4.

+-----+
| HA |
+-----+
| EID: HA
|
-----------------
| |
+-----+ +-----+
| LR1 | | LR2 |
+-----+ +-----+
| |
| |
+-----+ +-----+
|ISP1 | |ISP2 |
+-----+ +-----+
| |
+----------------+ +-----+ |
| |-----| EL1 |--|
| | +-----+ |
| Internet | | +-----+
| | |--| HC |
| | | +-----+
+----------------+ EID: HC
| |
+-----+ +-----+
| LR3 | | LR4 |
+-----+ +-----+
| |
-------------------
|
| EID: HB
+-----+
| HB |
+-----+

Figure 2: Malicious xTRs' Reference Environment

Since xTRs are cornerstone in the LISP architecture, malicious xTRs
are probably the most serious threat to the LISP control plane from a
security viewpoint. Indeed, the impact of compromised LISP Control
Plane can be severe, and the most effective way to attack any multi-
organizational control plane is from within the system itself. To
understand the problem, let us consider the following scenario. Host
HC and HB exchange packets with host HA. As all these hosts reside
in LISP sites, LR1 and LR2 store mappings for HB and HC. Thus, these
xTRs may need to exchange LISP control plane packets with EL1, e.g.,
to perform reachability tests or to refresh expired mappings (e.g.,
if HC's mapping has a small TTL).

A first threat against the LISP control plane is when EL1 replies to
a legitimate Map-Request message sent by LR1 or LR2 with a Map-Reply
message that contains an EID-Prefix that is larger than the prefix
owned by the site attached to EL1. For instance if the prefix owned
by EL1 is 192.0.2.0/25 but the Map-Reply contain a mapping for
192.0.2.0/24. This could allow EL1 to attract packets destined to
other EIDs than the EIDs that are attached to EL1. This attack is
called an "overclaiming" attack.

A malicious ETR might fragment its eid-to-rloc database and then
instigate traffic to its site, therefore creating state on the
corresponding ITR's map-cache. This attack is called de-aggregation
attack.

Overclaiming attack could be combined with de-aggregation to succeed
a LISP Cache poisoning attack and prefix hijacking. For example, if
the EID prefix of the attacker is 192.0.2.0/25, it cannot provide a
mapping for the EID prefix 192.0.2.128/25 (i.e., it cannot hijack the
prefix). However, since a Map-Reply can contain several map records,
it is possible to hijack such a prefix by providing as well a mapping
for it. To this end, the attacker could send a Map-Reply with an EID
prefix that covers at the same time the requested EID and the
hijacked target prefix. Continuing the previous example, if the
requested mapping is for EID 192.0.2.1, and the target hijack prefix
is 192.0.2.128/25, the Map-Reply will contain a map record for
192.0.2.0/24 and a map record for 192.0.2.128/25. Such a reply is
considered legitimate according to the requested EID, while the map
record of the hijacked prefix may lead to traffic redirection/
disruption and ITR's Cache poisoning.

Another variant of the overclaiming attack is a Denial of Service
attack by sending a Negative Map-Reply message for a larger prefix
without any locator and with the Drop action. Such a Negative Map-
Reply indicates that the ETR that receives it should discard all
packets.

By enabling [I-D.ietf-lisp-sec], overclaiming attacks are mitigated
under the assumption that the mapping system can be trusted. This
assumption is equivalent to the general assumption that the control-
plane is trustable in BGP meaning that the threat is not more severe
than what is observed today. In addition, at the time of the writing
all Map Server implementations are configured with the minimal prefix
allowed to be register by their customers such that a customer cannot
register an overclaimed attack. Therefore, if mappings are always
retrieved via the mapping system with LISP-Sec activated and if Map-
Registers are cryptographically protected as recommended in the
specifications, overclaiming attack is not possible.

Another concern with malicious xTRs is the possibility of Denial of
Service attacks. A first attack is the flooding attack that was
described in [I-D.bagnulo-lisp-threat]. This attack allows a
malicious xTR to redirect traffic to a victim. The malicious xTR
first defines a mapping for HC with two RLOCs: its own RLOC (EL1) and
the RLOC of the victim (e.g., LR3). The victim's RLOC is set as
unreachable in the mapping. HC starts a large download from host HA.
Once the download starts, the malicious xTR updates its Locator
Status Bits, changes the mapping's version number or sets the SMR bit
such that LR1 updates its EID-to-RLOC Cache to send all packets
destined to HC to the victim's RLOC. Instead of downloading from HA,
the attacker could also send packets that trigger a response (e.g.,
ICMP, TCP SYN, DNS request, ...) to HA. HA would then send its
response and its xTR would forward it to the victim's RLOC.

An important point to note about this flooding attack is that it
reveals a limitation of the LISP architecture. A LISP ITR relies on
the received mapping and possible reachability information to select
the RLOC of the ETR that it uses to reach a given EID or block of
EIDs. However, if the ITR made a mistake, e.g., due to
misconfiguration, wrong implementation, or other types of errors and
has chosen a RLOC that does not serve the destination EID, there is
no easy way for the LISP ETR to inform the ITR of its mistake. A
possible solution is to enforce an ETR to perform a reachability test
with the selected ITR as soon as there is LISP encapsulated traffic
between the two. We recommend to never use reachability information
without verifying them first.

Note that the attacks discussed in this section are for documentation
purpose only. Malicious xTRs are either somehow directly deployed by
attackers or the result of attackers gaining privileged access to
existing xTRs. As such, it is out of the scope of LISP to propose
any mechanism to protect routers or to avoid their deployments with
malicious intentions.

The correct deployment of anti-spoofing and rate limiting techniques
combined with LISP-Sec and Map-Register authentication prevents
threats caused by malicious xTRs, as long as mappings are always
retrieved via a trustable mapping system. In addition reachability
information SHOULD be verified before usage.

9. Security of the Proposed Mapping Systems

9.1. LISP+ALT

One of the assumptions in [RFC6830] is that the mapping system is
more secure than sending Map-Request and Map-Reply messages directly.

We analyze this assumption in this section by analyzing the security
of the ALT mapping system.

The ALT mapping system is basically a manually configured overlay of
GRE tunnels between ALT routers. BGP sessions are established
between ALT routers that are connected through such tunnels. An ALT
router advertises the EID prefixes that it serves over its BGP
sessions with neighboring ALT routers and the EID-Prefixes that it
has learned from neighboring ALT routers.

The ALT mapping system is in fact a discovery system that allows any
ALT router to discover the ALT router that is responsible for a given
EID-Prefix. To obtain a mapping from the ALT system, an ITR sends a
packet containing a Map-Request on the overlay. This Map-Request is
sent inside a packet whose destination is the requested EID. The
Map-Request is routed on the overlay until it reaches the ALT router
that advertised initially the prefix that contains the requested EID.
This ALT router then replies directly by sending a Map-Reply to the
RLOC of the requesting ITR.

The security of the ALT mapping system depends on many factors,
including:

o The security of the intermediate ALT routers.

o The validity of the BGP advertisements sent on the ALT overlay.

ALT routers are interconnected with tunnels, the usage of secured
tunnels prevents BGP advertisements to be altered, dropped, or added
by on-path or off path attackers. If a high level of security is
required, works in the SIDR working group that develop security
solutions for BGP ([RFC6480]) could be applied to LISP+ALT.

The security of the intermediate ALT routers is another concern. A
malicious intermediate ALT router could manipulate the received BGP
advertisements and also answer to received Map-Requests without
forwarding them to their final destination on the overlay. This
could lead to various types of redirection attacks. Note that in
contrast with a regular IP router that could also manipulate in
transit packets, when a malicious or compromised ALT router replies
to a Map-Request, it can redirect legitimate traffic for a long
period of time by sending an invalid Map-Reply message. Thus, the
impact of a malicious ALT router could be more severe than a
malicious router in today's Internet. BGP is also weak in case of a
router involved in the BGP topology is compromised.

Configuring correctly the Map Servers, Map Revolvers, and ALT routers
with filters corresponding to their customer cones provides the same
security level as in BGP. If more security is necessary,
cryptography must be used to validate the mappings themselves.

9.2. LISP-DDT

The LISP Delegated Database Tree (LISP-DDT) mapping system is
proposed as an alternative for LISP+ALT [I-D.ietf-lisp-ddt]. LISP-
DDT is a hierarchical distributed database for EID-to-RLOC mappings.
Each DDT node is configured with an EID prefix it is authoritative
for, as well as the RLOC addresses and EID prefixes of the LISP-DDT
nodes that are authoritative for more specific EID prefix. In LISP-
DDT, mappings are retrieved iterative. A Map Resolver that needs to
locate a mapping traverses the tree of DDT nodes contacting them one
after another until the leaf of the DDT tree that is authoritative
for the longest matching EID prefix for the mapping's EID is reached.
The Map Resolver traverses the hierarchy of LISP-DDT nodes by sending
Map-Requests, with the LISP-DDT-originated bit set, to LISP-DDT
nodes. The Map Resolver first contacts the root of the hierarchy.
When a LISP-DDT node receives a Map-Request, it replies to the Map
Resolver with a Map-Referral that contains the list of the locators
of its children that are authoritative of a prefix that covers the
EID in the Map-Request. The Map Resolver then contacts one of these
children that will return, at its turn, a Map-Referral. This
procedure is iteratively executed until a Map-Referral marked with
the done flag is received. The locators that appear in a referral
with the done flag are those of the authoritative ETRs for the EID in
the Map-Request. At that moment, the Map Resolver falls back to its
normal behavior and sends a Map-Request to the ETR in order for the
ITR to obtain the mapping. It is worth to mention that the Map
Resolver can cache the referrals to avoid traversing all the whole
hierarchy for all mapping retrievals.

The operation in LISP-DDT is different from ALT and thus it does not
present the same threats as LISP+ALT. As a first difference, LISP-
DDT natively includes security specification providing data origin
authentication, data integrity protection and secure EID prefix
delegation. Hence, these aspects are no further explored in this
document.

However, threats exist for LISP-DDT as well. For instance, a DoS
attack could be performed on the mapping infrastructure by asking to
retrieve a large amount of mappings at the same time, hence, the
importance of carefully provisioning the topology of the DDT
hierarchy.

If an attacker manages to compromise a LISP-DDT node it could send
fake referrals to the Map Resolver and then control the mappings
delivered to the ITRs. Furthermore, the effects of such an attack
could be longer than the attack itself if the Map Resolver caches the
referrals.

The correct deployment of anti-spoofing and rate limiting techniques
combined with embedded security features of LISP-DDT prevent attacks
leveraging LISP-DDT.

10. Threats concerning LISP-MS

LISP-MS ([RFC6833] specifies two network elements, namely the Map
Server and the Map Resolver, that are meant to be used by xTRs to
access the mapping system. The advantage is clearly the fact that
even if the mapping system changes in time xTRs do not need to change
anything since they deal only with Map Servers and Map Resolvers.
This includes the security aspects, since no change in the local
security policies is needed.

10.1. Map Server

Map Server is used to dispatch Map-Request coming from the mapping
system to ETRs that are authoritative for the EID in the request. To
this end it is necessary that ETRs register their mappings to the Map
Server. This allows the Map Server to know toward which ETR to
forward Map-Requests and also to announce the EID-prefixes of the
registered mappings in the mapping system.

LISP uses a shared key approach in order to protect the Map Server
and grant registration rights only to ETRs that have a valid key.
Shared key must be used to protect both the registration message and
the Map-Notify message when used. The mechanism used to share the
key between a Map Server and an ETRs must be secured to avoid that a
malicious nodes catch the key and uses it to send forged Map-Register
message to the Map Server. A forged Map-Register message could be
used to attract Map-Request and thus provide invalid Map-Replies or
the redirect Map-Requests to a target to mount a DoS attack.

More subtle attacks could be carried out only in the case of
malicious ETRs. A malicious ETR could register an invalid RLOC to
divert Map-Requests to a target ETR and succeed a DoS attack on it.
To avoid this kind of attack, the Map Server must check that the
registered RLOCs belong to ETRs authoritative for the registered EID
prefix. Such check can be done by sending and explicit Map-Request
for the EID to the ETRs in the mapping and check that replies with a
Map-Reply. If the ETRs return a valid Map-Reply, the RLOC belongs to
an authoritative ETR. Note that this does not protect against
malicious ETRs that create forged Map-Replies. Stronger techniques
for RLOC check are presented in [I-D.saucez-lisp-mapping-security].

Similarly to the previous case, a malicious ETR could register an
invalid EID-prefix to attract Map-Requests or to redirect them to a
target to mount a DoS attack. To avoid this kind of attack, the Map
Server must check that the prefixes registered by an ETR belong to
that ETR. One method could be to manually configure EID-prefix
ranges that can be announced by ETRs.
[I-D.saucez-lisp-mapping-security] present alternative techniques to
verify the prefix claimed by an ETR.

The correct deployment of anti-spoofing and rate limiting techniques
combined with usage of Map-Register authentication prevents attacks
leveraging the Map Server.

10.2. Map Resolver

Map Resolvers receive Map-Requests, typically from ITRs, and use the
mapping system to find a mapping for the EID in the Map-Request. It
can work in two modes:

Non-Caching Mode: The resolver just forwards the Map-Request to the
mapping system, which will take care of delivering the request
to an authoritative ETR. The latter will send back a Map-Reply
directly to the ITR that has originally issued the request.

Caching Mode: The resolver will generate a new Map-Request and send
it to the mapping system. In this way it will receive the
corresponding reply, store a local copy in a cache, and send
back a reply to the original requester. Since all requested
mappings are locally cached, before actually making a request
to the mapping system it performs a lookup in the local cache
and in case of an hit, it send back a reply without querying
the mapping system.

In its basic mode, i.e., non-caching mode, the Map Resolver does not
keep state, hence, the only direct form of attack is a DoS attack,
where an attacker (or a group of attackers) could try to exhaust
computational power by flooding the resolver with requests. Common
filtering techniques and BCP against DoS attacks could be applied in
this case.

Nonetheless, attackers could use resolvers as relay for DoS attacks
against xTRs. An off-path spoofing attacker could generate a high
load of requests to a set of resolvers, hence distributing the load
in order to avoid to be blocked. All this requests can use a
specific EID that makes all the requests to be forwarded to a
specific ETR, which, as a result, will be victim of a DDoS attack.
Similarly, the attacker ITR, SA could use a send spoofed Map-Request
messages whose source address making all
the replies to converge to one single ITR, which, as a result, will
be victim of a DDoS attack. Such scenarios EID addresses are not specific to LISP,
but rather a common problem of every query infrastructure, hence the
same BCP can be applied in order to limit the attacks.

When functioning in caching-mode, the resolver will use the same type
of cache than ITRs. Due to its similarity with the ITRs' cache the
analysis provided in Section 5.2 holds also in this case. However,
an important difference exists: this cache is not used for packet
encapsulation but only for quick replies when new requests arrive.
Therefore, as the caching-mode is only an optimization, the attacks
that aim at filling the Map Resolver cache have a less severe impact
on all the traffic. The usage of LISP-Sec prevents ITR to obtain invalid
mappings. It is worth noting that caching addresses inside
192.0.2.0/24 and source RLOC address is not used in current
implementations as it makes mapping synchronization hard for mobile
devices.

When Map Resolvers are used as front-end of the LIS-DDT mapping
system they may be exposed to another variant of DoS. Indeed, the
iterative operation of the Map Resolver on the DDT hierarchy implies
that it has to maintain state about the ITR that requested the
mapping, this in order to send the final Map-Request to the ETR on
behalf of the victim ITR. An attacker might leverage on this to fill the
Map Resolver memory and then cause a DoS. Rate limiting can be used
to present this attack.

The question may arise on whether a Kaminsky-like attack is possible Upon
reception of these Map-Request messages, the ETR would send large
Map-Reply messages for an off-path attacker against ITRs sending requests each of the addresses inside p/P back to a certain
resolver. the
victim ITR.

The 64-bits nonce present in every Map-Request message has been
introduced in may also contain the LISP specification to avoid such kind SMR bit. Upon reception
of attack.
There has been discussion within a Map-Request message with the LISP Working Group on SMR bit, an ETR must return to the
optimal size
source of the nonce, and it seems that 64-bits provides
sufficient protection.

A possible way Map-Request message a Map-Request message to limit retrieve
the above-described attacks is to introduce
strong identification in corresponding mapping. This raises similar problems as the Map-Request/Map-Reply by using P bit
discussed above except that as the
Encapsulated Control Message with authentication enabled
[I-D.ietf-lisp-sec].

The correct deployment of anti-spoofing and rate limiting techniques
combined with LISP-Sec and Map-Register authentication prevent
attacks leveraging Map Resolver.

11. Security Recommendations

Different deployments of LISP may have different security
requirements. The recommendations in this document aim at mitigating
threats in in public deployments of LISP.

To mitigate Map-Request messages are smaller
than Map-Reply messages, the impact risk of amplification attacks against LISP in public deployments,
the following recommendations should be followed.

First, the use of some form of filtering can help in avoid or at
least mitigate some types of attacks.

o On ETRs, packets should be decapsulated only is
reduced. This is not true anymore if the destination
EID is effectively part of ETR append to the EID-Prefix downstream Map-
Request messages its own Map-Records. This mechanism is meant to
reduce the ETR.
Further, still on ETRs, packets should be decapsulated only if a delay in mapping for the source EID distribution since mapping information is present
provided in the Map-Request message.

Furthermore, appending Map-Records to Map-Request messages allows an
off-path attacker to generate a (spoofed or not) Map-Request message
and include in the EID-to-RLOC Cache and
has been obtained through Map-Reply portion of the message mapping system (not gleaned).

o On ITRs, packets should be encapsulated only if the source for EID is
effectively part of
prefixes that it does not serve.

Moreover, attackers can use Map Resolver and/or Map Server network
elements to perform relay attacks. Indeed, on the EID-Prefix downstream one hand, a Map
Resolver is used to dispatch Map-Request to the ITR. Further,
still mapping system and,
on ITRs, packets should be encapsulated only if the other hand, a mapping
obtained Map Server is used to dispatch Map-Requests
coming from the mapping system is present to ETRs that are authoritative for the
EID in the EID-to-RLOC
Cache (no Data-Probing).

Note that Map-Request.

5.4.2. Attacks with Map-Reply messages

In this filtering, since complete mappings need to be
installed in both ITRs and ETRs, can introduce higher connection
setup latency and hence potentially more packets drops due to section we analyze the
lack attacks that could occur when an off-
path attacker sends directly Map-Reply messages to ETRs without using
one of mappings in the EID-to-RLOC Cache.

While the gleaning mechanism allows starting encapsulating packets proposed LISP mapping systems.

There are two different types of Map-Reply messages:

Positive Map-Reply: These messages contain a Map-Record binding an
EID-Prefix to one or more RLOCs.

Negative Map-Reply: These messages contain a certain EID in parallel Map-Record for an EID-
Prefix with the Map-Request an empty locator-set and specifying an action,
which may be either Drop, natively forward, or Send Map-
Request.

Positive Map-Reply messages are used to obtain a mapping
when a new flow is established, it creates important security risks
since it allows attackers map EID-Prefixes onto RLOCs.
Negative map-reply messages are used to indicate non-lisp prefixes.
ITRs can, if needed, be configured to send all traffic destined for
non-lisp prefixes to perform identity hijacks. Although the
duration a Proxy-ETR.

Most of these identity hijacks is limited (except the case security of
rate limitation exhaustion), their impact can be severe. A first
option would be to disable gleaning until the security concerns are
solved. A second option would be to strictly limit Map-Reply messages depends on the number of
packets 64 bits
nonce that can be forwarded via is included in a gleaned entry. Overall Map-Request and returned in the
benefits of gleaning, i.e., avoiding Map-
Reply. f an ETR does not accept Map-Reply messages with an invalid
nonce, the loss risk of attack is acceptable given the first packet size of
a flow, seems very small compared to the associated security risks.
Furthermore, measurements performed in data centers show nonce
(64 bits). However, the nonce only confirms that today's
Internet often operate with packet loss ratio the map-reply
received was sent in response to a map-request sent, it does not
validate the contents of 1 that map-reply.

In addition, an attacker could perform EID-to-RLOC Cache overflow
attack by de-aggregating (i.e., splitting an EID prefix into
artificially smaller EID prefixes) either positive or 2 percentage
([Chu]). These packet loss ratios are probably already orders negative
mappings.

In presence of
magnitude malicious ETRs, overclaiming attacks are possible.
Such an attack happens when and ETR replies to a legitimate Map-
Request message it received with a Map-Reply message that contains an
EID-Prefix that is larger than the improvement provided prefix owned by the gleaning
mechanism.

With the increasing deployment of spoofing prevention techniques such
as [RFC3704] or SAVI [SAVI], it can be expected that attackers will
become less capable of sending packets with a spoofed source address.
To prevent packet injection attacks from non-spoofing attackers
(NSA), ETRs should always verify site that
encompasses the source RLOC of each
received LISP data encapsulated packet corresponds to one EID of the
RLOCs listed in Map-Request. For instance if the mappings prefix
owned by the site is 192.0.2.0/25 but the Map-Reply contains a
mapping for 192.0.2.0/24, then the source EID found in the inner
packet. An alternative could be to use existing IPSec techniques

[RFC4301] and when necessary including perhaps [RFC5386] mapping will influence packets
destined to establish
an authenticated tunnel between the ITR and other EIDs than the ETR.

[RFC6830] recommends to rate limit one the control messages LISP site has authority on.

A malicious ETR might also fragment its EID-to-RLOC database so that are sent
by an xTR.
ITR's might have to install much more mappings than really necessary.
This limit attack is important to deal with denial of service
attacks. However, a strict limit, e.g., implemented called de-aggregation attack.

5.4.3. Attacks with a token
bucket, on all the Map-Request and Map-Reply Map-Register messages

Map-Register messages are sent by an xTR
is not sufficient. An xTR should distinguish between different types
of control plane packets:

1. The Map-Request messages that it sends ETRs to refresh expired mapping
information.

2. The Map-Request messages that it sends indicate to obtain the mapping
information because one of
system the served hosts tried to contact an
external EID.

3. The Map-Request messages that it sends as reachability probes.

4. The Map-Reply messages that it sends as response EID prefixes associated to reachability
probes.

5. them. The Map-Request messages Map-Register message
provides an EID prefix and the list of ETRs that it sends are able to support gleaning.

These control plane provide
Map-Replies for the EID covered by the EID prefix.

As Map-Register messages are used for different purposes. Fixing protected by an authentication
mechanism, only a global rate limit compromised ETR can register itself to its
allocated Map Server.

A compromised ETR can perform an overclaiming attack in order to
influence the route followed by Map-Requests for all control plane EIDs outside the
scope of its legitimate EID prefix.

A compromised ETR can also perform a deaggregation attack in order to
register more EID prefixes than necessary to its Map Servers.

5.4.4. Attacks with Map-Notify messages

Map-Notify messages increases are sent by a Map Server to an ETR to acknowledge
the risk
of Denial good reception and processing of Service attacks if a single type of control plane
message Map-Register message.

A spoofing attacker compromised ETR can exceed the configured limit. This risk could be
mitigated by either specifying send a rate for each of Map-Register with the five types of
control plane messages. Another option could be to define a maximum
rate for all control plane messages,
M-bit set and prioritize the control plane
messages according a spoofed source address to force the list above (with the highest priority for Map Server to
send a Map-Notify message type 1).

In [RFC6830], there is no mechanism that allows an xTR to verify the
validity of the content spoofed address and then succeed a Map-Reply message that it receives.
Besides
relay attack. Similarly to the attacks discussed earlier in pair Map-Request/Map-Reply, the document, pair
Map-Register/Map-Notify is protected by a time-shifted
attack where nonce making hard for an
attacker is able to modify the content of inject a Map-Reply
message but then needs falsified notification to move off-path could also create redirection
attacks. The nonce only allows an xTR ETR to verify make this
ETR believe that a Map-Reply
responds the registration succeeded while it has not.

6. Attack categories

6.1. Intrusion

6.1.1. Description

With an intrusion attack an attacker gains remote access to some
resources (e.g., a previously sent Map-Request message. To verify the
validity and integrity of bindings between EID-Prefixes and their
RLOCS, solutions proposed in [I-D.saucez-lisp-mapping-security] and
[I-D.ietf-lisp-sec] could host, a router, or a network) that are normally
denied to her.

6.1.2. Vectors

Intrusion attacks can be deployed. Having LISP-SEC and lisp-
mapping-security in place would prevent all the above-mentioned
threats.

Finally, there is also the risk mounted using:

o Spoofing EID or RLOCs

o Instance ID bits

6.2. Denial of Service (DoS)

6.2.1. Description

A Denial of Service (DoS) attack against
the EID-to-RLOC Cache. We have discussed these attacks when
considering external attackers with, e.g., the gleaning mechanism and
in Section 5.2. If an ITR has a limited EID-to-RLOC Cache, aims at disrupting a
malicious or compromised host residing in specific
targeted service either by exhausting the site resources of the victim up
to the point that it serves
could generate packets is not able to random destinations provide a reliable service to force
legit traffic and/or systems or by exploiting vulnerabilities to make
the ITR targeted service unable to
issue a large number operate properly.

6.2.2. Vectors

Denial of Map-Requests whose answers could fill its
cache. Faced with such misbehaving hosts, LISP ITR should Service attacks can be able to
limit mounted using

o Gleaning

o Interworking

o Locator Status Bits

o Map-Version bit

o Nonce-Present and Echo-Nonce bits

o Map-Request message

o Map-Reply message

o Map-Register message

o Map-Notify message

6.3. Eavesdropping

6.3.1. Description

With an eavesdropping attack, the percent attacker collects traffic of Map-Requests that it sends for a given source
EID.

In
target through deep packet inspection in order to mitigate flooding attacks it would be worth consider
developing secure mechanisms to allow an ETR to indicate gain access to an ITR
restricted or sensitive information such as passwords, session
tokens, or any other confidential information. This type of attack
is usually carried out in a way such that it the target does not serve even
notice the attack. When the attacker is positioned on the path of
the target traffic, it is called a particular EID Man-in-the-Middle attack.
However, this is not a requirement to carry out and eavesdropping
attack. Indeed the attacker might be able, for instance through an
intrusion attack on a weaker system, either to duplicate or block of EIDs.

12. even re-
direct the traffic, in both cases having access to the raw packets.

6.3.2. Vectors

Eavesdropping attacks can be mounted using

o Gleaning

o Locator Status Bits

o Nonce-Present and the Echo-Nonce bits

o Map-Request messages

o Map-Reply messages

7. Recommendations

TBD

8. IANA Considerations

This document makes no request to IANA.

13.

9. Security Considerations

Security considerations are the core of this document and do not need
to be further discussed in this section.

14.

10. Acknowledgments

This document builds upon the draft of Marcelo Bagnulo
([I-D.bagnulo-lisp-threat]), where the flooding attack and the
reference environment were first described.

The authors would like to thank Florin Coras, Vina Ermagan, Darrel
Lewis, and Jeff Wheeler for their comments.

This work has been partially supported by the INFSO-ICT-216372
TRILOGY Project (www.trilogy-project.org).

15.

11. References

15.1.

11.1. Normative References

[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security
Concerns with IP Tunneling", RFC 6169, April 2011.

[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830, January
2013.

[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
"Interworking between Locator/ID Separation Protocol
(LISP) and Non-LISP Sites", RFC 6832, January 2013.

[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation
Protocol (LISP) Map-Server Interface", RFC 6833, January
2013.

[RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
Separation Protocol (LISP) Map-Versioning", RFC 6834,
January 2013.

[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol Alternative Logical
Topology (LISP+ALT)", RFC 6836, January 2013.

[RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to
Routing Locator (RLOC) Database", RFC 6837, January 2013.

15.2.

11.2. Informative References

[Chu] Jerry Chu, H., "Tuning TCP Parameters for the 21st
Century", Century
", 75th IETF, Stockholm, July 2009,
<http://tools.ietf.org/wg/savi/>.

[I-D.bagnulo-lisp-threat]
Bagnulo, M., "Preliminary LISP Threat Analysis",
draft-bagnulo-lisp-threat-01 draft-
bagnulo-lisp-threat-01 (work in progress), July 2007.

[I-D.ietf-lisp-ddt]
Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP
Delegated Database Tree", draft-ietf-lisp-ddt-01 (work in
progress), March 2013.

[I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D.,
and O. Bonaventure, "LISP-Security (LISP-SEC)",
draft-ietf-lisp-sec-04 draft-
ietf-lisp-sec-04 (work in progress), October 2012.

[I-D.ietf-tcpm-tcp-security]
Gont, F., "Survey of Security Hardening Methods for
Transmission Control Protocol (TCP) Implementations",
draft-ietf-tcpm-tcp-security-03 (work in progress), March
2012.

[I-D.meyer-lisp-cons]
Brim, S., "LISP-CONS: A Content distribution Overlay
Network Service for LISP", draft-meyer-lisp-cons-04 (work
in progress), April 2008.

[I-D.saucez-lisp-mapping-security]
Saucez, D. and O. Bonaventure, "Securing LISP Mapping
replies", draft-saucez-lisp-mapping-security-00 (work in
progress), February 2011.

[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.

[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.

[RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing
Security: An Unauthenticated Mode of IPsec", RFC 5386,
November 2008.

[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, February 2012.

[SAVI] IETF, "Source Address Validation Improvements Working
Group",
Group ", 2013, <http://tools.ietf.org/wg/savi/>.

[Saucez09]
Saucez, D. and L. Iannone, "How to mitigate the effect of
scans on mapping systems", systems ", Submitted to the Trilogy
Summer School on Future Internet, 2009.

Appendix A. Document Change Log

o Version 06 Posted October 2013.

* Complete restructuration, temporary version to be used at
October 2013 interim meeting.

o Version 05 Posted August 2013.

* Removal of severity levels to become a short recommendation to
reduce the risk of the discussed threat.

o Version 04 Posted February 2013.

* Clear statement that the document compares threats of public
LISP deployments with threats in the current Internet
architecture.

* Addition of a severity level discussion at the end of each
section.

* Addressed comments from V. Ermagan and D. Lewis' reviews.

* Updated References.

* Further editorial polishing.

o Version 03 Posted October 2012.

* Dropped Reference to RFC 2119 notation because it is not
actually used in the document.

* Deleted future plans section.

* Updated References

* Deleted/Modified sentences referring to the early status of the
LISP WG and documents at the time of writing early versions of
the document.

* Further editorial polishing.

* Fixed all ID nits.

o Version 02 Posted September 2012.

* Added a new attack that combines overclaiming and de-
aggregation (see Section 6.2). 5.4.2).

* Editorial polishing.

o Version 01 Posted February 2012.

* Added discussion on LISP-DDT in Section 9.2. LISP-DDT.

o Version 00 Posted July 2011.

* Added discussion on LISP-MS in Section 10. LISP-MS>.

* Added discussion on Instance ID in Section 5.4. 5.3.2.

* Editorial polishing of the whole document.

* Added "Change Log" appendix to keep track of main changes.

* Renamed "draft-saucez-lisp-security-03.txt.

Authors' Addresses

Damien Saucez
INRIA
2004 route des Lucioles BP 93
06902 Sophia Antipolis Cedex
France

Email: damien.saucez@inria.fr

Luigi Iannone
Telecom ParisTech
23, Avenue d'Italie, CS 51327
75214 PARIS Cedex 13
France

Email: luigi.iannone@telecom-paristech.fr

Olivier Bonaventure
Universite catholique de Louvain
Place St. Barbe 2
Louvain la Neuve
Belgium

Email: olivier.bonaventure@uclouvain.be