draft-ietf-lisp-threats-08.txt   draft-ietf-lisp-threats-09.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 24, 2014 Telecom ParisTech Expires: October 10, 2014 Telecom ParisTech
O. Bonaventure O. Bonaventure
Universite catholique de Louvain Universite catholique de Louvain
October 21, 2013 April 8, 2014
LISP Threats Analysis LISP Threats Analysis
draft-ietf-lisp-threats-08.txt draft-ietf-lisp-threats-09.txt
Abstract Abstract
This document proposes a threat analysis of the Locator/Identifier This document proposes a threat analysis of the Locator/Identifier
Separation Protocol (LISP) if deployed in the Internet. Separation Protocol (LISP) if deployed in the Internet.
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 24, 2014. This Internet-Draft will expire on October 10, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. On-path Attackers . . . . . . . . . . . . . . . . . . . . . . 3 2. On-path Attackers . . . . . . . . . . . . . . . . . . . . . . 3
3. Off-Path Attackers: Reference Environment . . . . . . . . . . 4 3. Off-Path Attackers: Reference Environment . . . . . . . . . . 3
4. Attack vectors . . . . . . . . . . . . . . . . . . . . . . . 5 4. Attack vectors . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Configured EID-to-RLOC mappings . . . . . . . . . . . . . 5 4.1. Configured EID-to-RLOC mappings . . . . . . . . . . . . . 6
4.2. EID-to-RLOC Cache . . . . . . . . . . . . . . . . . . . . 6 4.2. EID-to-RLOC Cache . . . . . . . . . . . . . . . . . . . . 6
4.3. Attacks using the data-plane . . . . . . . . . . . . . . 6 4.3. Attacks using the data-plane . . . . . . . . . . . . . . . 7
4.3.1. Attacks not leveraging on the LISP header . . . . . . 6 4.3.1. Attacks not leveraging on the LISP header . . . . . . 7
4.3.2. Attacks leveraging on the LISP header . . . . . . . . 8 4.3.2. Attacks leveraging on the LISP header . . . . . . . . 8
4.4. Attacks using the control-plane . . . . . . . . . . . . . 11 4.4. Attacks using the control-plane . . . . . . . . . . . . . 11
4.4.1. Attacks with Map-Request messages . . . . . . . . . . 11 4.4.1. Attacks with Map-Request messages . . . . . . . . . . 11
4.4.2. Attacks with Map-Reply messages . . . . . . . . . . . 12 4.4.2. Attacks with Map-Reply messages . . . . . . . . . . . 12
4.4.3. Attacks with Map-Register messages . . . . . . . . . 13 4.4.3. Attacks with Map-Register messages . . . . . . . . . . 13
4.4.4. Attacks with Map-Notify messages . . . . . . . . . . 14 4.4.4. Attacks with Map-Notify messages . . . . . . . . . . . 14
5. Attack categories . . . . . . . . . . . . . . . . . . . . . . 14 5. Attack categories . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Intrusion . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1. Intrusion . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1.1. Description . . . . . . . . . . . . . . . . . . . . . 14 5.1.1. Description . . . . . . . . . . . . . . . . . . . . . 14
5.1.2. Vectors . . . . . . . . . . . . . . . . . . . . . . . 14 5.1.2. Vectors . . . . . . . . . . . . . . . . . . . . . . . 14
5.2. Denial of Service (DoS) . . . . . . . . . . . . . . . . . 14 5.2. Denial of Service (DoS) . . . . . . . . . . . . . . . . . 14
5.2.1. Description . . . . . . . . . . . . . . . . . . . . . 14 5.2.1. Description . . . . . . . . . . . . . . . . . . . . . 14
5.2.2. Vectors . . . . . . . . . . . . . . . . . . . . . . . 15 5.2.2. Vectors . . . . . . . . . . . . . . . . . . . . . . . 14
5.3. Subversion . . . . . . . . . . . . . . . . . . . . . . . 15 5.3. Subversion . . . . . . . . . . . . . . . . . . . . . . . . 15
5.3.1. Description . . . . . . . . . . . . . . . . . . . . . 15 5.3.1. Description . . . . . . . . . . . . . . . . . . . . . 15
5.3.2. Vectors . . . . . . . . . . . . . . . . . . . . . . . 15 5.3.2. Vectors . . . . . . . . . . . . . . . . . . . . . . . 15
6. Note on privacy . . . . . . . . . . . . . . . . . . . . . . . 16 6. Note on Privacy . . . . . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . 18 10.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Document Change Log . . . . . . . . . . . . . . . . 19 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
The Locator/ID Separation Protocol (LISP) is defined in [RFC6830]. The Locator/ID Separation Protocol (LISP) is specified in [RFC6830].
The present document assesses the security level and identifies The present document assess the potential security threats identified
security threats in the LISP specification if LISP is deployed in the in the LISP specifications if LISP is deployed in the Internet (i.e.,
Internet (i.e., a public non-trustable environment). As a result of a public non-trustable environment).
the performed analysis, the document discusses the severity of the
threats and proposes recommendations to reach the same level of
security in LISP than in Internet today (e.g., without LISP).
The document is composed of three main parts: the first discussing
the LISP data-plane; while the second discussing the LISP control-
plane. The final part summarizes the recommendations to prevent the
identified threats.
The LISP data-plane consists of LISP packet encapsulation,
decapsulation, and forwarding and includes the map cache data
structures used to perform these operations.
The LISP control-plane consists in the mapping distribution system, The document is composed of two main parts: the first discussing the
which can be one of the mapping distribution systems proposed so far techniques that can be used by attackers to succeed attacks based on
(e.g., [RFC6830], [I-D.ietf-lisp-ddt], [RFC6836], [RFC6833], the LISP protocol and architecture; the second discussing the main
[I-D.meyer-lisp-cons], and [RFC6837]), and the Map-Request, Map- categories of attacks and how to construct them.
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] and [I-D.ietf-lisp-deployment]. The document
including as well LISP Interworking [RFC6832], LISP-MS [RFC6833], and focuses on LISP unicast, including as well LISP Interworking
LISP Map-Versioning [RFC6834]. The reading of these documents is a [RFC6832], LISP-MS [RFC6833], and LISP Map-Versioning [RFC6834]. The
prerequisite for understanding the present document. reading of these documents is a prerequisite for understanding the
present document.
Unless otherwise stated, the document assumes a generic IP service This document assumes a generic IP service and does not discuss the
and does not discuss the difference, from a security viewpoint, difference, from a security viewpoint, between using IPv4 or IPv6.
between using IPv4 or IPv6.
2. On-path Attackers 2. 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 this document does secure packet payloads from on path attacks, so this document does
not consider on-path attackers in this document. not consider on-path attackers.
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. This documents does not consider time-shifted
document. attacks.
3. Off-Path Attackers: Reference Environment 3. Off-Path Attackers: Reference Environment
The reference environment shown in the figure below is considered The reference environment shown in the figure below is considered
throughout this document. There are two hosts attached to LISP throughout this document. There are two hosts attached to LISP
routers: HA and HB. HA is attached to the two LISP xTRs LR1 and LR2, routers: HA and HB. HA is attached to the two LISP xTRs LR1 and LR2,
which in turn are attached to two different ISPs. HB is attached to which in turn are attached to two different ISPs. HB is attached to
the two LISP xTRs LR3 and LR4. HA and HB are the EIDs of the two the two LISP xTRs LR3 and LR4. HA and HB are the EIDs of the two
hosts. LR1, LR2, LR3, and LR4 are the RLOCs of the xTRs. PxTR is a hosts. LR1, LR2, LR3, and LR4 are the RLOCs of the xTRs. PxTR is a
proxy xTR and MR/MS plays the roles of Map Server and/or Map proxy xTR and MR/MS plays the roles of Map Server and/or Map
Resolver. Resolver.
+-----+ +-----+
| HA | | HA |
+-----+ +-----+
| EID: HA | EID: HA
| |
----------------- -----------------
| | | |
+-----+ +-----+ +-----+ +-----+
| LR1 | | LR2 | | LR1 | | LR2 |
+-----+ +-----+ +-----+ +-----+
| | | |
| | | |
+-----+ +-----+ +-----+ +-----+
|ISP1 | |ISP2 | |ISP1 | |ISP2 |
+-----+ +-----+ +-----+ +-----+
| | | |
skipping to change at page 4, line 44 skipping to change at page 4, line 39
+------+ | | +-----+ +------+ | | +-----+
| Internet | | Internet |
+-------+ | | +-----+ +-------+ | | +-----+
| MR/MS |----| |-----| NSA | | MR/MS |----| |-----| NSA |
+-------+ +----------------+ +-----+ +-------+ +----------------+ +-----+
| | | |
+-----+ +-----+ +-----+ +-----+
| LR3 | | LR4 | | LR3 | | LR4 |
+-----+ +-----+ +-----+ +-----+
| | | |
------------------- -------------------
| |
| EID: HB | EID: HB
+-----+ +-----+
| HB | | HB |
+-----+ +-----+
Figure 1: Reference Network Figure 1: Reference Network
We consider two off-path attackers with different capabilities: We consider two off-path attackers with different capabilities:
SA is an off-path attacker that is able to send spoofed packets, SA is an off-path attacker that is able to send spoofed packets,
i.e., packets with a different source IP address than its i.e., packets with a different source IP address than its
assigned IP address. SA stands for Spoofing Attacker. assigned IP address. SA stands for Spoofing Attacker. To
perform some of the attacks described in this document SA needs
to be in a non-LISP site.
NSA is an off-path attacker that is only able to send packets whose NSA is an off-path attacker that is only able to send packets whose
source address is its assigned IP address. NSA stands for Non source address is its assigned IP address. NSA stands for Non
Spoofing Attacker. Spoofing Attacker.
It should be noted that with LISP, packet spoofing is slightly It should be noted that with LISP, packet spoofing is slightly
different than in the current Internet. Generally the term "spoofed different than in the current Internet. Generally the term "spoofed
packet" indicates a packet containing a source IP address that is not packet" indicates a packet containing a source IP address that is not
the one of the actual originator of the packet. Since LISP uses the one of the actual originator of the packet. 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
skipping to change at page 6, line 22 skipping to change at page 6, line 27
4.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 via the LISP control-plane. Attacks against this data ETR's mapping via the LISP control-plane. Attacks against this data
structure could happen either when the mappings are first installed structure could happen either when the mappings are first installed
in the cache or by corrupting (poisoning) the mappings already in the cache or by corrupting (poisoning) the mappings already
present in the cache. present in the cache.
This document calls "cache poisoning attack", any attack that alters Cache poisoning attacks are used to alter (any combination of) the
the EID-to-RLOC Cache. Cache poisoning attacks are use to alter (any following parts of the mappings installed in the EID-to-RLOC Cache:
combination of) the following parts of mapping installed 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
o Mapping version o Mapping version
o Mapping Instance ID o Mapping Instance ID
Cache poisoning attacks can be performed by attackers from the
outside of the attacked LISP network but also directly from the
inside. As a matter of fact, end-hosts behind an ITR can use the
data-plane to overflow the ITR's EID-to-RLOC Cache by sending packets
to non-popular EID prefixes (similar to scan attack but with a
different goal). In such a scenario the ITR may evict popular (in-
use) entries from the map-cache disrupting the normal operation of
the network by forcing cache miss [Florin13].
4.3. Attacks using the data-plane 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 configured EID-to-RLOC mappings as specified in the RLOC Cache and configured EID-to-RLOC mappings as specified in the
original LISP document ([RFC6830]). original LISP document ([RFC6830]).
4.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]).
Taking notation of the reference environment notation (Figure 1), to Taking notation of the reference environment (Figure 1), to inject a
inject a packet in the HA->HB flow, a spoofing off-path attacker (SA) packet in the HA->HB flow, a spoofing off-path attacker (SA) could
could send a LISP encapsulated packet whose source is set to LR1 or send a LISP encapsulated packet whose source is set to LR1 or LR2 and
LR2 and destination LR3 or LR4. The packet will reach HB as if the destination LR3 or LR4. The packet will reach HB as if the packet
packet was sent by host HA. This is not different from today's was sent by host HA. This is not different from today's Internet
Internet where a spoofing off-path attacker may inject data packets where a spoofing off-path attacker may inject data packets in any
in any flow. A non-spoofing off-path attacker (NSA) could only send flow. A non-spoofing off-path attacker (NSA) could only send a
a packet whose source address is set to its assigned IP address. The 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.
4.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
skipping to change at page 8, line 6 skipping to change at page 8, line 6
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 for host HA at that time. The xTR will store the gleaned entry and
use it to return the packets sent by host HB. In parallel, the ETR use it to return the packets sent by host HB. In parallel, the ETR
will 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 a given time
attacker could send to LR1 (resp. LR3) a LISP data encapsulated the attacker could send to LR1 (resp. LR3) a LISP data encapsulated
packet whose source RLOC is its IP address and contains an IP packet 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 establish 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.
4.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
skipping to change at page 9, line 51 skipping to change at page 9, line 45
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 4.4.1) so that more bandwidth is amplification attacks (see Section 4.4.1) so that more bandwidth is
consumed on the target than the bandwidth necessary at the attacker consumed on the target (because of the larger packets) than the
side. bandwidth necessary at the attacker side.
4.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.
skipping to change at page 10, line 32 skipping to change at page 10, line 27
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 attack, 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 create 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
skipping to change at page 11, line 10 skipping to change at page 11, line 6
4.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 to get off-path attacker can randomly guess a valid Instance ID value to get
access to network that might not been accessible in normal access to network that might not been accessible in normal
conditions. However, the impact of such attack is directly on end- conditions. However, such attacks target end-systems, which is out
systems which is is out of the scope of this document. of the scope of this document.
4.4. Attacks 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 the different LISP indexing sub- analyze the particularities of the different LISP indexing sub-
system. system.
4.4.1. Attacks with Map-Request messages 4.4.1. Attacks with Map-Request messages
skipping to change at page 11, line 39 skipping to change at page 11, line 35
The first possible exploitation is the RLOC record P bit. The RLOC The first possible exploitation is the RLOC record P bit. The RLOC
record P bit is used to probe the reachability of remote ETRs. In record P bit is used to probe the reachability of remote ETRs. In
our reference environment, LR3 could probe the reachability of LR1 by our reference environment, LR3 could probe the reachability of LR1 by
sending a Map-Request with the RLOC record P bit set. LR1 would sending a Map-Request with the RLOC record P bit set. LR1 would
reply by sending a Map-Reply message with the RLOC record P bit set reply by sending a Map-Reply message with the RLOC record P bit set
and the same nonce as in the Map-Request message. and the same nonce as in the Map-Request message.
A spoofing off-path attacker (SA) could use the RLOC record P bit to A spoofing off-path attacker (SA) could use the RLOC record P bit to
force a victim ETR to send a Map-Reply to the spoofed source address force a victim ETR to send a Map-Reply to the spoofed source address
of the Map-Request message. As the Map-Reply can be larger than the of the Map-Request message. As the Map-Reply can be larger than the
Map-Request message, there is a risk of amplification attack. Map-Request message, there is a risk of amplification attack. Map-
Considering only IPv6 addresses, a Map-Request can be as small as 40 Requests are usually smaller than a hundred bytes while the maximum
bytes, considering one single ITR address and no Mapping Protocol size of a Map-Reply (without considering any MTU constrain) can be
Data. The Map-Reply instead has a proportional to the maximum number above 1 MB, largely bigger than the message sent by the attacker.
of RLOCs in a mapping and maximum number of records in a Map-Reply. These numbers are however theoretical values not considering
Since up to 255 RLOCs can be associated to an EID-Prefix and 255 transport layer limitations and it is more likely that the reply will
records can be stored in a Map-Reply, the maximum size of a Map-Reply contain only one record with at most a dozen of locators, limiting so
is thus above 1 MB, largely bigger than the message sent by the the amplification factor.
attacker. These numbers are however theoretical values not
considering transport layer limitations and it is more likely that
the reply will contain only one record with at most a dozen of
locators, limiting so the amplification factor.
Similarly, if a non-spoofing off-path attacker (NSA) sends a Map- Similarly, if a non-spoofing off-path attacker (NSA) sends a Map-
Request with the RLOC record P bit set, it will receive a Map-Reply Request with the RLOC record P bit set, it will receive a Map-Reply
with the RLOC record P 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 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 RLOC the corresponding mapping. Note that according to [RFC6830] the SMR-
record P bit discussed above except that as the Map-Request messages triggered Map-Request might be sent through the mapping system,
are smaller than Map-Reply messages, the risk of amplification depending on the number of RLOCs in the locators set. This raises
attacks is reduced. This is not true anymore if the ETR append to similar problems as the RLOC record P bit discussed above except that
the Map-Request messages its own Map-Records. This mechanism is as the Map-Request messages are smaller than Map-Reply messages, the
meant to reduce the delay in mapping distribution since mapping risk of amplification attacks is reduced. This is not true anymore
information is provided in the Map-Request message. if the ETR append to the Map-Request messages its own Map-Records.
This mechanism is meant to reduce the delay in mapping distribution
since mapping information is provided in the Map-Request message.
Furthermore, appending Map-Records to Map-Request messages allows an 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
skipping to change at page 14, line 20 skipping to change at page 14, line 10
register more EID prefixes than necessary to its Map Servers. register more EID prefixes than necessary to its Map Servers.
Similarly, a compromised Map Server can accept invalid registration Similarly, a compromised Map Server can accept invalid registration
or advertise invalid EID prefix to the indexing sub-system. or advertise invalid EID prefix to the indexing sub-system.
4.4.4. Attacks with Map-Notify messages 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.
An compromised ETR using EID that it is not authoritative for can A compromised ETR using EID that it is not authoritative for can send
send a Map-Register with the M-bit set and a spoofed source address a Map-Register with the M-bit set and a spoofed source address to
to force the Map Server to send a Map-Notify message to the spoofed force the Map Server to send a Map-Notify message to the spoofed
address and then succeed a relay attack. Similarly to the pair Map- address and then succeed a relay attack. Similarly to the pair Map-
Request/Map-Reply, the pair Map-Register/Map-Notify is protected by a Request/Map-Reply, the pair Map-Register/Map-Notify is protected by a
nonce making it hard for an attacker to inject a falsified nonce making it hard for an attacker to inject a falsified
notification to an ETR to make this ETR believe that the registration notification to an ETR to make this ETR believe that the registration
succeeded while it has not. succeeded while it has not.
5. Attack categories 5. Attack categories
5.1. Intrusion 5.1. Intrusion
skipping to change at page 16, line 4 skipping to change at page 15, line 43
requirement to carry out and eavesdropping attack. Indeed the requirement to carry out and eavesdropping attack. Indeed the
attacker might be able, for instance through an intrusion attack on a attacker might be able, for instance through an intrusion attack on a
weaker system, either to duplicate or even re-direct the traffic, in weaker system, either to duplicate or even re-direct the traffic, in
both cases having access to the raw packets. both cases having access to the raw packets.
5.3.2. Vectors 5.3.2. Vectors
Subversion 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
6. Note on privacy 6. Note on Privacy
As presented by [RFC6973], universal privacy considerations are As presented by [RFC6973], universal privacy considerations are
impossible to establish as the privacy definition may vary from one impossible to establish as the privacy definition may vary from one
to another. As a consequence, this document does not aim at to another. As a consequence, this document does not aim at
identifying privacy issues related to the LISP protocol but it is identifying privacy issues related to the LISP protocol but it is
necessary to highlight that security threats identified in this necessary to highlight that security threats identified in this
document could play a role in privacy threats as defined in section 5 document could play a role in privacy threats as defined in section 5
of [RFC6973]. of [RFC6973].
7. IANA Considerations 7. IANA Considerations
skipping to change at page 16, line 39 skipping to change at page 16, line 32
Separation Protocol and is then a piece of choice to understand the Separation Protocol and is then a piece of choice to understand the
security risks at stake while deploying LISP in non-trustable security risks at stake while deploying LISP in non-trustable
environment. environment.
The purpose of this document is not to provide recommendations to The purpose of this document is not to provide recommendations to
protect against attacks, however most of threats can be prevented protect against attacks, however most of threats can be prevented
with careful deployment and configuration (e.g., filter) and also by with careful deployment and configuration (e.g., filter) and also by
applying the general rules in security that consist in activating applying the general rules in security that consist in activating
only features that are necessary in the deployment and verifying the only features that are necessary in the deployment and verifying the
validity of the information obtained from third parties. More validity of the information obtained from third parties. More
detailed recommendation are given in [book_chapter]. detailed recommendations are given in [Saucez13].
The control-plane is probably the most critical part of LISP from a The control-plane is probably the most critical part of LISP from a
security viewpoint and it is worth to notice that the specifications security viewpoint and it is worth to notice that the specifications
already offer authentication mechanism for Map-Register messages already offer authentication mechanism for Map-Register messages
([RFC6833]) and that [I-D.ietf-lisp-sec] and [I-D.ietf-lisp-ddt] are ([RFC6833]) and that [I-D.ietf-lisp-sec] and [I-D.ietf-lisp-ddt] are
clearly going in the direction of a secure control-plane. clearly going in the direction of a secure control-plane.
9. Acknowledgments 9. Acknowledgments
This document builds upon the draft of Marcelo Bagnulo This document builds upon the draft of Marcelo Bagnulo
skipping to change at page 17, line 19 skipping to change at page 17, line 8
reference environment were first described. reference environment were first described.
The authors would like to thank Ronald Bonica, Albert Cabellos, Noel The authors would like to thank Ronald Bonica, Albert Cabellos, Noel
Chiappa, Florin Coras, Vina Ermagan, Dino Farinacci, Stephen Farrell, Chiappa, Florin Coras, Vina Ermagan, Dino Farinacci, Stephen Farrell,
Joel Halpern, Emily Hiltzik, Darrel Lewis, Edward Lopez, Fabio Maino, Joel Halpern, Emily Hiltzik, Darrel Lewis, Edward Lopez, Fabio Maino,
Terry Manderson, and Jeff Wheeler for their comments. Terry Manderson, and Jeff Wheeler for their comments.
This work has been partially supported by the INFSO-ICT-216372 This work has been partially supported by the INFSO-ICT-216372
TRILOGY Project (www.trilogy-project.org). TRILOGY Project (www.trilogy-project.org).
The work of Luigi Iannone has been partially supported by the ANR-13-
INFR-0009 LISP-Lab Project (www.lisp-lab.org) and the EIT KIC ICT-
Labs SOFNETS Project.
10. References 10. References
10.1. Normative References 10.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,
2013. January 2013.
[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
"Interworking between Locator/ID Separation Protocol "Interworking between Locator/ID Separation Protocol
(LISP) and Non-LISP Sites", RFC 6832, January 2013. (LISP) and Non-LISP Sites", RFC 6832, January 2013.
[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation
Protocol (LISP) Map-Server Interface", RFC 6833, January Protocol (LISP) Map-Server Interface", RFC 6833,
2013. January 2013.
[RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
Separation Protocol (LISP) Map-Versioning", RFC 6834, Separation Protocol (LISP) Map-Versioning", RFC 6834,
January 2013. January 2013.
[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol Alternative Logical
Topology (LISP+ALT)", RFC 6836, January 2013.
[RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to
Routing Locator (RLOC) Database", RFC 6837, January 2013.
[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, July Considerations for Internet Protocols", RFC 6973,
2013. July 2013.
10.2. Informative References 10.2. Informative References
[Chu] Jerry Chu, H., "Tuning TCP Parameters for the 21st Century [Florin13]
", 75th IETF, Stockholm, July 2009, Coras, F., Domingo-Pascual, J., Lewis, D., and A.
<http://tools.ietf.org/wg/savi/>. Cabellos-Aparicio, "An Analytical Model for Loc/ID
Mappings Caches", Technical Report. arXiv:1312.1378v2,
2013, <http://arxiv.org/pdf/1312.1378v2.pdf>.
[I-D.bagnulo-lisp-threat] [I-D.bagnulo-lisp-threat]
Bagnulo, M., "Preliminary LISP Threat Analysis", draft- Bagnulo, M., "Preliminary LISP Threat Analysis",
bagnulo-lisp-threat-01 (work in progress), July 2007. draft-bagnulo-lisp-threat-01 (work in progress),
July 2007.
[I-D.ietf-lisp-ddt] [I-D.ietf-lisp-ddt]
Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP
Delegated Database Tree", draft-ietf-lisp-ddt-01 (work in Delegated Database Tree", draft-ietf-lisp-ddt-01 (work in
progress), March 2013. progress), March 2013.
[I-D.ietf-lisp-deployment]
Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-
Pascual, J., and D. Lewis, "LISP Network Element
Deployment Considerations", draft-ietf-lisp-deployment-12
(work in progress), January 2014.
[I-D.ietf-lisp-sec] [I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D., Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D.,
and O. Bonaventure, "LISP-Security (LISP-SEC)", draft- and O. Bonaventure, "LISP-Security (LISP-SEC)",
ietf-lisp-sec-04 (work in progress), October 2012. draft-ietf-lisp-sec-05 (work in progress), October 2013.
[I-D.ietf-tcpm-tcp-security]
Gont, F., "Survey of Security Hardening Methods for
Transmission Control Protocol (TCP) Implementations",
draft-ietf-tcpm-tcp-security-03 (work in progress), March
2012.
[I-D.meyer-lisp-cons]
Brim, S., "LISP-CONS: A Content distribution Overlay
Network Service for LISP", draft-meyer-lisp-cons-04 (work
in progress), April 2008.
[I-D.saucez-lisp-mapping-security]
Saucez, D. and O. Bonaventure, "Securing LISP Mapping
replies", draft-saucez-lisp-mapping-security-00 (work in
progress), February 2011.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing [Saucez13]
Security: An Unauthenticated Mode of IPsec", RFC 5386,
November 2008.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, February 2012.
[SAVI] IETF, "Source Address Validation Improvements Working
Group ", 2013, <http://tools.ietf.org/wg/savi/>.
[Saucez09]
Saucez, D. and L. Iannone, "How to mitigate the effect of
scans on mapping systems ", Trilogy Summer School on
Future Internet, 2009.
[book_chapter]
Saucez, D., Iannone, L., and O. Bonaventure, "The Map-and- Saucez, D., Iannone, L., and O. Bonaventure, "The Map-and-
Encap Locator/Identifier separation paradigm: a Security Encap Locator/Identifier separation paradigm: a Security
Analysis ", Solutions for Sustaining Scalability in Analysis", Solutions for Sustaining Scalability in
Internet Growth, IGI Global, 2013. Internet Growth, IGI Global, 2013.
Appendix A. Document Change Log Appendix A. Document Change Log
o Version 09 Posted March 2014.
* Updated document according to the review of A. Cabellos.
o Version 08 Posted October 2013. o Version 08 Posted October 2013.
* Addition of a privacy consideration note. * Addition of a privacy consideration note.
* Editorial changes * Editorial changes
o Version 07 Posted October 2013. o Version 07 Posted October 2013.
* This version is updated according to the thorough review made * This version is updated according to the thorough review made
during October 2013 LISP WG interim meeting. during October 2013 LISP WG interim meeting.
 End of changes. 45 change blocks. 
176 lines changed or deleted 147 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/