draft-ietf-lisp-threats-06.txt   draft-ietf-lisp-threats-07.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: April 05, 2014 Telecom ParisTech Expires: April 10, 2014 Telecom ParisTech
O. Bonaventure O. Bonaventure
Universite catholique de Louvain Universite catholique de Louvain
October 02, 2013 October 07, 2013
LISP Threats Analysis LISP Threats Analysis
draft-ietf-lisp-threats-06.txt draft-ietf-lisp-threats-07.txt
Abstract Abstract
This document discusses potential security concerns with the Locator/ This document proposes a threat analysis of the Locator/Identifier
Identifier Separation Protocol (LISP) if deployed in the Internet and Separation Protocol (LISP) if deployed in the Internet.
proposes a set of recommendations to mitigate the identified threats
and to reach a level of security equivalent to what is observed in
the Internet today (i.e., without LISP). By following the
recommendations of this draft a LISP deployment can achieve a
security level that is comparable to the existing Internet
architecture.
Status of This 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 April 05, 2014. This Internet-Draft will expire on April 10, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 2. On-path Attackers . . . . . . . . . . . . . . . . . . . . . . 3
3. On-path Attackers . . . . . . . . . . . . . . . . . . . . . . 4 3. Off-Path Attackers: Reference Environment . . . . . . . . . . 3
4. Off-Path Attackers: Reference Environment . . . . . . . . . . 4 4. Attack vectors . . . . . . . . . . . . . . . . . . . . . . . 5
5. Attack vectors . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Configured EID-to-RLOC mappings . . . . . . . . . . . . . 5
5.1. EID-to-RLOC Database . . . . . . . . . . . . . . . . . . 6 4.2. EID-to-RLOC Cache . . . . . . . . . . . . . . . . . . . . 6
5.2. EID-to-RLOC Cache . . . . . . . . . . . . . . . . . . . . 6 4.3. Attacks using the data-plane . . . . . . . . . . . . . . 6
5.3. Attack using the data-plane . . . . . . . . . . . . . . . 7 4.3.1. Attacks not leveraging on the LISP header . . . . . . 7
5.3.1. Attacks not leveraging on the LISP header . . . . . . 7 4.3.2. Attacks leveraging on the LISP header . . . . . . . . 8
5.3.2. Attacks leveraging on the LISP header . . . . . . . . 9 4.4. Attacks using the control-plane . . . . . . . . . . . . . 10
5.4. Attack using the control-plane . . . . . . . . . . . . . 11 4.4.1. Attacks with Map-Request messages . . . . . . . . . . 11
5.4.1. Attacks with Map-Request messages . . . . . . . . . . 11 4.4.2. Attacks with Map-Reply messages . . . . . . . . . . . 12
5.4.2. Attacks with Map-Reply messages . . . . . . . . . . . 13 4.4.3. Attacks with Map-Register messages . . . . . . . . . 13
5.4.3. Attacks with Map-Register messages . . . . . . . . . 14 4.4.4. Attacks with Map-Notify messages . . . . . . . . . . 14
5.4.4. Attacks with Map-Notify messages . . . . . . . . . . 14 5. Attack categories . . . . . . . . . . . . . . . . . . . . . . 14
6. Attack categories . . . . . . . . . . . . . . . . . . . . . . 14 5.1. Intrusion . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Intrusion . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1.1. Description . . . . . . . . . . . . . . . . . . . . . 14
6.1.1. Description . . . . . . . . . . . . . . . . . . . . . 14 5.1.2. Vectors . . . . . . . . . . . . . . . . . . . . . . . 14
6.1.2. Vectors . . . . . . . . . . . . . . . . . . . . . . . 14 5.2. Denial of Service (DoS) . . . . . . . . . . . . . . . . . 14
6.2. Denial of Service (DoS) . . . . . . . . . . . . . . . . . 15 5.2.1. Description . . . . . . . . . . . . . . . . . . . . . 14
6.2.1. Description . . . . . . . . . . . . . . . . . . . . . 15 5.2.2. Vectors . . . . . . . . . . . . . . . . . . . . . . . 14
6.2.2. Vectors . . . . . . . . . . . . . . . . . . . . . . . 15 5.3. Subversion . . . . . . . . . . . . . . . . . . . . . . . 15
6.3. Eavesdropping . . . . . . . . . . . . . . . . . . . . . . 15 5.3.1. Description . . . . . . . . . . . . . . . . . . . . . 15
6.3.1. Description . . . . . . . . . . . . . . . . . . . . . 15 5.3.2. Vectors . . . . . . . . . . . . . . . . . . . . . . . 15
6.3.2. Vectors . . . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Document Change Log . . . . . . . . . . . . . . . . 18 Appendix A. Document Change Log . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
The Locator/ID Separation Protocol (LISP) is defined in [RFC6830]. The Locator/ID Separation Protocol (LISP) is defined in [RFC6830].
The present document assesses the security level and identifies The present document assesses the security level and identifies
security threats in the LISP specification if LISP is deployed in the security threats in the LISP specification if LISP is deployed in the
Internet (i.e., a public non-trustable environment). As a result of Internet (i.e., a public non-trustable environment). As a result of
the performed analysis, the document discusses the severity of the the performed analysis, the document discusses the severity of the
threats and proposes recommendations to reach the same level of threats and proposes recommendations to reach the same level of
security in LISP than in Internet today (e.g., without LISP). security in LISP than in Internet today (e.g., without LISP).
The document is composed of three main parts: the first discussing The document is composed of three main parts: the first discussing
the LISP data-plane; while the second discussing the LISP control- the LISP data-plane; while the second discussing the LISP control-
plane. The final part summarizes the recommendations to prevent the plane. The final part summarizes the recommendations to prevent the
identified threats. identified threats.
The LISP data-plane consists of LISP packet encapsulation, The LISP data-plane consists of LISP packet encapsulation,
decapsulation, and forwarding and includes the EID-to-RLOC Cache and decapsulation, and forwarding and includes the map cache data
EID-to-RLOC Database data structures used to perform these structures used to perform these operations.
operations.
The LISP control-plane consists in the mapping distribution system, The LISP control-plane consists in the mapping distribution system,
which can be one of the mapping distribution systems proposed so far which can be one of the mapping distribution systems proposed so far
(e.g., [RFC6830], [I-D.ietf-lisp-ddt], [RFC6836], [RFC6833], (e.g., [RFC6830], [I-D.ietf-lisp-ddt], [RFC6836], [RFC6833],
[I-D.meyer-lisp-cons], and [RFC6837]), and the Map-Request, Map- [I-D.meyer-lisp-cons], and [RFC6837]), and the Map-Request, Map-
Reply, Map-Register, and Map-Notification messages. Reply, Map-Register, and Map-Notification messages.
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]. The document focuses on LISP unicast, discussed in [RFC6830]. The document focuses on LISP unicast,
including as well LISP Interworking [RFC6832], LISP-MS [RFC6833], including as well LISP Interworking [RFC6832], LISP-MS [RFC6833], and
LISP Map-Versioning [RFC6834], and briefly considering the ALT LISP Map-Versioning [RFC6834]. The reading of these documents is a
mapping system described in [RFC6836] and the Delegated Database Tree prerequisite for understanding the present document.
mapping system described in [I-D.ietf-lisp-ddt]. The reading of
these documents is a prerequisite for understanding the present
document.
Unless otherwise stated, the document assumes a generic IP service Unless otherwise stated, the document assumes a generic IP service
and does not discuss the difference, from a security viewpoint, and does not discuss the difference, from a security viewpoint,
between using IPv4 or IPv6. between using IPv4 or IPv6.
This document has identified several threats on LISP in the case of 2. On-path Attackers
public deployments. However, most of the threats can be prevented
with careful deployment and configuration and general rules in
security that consist in activating only features that are necessary
in the deployment and to carefully verifying the validity of the
information obtained from third parties also applies in the case of
LISP. Finally, this document has not identified any threats that
would require a change in the LISP protocol or architecture.
2. Definition of Terms
The present document does not introduce any other new term, compared
to the main LISP specification. For a complete list of terms please
refer to [RFC6830].
3. On-path Attackers
On-path attackers are attackers that are able to capture and modify On-path attackers are attackers that are able to capture and modify
all the packets exchanged between an Ingress Tunnel Router (ITR) and all the packets exchanged between an Ingress Tunnel Router (ITR) and
an Egress Tunnel Router (ETR). To cope with such an attacker, an Egress Tunnel Router (ETR). To cope with such an attacker,
cryptographic techniques such as those used by IPSec ([RFC4301]) are cryptographic techniques such as those used by IPSec ([RFC4301]) are
required. As with IP, LISP relies on higher layer cryptography to required. As with IP, LISP relies on higher layer cryptography to
secure packet payloads from on path attacks, so we do not consider secure packet payloads from on path attacks, so we do not consider
on-path attackers in this document. on-path attackers in this document.
Similarly, a time-shifted attack is an attack where the attacker is Similarly, a time-shifted attack is an attack where the attacker is
temporarily on the path between two communicating hosts. While it is temporarily on the path between two communicating hosts. While it is
on-path, the attacker sends specially crafted packets or modifies on-path, the attacker sends specially crafted packets or modifies
packets exchanged by the communicating hosts in order to disturb the packets exchanged by the communicating hosts in order to disturb the
packet flow (e.g., by performing a man in the middle attack). An packet flow (e.g., by performing a man in the middle attack). An
important issue for time-shifted attacks is the duration of the important issue for time-shifted attacks is the duration of the
attack once the attacker has left the path between the two attack once the attacker has left the path between the two
communicating hosts. We do not consider time-shifted attacks in this communicating hosts. We do not consider time-shifted attacks in this
document. document.
4. Off-Path Attackers: Reference Environment 3. Off-Path Attackers: Reference Environment
Throughout this document we consider the reference environment shown Throughout this document we consider the reference environment shown
in the figure below. There are two hosts attached to LISP routers: in the figure below. There are two hosts attached to LISP routers:
HA and HB. HA is attached to the two LISP xTRs LR1 and LR2, which in HA and HB. HA is attached to the two LISP xTRs LR1 and LR2, which in
turn are attached to two different ISPs. HB is attached to the two turn are attached to two different ISPs. HB is attached to the two
LISP xTRs LR3 and LR4. HA and HB are the EIDs of the two hosts. LISP xTRs LR3 and LR4. HA and HB are the EIDs of the two hosts.
LR1, LR2, LR3, and LR4 are the RLOCs of the xTRs. PxTR is a proxy LR1, LR2, LR3, and LR4 are the RLOCs of the xTRs. PxTR is a proxy
xTR and MR/MS plays the roles of Map Server and/or Map Resolver. xTR and MR/MS plays the roles of Map Server and/or Map Resolver.
+-----+ +-----+
| HA | | HA |
skipping to change at page 6, line 17 skipping to change at page 5, line 40
different kind of attacks. different kind of attacks.
In the reference environment, both SA and NSA attackers are capable In the reference environment, both SA and NSA attackers are capable
of sending LISP encapsulated data packets and LISP control packets. of sending LISP encapsulated data packets and LISP control packets.
This means that SA is able to perform both RLOC and EID spoofing 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 while NSA can only perform EID spoofing. They may also send other
types of IP packets such as ICMP messages. We assume that both types of IP packets such as ICMP messages. We assume that both
attackers can query the LISP mapping system (e.g., through a public attackers can query the LISP mapping system (e.g., through a public
Map Resolver) to obtain the mappings for both HA and HB. Map Resolver) to obtain the mappings for both HA and HB.
5. Attack vectors 4. Attack vectors
This section presents techniques that can be used by attackers to This section presents techniques that can be used by attackers to
succeed attacks leveraging the LISP protocol and architecture. This succeed attacks leveraging the LISP protocol and architecture. This
section focuses on the techniques while Section 6 presents the section focuses on the techniques while Section 5 presents the
attacks that can be succeeded while using these techniques. attacks that can be succeeded while using these techniques.
5.1. EID-to-RLOC Database 4.1. Configured EID-to-RLOC mappings
The EID-to-RLOC Database on each xTR maintains the set of mappings Each xTR maintains a set of configured mappings related to the EID-
related to the EID-Prefixes that are "behind" the xTR. Where Prefixes that are "behind" the xTR [RFC6830]. Where "behind" means
"behind" means that at least one of the xTR's globally visible IP that at least one of the xTR's globally visible IP addresses is a
addresses is a RLOC for those EID-Prefixes. RLOC for those EID-Prefixes.
As described in [RFC6830], the EID-to-RLOC Database content is As these mappings are determined by configuration. This means that
determined by configuration. This means that the only way to attack the only way to attack this data structure is by gaining privileged
this data structure is by gaining privileged access to the xTR. As access to the xTR. As such, it is out of the scope of LISP to
such, it is out of the scope of LISP to propose any mechanism to propose any mechanism to protect routers and, hence, it is no further
protect routers and, hence, it is no further analyzed in this analyzed in this document.
document.
5.2. EID-to-RLOC Cache 4.2. EID-to-RLOC Cache
The EID-to-RLOC Cache (also called the Map-Cache) is the data The EID-to-RLOC Cache (also called the Map-Cache) is the data
structure that stores a copy of the mappings retrieved from a remote structure that stores a copy of the mappings retrieved from a remote
ETR's mapping database via the LISP control-plane. Attacks against ETR's mapping via the LISP control-plane. Attacks against this data
this data structure could happen either when the mappings are first structure could happen either when the mappings are first installed
installed in the cache or by corrupting (poisoning) the mappings in the cache or by corrupting (poisoning) the mappings already
already present in the cache. present in the cache.
In this document we call "cache poisoning attack", any attach that In this document we call "cache poisoning attack", any attack that
alters the EID-to-RLOC Cache. Cache poisoning attacks are use to alters the EID-to-RLOC Cache. Cache poisoning attacks are use to
alter (any combination of) the following parts of mapping installed alter (any combination of) the following parts of mapping installed
in the EID-to-RLOC Cache: in the EID-to-RLOC Cache:
o EID prefix o EID prefix
o RLOC list o RLOC list
o RLOC priority o RLOC priority
o RLOC weight o RLOC weight
o RLOC reachability o RLOC reachability
o Mapping TTL o Mapping TTL
skipping to change at page 7, line 18 skipping to change at page 6, line 41
o RLOC weight o RLOC weight
o RLOC reachability o RLOC reachability
o Mapping TTL o Mapping TTL
o Mapping version o Mapping version
o Mapping Instance ID o Mapping Instance ID
5.3. Attack using the data-plane 4.3. Attacks using the data-plane
The data-plane is constituted of the operations of encapsulation, The data-plane is constituted of the operations of encapsulation,
decapsulation, and forwarding as well as the content of the EID-to- decapsulation, and forwarding as well as the content of the EID-to-
RLOC Cache and EID-to-RLOC Database as specified in the original LISP RLOC Cache and configured EID-to-RLOC mappings as specified in the
document ([RFC6830]). original LISP document ([RFC6830]).
5.3.1. Attacks not leveraging on the LISP header 4.3.1. Attacks not leveraging on the LISP header
An attacker can inject packets into flows without using the LISP An attacker can inject packets into flows without using the LISP
header, i.e., with the N, L, E, V, and I bits ([RFC6830]). header, i.e., with the N, L, E, V, and I bits ([RFC6830]).
To inject a packet in the HA-HB flow, a spoofing off-path attacker Taking notation of the reference environment notation (Figure 1), to
(SA) could send a LISP encapsulated packet whose source is set to LR1 inject a packet in the HA->HB flow, a spoofing off-path attacker (SA)
or LR2 and destination LR3 or LR4. The packet will reach HB as if could send a LISP encapsulated packet whose source is set to LR1 or
the packet was sent by host HA. This is not different from today's 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 Internet where a spoofing off-path attacker may inject data packets
in any flow. A non-spoofing off-path attacker (NSA) could only send 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 a packet whose source address is set to its assigned IP address. The
destination address of the encapsulated packet could be LR3 or LR4. destination address of the encapsulated packet could be LR3 or LR4.
5.3.1.1. Gleaning Attacks 4.3.1.1. Gleaning Attacks
In order to reduce the time required to obtain a mapping, [RFC6830] In order to reduce the time required to obtain a mapping, [RFC6830]
proposes the gleaning mechanism that allows an ITR to learn a mapping proposes the gleaning mechanism that allows an ITR to learn a mapping
from the LISP data encapsulated packets and the Map-Request packets from the LISP data encapsulated packets and the Map-Request packets
that it receives. LISP data encapsulated packet contains a source that it receives. LISP data encapsulated packet contains a source
RLOC, destination RLOC, source EID and destination EID. When an ITR RLOC, destination RLOC, source EID and destination EID. When an ITR
receives a data encapsulated packet coming from a source EID for receives a data encapsulated 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 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. 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 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 LISP ITR sends a Map-Request to retrieve the mapping for the gleaned
EID from the mapping system. [RFC6830] recommends storing the EID from the mapping system. [RFC6830] recommends storing the
gleaned entries for only a few seconds. gleaned entries for only a few seconds.
An attacker can send LISP encapsulated packets to host HB with host An attacker can send LISP encapsulated packets to host HB with host
HA's EID and if the xTRs that serve host HB do not store a mapping HA's EID and if the xTRs that serve host HB do not store a mapping
for host HA at that time The xTR will store the gleaned entry and use for host HA at that time. The xTR will store the gleaned entry and
it to return the packets sent by host HB. In parallel, the ETR will use it to return the packets sent by host HB. In parallel, the ETR
send a Map-Request to retrieve the mapping for HA but until the will send a Map-Request to retrieve the mapping for HA but until the
reception of the Map-Reply, host HB will exchange packets with the reception of the Map-Reply, host HB will exchange packets with the
attacker instead of HA. attacker instead of HA.
Similarly, if an off-path attacker knows that hosts HA and HB that Similarly, if an off-path attacker knows that hosts HA and HB that
resides in different sites will exchange information at time t the resides in different sites will exchange information at time t the
attacker could send to LR1 (resp. LR3) a LISP data encapsulated attacker could send to LR1 (resp. LR3) a LISP data encapsulated
packet whose source RLOC is its IP address and contains an IP packet 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 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 that will not trigger an answer, for example the last part of a
fragmented packet. Upon reception of these packets, LR1 and LR3 fragmented packet. Upon reception of these packets, LR1 and LR3
install gleaned entries that point to the attacker. If host HA is install gleaned entries that point to the attacker. If host HA is
willing to establishes a flow with host HB at that time, the packets willing to establishes a flow with host HB at that time, the packets
that they exchange will pass through the attacker as long as the that they exchange will pass through the attacker as long as the
gleaned entry is active on the xTRs. gleaned entry is active on the xTRs.
By itself, an attack made solely using gleaning cannot last long, By itself, an attack made solely using gleaning cannot last long,
however it should be noted that with current network capacities, a however it should be noted that with current network capacities, a
large amount of packets might be exchanged during even a small large amount of packets might be exchanged during even a small
fraction of time. fraction of time.
5.3.1.2. Threats concerning Interworking 4.3.1.2. Threats concerning 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 in order to reach LISP encapsulate packets arriving from the DFZ in order to reach LISP
sites. A Proxy-ETR has functionality similar to the ETR, however, sites. A Proxy-ETR has functionality similar to the ETR, however,
its main purpose is to inject de-encapsulated packets in the DFZ in 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. 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 PETR) is a particular case of ITR (resp. ETR), it is subject to same
attacks than ITRs (resp. ETR). attacks than ITRs (resp. ETR).
PxTRs can be targeted by attacks aiming to influence traffic between PxTRs can be targeted by attacks aiming to influence traffic between
LISP and non-LISP sites but also to launch relay attacks. LISP and non-LISP sites but also to launch relay attacks.
It is worth to notice that when PITR and PETR functions are It is worth to notice that when PITR and PETR functions are
separated, attacks targeting xTRs are ineffective. separated, attacks targeting nodes that collocate PITR and PETR
functionality are ineffective.
5.3.2. Attacks leveraging on the LISP header 4.3.2. Attacks leveraging on the LISP header
The main LISP document [RFC6830] defines several flags that modify The main LISP document [RFC6830] defines several flags that modify
the interpretation of the LISP header in data packets. In this the interpretation of the LISP header in data packets. In this
section, we discuss how an off-path attacker could exploit this LISP section, we discuss how an off-path attacker could exploit this LISP
header. header.
5.3.2.1. Attacks using the Locator Status Bits 4.3.2.1. Attacks using the 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. In
particular, a packet with the L bit set and all Locator Status Bits particular, a packet with the L bit set and all Locator Status Bits
set to zero indicates that none of the locators of the encapsulated set to zero indicates that none of the locators of the encapsulated
source EID are reachable. The reaction of a LISP ETR that receives source EID are reachable. The reaction of a LISP ETR that receives
such a packet is not clearly described in [RFC6830]. 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 An attacker can send a data packet with the L bit set to 1 and some
or all Locator Status Bits set to zero. Therefore, by blindly or all Locator Status Bits set to zero. Therefore, by blindly
trusting the Locator Status Bits communication going on can be trusting the Locator Status Bits communication going on can be
altered or forced to go through a particular set of locators. altered or forced to go through a particular set of locators.
5.3.2.2. Attacks using the Map-Version bit 4.3.2.2. Attacks using the Map-Version bit
The optional Map-Version bit is used to indicate whether the low- The optional Map-Version bit is used to indicate whether the low-
order 24 bits of the first 32 bits longword of the LISP header order 24 bits of the first 32 bits longword of the LISP header
contain a Source and Destination Map-Version. When a LISP ETR contain a Source and Destination Map-Version. When a LISP ETR
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 mapping, in the EID-to-RLOC the current version of its own configured EID-to-RLOC mapping, for
Database, for the destination EID found in the encapsulated the destination EID found in the encapsulated packet. If the
packet. If the received Destination Map-Version is smaller (i.e., received Destination Map-Version is smaller (i.e., older) than the
older) than the current version, the ETR should apply the SMR current version, the ETR should apply the SMR procedure described
procedure described in [RFC6830] and send a Map-Request with the in [RFC6830] and send a Map-Request with the SMR bit set.
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 An off-path attacker could use the Map-Version bit to force an ETR to
send Map-Request messages. The attacker could retrieve the current send Map-Request messages. The attacker could retrieve the current
source and destination Map-Version for both HA and HB. Based on this source and destination Map-Version for both HA and HB. Based on this
information, it could send a spoofed packet with an older Source Map- information, it could send a spoofed packet with an older Source Map-
Version or Destination Map-Version. If the size of the Map-Request Version or Destination Map-Version. If the size of the Map-Request
message is larger than the size of the smallest LISP-encapsulated message is larger than the size of the smallest LISP-encapsulated
packet that could trigger such a message, this could lead to packet that could trigger such a message, this could lead to
amplification attacks (see Section 5.4.1). amplification attacks (see Section 4.4.1) so that more bandwidth is
consumed on the target than the bandwidth necessary at the attacker
side.
5.3.2.3. Attacks using the Nonce-Present and the Echo-Nonce bits 4.3.2.3. Attacks using the Nonce-Present and the Echo-Nonce bits
The Nonce-Present and Echo-Nonce bits are used when verifying the The Nonce-Present and Echo-Nonce bits are used when verifying the
reachability of a remote ETR. Assume that LR3 wants to verify that 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 LR1 receives the packets that it sends. LR3 can set the Echo-Nonce
and the Nonce-Present bits in LISP data encapsulated packets and and the Nonce-Present bits in LISP data encapsulated packets and
include a random nonce in these packets. Upon reception of these 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 packets, LR1 will store the nonce sent by LR3 and echo it when it
returns LISP encapsulated data packets to LR3. returns LISP encapsulated data packets to LR3.
A spoofing off-path attacker (SA) could interfere with this A spoofing off-path attacker (SA) could interfere with this
skipping to change at page 10, line 37 skipping to change at page 10, line 18
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 and the appropriate source and
destination RLOCs. These packets will force the receiving ETR to destination RLOCs. These packets will force the receiving ETR to
store the received nonce and echo it in the LISP encapsulated store the received nonce and echo it in the LISP encapsulated
packets that it sends. packets that it sends.
The first type of packet should not cause any major problem to ITRs. 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 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 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 believe that the ETR it is testing is reachable while in reality it
is not reachable. To increase the success likelihood of such attach, is not reachable. To increase the success likelihood of such attack,
the attacker should created a massive amount of packets carrying all the attacker should created a massive amount of packets carrying all
possible nonce values. possible nonce values.
The second type of packet could be exploited to attack the nonce- The second type of packet could be exploited to attack the nonce-
based reachability test. Consider a spoofing off-path attacker (SA) based reachability test. Consider a spoofing off-path attacker (SA)
that sends a continuous flow of spoofed LISP data encapsulated that sends a continuous flow of spoofed LISP data encapsulated
packets that contain the Nonce-Present and the Echo-Nonce bit and packets that contain the Nonce-Present and the Echo-Nonce bit and
each packet contains a different random nonce. The ETR that receives each packet contains a different random nonce. The ETR that receives
such packets will continuously change the nonce that it returns to such packets will continuously change the nonce that it returns to
the remote ITR. If the remote ITR starts a nonce-reachability test, 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 this test may fail because the ETR has received a spoofed LISP data
encapsulated packet with a different random nonce and never echoes encapsulated packet with a different random nonce and never echoes
the real nonce. In this case the ITR will consider the ETR not 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 reachable. The success of this test depends on the ratio between the
amount of packets sent by the legitimate ITR and the spoofing off- amount of packets sent by the legitimate ITR and the spoofing off-
path attacker (SA). path attacker (SA).
5.3.2.4. Attacks using the Instance ID bits 4.3.2.4. Attacks using the Instance ID bits
LISP allows to carry in its header a 24-bits value called "Instance 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 ID" and used on the ITR to indicate which local Instance ID has been
used for encapsulation, while on the ETR can be used to select the used for encapsulation, while on the ETR can be used to select the
forwarding table used for forwarding the decapsulated packet. forwarding table used for forwarding the decapsulated packet.
The Instance ID increases exposure to attacks ([RFC6169]) as if an The Instance ID increases exposure to attacks ([RFC6169]) as if an
off-path attacker can randomly guess a valid Instance ID value she off-path attacker can randomly guess a valid Instance ID value to get
gets access to network that she might not have access. However, the access to network that might not been accessible in normal
impact of such attack is directly on end-systems which is is out of conditions. However, the impact of such attack is directly on end-
the scope of this document. systems which is is out of the scope of this document.
5.4. Attack using the control-plane 4.4. Attacks using the control-plane
In this section, we discuss the different types of attacks that could In this section, we discuss the different types of attacks that could
occur when an off-path attacker sends control-plane packets. We occur when an off-path attacker sends control-plane packets. We
focus on the packets that are sent directly to the ETR and do not focus on the packets that are sent directly to the ETR and do not
analyze the particularities of a LISP mapping system. analyze the particularities of the different LISP indexing sub-
system.
5.4.1. Attacks with Map-Request messages 4.4.1. Attacks with Map-Request messages
An off-path attacker could send Map-Request packets to a victim ETR. An off-path attacker could send Map-Request packets to a victim ETR.
In theory, a Map-Request packet is only used to solicit an answer and In theory, a Map-Request packet is only used to solicit an answer and
as such it should not lead to security problems. However, the LISP as such it should not lead to security problems. However, the LISP
specification [RFC6830] contains several particularities that could specification [RFC6830] contains several particularities that could
be exploited by an off-path attacker. be exploited by an off-path attacker.
The first possible exploitation is the P bit. The P bit is used to The first possible exploitation is the RLOC record P bit. The RLOC
probe the reachability of remote ETRs. In our reference environment, record P bit is used to probe the reachability of remote ETRs. In
LR3 could probe the reachability of LR1 by sending a Map-Request with our reference environment, LR3 could probe the reachability of LR1 by
the P bit set. LR1 would reply by sending a Map-Reply message with sending a Map-Request with the RLOC record P bit set. LR1 would
the P bit set and the same nonce as in the Map-Request message. 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 P bit to force a A spoofing off-path attacker (SA) could use the RLOC record P bit to
victim ETR to send a Map-Reply to the spoofed source address of the force a victim ETR to send a Map-Reply to the spoofed source address
Map-Request message. As the Map-Reply can be larger than the Map- of the Map-Request message. As the Map-Reply can be larger than the
Request message, there is a risk of amplification attack. Map-Request message, there is a risk of amplification attack.
Considering only IPv6 addresses, a Map-Request can be as small as 40 Considering only IPv6 addresses, a Map-Request can be as small as 40
bytes, considering one single ITR address and no Mapping Protocol bytes, considering one single ITR address and no Mapping Protocol
Data. The Map-Reply instead has a size of O(12 + (R * (28 + N * Data. The Map-Reply instead has a proportional to the maximum number
24))) bytes, where N is the maximum number of RLOCs in a mapping and of RLOCs in a mapping and maximum number of records in a Map-Reply.
R the maximum number of records in a Map-Reply. Since up to 255 Since up to 255 RLOCs can be associated to an EID-Prefix and 255
RLOCs can be associated to an EID-Prefix and 255 records can be records can be stored in a Map-Reply, the maximum size of a Map-Reply
stored in a Map-Reply, the maximum size of a Map-Reply is thus above is thus above 1 MB, largely bigger than the message sent by the
1 MB showing a size factor of up to 39,193 between the message sent attacker. These numbers are however theoretical values not
by the attacker and the message sent by the ETR. These numbers are considering transport layer limitations and it is more likely that
however theoretical values not considering transport layer the reply will contain only one record with at most a dozen of
limitations and it is more likely that the reply will contain only locators, limiting so the amplification factor.
one record with at most a dozen of locators, giving an amplification
factor around 8.
Similarly, if a non-spoofing off-path attacker (NSA) sends a Map- Similarly, if a non-spoofing off-path attacker (NSA) sends a Map-
Request with the P bit set, it will receive a Map-Reply with the P Request with the RLOC record P bit set, it will receive a Map-Reply
bit set. with the RLOC record P bit set.
An amplification attack could be launched by a spoofing off-path An amplification attack could be launched by a spoofing off-path
attacker (SA) as follows. Consider an attacker SA and EID-Prefix attacker (SA) as follows. Consider an attacker SA and EID-Prefix
192.0.2.0/24 and a victim ITR, SA could send spoofed Map-Request 192.0.2.0/24 and a victim ITR, SA could send spoofed Map-Request
messages whose source EID addresses are all the addresses inside messages whose source EID addresses are all the addresses inside
192.0.2.0/24 and source RLOC address is the victim ITR. Upon 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 reception of these Map-Request messages, the ETR would send large
Map-Reply messages for each of the addresses inside p/P back to the Map-Reply messages for each of the addresses inside p/P back to the
victim ITR. victim ITR.
The Map-Request message may also contain the SMR bit. Upon reception The Map-Request message may also contain the SMR bit. Upon reception
of a Map-Request message with the SMR bit, an ETR must return to the 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 source of the Map-Request message a Map-Request message to retrieve
the corresponding mapping. This raises similar problems as the P bit the corresponding mapping. This raises similar problems as the RLOC
discussed above except that as the Map-Request messages are smaller record P bit discussed above except that as the Map-Request messages
than Map-Reply messages, the risk of amplification attacks is are smaller than Map-Reply messages, the risk of amplification
reduced. This is not true anymore if the ETR append to the Map- attacks is reduced. This is not true anymore if the ETR append to
Request messages its own Map-Records. This mechanism is meant to the Map-Request messages its own Map-Records. This mechanism is
reduce the delay in mapping distribution since mapping information is meant to reduce the delay in mapping distribution since mapping
provided in the Map-Request message. information is provided in the Map-Request message.
Furthermore, appending Map-Records to Map-Request messages allows an Furthermore, appending Map-Records to Map-Request messages allows an
off-path attacker to generate a (spoofed or not) Map-Request message off-path attacker to generate a (spoofed or not) Map-Request message
and include in the Map-Reply portion of the message mapping for EID and include in the Map-Reply portion of the message mapping for EID
prefixes that it does not serve. prefixes that it does not serve.
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 perform relay attacks. Indeed, on the one hand, a Map
Resolver is used to dispatch Map-Request to the mapping system and, Resolver is used to dispatch Map-Request to the mapping system and,
on the other hand, a Map Server is used to dispatch Map-Requests on the other hand, a Map Server is used to dispatch Map-Requests
coming from the mapping system to ETRs that are authoritative for the coming from the mapping system to ETRs that are authoritative for the
EID in the Map-Request. EID in the Map-Request.
5.4.2. Attacks with Map-Reply messages 4.4.2. Attacks with Map-Reply messages
In this section we analyze the attacks that could occur when an off- In this section we analyze the attacks that could occur when an off-
path attacker sends directly Map-Reply messages to ETRs without using path attacker sends directly Map-Reply messages to ETRs without using
one of the proposed LISP mapping systems. one of the proposed LISP mapping systems.
There are two different types of Map-Reply messages: There are two different types of Map-Reply messages:
Positive Map-Reply: These messages contain a Map-Record binding an Positive Map-Reply: These messages contain a Map-Record binding an
EID-Prefix to one or more RLOCs. EID-Prefix to one or more RLOCs.
Negative Map-Reply: These messages contain a Map-Record for an EID- Negative Map-Reply: These messages contain a Map-Record for an EID-
Prefix with an empty locator-set and specifying an action, Prefix with an empty locator-set and specifying an action,
which may be either Drop, natively forward, or Send Map- which may be either Drop, natively forward, or Send Map-
Request. Request.
Positive Map-Reply messages are used to map EID-Prefixes onto RLOCs. Positive Map-Reply messages are used to map EID-Prefixes onto RLOCs.
Negative map-reply messages are used to indicate non-lisp prefixes. Negative Map-Reply messages are used to indicate non-LISP prefixes.
ITRs can, if needed, be configured to send all traffic destined for ITRs can, if needed, be configured to send all traffic destined for
non-lisp prefixes to a Proxy-ETR. 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. f 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 acceptable given the size of the nonce
(64 bits). However, the nonce only confirms that the map-reply (64 bits). However, 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 In addition, an attacker could perform EID-to-RLOC Cache overflow
attack by de-aggregating (i.e., splitting an EID prefix into attack by de-aggregating (i.e., splitting an EID prefix into
artificially smaller EID prefixes) either positive or negative artificially smaller EID prefixes) either positive or negative
mappings. mappings.
In presence of malicious ETRs, overclaiming attacks are possible. In presence of malicious ETRs, overclaiming attacks are possible.
Such an attack happens when and ETR replies to a legitimate Map- Such an attack happens when and ETR replies to a legitimate Map-
Request message it received with a Map-Reply message that contains an Request message it received with a Map-Reply message that contains an
EID-Prefix that is larger than the prefix owned by the site that EID-Prefix that is larger than the prefix owned by the site that
encompasses the EID of the Map-Request. For instance if the prefix encompasses the EID of the Map-Request. For instance if the prefix
owned by the site is 192.0.2.0/25 but the Map-Reply contains a owned by the site is 192.0.2.0/25 but the Map-Reply contains a
mapping for 192.0.2.0/24, then the mapping will influence packets mapping for 192.0.2.0/24, then the mapping will influence packets
destined to other EIDs than the one the LISP site has authority on. destined to other EIDs than the one the LISP site has authority on.
A malicious ETR might also fragment its EID-to-RLOC database so that A malicious ETR might also fragment its configured EID-to-RLOC
ITR's might have to install much more mappings than really necessary. mappings so that ITR's might have to install much more mappings than
This attack is called de-aggregation attack. really necessary. This attack is called de-aggregation attack.
5.4.3. Attacks with Map-Register messages 4.4.3. Attacks with 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 perform an overclaiming attack 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.
A compromised ETR can also perform a deaggregation attack in order to A compromised ETR can also perform a deaggregation attack in order to
register more EID prefixes than necessary to its Map Servers. register more EID prefixes than necessary to its Map Servers.
5.4.4. Attacks with Map-Notify messages Similarly, a compromised Map Server can accept invalid registration
or advertise invalid EID prefix to the indexing sub-system.
4.4.4. Attacks with 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 spoofing attacker compromised ETR can send a Map-Register with the An compromised ETR using EID that it is not authoritative for can
M-bit set and a spoofed source address to force the Map Server to send a Map-Register with the M-bit set and a spoofed source address
send a Map-Notify message to the spoofed address and then succeed a to force the Map Server to send a Map-Notify message to the spoofed
relay attack. Similarly to the pair Map-Request/Map-Reply, the pair address and then succeed a relay attack. Similarly to the pair Map-
Map-Register/Map-Notify is protected by a nonce making hard for an Request/Map-Reply, the pair Map-Register/Map-Notify is protected by a
attacker to inject a falsified notification to an ETR to make this nonce making it hard for an attacker to inject a falsified
ETR believe that the registration succeeded while it has not. notification to an ETR to make this ETR believe that the registration
succeeded while it has not.
6. Attack categories 5. Attack categories
6.1. Intrusion 5.1. Intrusion
6.1.1. Description 5.1.1. Description
With an intrusion attack an attacker gains remote access to some With an intrusion attack an attacker gains remote access to some
resources (e.g., a host, a router, or a network) that are normally resources (e.g., a host, a router, or a network) that are normally
denied to her. denied to her.
6.1.2. Vectors 5.1.2. Vectors
Intrusion attacks can be mounted using: Intrusion attacks can be mounted using:
o Spoofing EID or RLOCs o Spoofing EID or RLOCs
o Instance ID bits o Instance ID bits
6.2. Denial of Service (DoS) 5.2. Denial of Service (DoS)
6.2.1. Description 5.2.1. Description
A Denial of Service (DoS) attack aims at disrupting a specific A Denial of Service (DoS) attack aims at disrupting a specific
targeted service either by exhausting the resources of the victim up 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 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 legit traffic and/or systems or by exploiting vulnerabilities to make
the targeted service unable to operate properly. the targeted service unable to operate properly.
6.2.2. Vectors 5.2.2. Vectors
Denial of Service attacks can be mounted using Denial of Service attacks can be mounted using
o Gleaning o Gleaning
o Interworking o Interworking
o Locator Status Bits o Locator Status Bits
o Map-Version bit o Map-Version bit
o Nonce-Present and Echo-Nonce bits o Nonce-Present and Echo-Nonce bits
o Map-Request message o Map-Request message
skipping to change at page 15, line 37 skipping to change at page 15, line 20
o Nonce-Present and Echo-Nonce bits o Nonce-Present and Echo-Nonce bits
o Map-Request message o Map-Request message
o Map-Reply message o Map-Reply message
o Map-Register message o Map-Register message
o Map-Notify message o Map-Notify message
6.3. Eavesdropping 5.3. Subversion
6.3.1. Description 5.3.1. Description
With an eavesdropping attack, the attacker collects traffic of a With subversion an attacker can gain access (e.g., using
target through deep packet inspection in order to gain access to eavesdropping or impersonation) to restricted or sensitive
restricted or sensitive information such as passwords, session information such as passwords, session tokens, or any other
tokens, or any other confidential information. This type of attack confidential information. This type of attack is usually carried out
is usually carried out in a way such that the target does not even in a way such that the target does not even notice the attack. When
notice the attack. When the attacker is positioned on the path of the attacker is positioned on the path of the target traffic, it is
the target traffic, it is called a Man-in-the-Middle attack. called a Man-in-the-Middle attack. However, this is not a
However, this is not a requirement to carry out and eavesdropping requirement to carry out and eavesdropping attack. Indeed the
attack. Indeed the attacker might be able, for instance through an attacker might be able, for instance through an intrusion attack on a
intrusion attack on a weaker system, either to duplicate or even re- weaker system, either to duplicate or even re-direct the traffic, in
direct the traffic, in both cases having access to the raw packets. both cases having access to the raw packets.
6.3.2. Vectors 5.3.2. Vectors
Eavesdropping attacks can be mounted using Subversion attacks can be mounted using
o Gleaning o Gleaning
o Locator Status Bits o Locator Status Bits
o Nonce-Present and the Echo-Nonce bits o Nonce-Present and the Echo-Nonce bits
o Map-Request messages o Map-Request messages
o Map-Reply messages o Map-Reply messages
7. Recommendations 6. IANA Considerations
This document makes no request to IANA.
TBD
8. IANA Considerations 7. Security Considerations
This document makes no request to IANA. This document is devoted to threat analysis of the Locator/Identifier
Separation Protocol and is then a piece of choice to understand the
security risks at stake while deploying LISP in non-trustable
environment.
9. Security Considerations The purpose of this document is not to provide recommendations to
protect against attacks, however most of threats can be prevented
with careful deployment and configuration (e.g., filter) and also by
applying the general rules in security that consist in activating
only features that are necessary in the deployment and verifying the
validity of the information obtained from third parties. More
detailed recommendation are given in [book_chapter].
Security considerations are the core of this document and do not need The control-plane is probably the most critical part of LISP from a
to be further discussed in this section. security viewpoint and it is worth to notice that the specifications
already offer authentication mechanism for Map-Register messages
([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.
10. Acknowledgments 8. 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 Florin Coras, Vina Ermagan, Darrel The authors would like to thank Ronald Bonica, Albert Cabellos, Noel
Lewis, and Jeff Wheeler for their comments. Chiappa, Florin Coras, Vina Ermagan, Dino Farinacci, 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 This work has been partially supported by the INFSO-ICT-216372
TRILOGY Project (www.trilogy-project.org). TRILOGY Project (www.trilogy-project.org).
11. References 9. References
11.1. Normative References 9.1. Normative References
[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security
Concerns with IP Tunneling", RFC 6169, April 2011. 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, January Locator/ID Separation Protocol (LISP)", RFC 6830, January
2013. 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
skipping to change at page 17, line 28 skipping to change at page 17, line 24
Separation Protocol (LISP) Map-Versioning", RFC 6834, Separation Protocol (LISP) Map-Versioning", RFC 6834,
January 2013. January 2013.
[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol Alternative Logical "Locator/ID Separation Protocol Alternative Logical
Topology (LISP+ALT)", RFC 6836, January 2013. Topology (LISP+ALT)", RFC 6836, January 2013.
[RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to
Routing Locator (RLOC) Database", RFC 6837, January 2013. Routing Locator (RLOC) Database", RFC 6837, January 2013.
11.2. Informative References 9.2. Informative References
[Chu] Jerry Chu, H., "Tuning TCP Parameters for the 21st Century [Chu] Jerry Chu, H., "Tuning TCP Parameters for the 21st Century
", 75th IETF, Stockholm, July 2009, ", 75th IETF, Stockholm, July 2009,
<http://tools.ietf.org/wg/savi/>. <http://tools.ietf.org/wg/savi/>.
[I-D.bagnulo-lisp-threat] [I-D.bagnulo-lisp-threat]
Bagnulo, M., "Preliminary LISP Threat Analysis", draft- Bagnulo, M., "Preliminary LISP Threat Analysis", draft-
bagnulo-lisp-threat-01 (work in progress), July 2007. bagnulo-lisp-threat-01 (work in progress), July 2007.
[I-D.ietf-lisp-ddt] [I-D.ietf-lisp-ddt]
skipping to change at page 18, line 33 skipping to change at page 18, line 31
November 2008. November 2008.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, February 2012. Secure Internet Routing", RFC 6480, February 2012.
[SAVI] IETF, "Source Address Validation Improvements Working [SAVI] IETF, "Source Address Validation Improvements Working
Group ", 2013, <http://tools.ietf.org/wg/savi/>. Group ", 2013, <http://tools.ietf.org/wg/savi/>.
[Saucez09] [Saucez09]
Saucez, D. and L. Iannone, "How to mitigate the effect of Saucez, D. and L. Iannone, "How to mitigate the effect of
scans on mapping systems ", Submitted to the Trilogy scans on mapping systems ", Trilogy Summer School on
Summer School on Future Internet, 2009. Future Internet, 2009.
[book_chapter]
Saucez, D., Iannone, L., and O. Bonaventure, "The Map-and-
Encap Locator/Identifier separation paradigm: a Security
Analysis ", Solutions for Sustaining Scalability in
Internet Growth, IGI Global, 2013.
Appendix A. Document Change Log Appendix A. Document Change Log
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. o Version 06 Posted October 2013.
* Complete restructuration, temporary version to be used at * Complete restructuration, temporary version to be used at
October 2013 interim meeting. October 2013 interim meeting.
o Version 05 Posted August 2013. o Version 05 Posted August 2013.
* Removal of severity levels to become a short recommendation to * Removal of severity levels to become a short recommendation to
reduce the risk of the discussed threat. reduce the risk of the discussed threat.
skipping to change at page 19, line 34 skipping to change at page 19, line 50
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 overclaiming and de-
aggregation (see Section 5.4.2). aggregation (see Section 4.4.2).
* 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 5.3.2. * Added discussion on Instance ID in Section 4.3.2.
* 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. 80 change blocks. 
211 lines changed or deleted 219 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/