draft-ietf-lisp-threats-15.txt   rfc7835.txt 
Network Working Group D. Saucez Internet Engineering Task Force (IETF) D. Saucez
Internet-Draft INRIA Request for Comments: 7835 INRIA
Intended status: Informational L. Iannone Category: Informational L. Iannone
Expires: August 1, 2016 Telecom ParisTech ISSN: 2070-1721 Telecom ParisTech
O. Bonaventure O. Bonaventure
Universite catholique de Louvain Universite catholique de Louvain
January 29, 2016 April 2016
LISP Threats Analysis Locator/ID Separation Protocol (LISP) Threat Analysis
draft-ietf-lisp-threats-15.txt
Abstract Abstract
This document provides a threat analysis of the Locator/Identifier This document provides a threat analysis of the Locator/ID Separation
Separation Protocol (LISP). Protocol (LISP).
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for informational purposes.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on August 1, 2016. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7835.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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. Threat model . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Attacker's Operation Modes . . . . . . . . . . . . . . . . 4 2.1. Operation Modes of Attackers . . . . . . . . . . . . . . 4
2.1.1. On-path vs. Off-path Attackers . . . . . . . . . . . . 4 2.1.1. On-Path vs. Off-Path Attackers . . . . . . . . . . . 4
2.1.2. Internal vs. External Attackers . . . . . . . . . . . 4 2.1.2. Internal vs. External Attackers . . . . . . . . . . . 4
2.1.3. Live vs. Time-shifted attackers . . . . . . . . . . . 5 2.1.3. Live vs. Time-Shifted Attackers . . . . . . . . . . . 5
2.1.4. Control-plane vs. Data-plane attackers . . . . . . . . 5 2.1.4. Control-Plane vs. Data-Plane Attackers . . . . . . . 5
2.1.5. Cross mode attackers . . . . . . . . . . . . . . . . . 5 2.1.5. Cross-Mode Attackers . . . . . . . . . . . . . . . . 5
2.2. Threat categories . . . . . . . . . . . . . . . . . . . . 5 2.2. Threat Categories . . . . . . . . . . . . . . . . . . . . 5
2.2.1. Replay attack . . . . . . . . . . . . . . . . . . . . 5 2.2.1. Replay Attack . . . . . . . . . . . . . . . . . . . . 5
2.2.2. Packet manipulation . . . . . . . . . . . . . . . . . 6 2.2.2. Packet Manipulation . . . . . . . . . . . . . . . . . 6
2.2.3. Packet interception and suppression . . . . . . . . . 6 2.2.3. Packet Interception and Suppression . . . . . . . . . 6
2.2.4. Spoofing . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.4. Spoofing . . . . . . . . . . . . . . . . . . . . . . 6
2.2.5. Rogue attack . . . . . . . . . . . . . . . . . . . . . 7 2.2.5. Rogue Attack . . . . . . . . . . . . . . . . . . . . 7
2.2.6. Denial of Service (DoS) attack . . . . . . . . . . . . 7 2.2.6. Denial-of-Service (DoS) Attack . . . . . . . . . . . 7
2.2.7. Performance attack . . . . . . . . . . . . . . . . . . 7 2.2.7. Performance Attack . . . . . . . . . . . . . . . . . 7
2.2.8. Intrusion attack . . . . . . . . . . . . . . . . . . . 7 2.2.8. Intrusion Attack . . . . . . . . . . . . . . . . . . 7
2.2.9. Amplification attack . . . . . . . . . . . . . . . . . 7 2.2.9. Amplification Attack . . . . . . . . . . . . . . . . 7
2.2.10. Passive Monitoring Attacks . . . . . . . . . . . . . . 8 2.2.10. Passive Monitoring Attacks . . . . . . . . . . . . . 7
2.2.11. Multi-category attacks . . . . . . . . . . . . . . . . 8 2.2.11. Multi-category Attacks . . . . . . . . . . . . . . . 8
3. Attack vectors . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Attack Vectors . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Gleaning . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Gleaning . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Locator Status Bits . . . . . . . . . . . . . . . . . . . 9 3.2. Locator Status Bits . . . . . . . . . . . . . . . . . . . 9
3.3. Map-Version . . . . . . . . . . . . . . . . . . . . . . . 10 3.3. Map-Version . . . . . . . . . . . . . . . . . . . . . . . 10
3.4. Routing Locator Reachability . . . . . . . . . . . . . . . 11 3.4. Routing Locator Reachability . . . . . . . . . . . . . . 11
3.5. Instance ID . . . . . . . . . . . . . . . . . . . . . . . 12 3.5. Instance ID . . . . . . . . . . . . . . . . . . . . . . . 12
3.6. Interworking . . . . . . . . . . . . . . . . . . . . . . . 12 3.6. Interworking . . . . . . . . . . . . . . . . . . . . . . 12
3.7. Map-Request messages . . . . . . . . . . . . . . . . . . . 12 3.7. Map-Request Messages . . . . . . . . . . . . . . . . . . 12
3.8. Map-Reply messages . . . . . . . . . . . . . . . . . . . . 13 3.8. Map-Reply Messages . . . . . . . . . . . . . . . . . . . 13
3.9. Map-Register messages . . . . . . . . . . . . . . . . . . 15 3.9. Map-Register Messages . . . . . . . . . . . . . . . . . . 15
3.10. Map-Notify messages . . . . . . . . . . . . . . . . . . . 15 3.10. Map-Notify Messages . . . . . . . . . . . . . . . . . . . 15
4. Note on Privacy . . . . . . . . . . . . . . . . . . . . . . . 15 4. Note on Privacy . . . . . . . . . . . . . . . . . . . . . . . 15
5. Threats Mitigation . . . . . . . . . . . . . . . . . . . . . . 16 5. Threat Mitigation . . . . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 7.1. Normative References . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.2. Informative References . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
Appendix A. Document Change Log (to be removed on publication) . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
The Locator/ID Separation Protocol (LISP) is specified in [RFC6830]. The Locator/ID Separation Protocol (LISP) is specified in [RFC6830].
This document provides an assessment of the potential security This document provides an assessment of the potential security
threats for the current LISP specifications if LISP is deployed in threats for the current LISP specifications if LISP is deployed in
the Internet (i.e., a public non-trustable environment). the Internet (i.e., a public non-trustable environment).
The document is composed of three main parts: the first defines a The document is composed of three main parts. The first part defines
general threat model that attackers use to mount attacks. The second a general threat model that attackers use to mount attacks. The
part, using this threat model, describes the techniques based on the second part, using this threat model, describes the techniques based
LISP protocol and LISP architecture that attackers may use to on LISP and its architecture that attackers may use to construct
construct attacks. The third part discusses mitigation techniques attacks. The third part discusses mitigation techniques and general
and general solutions to protect the LISP protocol and architecture solutions to protect LISP and its architecture from attacks.
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 [RFC7215] and does not cover threats due discussed in [RFC6830] and [RFC7215] and does not cover threats due
to specific implementations. The document focuses on LISP unicast, to specific implementations. The document focuses on LISP unicast,
including as well LISP Interworking [RFC6832], LISP Map-Server including as well LISP Interworking [RFC6832], LISP Map-Server
[RFC6833]), and LISP Map-Versioning [RFC6834]. Additional threats [RFC6833], and LISP Map-Versioning [RFC6834]. Additional threats may
may be discovered in the future while deployment continues. The be discovered in the future while deployment continues. The reader
reader is assumed to be familiar with these documents for is assumed to be familiar with these documents for understanding the
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. Threat model 2. Threat Model
This document assumes that attackers can be located anywhere in the This document assumes that attackers can be located anywhere in the
Internet (either in LISP sites or outside LISP sites) and that Internet (either in LISP sites or outside LISP sites) and that
attacks can be mounted either by a single attacker or by the attacks can be mounted either by a single attacker or by the
collusion of several attackers. collusion of several attackers.
An attacker is a malicious entity that performs the action of An attacker is a malicious entity that performs the action of
attacking a target in a network where LISP is (partially) deployed by attacking a target in a network where LISP is (partially) deployed by
leveraging the LISP protocol and/or architecture. leveraging LISP and/or its architecture.
An attack is the action of performing an illegitimate action on a An attack is the action of performing an illegitimate action on a
target in a network where LISP is (partially) deployed. target in a network where LISP is (partially) deployed.
The target of an attack is the entity (i.e., a device connected to The target of an attack is the entity (i.e., a device connected to
the network or a network) that is aimed to undergo the consequences the network or a network) that is aimed to undergo the consequences
of an attack. Other entities can potentially undergo side effects of of an attack. Other entities can potentially undergo side effects of
an attack, even though they are not directly targeted by the attack. an attack, even though they are not directly targeted by the attack.
The target of an attack can be selected specifically, i.e., a The target of an attack can be selected specifically, i.e., a
particular entity, or arbitrarily, i.e., any entity. Finally, an particular entity, or arbitrarily, i.e., any entity. Finally, an
attacker can aim at attacking one or several targets with a single attacker can aim to attack one or several targets with a single
attack. attack.
Section 2.1 specifies the different modes of operation that attackers Section 2.1 specifies the different modes of operation that attackers
can follow to mount attacks and Section 2.2 specifies the different can follow to mount attacks, and Section 2.2 specifies the different
categories of attacks that attackers can build. categories of attacks that attackers can build.
2.1. Attacker's Operation Modes 2.1. Operation Modes of Attackers
In this document attackers are classified according to their modes of In this document, attackers are classified according to their modes
operation, i.e., the temporal and spacial diversity of the attacker. of operation, i.e., the temporal and spacial diversity of the
These modes are not mutually exclusive, they can be used by attackers attacker. These modes are not mutually exclusive; they can be used
in any combination, and other modes may be discovered in the future. by attackers in any combination, and other modes may be discovered in
Further, attackers are not at all bound by our classification scheme, the future. Further, attackers are not at all bound by our
so implementers and those deploying will always need to do additional classification scheme, so implementers and those deploying will
risk analysis for themselves. always need to do additional risk analysis for themselves.
2.1.1. On-path vs. Off-path Attackers 2.1.1. On-Path vs. Off-Path Attackers
On-path attackers, also known as Men-in-the-Middle, are able to On-path attackers, also known as Men-in-the-Middle, are able to
intercept and modify packets between legitimate communicating intercept and modify packets between legitimate communicating
entities. On-path attackers are located either directly on the entities. On-path attackers are located either directly on the
normal communication path (either by gaining access to a node 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 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 location path but manage to deviate (or gain a copy of) packets sent
between the communication entities. On-path attackers hence mount between the communication entities. On-path attackers hence mount
their attacks by modifying packets initially sent legitimately their attacks by modifying packets initially sent legitimately
between communication entities. between communication entities.
An attacker is called off-path attacker if it does not have access to An attacker is called an off-path attacker if it does not have access
packets exchanged during the communication or if there is no to packets exchanged during the communication or if there is no
communication. In order for their attacks to succeed, off-path communication. In order for their attacks to succeed, off-path
attackers must hence generate packets and inject them in the network. attackers must hence generate packets and inject them in the network.
2.1.2. Internal vs. External Attackers 2.1.2. Internal vs. External Attackers
An internal attacker launches its attack from a node located within a An internal attacker launches its attack from a node located within a
legitimate LISP site. Such an attacker is either a legitimate node legitimate LISP site. Such an attacker is either a legitimate node
of the site or it exploits a vulnerability to gain access to a of the site or it exploits a vulnerability to gain access to a
legitimate node in the site. Because of their location, internal legitimate node in the site. Because of their location, internal
attackers are trusted by the site they are in. attackers are trusted by the site they are in.
On the contrary, an external attacker launches its attacks from the On the contrary, an external attacker launches its attacks from the
outside of a legitimate LISP site. outside of a legitimate LISP site.
2.1.3. Live vs. Time-shifted attackers 2.1.3. Live vs. Time-Shifted Attackers
A live attacker mounts attacks for which it must remain connected as A live attacker mounts attacks for which it must remain connected as
long as the attack is mounted. In other words, the attacker must long as the attack is mounted. In other words, the attacker must
remain active for the whole duration of the attack. Consequently, remain active for the whole duration of the attack. Consequently,
the attack ends as soon as the attacker (or the used attack vector) the attack ends as soon as the attacker (or the used attack vector)
is neutralized. is neutralized.
On the contrary, a time-shifted attacker mounts attacks that remain On the contrary, a time-shifted attacker mounts attacks that remain
active after it disconnects from the Internet. active after it disconnects from the Internet.
2.1.4. Control-plane vs. Data-plane attackers 2.1.4. Control-Plane vs. Data-Plane Attackers
A control-plane attacker mounts its attack by using control-plane A control-plane attacker mounts its attack by using control-plane
functionalities, typically the mapping system. functionalities, typically the mapping system.
A data-plane attacker mounts its attack by using data-plane A data-plane attacker mounts its attack by using data-plane
functionalities. functionalities.
As there is no complete isolation between the control-plane and the As there is no complete isolation between the control plane and the
data-plane, an attacker can operate in the control-plane (or data- data plane, an attacker can operate in the control plane (or data
plane) to mount attacks targeting the data-plane (or control-plane) plane) to mount attacks targeting the data plane (or control plane)
or keep the attacked and targeted planes at the same layer (i.e., 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- from control plane to control plane or from data plane to data
plane). plane).
2.1.5. Cross mode attackers 2.1.5. Cross-Mode Attackers
The attacker modes of operation are not mutually exclusive and hence The modes of operation used by attackers are not mutually exclusive;
attackers can combine them to mount attacks. hence, attackers can combine them to mount attacks.
For example, an attacker can launch an attack using the control-plane For example, an attacker can launch an attack using the control plane
directly from within a LISP site to which it is able to get temporary directly from within a LISP site to which it is able to get temporary
access (i.e., internal + control-plane attacker) to create a access (i.e., internal + control-plane attacker) to create a
vulnerability on its target and later on (i.e., time-shifted + vulnerability on its target and later on (i.e., time-shifted +
external attacker) mount an attack on the data plane (i.e., data- external attacker) mount an attack on the data plane (i.e., data-
plane attacker) that leverages the vulnerability. plane attacker) that leverages the vulnerability.
2.2. Threat categories 2.2. Threat Categories
Attacks can be classified according to the nine following categories. Attacks can be classified according to the eleven following
These categories are not mutually exclusive and can be used by categories. These categories are not mutually exclusive and can be
attackers in any combination. used by attackers in any combination.
2.2.1. Replay attack 2.2.1. Replay Attack
A replay attack happens when an attacker retransmits at a later time, A replay attack happens when an attacker retransmits a packet (or a
and without modifying it, a packet (or a sequence of packets) that sequence of packets) without modifying it.
has already been transmitted.
2.2.2. Packet manipulation 2.2.2. Packet Manipulation
A packet manipulation attack happens when an attacker receives a A packet manipulation attack happens when an attacker receives a
packet, modifies the packet (i.e., changes some information contained packet, modifies the packet (i.e., changes some information contained
in the packet) and finally transmits the packet to its final in the packet), and finally transmits the packet to its final
destination that can be the initial destination of the packet or a destination, which can be the initial destination of the packet or a
different one. different one.
2.2.3. Packet interception and suppression 2.2.3. Packet Interception and Suppression
In a packet interception and suppression attack, the attacker In a packet interception and suppression attack, the attacker
captures the packet and drops it before it can reach its final captures the packet and drops it before it can reach its final
destination. destination.
2.2.4. Spoofing 2.2.4. Spoofing
With a spoofing attack, the attacker injects packets in the network With a spoofing attack, the attacker injects packets in the network
pretending to be another node. Spoofing attacks are made by forging pretending to be another node. Spoofing attacks are made by forging
source addresses in packets. source addresses in packets.
It should be noted that with LISP, packet spoofing is similar to It should be noted that with LISP, packet spoofing is similar to
spoofing with any other existing tunneling technology currently spoofing with any other existing tunneling technology currently
deployed in the Internet. Generally the term "spoofed packet" deployed in the Internet. Generally, the term "spoofed packet"
indicates a packet containing a source IP address that is not the indicates a packet containing a source IP address that is not the
actual originator of the packet. Hence, since LISP uses actual originator of the packet. Hence, since LISP uses
encapsulation, the spoofed address could be in the outer header as encapsulation, the spoofed address could be in the outer header as
well as in the inner header, this translates to two types of well as in the inner header; this translates to two types of
spoofing. spoofing.
Inner address spoofing: the attacker uses encapsulation and uses a Inner address spoofing: The attacker uses encapsulation and uses a
spoofed source address in the inner packet. In case of data- spoofed source address in the inner packet. In case of data-plane
plane LISP encapsulation, that corresponds to spoofing the LISP encapsulation, that corresponds to spoofing the source
source EID (End-point IDentifier) address of the encapsulated Endpoint Identifier (EID) address of the encapsulated packet.
packet.
Outer address spoofing: the attacker does not use encapsulation and Outer address spoofing: The attacker does not use encapsulation and
spoofs the source address of the packet. In case of data-plane spoofs the source address of the packet. In case of data-plane
LISP encapsulation, that corresponds to spoofing the source LISP encapsulation, that corresponds to spoofing the source
RLOC (Routing LOCator) address of the encapsulated packet. Routing Locator (RLOC) address of the encapsulated packet.
Note that the two types of spoofing are not mutually exclusive, Note that the two types of spoofing are not mutually exclusive;
rather all combinations are possible and could be used to perform rather, all combinations are possible and could be used to perform
different kinds of attacks. For example, an attacker outside a LISP different kinds of attacks. For example, an attacker outside a LISP
site can generate a packet with a forged source IP address (i.e., site can generate a packet with a forged source IP address (i.e.,
outer address spoofing) and forward it to a LISP destination. The outer address spoofing) and forward it to a LISP destination. The
packet is then eventually encapsulated by a PITR (Proxy Ingress packet is then eventually encapsulated by a Proxy Ingress Tunnel
Tunnel Router) so that once encapsulated the attack corresponds to a Router (PITR) so that once encapsulated, the attack corresponds to an
inner address spoofing. One can also imagine an attacker forging a inner address spoofing. One can also imagine an attacker forging a
packet with encapsulation where both inner and outer source addresses packet with encapsulation where both inner and outer source addresses
are spoofed. are spoofed.
It is important to note that the combination of inner and outer It is important to note that the combination of inner and outer
spoofing makes the identification of the attacker complex as the spoofing makes the identification of the attacker complex as the
packet may not contain information that allows to detect the origin packet may not contain information that allows detection of the
of the attack. origin of the attack.
2.2.5. Rogue attack 2.2.5. Rogue Attack
In a rogue attack the attacker manages to appear as a legitimate In a rogue attack, the attacker manages to appear as a legitimate
source of information, without faking its identity (as opposed to a source of information, without faking its identity (as opposed to a
spoofing attacker). spoofing attacker).
2.2.6. Denial of Service (DoS) attack 2.2.6. Denial-of-Service (DoS) Attack
A Denial of Service (DoS) attack aims at disrupting a specific A DoS attack aims to disrupt a specific targeted service to make it
targeted service to make it unable to operate properly. unable to operate properly.
2.2.7. Performance attack 2.2.7. Performance Attack
A performance attacks aims at exploiting computational resources A performance attack aims to exploit computational resources (e.g.,
(e.g., memory, processor) of a targeted node so as to make it unable memory, processor) of a targeted node so as to make it unable to
to operate properly. operate properly.
2.2.8. Intrusion attack 2.2.8. Intrusion Attack
In an intrusion attack, the attacker gains remote access to a In an intrusion attack, the attacker gains remote access to a
resource (e.g., a host, a router, or a network) or information that resource (e.g., a host, a router, or a network) or information that
it legitimately should not have access. Intrusion attacks can lead it legitimately should not have accessed. Intrusion attacks can lead
to privacy leakages. to privacy leakages.
2.2.9. Amplification attack 2.2.9. Amplification Attack
In an amplification attack, the traffic generated by the target of 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 attack in response to the attack is larger than the traffic that
the attacker must generate. the attacker must generate.
In some cases, the data-plane can be several orders of magnitude In some cases, the data plane can be several orders of magnitude
faster than the control-plane at processing packets. This difference faster than the control plane at processing packets. This difference
can be exploited to overload the control-plane via the data-plane can be exploited to overload the control plane via the data plane
without overloading the data-plane. without overloading the data plane.
2.2.10. Passive Monitoring Attacks 2.2.10. Passive Monitoring Attacks
An attacker can use pervasive monitoring, which is a technical attack An attacker can use pervasive monitoring, which is a technical attack
[RFC7258], targeting information about LISP traffic that may or not [RFC7258] that targets information about LISP traffic that may or may
be used to mount other type of attacks. not be used to mount other types of attacks.
2.2.11. Multi-category attacks 2.2.11. Multi-category Attacks
Attacks categories are not mutually exclusive and any combination can Attack categories are not mutually exclusive, and any combination can
be used to perform specific attacks. be used to perform specific attacks.
For example, one can mount a rogue attack to perform a performance For example, one can mount a rogue attack to perform a performance
attack starving the memory of an ITR (Ingress Tunnel Router) attack starving the memory of an Ingress Tunnel Router (ITR)
resulting in a DoS (Denial-of-Service) on the ITR. resulting in a DoS on the ITR.
3. Attack vectors 3. Attack Vectors
This section presents attack techniques that may be used by attackers This section presents attack techniques that may be used by attackers
when leveraging the LISP protocol and/or architecture. when leveraging LISP and/or its architecture.
3.1. Gleaning 3.1. Gleaning
To reduce the time required to obtain a mapping, the optional To reduce the time required to obtain a mapping, the optional
gleaning mechanism defined for LISP allows an xTR ( Ingress and/or gleaning mechanism defined for LISP allows an xTR (Ingress and/or
Egress Tunnel Router) to directly learn a mapping from the LISP data Egress Tunnel Router) to directly learn a mapping from the LISP-
encapsulated packets and the Map-Request packets that it receives. encapsulated data packets and the Map-Request packets that it
LISP encapsulated data packets contain a source RLOC, destination receives. LISP-encapsulated data packets contain a source RLOC,
RLOC, source EID and destination EID. When an xTR receives an destination RLOC, source EID, and destination EID. When an xTR
encapsulated data packet coming from a source EID for which it does receives an encapsulated data packet coming from a source EID for
not already know a mapping, it may insert the mapping between the which it does not already know a mapping, it may insert the mapping
source RLOC and the source EID in its EID-to-RLOC Cache. The same between the source RLOC and the source EID in its EID-to-RLOC cache.
technique can be used when an xTR receives a Map-Request as the Map- The same technique can be used when an xTR receives a Map-Request as
Request also contains a source EID address and a source RLOC. Once a the Map-Request also contains a source EID address and a source RLOC.
gleaned entry has been added to the EID-to-RLOC cache, the xTR sends Once a gleaned entry has been added to the EID-to-RLOC cache, the xTR
a Map-Request to retrieve the actual mapping for the gleaned EID from sends a Map-Request to retrieve the actual mapping for the gleaned
the mapping system. EID from the mapping system.
If a packet injected by an off-path attacker and with a spoofed inner If a packet injected by an off-path attacker and with a spoofed inner
address is gleaned by an xTR then the attacker may divert the traffic address is gleaned by an xTR, then the attacker may divert the
meant to be delivered to the spoofed EID as long as the gleaned entry traffic meant to be delivered to the spoofed EID as long as the
is used by the xTR. This attack can be used as part of replay, gleaned entry is used by the xTR. This attack can be used as part of
packet manipulation, packet interception and suppression, or DoS replay, packet manipulation, packet interception and suppression, or
attacks as the packets are sent to the attacker. DoS attacks as the packets are sent to the attacker.
If the packet sent by the attacker contains a spoofed outer address If the packet sent by the attacker contains a spoofed outer address
instead of a spoofed inner address then it can achieve a DoS or a instead of a spoofed inner address, then it can achieve a DoS or a
performance attack as the traffic normally destined to the attacker performance attack as the traffic normally destined to the attacker
will be redirected to the spoofed source RLOC. Such traffic may will be redirected to the spoofed source RLOC. Such traffic may
overload the owner of the spoofed source RLOC, preventing it from overload the owner of the spoofed source RLOC, preventing it from
operating properly. operating properly.
If the packet injected uses both inner and outer spoofing, the If the packet injected uses both inner and outer spoofing, the
attacker can achieve a spoofing, a performance, or an amplification attacker can achieve a spoofing, a performance, or an amplification
attack as traffic normally destined to the spoofed EID address will attack as traffic normally destined to the spoofed EID address will
be sent to the spoofed RLOC address. If the attacked LISP site also be sent to the spoofed RLOC address. If the attacked LISP site also
generates traffic to the spoofed EID address, such traffic may have a generates traffic to the spoofed EID address, such traffic may have a
positive amplification factor. positive amplification factor.
A gleaning attack does not only impact the data-plane but can also A gleaning attack does not only impact the data plane but can also
have repercussions on the control-plane as a Map-Request is sent have repercussions on the control plane as a Map-Request is sent
after the creation of a gleaned entry. The attacker can then achieve after the creation of a gleaned entry. The attacker can then achieve
DoS and performance attacks on the control-plane. For example, if an 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 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 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 Map-Request for each such packet until the mapping is installed,
leads to an over-utilisation of the control-plane as each packet which leads to an over-utilization of the control plane as each
generates a control-plane event. In order for this attack to packet generates a control-plane event. In order for this attack to
succeed, the attacker may not need to use spoofing. This issue can succeed, the attacker may not need to use spoofing. This issue can
occur even if gleaning is turned off since whether or not gleaning is occur even if gleaning is turned off since whether or not gleaning is
used as the ITR may need to send a Map-Request in response to used, the ITR may need to send a Map-Request in response to incoming
incoming packets whose EID is not currently in the cache. packets whose EID is not currently in the cache.
Gleaning attacks are fundamentally involving a time-shifted mode of Gleaning attacks fundamentally involve a time-shifted mode of
operation as the attack may last as long as the gleaned entry is kept operation as the attack may last as long as the gleaned entry is kept
by the targeted xTR. RFC 6830 [RFC6830] recommends to store the by the targeted xTR. [RFC6830] recommends storing the gleaned
gleaned entries for only a few seconds which limits the duration of entries for only a few seconds, which limits the duration of the
the attack. attack.
Gleaning attacks always involve external data-plane attackers but Gleaning attacks always involve external data-plane attackers but
results in attacks on either the control-plane or data-plane. result in attacks on either the control plane or data plane.
Note, the outer spoofed address does not need to be the RLOC of a Note that the outer spoofed address does not need to be the RLOC of a
LISP site, it may be any address. LISP site; it may be any address.
3.2. Locator Status Bits 3.2. Locator Status Bits
When the L bit in the LISP header is set to 1, it indicates that the When the L bit in the LISP header is set to 1, it indicates that the
second 32-bits longword of the LISP header contains the Locator second 32-bit longword of the LISP header contains the Locator-
Status Bits. In this field, each bit position reflects the status of Status-Bits (LSBs). In this field, each bit position reflects the
one of the RLOCs mapped to the source EID found in the encapsulated status of one of the RLOCs mapped to the source EID found in the
packet. The reaction of a LISP xTR that receives such a packet is encapsulated packet. The reaction of a LISP xTR that receives such a
left as operational choice in [RFC6830]. packet is left as an operational choice in [RFC6830].
When an attacker sends a LISP encapsulated packet with an When an attacker sends a LISP-encapsulated packet with an
illegitimately crafted LSB to an xTR, it can influence the xTR's illegitimately crafted LSB to an xTR, it can influence the xTR's
choice of the locators for the prefix associated to the source EID. choice of the locators for the prefix associated with the source EID.
In case of an off-path attacker, the attacker must inject a forged In case of an off-path attacker, the attacker must inject a forged
packet in the network with a spoofed inner address. An on-path packet in the network with a spoofed inner address. An on-path
attacker can manipulate the LSB of legitimate packets passing through attacker can manipulate the LSB of legitimate packets passing through
it and hence does not need to use spoofing. Instead of manipulating 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 the LSB field, an on-path attacker can also obtain the same result of
injecting packets with invalid LSB values by replaying packets. injecting packets with invalid LSB values by replaying packets.
The LSB field can be leveraged to mount a DoS attack by either The LSB field can be leveraged to mount a DoS attack by either
declaring all RLOCs as unreachable (all LSB set to 0), or by declaring all RLOCs as unreachable (all LSBs set to 0), concentrating
concentrating all the traffic to one RLOC (e.g., all but one LSB set all the traffic to one RLOC (e.g., all but one LSB set to 0), and
to 0) and hence overloading the RLOC concentrating all the traffic hence overloading the RLOC concentrating all the traffic from the
from the xTR, or by forcing packets to be sent to RLOCs that are xTR, or by forcing packets to be sent to RLOCs that are actually not
actually not reachable (e.g., invert LSB values). reachable (e.g., invert LSB values).
The LSB field can also be used to mount a replay, a packet The LSB field can also be used to mount a replay, a packet
manipulation, or a packet interception and suppression attack. manipulation, or a packet interception and suppression attack.
Indeed, if the attacker manages to be on the path between the xTR and Indeed, if the attacker manages to be on the path between the xTR and
one of the RLOCs specified in the mapping, forcing packets to go via one of the RLOCs specified in the mapping, forcing packets to go via
that RLOC implies that the attacker will gain access to the packets. that RLOC implies that the attacker will gain access to the packets.
Attacks using the LSB are fundamentally involving a time-shifted mode Attacks using the LSB fundamentally involve a time-shifted mode of
of operation as the attack may last as long as the reachability operation as the attack may last as long as the reachability
information gathered from the LSB is used by the xTR to decide the information gathered from the LSB is used by the xTR to decide the
RLOCs to be used. RLOCs to be used.
3.3. Map-Version 3.3. Map-Version
When the Map-Version bit of the LISP header is set to 1, it indicates When the Map-Version bit of the LISP header is set to 1, it indicates
that the low-order 24 bits of the first 32 bits longword of the LISP that the low-order 24 bits of the first 32-bit longword of the LISP
header contain a Source and Destination Map-Version. When a LISP xTR header contain a Source and Destination Map-Version. When a LISP xTR
receives a LISP encapsulated packet with the Map-Version bit set to receives a LISP-encapsulated packet with the Map-Version bit set to
1, the following actions are taken: 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 (Solicit-Map- current version, the Egress Tunnel Router (ETR) should apply the
Request) procedure described in [RFC6830] and send a Map-Request Solicit-Map-Request (SMR) procedure described in [RFC6830] and
with the SMR bit set. 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.
A cross-mode attacker can use the Map-Version bit to mount a DoS A cross-mode attacker can use the Map-Version bit to mount a DoS
attack, an amplification attack, or a spoofing attack. For instance attack, an amplification attack, or a spoofing attack. For instance,
if the mapping cached at the xTR is outdated, the xTR will send a if the mapping cached at the xTR is outdated, the xTR will send a
Map-Request to retrieve the new mapping which can yield to a DoS Map-Request to retrieve the new mapping, which can yield to a DoS
attack (by excess of signalling traffic) or an amplification attack attack (by excess of signaling traffic) or an amplification attack if
if the data-plane packet sent by the attacker is smaller, or the data-plane packet sent by the attacker is smaller, or otherwise
otherwise uses fewer resources, than the control-plane packets sent uses fewer resources, than the control-plane packets sent in response
in response to the attacker's packet. With a spoofing attack, and if to the attacker's packet. With a spoofing attack, and if the xTR
the xTR considers that the spoofed ITR has an outdated mapping, it considers that the spoofed ITR has an outdated mapping, it will send
will send an SMR to the spoofed ITR which can result in performance, an SMR to the spoofed ITR, which can result in a performance,
amplification, or DoS attack as well. amplification, or DoS attack as well.
Map-Version attackers are inherently cross mode as the Map-Version is Map-Version attackers are inherently cross-mode as the Map-Version is
a method to put control information in the data-plane. Moreover, a method to put control information in the data plane. Moreover,
this vector involves live attackers. Nevertheless, on-path attackers this vector involves live attackers. Nevertheless, on-path attackers
do not have specific advantage over off-path attackers. do not have a specific advantage over off-path attackers.
3.4. Routing Locator Reachability 3.4. Routing Locator Reachability
The Nonce-Present and Echo-Nonce bits in the LISP header are used to The Nonce-Present and Echo-Nonce bits in the LISP header are used to
verify the reachability of an xTR. A testing xTR sets the Echo-Nonce verify the reachability of an xTR. A testing xTR sets the Echo-Nonce
and the Nonce-Present bits in LISP data encapsulated packets and and the Nonce-Present bits in LISP-encapsulated data packets and
include a random nonce in the LISP header of packets. Upon reception includes a random nonce in the LISP header of the packets. Upon
of these packets, the tested xTR stores the nonce and echoes it reception of these packets, the tested xTR stores the nonce and
whenever it returns a LISP encapsulated data packets to the testing echoes it whenever it returns a LISP-encapsulated data packet to the
xTR. The reception of the echoed nonce confirms that the tested xTR testing xTR. The reception of the echoed nonce confirms that the
is reachable. tested xTR is reachable.
An attacker can interfere with the reachability test by sending two An attacker can interfere with the reachability test by sending two
different types of packets: different types of packets:
1. LISP data encapsulated packets with the Nonce-Present bit set and 1. LISP-encapsulated data packets with the Nonce-Present bit set and
a random nonce. Such packets are normally used in response to a a random nonce. Such packets are normally used in response to a
reachability test. reachability test.
2. LISP data encapsulated packets with the Nonce-Present and the 2. LISP-encapsulated data packets with the Nonce-Present and the
Echo-Nonce bits both set. These packets will force the receiving Echo-Nonce bits both set. These packets will force the receiving
ETR to store the received nonce and echo it in the LISP ETR to store the received nonce and echo it in the LISP-
encapsulated packets that it sends. These packets are normally encapsulated packets that it sends. These packets are normally
used as a trigger for a reachability test. used as a trigger for a reachability test.
The first type of packets are used to make xTRs think that an other The first type of packets are used to make xTRs think that another
xTR is reachable while it is not. It is hence a way to mount a DoS xTR is reachable when it is not. It is hence a way to mount a DoS
attack (i.e., the ITR will send its packet to a non-reachable ETR attack (i.e., the ITR will send its packet to a non-reachable ETR
when it should use another one). when it should use another one).
The second type of packets could be exploited to attack the nonce- The second type of packets could be exploited to attack the nonce-
based reachability test. If the attacker sends a continuous flow of based reachability test. If the attacker sends a continuous flow of
packets that each have a different random nonce, the ETR that packets that each have a different random nonce, the ETR that
receives such packets will continuously change the nonce that it receives such packets will continuously change the nonce that it
returns to the remote ITR, which can yield to a performance attack. 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 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 because the ETR may echo an invalid nonce. This hence yields to a
DoS attack. DoS attack.
In the case of an on-path attacker, a packet manipulation attack is In the case of an on-path attacker, a packet manipulation attack is
necessary to mount the attack. To mount such an attack, an off-path necessary to mount the attack. To mount such an attack, an off-path
attacker must mount an outer address spoofing attack. attacker must mount an outer address spoofing attack.
If an xTR chooses to periodically check with active probes the If an xTR chooses to periodically check with active probes the
liveness of entries in its EID-to-RLOC cache (as described in section liveness of entries in its EID-to-RLOC cache (as described in
6.3 of [RFC6830]), then this may amplify the attack that caused the Section 6.3 of [RFC6830]), then this may amplify the attack that
insertion of entries being checked. caused the insertion of entries being checked.
3.5. Instance ID 3.5. Instance ID
LISP allows to carry in its header a 24-bits value called Instance ID LISP allows a 24-bit value called Instance ID to be carried in its
and used on the ITR to indicate which local Instance ID has been used header; it's used on the ITR to indicate which local Instance ID has
for encapsulation, while on the ETR the instance ID decides the been used for encapsulation, while on the ETR, the Instance ID
forwarding table to use to forward the decapsulated packet in the decides which forwarding table to use to forward the decapsulated
LISP site. packet in the LISP site.
An attacker (either a control-plane or data-plane attacker) can use An attacker (either a control-plane or data-plane attacker) can use
the instance ID functionality to mount an intrusion attack. the Instance ID functionality to mount an intrusion attack.
3.6. Interworking 3.6. Interworking
[RFC6832] defines Proxy-ITR and Proxy-ETR network elements to allow [RFC6832] defines Proxy-ITR and Proxy-ETR network elements to allow
LISP and non-LISP sites to communicate. The Proxy-ITR has LISP and non-LISP sites to communicate. The Proxy-ITR has
functionality similar to the ITR, however, its main purpose is to functionality similar to the ITR; however, its main purpose is to
encapsulate packets arriving from the DFZ (Default-Free Zone) in encapsulate packets arriving from the Default-Free Zone (DFZ) in
order to reach LISP sites. A PETR (Proxy Egress Tunnel Router) has order to reach LISP sites. A Proxy Egress Tunnel Router (PETR) has
functionality similar to the ETR, however, its main purpose is to functionality similar to the ETR; however, its main purpose is to
inject de-encapsulated packets in the DFZ in order to reach non-LISP inject de-encapsulated packets in the DFZ in order to reach non-LISP
sites from LISP sites. As a PITR (or PETR) is a particular case of sites from LISP sites. As a PITR (or PETR) is a particular case of
ITR (or ETR), it is subject to similar attacks as ITRs (or ETRs). ITR (or ETR), it is subject to similar attacks as ITRs (or ETRs).
As any other system relying on proxies, LISP interworking can be used As any other system relying on proxies, LISP interworking can be used
by attackers to hide their exact origin in the network. by attackers to hide their exact origin in the network.
3.7. Map-Request messages 3.7. Map-Request Messages
A control-plane off-path attacker can exploit Map-Request messages to A control-plane off-path attacker can exploit Map-Request messages to
mount DoS, performance, or amplification attacks. By sending Map- mount DoS, performance, or amplification attacks. By sending Map-
Request messages at high rate, the attacker can overload nodes Request messages at a high rate, the attacker can overload nodes
involved in the mapping system. For instance sending Map-Requests at involved in the mapping system. For instance, sending Map-Requests
high rate can considerably increase the state maintained in a Map- at a high rate can considerably increase the state maintained in a
Resolver or consume CPU cycles on ETRs that have to process the Map- Map-Resolver or consume CPU cycles on ETRs that have to process the
Request packets they receive in their slow path (i.e., performance or Map-Request packets they receive in their slow path (i.e.,
DoS attack). When the Map-Reply packet is larger than the Map- performance or DoS attack). When the Map-Reply packet is larger than
Request sent by the attacker, that yields to an amplification attack. the Map-Request sent by the attacker, that yields to an amplification
The attacker can combine the attack with a spoofing attack to attack. The attacker can combine the attack with a spoofing attack
overload the node to which the spoofed address is actually attached. to overload the node to which the spoofed address is actually
attached.
Note, if the attacker sets the P bit (Probe Bit) in the Map-Request, Note that if the attacker sets the P bit (Probe Bit) in the Map-
it will cause legitimately sending the Map-Request directly to the Request, the Map-Request will be legitimately sent directly to the
ETR instead of passing through the mapping system. ETR instead of passing through the mapping system.
The SMR bit can be used to mount a variant of these attacks. The SMR bit can be used to mount a variant of these attacks.
For efficiency reasons, Map-Records can be appended to Map-Request For efficiency reasons, Map-Records can be appended to Map-Request
messages. When an xTR receives a Map-Request with appended Map- messages. When an xTR receives a Map-Request with appended Map-
Records, it does the same operations as for the other Map-Request Records, it does the same operations as for the other Map-Request
messages and so is subject to the same attacks. However, it also messages and so is subject to the same attacks. However, it also
installs in its EID-to-RLOC cache the Map-Records contained in the 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 Map-Request. An attacker can then use this vector to force the
installation of mappings in its target xTR. Consequently, the EID- installation of mappings in its target xTR. Consequently, the EID-
to-RLOC cache of the xTR is polluted by potentially forged mappings to-RLOC cache of the xTR is polluted by potentially forged mappings
allowing the attacker to mount any of the attacks categorized in allowing the attacker to mount any of the attacks categorized in
Section 2.2 (see Section 3.8 for more details). Note, the attacker Section 2.2 (see Section 3.8 for more details). Note that the
does not need to forge the mappings present in the Map-Request to attacker does not need to forge the mappings present in the Map-
achieve a performance or DoS attack. Indeed, if the attacker owns a Request to achieve a performance or DoS attack. Indeed, if the
large enough EID prefix it can de-aggregate it in many small attacker owns a large enough EID prefix, it can de-aggregate it in
prefixes, each corresponding to another mapping and it installs them many small prefixes, each corresponding to another mapping, and it
in the xTR cache by mean of the Map-Request. installs them in the xTR cache by means 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 relay its attacks and hide the origin of the attack. elements to relay its attacks and hide the origin of the attack.
Indeed, on the one hand, a Map Resolver is used to dispatch Map- Indeed, on the one hand, a Map Resolver is used to dispatch Map-
Request to the mapping system and, on the other hand, a Map Server is Request to the mapping system, and on the other hand, a Map Server is
used to dispatch Map-Requests coming from the mapping system to ETRs used to dispatch Map-Requests coming from the mapping system to ETRs
that are authoritative for the EID in the Map-Request. that are authoritative for the EID in the Map-Request.
3.8. Map-Reply messages 3.8. Map-Reply Messages
Most of the security risks associated with Map-Reply messages will Most of the security risks associated with Map-Reply messages will
depend on the 64 bits nonce that is included in a Map-Request and depend on the 64-bit nonce that is included in a Map-Request and
returned in the Map-Reply. Given the size of the nonce (64 bits), if returned in the Map-Reply. Given the size of the nonce (64 bits), if
best current practice is used [RFC4086] and if an ETR does not accept a best current practice is used [RFC4086] and if an ETR does not
Map-Reply messages with an invalid nonce, the risk of an off-path accept Map-Reply messages with an invalid nonce, the risk of an off-
attack is limited. Nevertheless, the nonce only confirms that the path attack is limited. Nevertheless, the nonce only confirms that
Map-Reply received was sent in response to a Map-Request sent, it the Map-Reply received was sent in response to a Map-Request sent; it
does not validate the contents of that Map-Reply. does not validate the contents of that Map-Reply.
If an attacker manages to send a valid (i.e., in response to a Map- If an attacker manages to send a valid (i.e., in response to a Map-
Request and with the correct nonce) Map-Reply to an ITR, then it can Request and with the correct nonce) Map-Reply to an ITR, then it can
perform any of the attacks categorised in Section 2.2 as it can perform any of the attacks categorized in Section 2.2 as it can
inject forged mappings directly in the ITR EID-to-RLOC cache. For inject forged mappings directly in the ITR EID-to-RLOC cache. For
instance, if the mapping injected to the ITR points to the address of instance, if the mapping injected to the ITR points to the address of
a node controlled by the attacker, it can mount replay, packet a node controlled by the attacker, it can mount replay, packet
manipulation, packet interception and suppression, or DoS attacks, as manipulation, packet interception and suppression, or DoS attacks, as
it will receive every packet destined to a destination lying in the it will receive every packet destined to a destination lying in the
EID prefix of the injected mapping. In addition, the attacker can EID prefix of the injected mapping. In addition, the attacker can
inject a plethora of mappings in the ITR to mount a performance inject a plethora of mappings in the ITR to mount a performance
attack by filling up the EID-to-RLOC cache of the ITR. The attacker attack by filling up the EID-to-RLOC cache of the ITR. The attacker
can also mount an amplification attack if the ITR at that time is can also mount an amplification attack if the ITR at that time is
sending a large number of packets to the EIDs matching the injected sending a large number of packets to the EIDs matching the injected
mapping. In this case, the RLOC address associated to the mapping is mapping. In this case, the RLOC address associated with the mapping
the address of the real target of the attacker and so all the traffic is the address of the real target of the attacker, so all the traffic
of the ITR will be sent to the target which means that with one 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 single packet the attacker may generate very high traffic towards its
final target. final target.
If the attacker is a valid ETR in the system, it can mount a rogue If the attacker is a valid ETR in the system, it can mount a rogue
attack if it uses prefixes over-claiming. In such a scenario, the attack if it uses prefix overclaiming. In such a scenario, the
attacker ETR replies to a legitimate Map-Request message which it attacker ETR replies to a legitimate Map-Request message that it
received with a Map-Reply message that contains an EID-Prefix that is received with a Map-Reply message that contains an EID prefix that is
larger than the prefix owned by the attacker. For example if the larger than the prefix owned by the attacker. For example, if the
owned prefix is 192.0.2.0/25 but the Map-Reply contains a mapping for owned prefix is 192.0.2.0/25 but the Map-Reply contains a mapping for
192.0.2.0/24, then the mapping will influence packets destined to 192.0.2.0/24, then the mapping will influence packets destined to
other EIDs than the one attacker has authority on. With such EIDs other than the one the attacker has authority on. With such
technique, the attacker can mount the attacks presented above as it technique, the attacker can mount the attacks presented above as it
can (partially) control the mappings installed on its target ITR. To can (partially) control the mappings installed on its target ITR. To
force its target ITR to send a Map-Request, nothing prevents the force its target ITR to send a Map-Request, nothing prevents the
attacker to initiate some communication with the ITR. This method attacker to initiate some communication with the ITR. This method
can be used by internal attackers that want to control the mappings can be used by internal attackers that want to control the mappings
installed in their site. To that aim, they simply have to collude installed in their site. To that aim, they simply have to collude
with an external attacker ready to over-claim prefixes on behalf of with an external attacker ready to overclaim prefixes on behalf of
the internal attacker. the internal attacker.
Note, when the Map-Reply is in response to a Map-Request sent via the Note that when the Map-Reply is in response to a Map-Request sent via
mapping system (i.e., not send directly from the ITR to an ETR), the the mapping system (i.e., not sent directly from the ITR to an ETR),
attacker does not need to use a spoofing attack to achieve its attack the attacker does not need to use a spoofing attack to achieve its
as by design the source IP address of a Map-Reply is not known in attack as by design the source IP address of a Map-Reply is not known
advance by the ITR. in advance by the ITR.
Map-Request and Map-Reply messages are exposed to any type of Map-Request and Map-Reply messages are exposed to any type of
attackers, on-path or off-path but also external or internal attackers, on-path or off-path but also external or internal
attackers. Also, even though they are control message, they can be attackers. Also, even though they are control messages, they can be
leveraged by data-plane attackers. As the decision of removing leveraged by data-plane attackers. As the decision of removing
mappings is based on the TTL indicated in the mapping, time-shifted mappings is based on the TTL indicated in the mapping, time-shifted
attackers can take advantage of injecting forged mappings as well. attackers can take advantage of injecting forged mappings as well.
3.9. Map-Register messages 3.9. Map-Register Messages
Map-Register messages are sent by ETRs to Map Servers to indicate to Map-Register messages are sent by ETRs to Map Servers to indicate to
the mapping system the EID prefixes associated to them. The Map- the mapping system the EID prefixes associated with them. The Map-
Register message provides an EID prefix and the list of ETRs that are Register message provides an EID prefix and the list of ETRs that are
able to provide Map-Replies for the EID covered by the EID prefix. able to provide 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 over-claim the prefix it owns in order to A compromised ETR can overclaim 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 (see Section 3.8 for the list of scope of its legitimate EID prefix (see Section 3.8 for the list of
over-claiming attacks). overclaiming attacks).
A compromised ETR can also de-aggregate its EID prefix 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 (see register more EID prefixes than necessary to its Map Servers (see
Section 3.7 for the impact of de-aggregation of prefixes by an Section 3.7 for the impact of de-aggregation of prefixes by an
attacker). attacker).
Similarly, a compromised Map Server can accept an invalid Similarly, a compromised Map Server can accept an invalid
registration or advertise an invalid EID prefix to the mapping registration or advertise an invalid EID prefix to the mapping
system. system.
3.10. 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 reception and processing of a Map-Register message. the reception and processing of a Map-Register message.
Similarly to the pair Map-Request/Map-Reply, the pair Map-Register/ Similarly, to the pair Map-Request/Map-Reply, the pair Map-Register/
Map-Notify is protected by a nonce making it difficult for an Map-Notify is protected by a nonce making it difficult for an
attacker to inject a falsified notification to an ETR to make this attacker to inject a falsified notification to an ETR to make this
ETR believe that the registration succeeded when it has not. ETR believe that the registration succeeded when it has not.
4. Note on Privacy 4. Note on Privacy
As reviewed in [RFC6973], universal privacy considerations are As reviewed in [RFC6973], universal privacy considerations are
difficult to establish as the privacy definitions may vary for difficult to establish as the privacy definitions may vary for
different scenarios. As a consequence, this document does not aim at different scenarios. As a consequence, this document does not aim to
identifying privacy issues related to the LISP protocol but the identify privacy issues related to the LISP protocol, but the
security threats identified in this document could play a role in security threats identified in this document could play a role in
privacy threats as defined in section 5 of [RFC6973]. privacy threats as defined in Section 5 of [RFC6973].
Similar to public deployments of any other control plane protocols, Similar to public deployments of any other control-plane protocol, in
in an Internet deployment, LISP mappings are public and hence provide an Internet deployment, LISP mappings are public and hence provide
information about the infrastructure and reachability of LISP sites information about the infrastructure and reachability of LISP sites
(i.e., the addresses of the edge routers). Depending upon deployment (i.e., the addresses of the edge routers). Depending upon deployment
details, LISP map replies might or might not provide finer grained details, LISP map replies might or might not provide finer-grained
and more detailed information than is available with currently and more detailed information than is available with currently
deployed routing and control protocols. deployed routing and control protocols.
5. Threats Mitigation 5. Threat Mitigation
Most of the above threats can be mitigated with careful deployment Most of the above threats can be mitigated with careful deployment
and configuration (e.g., filter) and also by applying the general and configuration (e.g., filter) and also by applying the general
rules of security, e.g. only activating features that are necessary rules of security, e.g., only activating features that are necessary
for the deployment and verifying the validity of the information for the deployment and verifying the validity of the information
obtained from third parties. obtained from third parties.
The control-plane is the most critical part of LISP from a security The control plane is the most critical part of LISP from a security
viewpoint and it is worth to notice that the LISP specifications viewpoint, and it is worth noticing that the LISP specifications
already offer an authentication mechanism for mappings registration already offer an authentication mechanism for mappings registration
([RFC6833]). This mechanism, combined with LISP-SEC [RFC6833]. This mechanism, combined with LISP-SEC [LISP-SEC],
[I-D.ietf-lisp-sec], strongly mitigates threats in non-trustable strongly mitigates threats in non-trustable environments such as the
environments such as the Internet. Moreover, an authentication data Internet. Moreover, an authentication data field for Map-Request
field for Map-Request messages and Encapsulated Control messages was messages and Encapsulated Control messages was allocated [RFC6830].
allocated [RFC6830]. This field provides a general authentication This field provides a general authentication mechanism technique for
mechanism technique for the LISP control-plane which future the LISP control plane that future specifications may use while
specifications may use while staying backward compatible. The exact staying backward compatible. The exact technique still has to be
technique still has to be designed and defined. To maximally designed and defined. To maximally mitigate the threats on the
mitigate the threats on the mapping system, authentication must be mapping system, authentication must be used, whenever possible, for
used, whenever possible, for both Map-Request and Map-Reply messages both Map-Request and Map-Reply messages and for messages exchanged
and for messages exchanged internally among elements of the mapping internally among elements of the mapping system, such as specified in
system, such as specified in [I-D.ietf-lisp-sec] and [LISP-SEC] and [LISP-DDT].
[I-D.ietf-lisp-ddt].
Systematically applying filters and rate-limitation, as proposed in Systematically applying filters and rate limitation, as proposed in
[RFC6830], will mitigate most of the threats presented in this [RFC6830], will mitigate most of the threats presented in this
document. In order to minimise the risk of overloading the control- document. In order to minimize the risk of overloading the control
plane with actions triggered from data-plane events, such actions plane with actions triggered from data-plane events, such actions
should be rate limited. should be rate limited.
Moreover, all information opportunistically learned (e.g., with LSB Moreover, all information opportunistically learned (e.g., with LSB
or gleaning) should be used with care until they are verified. For or gleaning) should be used with care until they are verified. For
example, a reachability change learned with LSB should not be used example, a reachability change learned with LSB should not be used
directly to decide the destination RLOC, but instead should trigger a directly to decide the destination RLOC but instead should trigger a
rate-limited reachability test. Similarly, a gleaned entry should be rate-limited reachability test. Similarly, a gleaned entry should be
used only for the flow that triggered the gleaning procedure until used only for the flow that triggered the gleaning procedure until
the gleaned entry has been verified [Trilogy]. the gleaned entry has been verified [Trilogy].
6. Security Considerations 6. Security Considerations
This document provides a threat analysis and proposes mitigation This document provides a threat analysis and proposes mitigation
techniques for the Locator/Identifier Separation Protocol. techniques for the Locator/ID Separation Protocol.
7. IANA Considerations
This document makes no request to IANA.
8. Acknowledgments
This document builds upon the document of Marcelo Bagnulo
([I-D.bagnulo-lisp-threat]), where the flooding attack and the
reference environment was first described.
The authors would like to thank Deborah Brungard, Ronald Bonica,
Albert Cabellos, Ross Callon, Noel Chiappa, Florin Coras, Vina
Ermagan, Dino Farinacci, Stephen Farrell, Joel Halpern, Emily
Hiltzik, Darrel Lewis, Edward Lopez, Fabio Maino, Terry Manderson,
and Jeff Wheeler for their comments.
This work has been partially supported by the INFSO-ICT-216372
TRILOGY Project (www.trilogy-project.org).
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-
Labs SOFNETS Project.
9. References 7. References
9.1. Normative References 7.1. Normative References
[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,
DOI 10.17487/RFC6830, January 2013, DOI 10.17487/RFC6830, January 2013,
<http://www.rfc-editor.org/info/rfc6830>. <http://www.rfc-editor.org/info/rfc6830>.
[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, DOI 10.17487/ (LISP) and Non-LISP Sites", RFC 6832,
RFC6832, January 2013, DOI 10.17487/RFC6832, January 2013,
<http://www.rfc-editor.org/info/rfc6832>. <http://www.rfc-editor.org/info/rfc6832>.
[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation
Protocol (LISP) Map-Server Interface", RFC 6833, Protocol (LISP) Map-Server Interface", RFC 6833,
DOI 10.17487/RFC6833, January 2013, DOI 10.17487/RFC6833, January 2013,
<http://www.rfc-editor.org/info/rfc6833>. <http://www.rfc-editor.org/info/rfc6833>.
[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,
DOI 10.17487/RFC6834, January 2013, DOI 10.17487/RFC6834, January 2013,
<http://www.rfc-editor.org/info/rfc6834>. <http://www.rfc-editor.org/info/rfc6834>.
[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,
DOI 10.17487/RFC6973, July 2013, DOI 10.17487/RFC6973, July 2013,
<http://www.rfc-editor.org/info/rfc6973>. <http://www.rfc-editor.org/info/rfc6973>.
9.2. Informative References 7.2. Informative References
[I-D.bagnulo-lisp-threat] [LISP-DDT] Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP
Bagnulo, M., "Preliminary LISP Threat Analysis", Delegated Database Tree", Work in Progress,
draft-bagnulo-lisp-threat-01 (work in progress), draft-ietf-lisp-ddt-03, April 2015.
July 2007.
[I-D.ietf-lisp-ddt] [LISP-SEC] Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP Saucez, "LISP-Security (LISP-SEC)", Work in Progress,
Delegated Database Tree", draft-ietf-lisp-ddt-03 (work in draft-ietf-lisp-sec-10, October 2015.
progress), April 2015.
[I-D.ietf-lisp-sec] [PRELIM-LISP-THREAT]
Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. Bagnulo, M., "Preliminary LISP Threat Analysis", Work in
Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-09 Progress, draft-bagnulo-lisp-threat-01, July 2007.
(work in progress), October 2015.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<http://www.rfc-editor.org/info/rfc4086>. <http://www.rfc-editor.org/info/rfc4086>.
[RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-
Pascual, J., and D. Lewis, "Locator/Identifier Separation Pascual, J., and D. Lewis, "Locator/Identifier Separation
Protocol (LISP) Network Element Deployment Protocol (LISP) Network Element Deployment
Considerations", RFC 7215, DOI 10.17487/RFC7215, Considerations", RFC 7215, DOI 10.17487/RFC7215, April
April 2014, <http://www.rfc-editor.org/info/rfc7215>. 2014, <http://www.rfc-editor.org/info/rfc7215>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
May 2014, <http://www.rfc-editor.org/info/rfc7258>. 2014, <http://www.rfc-editor.org/info/rfc7258>.
[Trilogy] Saucez, D. and L. Iannone, "How to mitigate the effect of [Trilogy] Saucez, D. and L. Iannone, "How to mitigate the effect of
scans on mapping systems", Trilogy Future Internet Summer scans on mapping systems", Trilogy Future Internet Summer
School., 2009. School, 2009.
Appendix A. Document Change Log (to be removed on publication)
o Version 15 Posted January 2016.
* Few changes to address Stephen Farrel comments as part of the
IESG Review.
o Version 14 Posted December 2015.
* Editorial changes according to Deborah Brungard's (Routing AD)
review.
o Version 13 Posted August 2015.
* Keepalive version.
o Version 12 Posted March 2015.
* Addressed comments by Ross Callon on the mailing list (http://
www.ietf.org/mail-archive/web/lisp/current/msg05829.html).
* Addition of a section discussing mitigation techniques for
deployments in non-trustable environments.
o Version 11 Posted December 2014.
* Editorial polishing. Clarifications added in few points.
o Version 10 Posted July 2014.
* Document completely remodelled 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.
* Updated document according to the review of A. Cabellos.
o Version 08 Posted October 2013.
* Addition of a privacy consideration note.
* Editorial changes
o Version 07 Posted October 2013.
* This version is updated according to the thorough review made
during October 2013 LISP WG interim meeting.
* Brief recommendations put in the security consideration
section.
* Editorial changes
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 over-claiming and de-
aggregation (see Section 3.8).
* Editorial polishing.
o Version 01 Posted February 2012.
* Added discussion on LISP-DDT.
o Version 00 Posted July 2011.
* Added discussion on LISP-MS>. Acknowledgments
* Added discussion on Instance ID. This document builds upon the document by Marcelo Bagnulo
[PRELIM-LISP-THREAT], where the flooding attack and the reference
environment was first described.
* Editorial polishing of the whole document. The authors would like to thank Ronald Bonica, Deborah Brungard,
Albert Cabellos, Ross Callon, Noel Chiappa, Florin Coras, Vina
Ermagan, Dino Farinacci, Stephen Farrell, Joel Halpern, Emily
Hiltzik, Darrel Lewis, Edward Lopez, Fabio Maino, Terry Manderson,
and Jeff Wheeler for their comments.
* Added "Change Log" appendix to keep track of main changes. This work has been partially supported by the INFSO-ICT-216372
TRILOGY Project <http://www.trilogy-project.org>.
* Renamed "draft-saucez-lisp-security-03.txt. The work of Luigi Iannone has been partially supported by the
ANR-13-INFR-0009 LISP-Lab Project <http://www.lisp-lab.org> and the
EIT KIC ICT-Labs SOFNETS Project.
Authors' Addresses Authors' Addresses
Damien Saucez Damien Saucez
INRIA INRIA
2004 route des Lucioles BP 93 2004 route des Lucioles BP 93
06902 Sophia Antipolis Cedex 06902 Sophia Antipolis Cedex
France France
Email: damien.saucez@inria.fr Email: damien.saucez@inria.fr
Luigi Iannone Luigi Iannone
Telecom ParisTech Telecom ParisTech
23, Avenue d'Italie, CS 51327 23, Avenue d'Italie, CS 51327
75214 PARIS Cedex 13 75214 Paris Cedex 13
France France
Email: ggx@gigix.net Email: ggx@gigix.net
Olivier Bonaventure Olivier Bonaventure
Universite catholique de Louvain Universite catholique de Louvain
Place St. Barbe 2 Place St. Barbe 2
Louvain la Neuve Louvain la Neuve
Belgium Belgium
Email: olivier.bonaventure@uclouvain.be Email: olivier.bonaventure@uclouvain.be
 End of changes. 142 change blocks. 
481 lines changed or deleted 348 lines changed or added

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