draft-ietf-lisp-threats-09.txt   draft-ietf-lisp-threats-10.txt 
Network Working Group D. Saucez Network Working Group D. Saucez
Internet-Draft INRIA Internet-Draft INRIA
Intended status: Informational L. Iannone Intended status: Informational L. Iannone
Expires: October 10, 2014 Telecom ParisTech Expires: January 5, 2015 Telecom ParisTech
O. Bonaventure O. Bonaventure
Universite catholique de Louvain Universite catholique de Louvain
April 8, 2014 July 4, 2014
LISP Threats Analysis LISP Threats Analysis
draft-ietf-lisp-threats-09.txt draft-ietf-lisp-threats-10.txt
Abstract Abstract
This document proposes a threat analysis of the Locator/Identifier This document proposes a threat analysis of the Locator/Identifier
Separation Protocol (LISP) if deployed in the Internet. Separation Protocol (LISP).
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 10, 2014. This Internet-Draft will expire on January 5, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. On-path Attackers . . . . . . . . . . . . . . . . . . . . . . 3 2. Threat model . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Off-Path Attackers: Reference Environment . . . . . . . . . . 3 2.1. Attacker modes of operation . . . . . . . . . . . . . . . 4
4. Attack vectors . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.1. On-path attackers vs. Off-path attackers . . . . . . . 4
4.1. Configured EID-to-RLOC mappings . . . . . . . . . . . . . 6 2.1.2. Internal attackers vs. External attackers . . . . . . 4
4.2. EID-to-RLOC Cache . . . . . . . . . . . . . . . . . . . . 6 2.1.3. Live attackers vs. Time-shifted attackers . . . . . . 4
4.3. Attacks using the data-plane . . . . . . . . . . . . . . . 7 2.1.4. Control-plane attackers vs. Data-plane attackers . . . 5
4.3.1. Attacks not leveraging on the LISP header . . . . . . 7 2.1.5. Cross mode attackers . . . . . . . . . . . . . . . . . 5
4.3.2. Attacks leveraging on the LISP header . . . . . . . . 8 2.2. Threat categories . . . . . . . . . . . . . . . . . . . . 5
4.4. Attacks using the control-plane . . . . . . . . . . . . . 11 2.2.1. Replay attack . . . . . . . . . . . . . . . . . . . . 5
4.4.1. Attacks with Map-Request messages . . . . . . . . . . 11 2.2.2. Packet manipulation . . . . . . . . . . . . . . . . . 5
4.4.2. Attacks with Map-Reply messages . . . . . . . . . . . 12 2.2.3. Packet interception and suppression . . . . . . . . . 6
4.4.3. Attacks with Map-Register messages . . . . . . . . . . 13 2.2.4. Spoofing . . . . . . . . . . . . . . . . . . . . . . . 6
4.4.4. Attacks with Map-Notify messages . . . . . . . . . . . 14 2.2.5. Rogue attack . . . . . . . . . . . . . . . . . . . . . 6
5. Attack categories . . . . . . . . . . . . . . . . . . . . . . 14 2.2.6. Denial of Service (DoS) attack . . . . . . . . . . . . 7
5.1. Intrusion . . . . . . . . . . . . . . . . . . . . . . . . 14 2.2.7. Performance attack . . . . . . . . . . . . . . . . . . 7
5.1.1. Description . . . . . . . . . . . . . . . . . . . . . 14 2.2.8. Intrusion attack . . . . . . . . . . . . . . . . . . . 7
5.1.2. Vectors . . . . . . . . . . . . . . . . . . . . . . . 14 2.2.9. Amplification attack . . . . . . . . . . . . . . . . . 7
5.2. Denial of Service (DoS) . . . . . . . . . . . . . . . . . 14 2.2.10. Multi-category attacks . . . . . . . . . . . . . . . . 7
5.2.1. Description . . . . . . . . . . . . . . . . . . . . . 14 3. Attack vectors . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2.2. Vectors . . . . . . . . . . . . . . . . . . . . . . . 14 3.1. Gleaning . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Subversion . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2. Locator Status Bits . . . . . . . . . . . . . . . . . . . 9
5.3.1. Description . . . . . . . . . . . . . . . . . . . . . 15 3.3. Map-Version . . . . . . . . . . . . . . . . . . . . . . . 9
5.3.2. Vectors . . . . . . . . . . . . . . . . . . . . . . . 15 3.4. Echo-Nonce algorithm . . . . . . . . . . . . . . . . . . . 10
6. Note on Privacy . . . . . . . . . . . . . . . . . . . . . . . 16 3.5. Instance ID . . . . . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 3.6. Interworking . . . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 3.7. Map-Request messages . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 3.8. Map-Reply messages . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.9. Map-Register messages . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 3.10. Map-Notify messages . . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . . 17 4. Note on Privacy . . . . . . . . . . . . . . . . . . . . . . . 14
Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 18 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
The Locator/ID Separation Protocol (LISP) is specified in [RFC6830]. The Locator/ID Separation Protocol (LISP) is specified in [RFC6830].
The present document assess the potential security threats identified The present document assess the potential security threats identified
in the LISP specifications if LISP is deployed in the Internet (i.e., in the LISP specifications if LISP is deployed in the Internet (i.e.,
a public non-trustable environment). a public non-trustable environment).
The document is composed of two main parts: the first discussing the The document is composed of three main parts: the first defines the
techniques that can be used by attackers to succeed attacks based on general threat model that attackers can follow to mount attacks. The
the LISP protocol and architecture; the second discussing the main second describing the techniques based on the LISP protocol and
categories of attacks and how to construct them. architecture that attackers can use to construct attacks. The third
discussing general solutions to protect the LISP protocol and
architecture from attacks.
This document does not consider all the possible uses of LISP as This document does not consider all the possible uses of LISP as
discussed in [RFC6830] and [I-D.ietf-lisp-deployment]. The document discussed in [RFC6830] and [RFC7215]. The document focuses on LISP
focuses on LISP unicast, including as well LISP Interworking unicast, including as well LISP Interworking [RFC6832], LISP-MS
[RFC6832], LISP-MS [RFC6833], and LISP Map-Versioning [RFC6834]. The [RFC6833], and LISP Map-Versioning [RFC6834]. The reading of these
reading of these documents is a prerequisite for understanding the documents is a prerequisite for understanding the present document.
present document.
This document assumes a generic IP service and does not discuss the This document assumes a generic IP service and does not discuss the
difference, from a security viewpoint, between using IPv4 or IPv6. difference, from a security viewpoint, between using IPv4 or IPv6.
2. On-path Attackers 2. Threat model
On-path attackers are attackers that are able to capture and modify This document assumes that attackers can be located anywhere in the
all the packets exchanged between an Ingress Tunnel Router (ITR) and Internet (either in LISP sites or outside LISP sites) and that
an Egress Tunnel Router (ETR). To cope with such an attacker, attacks can be mounted either by a single attacker or by the
cryptographic techniques such as those used by IPSec ([RFC4301]) are collusion of several attackers.
required. As with IP, LISP relies on higher layer cryptography to
secure packet payloads from on path attacks, so this document does
not consider on-path attackers.
Similarly, a time-shifted attack is an attack where the attacker is An attacker is a malicious entity that performs the action of
temporarily on the path between two communicating hosts. While it is attacking a target in a network where LISP is (partially) deployed by
on-path, the attacker sends specially crafted packets or modifies leveraging the LISP protocol and/or architecture.
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. This documents does not consider time-shifted
attacks.
3. Off-Path Attackers: Reference Environment An attack is the action of performing an illegitimate action on a
target in a network where LISP is (partially) deployed.
The reference environment shown in the figure below is considered The target of an attack is the entity (i.e., a device connected to
throughout this document. There are two hosts attached to LISP the network or a network) that is aimed to undergo the consequences
routers: HA and HB. HA is attached to the two LISP xTRs LR1 and LR2, of an attack. Other entities can potentially undergo side effects of
which in turn are attached to two different ISPs. HB is attached to an attack, even though they are not directly targeted by the attack.
the two LISP xTRs LR3 and LR4. HA and HB are the EIDs of the two The target of an attack can be selected specifically, i.e., a
hosts. LR1, LR2, LR3, and LR4 are the RLOCs of the xTRs. PxTR is a particular entity, or arbitrarily, i.e., any entity. Finally, an
proxy xTR and MR/MS plays the roles of Map Server and/or Map attacker can aim at attacking one or several targets with a single
Resolver. attack.
+-----+ Section 2.1 specifies the different modes of operation that attackers
| HA | can follow to mount attacks and Section 2.2 specifies the different
+-----+ categories of attacks that attackers can build.
| EID: HA
|
-----------------
| |
+-----+ +-----+
| LR1 | | LR2 |
+-----+ +-----+
| |
| |
+-----+ +-----+
|ISP1 | |ISP2 |
+-----+ +-----+
| |
+------+ +----------------+ +-----+
| PxTR |-----| |-----| SA |
+------+ | | +-----+
| Internet |
+-------+ | | +-----+
| MR/MS |----| |-----| NSA |
+-------+ +----------------+ +-----+
| |
+-----+ +-----+
| LR3 | | LR4 |
+-----+ +-----+
| |
-------------------
|
| EID: HB
+-----+
| HB |
+-----+
Figure 1: Reference Network 2.1. Attacker modes of operation
We consider two off-path attackers with different capabilities: Attackers can be classified according to the following four modes of
operation, i.e., the temporal and spacial locality of the attacker.
SA is an off-path attacker that is able to send spoofed packets, 2.1.1. On-path attackers vs. Off-path attackers
i.e., packets with a different source IP address than its
assigned IP address. SA stands for Spoofing Attacker. To
perform some of the attacks described in this document SA needs
to be in a non-LISP site.
NSA is an off-path attacker that is only able to send packets whose On-path attackers, also known as Men-in-the-Middle, are able to
source address is its assigned IP address. NSA stands for Non intercept and modify packets between legitimate communicating
Spoofing Attacker. entities. On-path attackers are located either directly on the
normal communication path (either by gaining access to a node on the
path or by placing themselves directly on the path) or outside the
location path but manage to deviate or gain a copy of packets sent
between the communication entities. On-path attackers hence mount
their attacks by modifying packets initially sent legitimately
between communication entities.
It should be noted that with LISP, packet spoofing is slightly An attacker is called off-path attacker if it does not have access to
different than in the current Internet. Generally the term "spoofed packets exchanged during the communication or if there is no
packet" indicates a packet containing a source IP address that is not communication. To succeed their attacks, off-path attackers must
the one of the actual originator of the packet. Since LISP uses hence generate packets and inject them in the network.
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. 2.1.2. Internal attackers vs. External attackers
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 An internal attacker launches its attack from a node located within a
LISP-encapsulated packet with a spoofed source RLOC. legitimate LISP site. Such an attacker is either a legitimate node
of the site or it exploits a vulnerability to gain access to a
legitimate node in the site. Because of their location, internal
attackers are trusted by the site they are in.
Note that the two types of spoofing are not mutually exclusive, On the contrary, an external attacker launches its attacks from the
rather all combinations are possible and could be used to perform outside of a legitimate LISP site.
different kind of attacks.
In the reference environment, both SA and NSA attackers are capable 2.1.3. Live attackers vs. Time-shifted attackers
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.
4. Attack vectors A live attacker mounts attacks for which it must remain connected as
long as the attack is mounted. In other words, the attacker must
remain active for the whole duration of the attack. Consequently,
the attack ends as soon as the attacker (or the used attack vector)
is neutralized.
This section presents techniques that can be used by attackers to On the contrary, a time-shifted attacker mounts attacks that remain
succeed attacks leveraging the LISP protocol and architecture. This active after it disconnects from the Internet.
section focuses on the techniques while Section 5 presents the
attacks that can be succeeded while using these techniques.
4.1. Configured EID-to-RLOC mappings 2.1.4. Control-plane attackers vs. Data-plane attackers
Each xTR maintains a set of configured mappings related to the EID- A control-plane attacker mounts its attack by using control-plane
Prefixes that are "behind" the xTR [RFC6830]. Where "behind" means functionalities, typically the mapping system.
that at least one of the xTR's globally visible IP addresses is a
RLOC for those EID-Prefixes.
As these mappings are determined by configuration. This means that A data-plane attacker mounts its attack by using data-plane
the only way to attack this data structure is by gaining privileged functionalities.
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.
4.2. EID-to-RLOC Cache As there is no strict delimitation between the control-plane and the
data-plane, an attacker can operate in the control-plane (resp. data-
plane) to mount attacks targeting the data-plane (resp. control-
plane) or keep the attacked and targeted planes at the same layer
(i.e., from control-plane to control-plane or from data-plane to
data-plane).
The EID-to-RLOC Cache (also called the Map-Cache) is the data 2.1.5. Cross mode attackers
structure that stores a copy of the mappings retrieved from a remote
ETR's mapping via the LISP control-plane. Attacks against this data
structure could happen either when the mappings are first installed
in the cache or by corrupting (poisoning) the mappings already
present in the cache.
Cache poisoning attacks are used to alter (any combination of) the The attacker modes of operation are not mutually exclusive and hence
following parts of the mappings installed in the EID-to-RLOC Cache: attackers can combine them to mount attacks.
o EID prefix For example, an attacker can launch an attack using the control-plane
directly from within a LISP site to which it got temporary access
(i.e., internal + control-plane attacker) to create a vulnerability
on its target and later on (i.e., time-shifted + external attacker)
mount an attack on the data plane (i.e., data-plane attacker) that
leverages the vulnerability.
o RLOC list 2.2. Threat categories
o RLOC priority Attacks can be classified according to the nine following categories.
o RLOC weight 2.2.1. Replay attack
o RLOC reachability A replay attack happens when an attacker retransmits at a later time,
and without modifying it, a packet (or a sequence of packets) that
has already been transmitted.
o Mapping TTL 2.2.2. Packet manipulation
o Mapping version A packet manipulation attack happens when an attacker receives a
packet, modifies the packet (i.e., changes some information contained
in the packet) and finally transmits the packet to its final
destination that can be the initial destination of the packet or
another one.
o Mapping Instance ID 2.2.3. Packet interception and suppression
Cache poisoning attacks can be performed by attackers from the In a packet interception and suppression attack, the attacker
outside of the attacked LISP network but also directly from the captures the packet and drops it before it can reach its final
inside. As a matter of fact, end-hosts behind an ITR can use the destination.
data-plane to overflow the ITR's EID-to-RLOC Cache by sending packets
to non-popular EID prefixes (similar to scan attack but with a
different goal). In such a scenario the ITR may evict popular (in-
use) entries from the map-cache disrupting the normal operation of
the network by forcing cache miss [Florin13].
4.3. Attacks using the data-plane 2.2.4. Spoofing
The data-plane is constituted of the operations of encapsulation, With a spoofing attack, the attacker injects packets in the network
decapsulation, and forwarding as well as the content of the EID-to- pretending being another node. Spoofing attacks are made by forging
RLOC Cache and configured EID-to-RLOC mappings as specified in the source addresses in packets.
original LISP document ([RFC6830]).
4.3.1. Attacks not leveraging on the LISP header It should be noted that with LISP, packet spoofing is similar to any
other existing tunneling technology currently deployed in the
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. Hence, 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.
An attacker can inject packets into flows without using the LISP Inner address spoofing: the attacker uses encapsulation and uses a
header, i.e., with the N, L, E, V, and I bits ([RFC6830]). spoofed source address in the inner packet. In case of data-
plane LISP encapsulation, that corresponds to spoof the source
EID address of the encapsulated packet.
Taking notation of the reference environment (Figure 1), to inject a Outer address spoofing: the attacker does not use encapsulation and
packet in the HA->HB flow, a spoofing off-path attacker (SA) could spoofs the source address of the packet.
send a LISP encapsulated packet whose source is set to 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 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 only send a
packet whose source address is set to its assigned IP address. The
destination address of the encapsulated packet could be LR3 or LR4.
4.3.1.1. Gleaning Attacks 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. For example, an attacker not in a LISP
site can generate a packet with a forged source IP address (i.e.,
outer address spoofing) and forward it to a LISP destination. The
packet is then eventually encapsulated by a PITR so that once
encapsulated the attack corresponds to a inner address spoofing. One
can also imagine an attacker forging a packet with encapsulation
where both inner an outer source addresses are spoofed.
In order to reduce the time required to obtain a mapping, [RFC6830] It is important to notice that the combination of inner and outer
proposes the gleaning mechanism that allows an ITR to learn a mapping spoofing makes the identification of the attacker complex as the
from the LISP data encapsulated packets and the Map-Request packets packet may not contain information that permits to detect the origin
that it receives. LISP data encapsulated packet contains a source of the attack.
RLOC, destination RLOC, source EID and destination EID. When an ITR
receives a data encapsulated packet coming from a source EID for 2.2.5. Rogue attack
In a rogue attack the attacker manages to appear as a legitimate
source of information, without faking its identity (as opposed to a
spoofing attacker).
2.2.6. Denial of Service (DoS) attack
A Denial of Service (DoS) attack aims at disrupting a specific
targeted service to make it unable to operate properly.
2.2.7. Performance attack
A performance attacks aims at exploiting computational resources
(e.g., memory, processor) of a targeted node so to make it unable to
operate properly.
2.2.8. Intrusion attack
In an intrusion attack the attacker gains remote access to a resource
(e.g., a host, a router, or a network) or information that it
normally doesn't have access to. Intrusion attacks can lead to
privacy leakages.
2.2.9. Amplification attack
In an amplification attack, the traffic generated by the target of
the attack in response to the attack is larger than the traffic that
the attacker must generate.
2.2.10. Multi-category attacks
Attacks categories are not mutually exclusive and any combination can
be used to perform specific attacks.
For example, one can mount a rogue attack to perform a performance
attack starving the memory of an ITR resulting in a DoS on the ITR.
3. Attack vectors
This section presents techniques that can be used by attackers to
succeed attacks leveraging the LISP protocol and/or architecture.
3.1. Gleaning
To reduce the time required to obtain a mapping, the optional
gleaning mechanism allows an xTR to directly learn a mapping from the
LISP data encapsulated packets and the Map-Request packets that it
receives. LISP encapsulated data packets contain a source RLOC,
destination RLOC, source EID and destination EID. When an xTR
receives an encapsulated data packet coming from a source EID for
which it does not already know a mapping, it may insert the mapping 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. 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.
An attacker can send LISP encapsulated packets to host HB with host The same technique can be used when an xTR receives a Map-Request as
HA's EID and if the xTRs that serve host HB do not store a mapping the Map-Request also contains a source EID address and a source RLOC.
for host HA at that time. The xTR will store the gleaned entry and Once a gleaned entry has been added to the EID-to-RLOC cache, the xTR
use it to return the packets sent by host HB. In parallel, the ETR sends a Map-Request to retrieve the actual mapping for the gleaned
will send a Map-Request to retrieve the mapping for HA but until the EID from the mapping system.
reception of the 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 a given time
the attacker could send 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. If host HA is
willing to establish a flow with host HB at that time, the packets
that they exchange will pass through the attacker as long as the
gleaned entry is active on the xTRs.
By itself, an attack made solely using gleaning cannot last long, If a packet injected by an off-path attacker and with a spoofed inner
however it should be noted that with current network capacities, a address is gleaned by an xTR then the attacker may divert the traffic
large amount of packets might be exchanged during even a small meant to be delivered to the spoofed EID as long as the gleaned entry
fraction of time. is used by the xTR. This attack can be used as part of replay,
packet manipulation, packet interception and suppression, or DoS
attacks as the packets are sent to the attacker.
4.3.1.2. Threats concerning Interworking If the packet sent by the attacker contains a spoofed outer address
instead of a spoofed inner address then it can succeed a DoS or a
performance attack as the traffic normally destined to the attacker
will be redirected to the spoofed source RLOC. Such traffic may
overload the owner of the spoofed source RLOC, preventing it from
operating properly.
[RFC6832] defines Proxy-ITR and Proxy-ETR network elements to allow If the packet injected uses both inner and outer spoofing, the
LISP and non-LISP sites to communicate. The Proxy-ITR has attacker can succeed a spoofing, a performance, or an amplification
functionality similar to the ITR, however, its main purpose is to attack as traffic normally destined to the spoofed EID address will
encapsulate packets arriving from the DFZ in order to reach LISP be sent to the spoofed RLOC address. If the attacked LISP site also
sites. A Proxy-ETR has functionality similar to the ETR, however, generates traffic to the spoofed EID address, such traffic may have a
its main purpose is to inject de-encapsulated packets in the DFZ in positive amplification factor.
order to reach non-LISP Sites from LISP sites. As a PITR (resp.
PETR) is a particular case of ITR (resp. ETR), it is subject to same
attacks than ITRs (resp. ETR).
PxTRs can be targeted by attacks aiming to influence traffic between A gleaning attack does not only impact the data-plane but can also
LISP and non-LISP sites but also to launch relay attacks. have repercussions on the control-plane as a Map-Request is sent
after the creation of a gleaned entry. The attacker can then succeed
DoS and performance attacks on the control-plane. For example, if an
attacker sends a packet for each address of a prefix not yet cached
in the EID-to-RLOC cache of an xTR, the xTR will potentially send a
Map-Request for each such packet until the mapping is installed which
leads to an over-utilisation of the control-plane as each packet
generates a control-plane event. For succeeding this example, the
attacker may not need to use spoofing.
It is worth to notice that when PITR and PETR functions are Gleaning attacks are fundamentally involving a time-shifted mode of
separated, attacks targeting nodes that collocate PITR and PETR operation as the attack may last as long as the gleaned entry is kept
functionality are ineffective. by the targeted xTR. Nevertheless, [RFC6830] recommends to store the
gleaned entries for only a few seconds which limits the duration of
the attack.
4.3.2. Attacks leveraging on the LISP header Gleaning attacks always involve external data-plane attackers but
results in attacks on either the control-plane or data-plane.
The main LISP document [RFC6830] defines several flags that modify It is worth to notice that the outer spoofed address does not need to
the interpretation of the LISP header in data packets. In this be the RLOC of a LISP site an may be any address.
section, we discuss how an off-path attacker could exploit this LISP
header.
4.3.2.1. Attacks using the Locator Status Bits 3.2. Locator Status Bits
When the L bit is set to 1, it indicates that the second 32-bits When the L bit is set to 1, it indicates that the second 32-bits
longword of the LISP header contains the Locator Status Bits. In longword of the LISP header contains the Locator Status Bits. In
this field, each bit position reflects the status of one of the RLOCs this field, each bit position reflects the status of one of the RLOCs
mapped to the source EID found in the encapsulated packet. In mapped to the source EID found in the encapsulated packet. The
particular, a packet with the L bit set and all Locator Status Bits reaction of a LISP xTR that receives such a packet is left as
set to zero indicates that none of the locators of the encapsulated operational choice in [RFC6830].
source EID are reachable. The reaction of a LISP ETR that receives
such a packet is not clearly described in [RFC6830].
An attacker can send a data packet with the L bit set to 1 and some When an attacker sends a LISP encapsulated packet with a crafted LSB
or all Locator Status Bits set to zero. Therefore, by blindly to an xTR, it can influence the xTR's choice of the locators for the
trusting the Locator Status Bits communication going on can be prefix associated to the source EID. In case of an off-path
altered or forced to go through a particular set of locators. attacker, the attacker must inject a forged packet in the network
with a spoofed inner address. An on-path attacker can manipulate the
LSB of legitimate packets passing through it and hence does not need
to use spoofing. Instead of manipulating the LSB field, an on-path
attacker can also obtain the same result of injecting packets with
invalid LSB values by replaying packets.
4.3.2.2. Attacks using the Map-Version bit The LSB field can be leveraged to succeed a DoS attack by either
declaring all RLOCs as unreachable (all LSB set to 0), or by
concentrating all the traffic to one RLOC (e.g., all but one LSB set
to 0) and hence overloading the RLOC concentrating all the traffic
from the xTR, or by forcing packets to be sent to RLOCs that are
actually not reachable (e.g., invert LSB values).
The optional Map-Version bit is used to indicate whether the low- The LSB field can also be used to mount a replay, a packet
order 24 bits of the first 32 bits longword of the LISP header manipulation, or a packet interception and suppression attack.
contain a Source and Destination Map-Version. When a LISP ETR Indeed, if the attacker manages to be on the path between the xTR and
receives a LISP encapsulated packet with the Map-Version bit set to one of the RLOCs specified in the mapping, forcing packets to go via
1, the following actions are taken: that RLOC implies that the attacker will gain access to the packets.
Attacks using the LSB are fundamentally involving a time-shifted mode
of operation as the attack may last as long as the reachability
information gathered from the LSB is used by the xTR to decide the
RLOCs to be used.
3.3. Map-Version
When the Map-Version bit is set to 1, it indicates that the low-order
24 bits of the first 32 bits longword of the LISP header contain a
Source and Destination Map-Version. When a LISP xTR receives a LISP
encapsulated packet with the Map-Version bit set to 1, the following
actions are taken:
o It compares the Destination Map-Version found in the header with o It compares the Destination Map-Version found in the header with
the current version of its own configured EID-to-RLOC mapping, for the current version of its own configured EID-to-RLOC mapping, for
the destination EID found in the encapsulated packet. If the the destination EID found in the encapsulated packet. If the
received Destination Map-Version is smaller (i.e., older) than the received Destination Map-Version is smaller (i.e., older) than the
current version, the ETR should apply the SMR procedure described current version, the ETR should apply the SMR procedure described
in [RFC6830] and send a Map-Request with the SMR bit set. in [RFC6830] and send a Map-Request with the SMR bit set.
o If a mapping exists in the EID-to-RLOC Cache for the source EID, o If a mapping exists in the EID-to-RLOC Cache for the source EID,
then it compares the Map-Version of that entry with the Source then it compares the Map-Version of that entry with the Source
Map-Version found in the header of the packet. If the stored Map-Version found in the header of the packet. If the stored
mapping is older (i.e., the Map-Version is smaller) than the mapping is older (i.e., the Map-Version is smaller) than the
source version of the LISP encapsulated packet, the xTR should source version of the LISP encapsulated packet, the xTR should
send a Map-Request for the source EID. send a Map-Request for the source EID.
An off-path attacker could use the Map-Version bit to force an ETR to A cross-mode attacker can use the Map-Version bit to mount a DoS
send Map-Request messages. The attacker could retrieve the current attack, an amplification attack, or a spoofing attack. For instance
source and destination Map-Version for both HA and HB. Based on this if the mapping cached at the xTR is outdated, the xTR will send a
information, it could send a spoofed packet with an older Source Map- Map-Request to retrieve the new mapping which can yield to a DoS
Version or Destination Map-Version. If the size of the Map-Request attack (by excess of signalling traffic) or an amplification attack
message is larger than the size of the smallest LISP-encapsulated if the data-plane packet sent by the attacker is smaller than the
packet that could trigger such a message, this could lead to control-plane packets sent in response to the attacker's packet.
amplification attacks (see Section 4.4.1) so that more bandwidth is With a spoofing attack and if the xTR considers that the spoofed ITR
consumed on the target (because of the larger packets) than the has an outdated mapping, it will send an SMR to the spoofed ITR which
bandwidth necessary at the attacker side. can result in performance, amplification, or DoS attack as well.
4.3.2.3. Attacks using the Nonce-Present and the Echo-Nonce bits Map-Version attackers are inherently cross mode as the Map-Version is
a method to put control information in the data-plane. Moreover,
this vector involves live attackers. Nevertheless, on-path attackers
do not take specific advantage over off-path attackers.
The Nonce-Present and Echo-Nonce bits are used when verifying the 3.4. Echo-Nonce algorithm
reachability of a remote ETR. Assume that LR3 wants to verify that
LR1 receives the packets that it sends. LR3 can set the Echo-Nonce
and the 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 nonce sent by LR3 and echo it when it
returns LISP encapsulated data packets to LR3.
A spoofing off-path attacker (SA) could interfere with this The Nonce-Present and Echo-Nonce bits are used to verifying the
reachability test by sending two different types of packets: reachability of an xTR. An testing xTR sets the Echo-Nonce and the
Nonce-Present bits in LISP data encapsulated packets and include a
random nonce in the LISP header of packets. Upon reception of these
packets, the tested xTR stores the nonce and echo it whenever it
returns a LISP encapsulated data packets to the testing xTR. The
reception of the echoed nonce confirms that the tested xTR is
reachable.
An attacker can interfere with the reachability test by sending two
different types of packets:
1. LISP data encapsulated packets with the Nonce-Present bit set and 1. LISP data encapsulated packets with the Nonce-Present bit set and
a random nonce and the appropriate source and destination RLOCs. a random nonce. Such packets are normally used in response to a
reachability test.
2. LISP data encapsulated packets with the Nonce-Present and the 2. LISP data encapsulated packets with the Nonce-Present and the
Echo-Nonce bits both set and the appropriate source and Echo-Nonce bits both set. These packets will force the receiving
destination RLOCs. These packets will force the receiving ETR to ETR to store the received nonce and echo it in the LISP
store the received nonce and echo it in the LISP encapsulated encapsulated packets that it sends. These packets are normally
packets that it sends. used as trigger for a reachability test.
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 attack,
the attacker should create a massive amount of packets carrying all
possible nonce values.
The second type of packet could be exploited to attack the nonce- The first type of packets is used to make xTRs think that an other
based reachability test. Consider a spoofing off-path attacker (SA) xTR is reachable while it is not. It is hence a way to mount a DoS
that sends a continuous flow of spoofed LISP data encapsulated attack (i.e., the ITR will send its packet to a non-reachable ETR
packets that contain the Nonce-Present and the Echo-Nonce bit and while it should use another one).
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 depends on the ratio between the
amount of packets sent by the legitimate ITR and the spoofing off-
path attacker (SA).
4.3.2.4. Attacks using the Instance ID bits The second type of packets could be exploited to attack the nonce-
based reachability test. If the attacker sends a continuous flow of
packets that each have a different random nonce, the ETR that
receives such packets will continuously change the nonce that it
returns to the remote ITR, which can yield to a performance attack.
If the remote ITR tries a nonce-reachability test, this test may fail
because the ETR may echo an invalid nonce. This hence yields to a
DoS attack.
LISP allows to carry in its header a 24-bits value called "Instance In the case of an on-path attacker, a packet manipulation attack is
ID" and used on the ITR to indicate which local Instance ID has been necessary to mount the attack. To mount such an attack, an off-path
used for encapsulation, while on the ETR can be used to select the attacker must mount an outer address spoofing attack.
forwarding table used for forwarding the decapsulated packet.
The Instance ID increases exposure to attacks ([RFC6169]) as if an 3.5. Instance ID
off-path attacker can randomly guess a valid Instance ID value to get
access to network that might not been accessible in normal
conditions. However, such attacks target end-systems, which is out
of the scope of this document.
4.4. Attacks using the control-plane LISP allows to carry in its header a 24-bits value called Instance ID
and used on the ITR to indicate which local Instance ID has been used
for encapsulation, while on the ETR the instance ID decides the
forwarding table to use to forward the decapsulated packet in the
LISP site.
In this section, we discuss the different types of attacks that could An attacker (either a control-plane or data-plane attacker) can use
occur when an off-path attacker sends control-plane packets. We the instance ID functionality to mount an intrusion attack.
focus on the packets that are sent directly to the ETR and do not
analyze the particularities of the different LISP indexing sub-
system.
4.4.1. Attacks with Map-Request messages 3.6. Interworking
An off-path attacker could send Map-Request packets to a victim ETR. [RFC6832] defines Proxy-ITR and Proxy-ETR network elements to allow
In theory, a Map-Request packet is only used to solicit an answer and LISP and non-LISP sites to communicate. The Proxy-ITR has
as such it should not lead to security problems. However, the LISP functionality similar to the ITR, however, its main purpose is to
specification [RFC6830] contains several particularities that could encapsulate packets arriving from the DFZ in order to reach LISP
be exploited by an off-path attacker. sites. A Proxy-ETR has functionality similar to the ETR, however,
its main purpose is to inject de-encapsulated packets in the DFZ in
order to reach non-LISP Sites from LISP sites. As a PITR (resp.
PETR) is a particular case of ITR (resp. ETR), it is subject to same
attacks than ITRs (resp. ETR).
The first possible exploitation is the RLOC record P bit. The RLOC As any other system relying on proxies, LISP interworking can be used
record P bit is used to probe the reachability of remote ETRs. In by attackers to hide their exact origin in the network.
our reference environment, LR3 could probe the reachability of LR1 by
sending a Map-Request with the RLOC record P bit set. LR1 would
reply by sending a Map-Reply message with the RLOC record P bit set
and the same nonce as in the Map-Request message.
A spoofing off-path attacker (SA) could use the RLOC record P bit to 3.7. Map-Request messages
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. Map-
Requests are usually smaller than a hundred bytes while the maximum
size of a Map-Reply (without considering any MTU constrain) can be
above 1 MB, largely bigger than the message sent by the attacker.
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, limiting so
the amplification factor.
Similarly, if a non-spoofing off-path attacker (NSA) sends a Map- A control-plane off-path attacker can exploit Map-Request messages to
Request with the RLOC record P bit set, it will receive a Map-Reply mount DoS, performance, or amplification attacks. By sending Map-
with the RLOC record P bit set. Request messages at high rate, the attacker can overload nodes
involved in the mapping system. For instance sending Map-Requests at
high rate can considerably increase the state maintained in a Map-
Resolver or consume CPU cycles on ETRs that have to process the Map-
Request packets they receive in their slow path (i.e., performance or
DoS attack). When the Map-Reply packet is larger than the Map-
Request sent by the attacker, that yields to an amplification attack.
The attacker can combine the attack with a spoofing attack to
overload the node to which the spoofed address is actually attached.
An amplification attack could be launched by a spoofing off-path It is worth to notice that if the attacker sets the P bit in the Map-
attacker (SA) as follows. Consider an attacker SA and EID-Prefix Request, it is legitimate the send the Map-Request directly to the
192.0.2.0/24 and a victim ITR, SA could send spoofed Map-Request ETR instead of passing through the mapping system.
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 back to the victim ITR.
The Map-Request message may also contain the SMR bit. Upon reception The SMR bit can be used to mount a variant of these attacks.
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. Note that according to [RFC6830] the SMR-
triggered Map-Request might be sent through the mapping system,
depending on the number of RLOCs in the locators set. This raises
similar problems as the RLOC record 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.
Furthermore, appending Map-Records to Map-Request messages allows an For efficiency reasons, Map-Records can be appended to Map-Request
off-path attacker to generate a (spoofed or not) Map-Request message messages. When an xTR receives a Map-Request with appended Map-
and include in the Map-Reply portion of the message mapping for EID Records, it does the same operations as for the other Map-Request
prefixes that it does not serve. messages and is so subject to the same attacks. However, it also
installs in its EID-to-RLOC cache the Map-Records contained in the
Map-Request. An attacker can then use this vector to force the
installation of mappings in its target xTR. Consequently, the EID-
to-RLOC cache of the xTR is polluted by potentially forged mappings
allowing the attacker to mount any of the attacks categorized in
Section 2.2 (see Section 3.8 for more details). It is worth to
mention that the attacker does not need to forge the mappings present
in the Map-Request to succeed a performance or DoS attack. Indeed,
if the attacker owns a large enough EID prefix it can de-aggregate it
in many small prefixes, each corresponding to another mapping and it
them in the xTR cache by the mean of the Map-Request.
Moreover, attackers can use Map Resolver and/or Map Server network Moreover, attackers can use Map Resolver and/or Map Server network
elements to perform relay attacks. Indeed, on the one hand, a Map elements to relay its attacks and hide the origin of the attack.
Resolver is used to dispatch Map-Request to the mapping system and, Indeed, on the one hand, a Map Resolver is used to dispatch Map-
on the other hand, a Map Server is used to dispatch Map-Requests Request to the mapping system and, on the other hand, a Map Server is
coming from the mapping system to ETRs that are authoritative for the used to dispatch Map-Requests coming from the mapping system to ETRs
EID in the Map-Request. that are authoritative for the EID in the Map-Request.
4.4.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. 3.8. Map-Reply messages
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 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- nonce that is included in a Map-Request and returned in the Map-
Reply. If an ETR does not accept Map-Reply messages with an invalid Reply. 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 nonce, the risk of attack is limited given the size of the nonce (64
(64 bits). However, the nonce only confirms that the Map-Reply bits). Nevertheless, the nonce only confirms that the Map-Reply
received was sent in response to a Map-Request sent, it does not received was sent in response to a Map-Request sent, it does not
validate the contents of that Map-Reply. validate the contents of that Map-Reply.
In addition, an attacker could perform EID-to-RLOC Cache overflow If an attacker manages to send a valid (i.e., in response to a Map-
attack by de-aggregating (i.e., splitting an EID prefix into Request and with the correct nonce) Map-Reply to an ITR, then it can
artificially smaller EID prefixes) either positive or negative perform any of the attack categorised in Section 2.2 as it can inject
mappings. forged mappings directly in the ITR EID-to-RLOC cache. For instance,
if the mapping injected to the ITR points to the address of a node
controlled by the attacker, it can mount replay, packet manipulation,
packet interception and suppression, or DoS attacks as it will
receive every packet destined to a destination lying in the EID
prefix of the injected mapping. In addition, the attacker can inject
plethora of mappings in the ITR to mount an performance attack by
filling up the EID-to-RLOC cache of the ITR. If the attacker can
also mount an amplification attack as soon as the ITR has to send a
lot of packets to the EIDs matching the injected mapping. In this
case, the RLOC address associated to the mapping is the address of
the real target of the attacker and all the traffic of the ITR will
be sent to the target which means that with one single packet the
attacker may generate very high traffic towards its final target.
In presence of malicious ETRs, overclaiming attacks are possible. If the attacker is a valid ETR in the system it can mount a rogue
Such an attack happens when and ETR replies to a legitimate Map- attack if it uses prefixes over-claiming. In such a scenario, the
Request message it received with a Map-Reply message that contains an attacker ETR replies to a legitimate Map-Request message it received
EID-Prefix that is larger than the prefix owned by the site that with a Map-Reply message that contains an EID-Prefix that is larger
encompasses the EID of the Map-Request. For instance if the prefix than the prefix owned by the attacker. For instance if the owned
owned by the site is 192.0.2.0/25 but the Map-Reply contains a prefix is 192.0.2.0/25 but the Map-Reply contains a mapping for
mapping for 192.0.2.0/24, then the mapping will influence packets 192.0.2.0/24, then the mapping will influence packets destined to
destined to other EIDs than the one the LISP site has authority on. other EIDs than the one attacker has authority on. With such
technique, the attacker can mount the attacks presented above as it
can (partially) control the mappings installed on its target ITR. To
force its target ITR to send a Map-Request, nothing prevents the
attacker to initiate some communication with the ITR. This method is
particularly interesting for internal attackers that want to control
the mappings installed in their site. To that aim, they simply have
to collude with an external attacker ready to over-claim prefixes on
behalf of the internal attacker.
A malicious ETR might also fragment its configured EID-to-RLOC It is worth to notice that when the Map-Reply is in response to a
mappings so that ITR's might have to install much more mappings than Map-Request sent via the mapping system (i.e., not send directly from
really necessary. This attack is called de-aggregation attack. the ITR to an ETR), the attacker does not need to use a spoofing
attack to succeed its attack as by design the source IP address of a
Map-Reply is not known in advance by the ITR.
4.4.3. Attacks with Map-Register messages Map-Request and Map-Reply messages are at the mercy of any type of
attackers, on-path or off-path but also external or internal
attackers. Also, even though they are control message, they can be
leveraged by data-plane attackers. As the decision of removing
mappings is based on the TTL indicated in the mapping, time-shifted
attackers can take benefit of injecting forged mappings as well.
3.9. Map-Register messages
Map-Register messages are sent by ETRs to indicate to the mapping Map-Register messages are sent by ETRs to indicate to the mapping
system the EID prefixes associated to them. The Map-Register message system the EID prefixes associated to them. The Map-Register message
provides an EID prefix and the list of ETRs that are able to provide provides an EID prefix and the list of ETRs that are able to provide
Map-Replies for the EID covered by the EID prefix. Map-Replies for the EID covered by the EID prefix.
As Map-Register messages are protected by an authentication As Map-Register messages are protected by an authentication
mechanism, only a compromised ETR can register itself to its mechanism, only a compromised ETR can register itself to its
allocated Map Server. allocated Map Server.
A compromised ETR can perform an overclaiming attack in order to A compromised ETR can over-claim the prefix it owns in order to
influence the route followed by Map-Requests for EIDs outside the influence the route followed by Map-Requests for EIDs outside the
scope of its legitimate EID prefix. scope of its legitimate EID prefix (see Section 3.8 for the list of
attacks opened by over-claiming).
A compromised ETR can also perform a deaggregation attack in order to A compromised ETR can also de-aggregate its EID prefix in order to
register more EID prefixes than necessary to its Map Servers. register more EID prefixes than necessary to its Map Servers (see
Section 3.7 for the impact of de-aggregation of prefixes by an
attacker).
Similarly, a compromised Map Server can accept invalid registration Similarly, a compromised Map Server can accept invalid registration
or advertise invalid EID prefix to the indexing sub-system. or advertise invalid EID prefix to the mapping system.
4.4.4. Attacks with Map-Notify messages 3.10. Map-Notify messages
Map-Notify messages are sent by a Map Server to an ETR to acknowledge Map-Notify messages are sent by a Map Server to an ETR to acknowledge
the good reception and processing of a Map-Register message. the good reception and processing of a Map-Register message.
A compromised ETR using EID that it is not authoritative for can send Similarly to the pair Map-Request/Map-Reply, the pair Map-Register/
a Map-Register with the M-bit set and a spoofed source address to Map-Notify is protected by a nonce making it hard for an attacker to
force the Map Server to send a Map-Notify message to the spoofed inject a falsified notification to an ETR to make this ETR believe
address and then succeed a relay attack. Similarly to the pair Map- that the registration succeeded while it has not.
Request/Map-Reply, the pair Map-Register/Map-Notify is protected by a
nonce making it hard for an attacker to inject a falsified
notification to an ETR to make this ETR believe that the registration
succeeded while it has not.
5. Attack categories
5.1. Intrusion
5.1.1. Description
With an intrusion attack an attacker gains remote access to some
resources (e.g., a host, a router, or a network) that are normally
denied to her.
5.1.2. Vectors
Intrusion attacks can be mounted using:
o Spoofing EID or RLOCs
o Instance ID bits
5.2. Denial of Service (DoS)
5.2.1. Description
A Denial of Service (DoS) attack aims at disrupting a specific
targeted service either by exhausting the resources of the victim up
to the point that it is not able to provide a reliable service to
legit traffic and/or systems or by exploiting vulnerabilities to make
the targeted service unable to operate properly.
5.2.2. Vectors
Denial of Service attacks can be 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
5.3. Subversion
5.3.1. Description
With subversion an attacker can gain access (e.g., using
eavesdropping or impersonation) to 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 the target does not even notice the attack. When
the attacker is positioned on the path of the target traffic, it is
called a 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 even re-direct the traffic, in
both cases having access to the raw packets.
5.3.2. Vectors
Subversion 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
6. Note on Privacy 4. Note on Privacy
As presented by [RFC6973], universal privacy considerations are As presented by [RFC6973], universal privacy considerations are
impossible to establish as the privacy definition may vary from one impossible to establish as the privacy definition may vary from one
to another. As a consequence, this document does not aim at to another. As a consequence, this document does not aim at
identifying privacy issues related to the LISP protocol but it is identifying privacy issues related to the LISP protocol but it is
necessary to highlight that security threats identified in this necessary to highlight that security threats identified in this
document could play a role in privacy threats as defined in section 5 document could play a role in privacy threats as defined in section 5
of [RFC6973]. of [RFC6973].
7. IANA Considerations Note, however, that like public deployments of any other control
plane protocol, in an Internet deployment mappings are public and
hence provide information about the infrastructure and reachability
of LISP sites (i.e., the addresses of the edge routers).
5. IANA Considerations
This document makes no request to IANA. This document makes no request to IANA.
8. Security Considerations 6. Security Considerations
This document is devoted to threat analysis of the Locator/Identifier This document is devoted to threat analysis of the Locator/Identifier
Separation Protocol and is then a piece of choice to understand the Separation Protocol and is then a piece of choice to understand the
security risks at stake while deploying LISP in non-trustable security risks at stake while deploying LISP in non-trustable
environment. environment.
The purpose of this document is not to provide recommendations to The purpose of this document is not to provide recommendations to
protect against attacks, however most of threats can be prevented protect against attacks, however most of threats can be prevented
with careful deployment and configuration (e.g., filter) and also by with careful deployment and configuration (e.g., filter) and also by
applying the general rules in security that consist in activating applying the general rules in security that consist in activating
only features that are necessary in the deployment and verifying the only features that are necessary in the deployment and verifying the
validity of the information obtained from third parties. More validity of the information obtained from third parties. More
detailed recommendations are given in [Saucez13]. detailed recommendations are given in [Saucez13].
The control-plane is probably the most critical part of LISP from a The control-plane is probably the most critical part of LISP from a
security viewpoint and it is worth to notice that the specifications security viewpoint and it is worth to notice that the specifications
already offer authentication mechanism for Map-Register messages already offer authentication mechanism for Map-Register messages
([RFC6833]) and that [I-D.ietf-lisp-sec] and [I-D.ietf-lisp-ddt] are ([RFC6833]) and that [I-D.ietf-lisp-sec] and [I-D.ietf-lisp-ddt] are
clearly going in the direction of a secure control-plane. clearly going in the direction of a secure control-plane.
9. Acknowledgments 7. Acknowledgments
This document builds upon the draft of Marcelo Bagnulo This document builds upon the draft of Marcelo Bagnulo
([I-D.bagnulo-lisp-threat]), where the flooding attack and the ([I-D.bagnulo-lisp-threat]), where the flooding attack and the
reference environment were first described. reference environment were first described.
The authors would like to thank Ronald Bonica, Albert Cabellos, Noel The authors would like to thank Ronald Bonica, Albert Cabellos, Ross
Chiappa, Florin Coras, Vina Ermagan, Dino Farinacci, Stephen Farrell, Callon, Noel Chiappa, Florin Coras, Vina Ermagan, Dino Farinacci,
Joel Halpern, Emily Hiltzik, Darrel Lewis, Edward Lopez, Fabio Maino, Stephen Farrell, Joel Halpern, Emily Hiltzik, Darrel Lewis, Edward
Terry Manderson, and Jeff Wheeler for their comments. Lopez, Fabio Maino, Terry Manderson, and Jeff Wheeler for their
comments.
This work has been partially supported by the INFSO-ICT-216372 This work has been partially supported by the INFSO-ICT-216372
TRILOGY Project (www.trilogy-project.org). TRILOGY Project (www.trilogy-project.org).
The work of Luigi Iannone has been partially supported by the ANR-13- The work of Luigi Iannone has been partially supported by the ANR-13-
INFR-0009 LISP-Lab Project (www.lisp-lab.org) and the EIT KIC ICT- INFR-0009 LISP-Lab Project (www.lisp-lab.org) and the EIT KIC ICT-
Labs SOFNETS Project. Labs SOFNETS Project.
10. References 8. References
10.1. Normative References
[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security 8.1. Normative References
Concerns with IP Tunneling", RFC 6169, April 2011.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830, Locator/ID Separation Protocol (LISP)", RFC 6830,
January 2013. January 2013.
[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
"Interworking between Locator/ID Separation Protocol "Interworking between Locator/ID Separation Protocol
(LISP) and Non-LISP Sites", RFC 6832, January 2013. (LISP) and Non-LISP Sites", RFC 6832, January 2013.
[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation
skipping to change at page 17, line 40 skipping to change at page 16, line 40
[RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
Separation Protocol (LISP) Map-Versioning", RFC 6834, Separation Protocol (LISP) Map-Versioning", RFC 6834,
January 2013. January 2013.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, Considerations for Internet Protocols", RFC 6973,
July 2013. July 2013.
10.2. Informative References 8.2. Informative References
[Florin13]
Coras, F., Domingo-Pascual, J., Lewis, D., and A.
Cabellos-Aparicio, "An Analytical Model for Loc/ID
Mappings Caches", Technical Report. arXiv:1312.1378v2,
2013, <http://arxiv.org/pdf/1312.1378v2.pdf>.
[I-D.bagnulo-lisp-threat] [I-D.bagnulo-lisp-threat]
Bagnulo, M., "Preliminary LISP Threat Analysis", Bagnulo, M., "Preliminary LISP Threat Analysis",
draft-bagnulo-lisp-threat-01 (work in progress), draft-bagnulo-lisp-threat-01 (work in progress),
July 2007. July 2007.
[I-D.ietf-lisp-ddt] [I-D.ietf-lisp-ddt]
Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP
Delegated Database Tree", draft-ietf-lisp-ddt-01 (work in Delegated Database Tree", draft-ietf-lisp-ddt-01 (work in
progress), March 2013. progress), March 2013.
[I-D.ietf-lisp-deployment]
Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-
Pascual, J., and D. Lewis, "LISP Network Element
Deployment Considerations", draft-ietf-lisp-deployment-12
(work in progress), January 2014.
[I-D.ietf-lisp-sec] [I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D., Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
and O. Bonaventure, "LISP-Security (LISP-SEC)", Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-06
draft-ietf-lisp-sec-05 (work in progress), October 2013. (work in progress), April 2014.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-
Internet Protocol", RFC 4301, December 2005. Pascual, J., and D. Lewis, "Locator/Identifier Separation
Protocol (LISP) Network Element Deployment
Considerations", RFC 7215, April 2014.
[Saucez13] [Saucez13]
Saucez, D., Iannone, L., and O. Bonaventure, "The Map-and- Saucez, D., Iannone, L., and O. Bonaventure, "The Map-and-
Encap Locator/Identifier separation paradigm: a Security Encap Locator/Identifier separation paradigm: a Security
Analysis", Solutions for Sustaining Scalability in Analysis", Solutions for Sustaining Scalability in
Internet Growth, IGI Global, 2013. Internet Growth, IGI Global, 2013.
Appendix A. Document Change Log Appendix A. Document Change Log
o Version 10 Posted July 2014.
* Document completely remodeled according to the discussions on
the mailing list in the thread
http://www.ietf.org/mail-archive/web/lisp/current/msg05206.html
and to address comments from Ronald Bonica and Ross Callon.
o Version 09 Posted March 2014. o Version 09 Posted March 2014.
* Updated document according to the review of A. Cabellos. * Updated document according to the review of A. Cabellos.
o Version 08 Posted October 2013. o Version 08 Posted October 2013.
* Addition of a privacy consideration note. * Addition of a privacy consideration note.
* Editorial changes * Editorial changes
skipping to change at page 19, line 49 skipping to change at page 18, line 49
* Deleted/Modified sentences referring to the early status of the * Deleted/Modified sentences referring to the early status of the
LISP WG and documents at the time of writing early versions of LISP WG and documents at the time of writing early versions of
the document. the document.
* Further editorial polishing. * Further editorial polishing.
* Fixed all ID nits. * Fixed all ID nits.
o Version 02 Posted September 2012. o Version 02 Posted September 2012.
* Added a new attack that combines overclaiming and de- * Added a new attack that combines over-claiming and de-
aggregation (see Section 4.4.2). aggregation (see Section 3.8).
* Editorial polishing. * Editorial polishing.
o Version 01 Posted February 2012. o Version 01 Posted February 2012.
* Added discussion on LISP-DDT. * Added discussion on LISP-DDT.
o Version 00 Posted July 2011. o Version 00 Posted July 2011.
* Added discussion on LISP-MS>. * Added discussion on LISP-MS>.
* Added discussion on Instance ID in Section 4.3.2. * Added discussion on Instance ID.
* Editorial polishing of the whole document. * Editorial polishing of the whole document.
* Added "Change Log" appendix to keep track of main changes. * Added "Change Log" appendix to keep track of main changes.
* Renamed "draft-saucez-lisp-security-03.txt. * Renamed "draft-saucez-lisp-security-03.txt.
Authors' Addresses Authors' Addresses
Damien Saucez Damien Saucez
 End of changes. 108 change blocks. 
548 lines changed or deleted 503 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/