draft-ietf-lisp-threats-10.txt   draft-ietf-lisp-threats-11.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: January 5, 2015 Telecom ParisTech Expires: July 3, 2015 Telecom ParisTech
O. Bonaventure O. Bonaventure
Universite catholique de Louvain Universite catholique de Louvain
July 4, 2014 December 30, 2014
LISP Threats Analysis LISP Threats Analysis
draft-ietf-lisp-threats-10.txt draft-ietf-lisp-threats-11.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). Separation Protocol (LISP).
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 5, 2015. This Internet-Draft will expire on July 3, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Threat model . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Threat model . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Attacker modes of operation . . . . . . . . . . . . . . . 4 2.1. Attacker's Operation Modes . . . . . . . . . . . . . . . 3
2.1.1. On-path attackers vs. Off-path attackers . . . . . . . 4 2.1.1. On-path vs. Off-path Attackers . . . . . . . . . . . 4
2.1.2. Internal attackers vs. External attackers . . . . . . 4 2.1.2. Internal vs. External Attackers . . . . . . . . . . . 4
2.1.3. Live attackers vs. Time-shifted attackers . . . . . . 4 2.1.3. Live vs. Time-shifted attackers . . . . . . . . . . . 4
2.1.4. Control-plane attackers vs. Data-plane attackers . . . 5 2.1.4. Control-plane vs. Data-plane attackers . . . . . . . 4
2.1.5. Cross mode attackers . . . . . . . . . . . . . . . . . 5 2.1.5. Cross mode attackers . . . . . . . . . . . . . . . . 5
2.2. Threat categories . . . . . . . . . . . . . . . . . . . . 5 2.2. Threat categories . . . . . . . . . . . . . . . . . . . . 5
2.2.1. Replay attack . . . . . . . . . . . . . . . . . . . . 5 2.2.1. Replay attack . . . . . . . . . . . . . . . . . . . . 5
2.2.2. Packet manipulation . . . . . . . . . . . . . . . . . 5 2.2.2. Packet manipulation . . . . . . . . . . . . . . . . . 5
2.2.3. Packet interception and suppression . . . . . . . . . 6 2.2.3. Packet interception and suppression . . . . . . . . . 5
2.2.4. Spoofing . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.4. Spoofing . . . . . . . . . . . . . . . . . . . . . . 5
2.2.5. Rogue attack . . . . . . . . . . . . . . . . . . . . . 6 2.2.5. Rogue attack . . . . . . . . . . . . . . . . . . . . 6
2.2.6. Denial of Service (DoS) attack . . . . . . . . . . . . 7 2.2.6. Denial of Service (DoS) attack . . . . . . . . . . . 6
2.2.7. Performance attack . . . . . . . . . . . . . . . . . . 7 2.2.7. Performance attack . . . . . . . . . . . . . . . . . 7
2.2.8. Intrusion attack . . . . . . . . . . . . . . . . . . . 7 2.2.8. Intrusion attack . . . . . . . . . . . . . . . . . . 7
2.2.9. Amplification attack . . . . . . . . . . . . . . . . . 7 2.2.9. Amplification attack . . . . . . . . . . . . . . . . 7
2.2.10. Multi-category attacks . . . . . . . . . . . . . . . . 7 2.2.10. Multi-category attacks . . . . . . . . . . . . . . . 7
3. Attack vectors . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Attack vectors . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Gleaning . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Gleaning . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Locator Status Bits . . . . . . . . . . . . . . . . . . . 9 3.2. Locator Status Bits . . . . . . . . . . . . . . . . . . . 9
3.3. Map-Version . . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Map-Version . . . . . . . . . . . . . . . . . . . . . . . 9
3.4. Echo-Nonce algorithm . . . . . . . . . . . . . . . . . . . 10 3.4. Echo-Nonce . . . . . . . . . . . . . . . . . . . . . . . 10
3.5. Instance ID . . . . . . . . . . . . . . . . . . . . . . . 11 3.5. Instance ID . . . . . . . . . . . . . . . . . . . . . . . 11
3.6. Interworking . . . . . . . . . . . . . . . . . . . . . . . 11 3.6. Interworking . . . . . . . . . . . . . . . . . . . . . . 11
3.7. Map-Request messages . . . . . . . . . . . . . . . . . . . 12 3.7. Map-Request messages . . . . . . . . . . . . . . . . . . 12
3.8. Map-Reply messages . . . . . . . . . . . . . . . . . . . . 13 3.8. Map-Reply messages . . . . . . . . . . . . . . . . . . . 12
3.9. Map-Register messages . . . . . . . . . . . . . . . . . . 14 3.9. Map-Register messages . . . . . . . . . . . . . . . . . . 14
3.10. Map-Notify messages . . . . . . . . . . . . . . . . . . . 14 3.10. Map-Notify messages . . . . . . . . . . . . . . . . . . . 14
4. Note on Privacy . . . . . . . . . . . . . . . . . . . . . . . 14 4. Note on Privacy . . . . . . . . . . . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 17 Appendix A. Document Change Log . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
The Locator/ID Separation Protocol (LISP) is specified in [RFC6830]. The Locator/ID Separation Protocol (LISP) is specified in [RFC6830].
The present document assess the potential security threats identified The present document assess the potential security threats identified
in the LISP specifications if LISP is deployed in the Internet (i.e., in the LISP specifications if LISP is deployed in the Internet (i.e.,
a public non-trustable environment). a public non-trustable environment).
The document is composed of three main parts: the first defines the The document is composed of three main parts: the first defines the
general threat model that attackers can follow to mount attacks. The general threat model that attackers can follow to mount attacks. The
second describing the techniques based on the LISP protocol and second describing the techniques based on the LISP protocol and
architecture that attackers can use to construct attacks. The third architecture that attackers can use to construct attacks. The third
discussing general solutions to protect the LISP protocol and discussing mitigation techniques and general solutions to protect the
architecture from attacks. LISP protocol and architecture from attacks.
This document does not consider all the possible uses of LISP as This document does not consider all the possible uses of LISP as
discussed in [RFC6830] and [RFC7215]. The document focuses on LISP discussed in [RFC6830] and [RFC7215]. The document focuses on LISP
unicast, including as well LISP Interworking [RFC6832], LISP-MS unicast, including as well LISP Interworking [RFC6832], LISP-MS
[RFC6833], and LISP Map-Versioning [RFC6834]. The reading of these [RFC6833], and LISP Map-Versioning [RFC6834]. The reading of these
documents is a prerequisite for understanding the present document. documents is a prerequisite for understanding the present document.
This document assumes a generic IP service and does not discuss the This document assumes a generic IP service and does not discuss the
difference, from a security viewpoint, between using IPv4 or IPv6. difference, from a security viewpoint, between using IPv4 or IPv6.
skipping to change at page 4, line 7 skipping to change at page 3, line 48
an attack, even though they are not directly targeted by the attack. an attack, even though they are not directly targeted by the attack.
The target of an attack can be selected specifically, i.e., a The target of an attack can be selected specifically, i.e., a
particular entity, or arbitrarily, i.e., any entity. Finally, an particular entity, or arbitrarily, i.e., any entity. Finally, an
attacker can aim at attacking one or several targets with a single attacker can aim at attacking one or several targets with a single
attack. attack.
Section 2.1 specifies the different modes of operation that attackers Section 2.1 specifies the different modes of operation that attackers
can follow to mount attacks and Section 2.2 specifies the different can follow to mount attacks and Section 2.2 specifies the different
categories of attacks that attackers can build. categories of attacks that attackers can build.
2.1. Attacker modes of operation 2.1. Attacker's Operation Modes
Attackers can be classified according to the following four modes of Attackers can be classified according to the following four modes of
operation, i.e., the temporal and spacial locality of the attacker. operation, i.e., the temporal and spacial diversity of the attacker.
2.1.1. On-path attackers vs. Off-path attackers 2.1.1. On-path vs. Off-path Attackers
On-path attackers, also known as Men-in-the-Middle, are able to On-path attackers, also known as Men-in-the-Middle, are able to
intercept and modify packets between legitimate communicating intercept and modify packets between legitimate communicating
entities. On-path attackers are located either directly on the entities. On-path attackers are located either directly on the
normal communication path (either by gaining access to a node on the normal communication path (either by gaining access to a node on the
path or by placing themselves directly on the path) or outside the path or by placing themselves directly on the path) or outside the
location path but manage to deviate or gain a copy of packets sent location path but manage to deviate (or gain a copy of) packets sent
between the communication entities. On-path attackers hence mount between the communication entities. On-path attackers hence mount
their attacks by modifying packets initially sent legitimately their attacks by modifying packets initially sent legitimately
between communication entities. between communication entities.
An attacker is called off-path attacker if it does not have access to An attacker is called off-path attacker if it does not have access to
packets exchanged during the communication or if there is no packets exchanged during the communication or if there is no
communication. To succeed their attacks, off-path attackers must communication. To succeed their attacks, off-path attackers must
hence generate packets and inject them in the network. hence generate packets and inject them in the network.
2.1.2. Internal attackers vs. External attackers 2.1.2. Internal vs. External Attackers
An internal attacker launches its attack from a node located within a An internal attacker launches its attack from a node located within a
legitimate LISP site. Such an attacker is either a legitimate node legitimate LISP site. Such an attacker is either a legitimate node
of the site or it exploits a vulnerability to gain access to a of the site or it exploits a vulnerability to gain access to a
legitimate node in the site. Because of their location, internal legitimate node in the site. Because of their location, internal
attackers are trusted by the site they are in. attackers are trusted by the site they are in.
On the contrary, an external attacker launches its attacks from the On the contrary, an external attacker launches its attacks from the
outside of a legitimate LISP site. outside of a legitimate LISP site.
2.1.3. Live attackers vs. Time-shifted attackers 2.1.3. Live vs. Time-shifted attackers
A live attacker mounts attacks for which it must remain connected as A live attacker mounts attacks for which it must remain connected as
long as the attack is mounted. In other words, the attacker must long as the attack is mounted. In other words, the attacker must
remain active for the whole duration of the attack. Consequently, remain active for the whole duration of the attack. Consequently,
the attack ends as soon as the attacker (or the used attack vector) the attack ends as soon as the attacker (or the used attack vector)
is neutralized. is neutralized.
On the contrary, a time-shifted attacker mounts attacks that remain On the contrary, a time-shifted attacker mounts attacks that remain
active after it disconnects from the Internet. active after it disconnects from the Internet.
2.1.4. Control-plane attackers vs. Data-plane attackers 2.1.4. Control-plane vs. Data-plane attackers
A control-plane attacker mounts its attack by using control-plane A control-plane attacker mounts its attack by using control-plane
functionalities, typically the mapping system. functionalities, typically the mapping system.
A data-plane attacker mounts its attack by using data-plane A data-plane attacker mounts its attack by using data-plane
functionalities. functionalities.
As there is no strict delimitation between the control-plane and the As there is no complete isolation between the control-plane and the
data-plane, an attacker can operate in the control-plane (resp. data- data-plane, an attacker can operate in the control-plane (resp.
plane) to mount attacks targeting the data-plane (resp. control- data-plane) to mount attacks targeting the data-plane (resp.
plane) or keep the attacked and targeted planes at the same layer control-plane) or keep the attacked and targeted planes at the same
(i.e., from control-plane to control-plane or from data-plane to layer (i.e., from control-plane to control-plane or from data-plane
data-plane). to data-plane).
2.1.5. Cross mode attackers 2.1.5. Cross mode attackers
The attacker modes of operation are not mutually exclusive and hence The attacker modes of operation are not mutually exclusive and hence
attackers can combine them to mount attacks. attackers can combine them to mount attacks.
For example, an attacker can launch an attack using the control-plane For example, an attacker can launch an attack using the control-plane
directly from within a LISP site to which it got temporary access directly from within a LISP site to which it got temporary access
(i.e., internal + control-plane attacker) to create a vulnerability (i.e., internal + control-plane attacker) to create a vulnerability
on its target and later on (i.e., time-shifted + external attacker) on its target and later on (i.e., time-shifted + external attacker)
skipping to change at page 5, line 47 skipping to change at page 5, line 39
A replay attack happens when an attacker retransmits at a later time, A replay attack happens when an attacker retransmits at a later time,
and without modifying it, a packet (or a sequence of packets) that and without modifying it, a packet (or a sequence of packets) that
has already been transmitted. has already been transmitted.
2.2.2. Packet manipulation 2.2.2. Packet manipulation
A packet manipulation attack happens when an attacker receives a A packet manipulation attack happens when an attacker receives a
packet, modifies the packet (i.e., changes some information contained packet, modifies the packet (i.e., changes some information contained
in the packet) and finally transmits the packet to its final in the packet) and finally transmits the packet to its final
destination that can be the initial destination of the packet or destination that can be the initial destination of the packet or a
another one. different one.
2.2.3. Packet interception and suppression 2.2.3. Packet interception and suppression
In a packet interception and suppression attack, the attacker In a packet interception and suppression attack, the attacker
captures the packet and drops it before it can reach its final captures the packet and drops it before it can reach its final
destination. destination.
2.2.4. Spoofing 2.2.4. Spoofing
With a spoofing attack, the attacker injects packets in the network With a spoofing attack, the attacker injects packets in the network
skipping to change at page 6, line 31 skipping to change at page 6, line 19
originator of the packet. Hence, since LISP uses encapsulation, the originator of the packet. Hence, since LISP uses encapsulation, the
spoofed address could be in the outer header as well as in the inner spoofed address could be in the outer header as well as in the inner
header, this translates in two types of spoofing. header, this translates in two types of spoofing.
Inner address spoofing: the attacker uses encapsulation and uses a Inner address spoofing: the attacker uses encapsulation and uses a
spoofed source address in the inner packet. In case of data- spoofed source address in the inner packet. In case of data-
plane LISP encapsulation, that corresponds to spoof the source plane LISP encapsulation, that corresponds to spoof the source
EID address of the encapsulated packet. EID address of the encapsulated packet.
Outer address spoofing: the attacker does not use encapsulation and Outer address spoofing: the attacker does not use encapsulation and
spoofs the source address of the packet. spoofs the source address of the packet. In case of data-plane
LISP encapsulation, that corresponds to spoof the source RLOC
address of the encapsulated packet.
Note that the two types of spoofing are not mutually exclusive, Note that the two types of spoofing are not mutually exclusive,
rather all combinations are possible and could be used to perform rather all combinations are possible and could be used to perform
different kind of attacks. For example, an attacker not in a LISP different kind of attacks. For example, an attacker outside a LISP
site can generate a packet with a forged source IP address (i.e., site can generate a packet with a forged source IP address (i.e.,
outer address spoofing) and forward it to a LISP destination. The outer address spoofing) and forward it to a LISP destination. The
packet is then eventually encapsulated by a PITR so that once packet is then eventually encapsulated by a PITR so that once
encapsulated the attack corresponds to a inner address spoofing. One encapsulated the attack corresponds to a inner address spoofing. One
can also imagine an attacker forging a packet with encapsulation can also imagine an attacker forging a packet with encapsulation
where both inner an outer source addresses are spoofed. where both inner an outer source addresses are spoofed.
It is important to notice that the combination of inner and outer It is important to notice that the combination of inner and outer
spoofing makes the identification of the attacker complex as the spoofing makes the identification of the attacker complex as the
packet may not contain information that permits to detect the origin packet may not contain information that allows to detect the origin
of the attack. of the attack.
2.2.5. Rogue attack 2.2.5. Rogue attack
In a rogue attack the attacker manages to appear as a legitimate In a rogue attack the attacker manages to appear as a legitimate
source of information, without faking its identity (as opposed to a source of information, without faking its identity (as opposed to a
spoofing attacker). spoofing attacker).
2.2.6. Denial of Service (DoS) attack 2.2.6. Denial of Service (DoS) attack
skipping to change at page 8, line 45 skipping to change at page 8, line 39
DoS and performance attacks on the control-plane. For example, if an DoS and performance attacks on the control-plane. For example, if an
attacker sends a packet for each address of a prefix not yet cached attacker sends a packet for each address of a prefix not yet cached
in the EID-to-RLOC cache of an xTR, the xTR will potentially send a in the EID-to-RLOC cache of an xTR, the xTR will potentially send a
Map-Request for each such packet until the mapping is installed which Map-Request for each such packet until the mapping is installed which
leads to an over-utilisation of the control-plane as each packet leads to an over-utilisation of the control-plane as each packet
generates a control-plane event. For succeeding this example, the generates a control-plane event. For succeeding this example, the
attacker may not need to use spoofing. attacker may not need to use spoofing.
Gleaning attacks are fundamentally involving a time-shifted mode of Gleaning attacks are fundamentally involving a time-shifted mode of
operation as the attack may last as long as the gleaned entry is kept operation as the attack may last as long as the gleaned entry is kept
by the targeted xTR. Nevertheless, [RFC6830] recommends to store the by the targeted xTR. RFC 6830 [RFC6830] recommends to store the
gleaned entries for only a few seconds which limits the duration of gleaned entries for only a few seconds which limits the duration of
the attack. the attack.
Gleaning attacks always involve external data-plane attackers but Gleaning attacks always involve external data-plane attackers but
results in attacks on either the control-plane or data-plane. results in attacks on either the control-plane or data-plane.
It is worth to notice that the outer spoofed address does not need to It is worth to notice that the outer spoofed address does not need to
be the RLOC of a LISP site an may be any address. be the RLOC of a LISP site an may be any address.
3.2. Locator Status Bits 3.2. Locator Status Bits
When the L bit is set to 1, it indicates that the second 32-bits When the L bit in the LISP header is set to 1, it indicates that the
longword of the LISP header contains the Locator Status Bits. In second 32-bits longword of the LISP header contains the Locator
this field, each bit position reflects the status of one of the RLOCs Status Bits. In this field, each bit position reflects the status of
mapped to the source EID found in the encapsulated packet. The one of the RLOCs mapped to the source EID found in the encapsulated
reaction of a LISP xTR that receives such a packet is left as packet. The reaction of a LISP xTR that receives such a packet is
operational choice in [RFC6830]. left as operational choice in [RFC6830].
When an attacker sends a LISP encapsulated packet with a crafted LSB When an attacker sends a LISP encapsulated packet with a crafted LSB
to an xTR, it can influence the xTR's choice of the locators for the to an xTR, it can influence the xTR's choice of the locators for the
prefix associated to the source EID. In case of an off-path prefix associated to the source EID. In case of an off-path
attacker, the attacker must inject a forged packet in the network attacker, the attacker must inject a forged packet in the network
with a spoofed inner address. An on-path attacker can manipulate the with a spoofed inner address. An on-path attacker can manipulate the
LSB of legitimate packets passing through it and hence does not need LSB of legitimate packets passing through it and hence does not need
to use spoofing. Instead of manipulating the LSB field, an on-path to use spoofing. Instead of manipulating the LSB field, an on-path
attacker can also obtain the same result of injecting packets with attacker can also obtain the same result of injecting packets with
invalid LSB values by replaying packets. invalid LSB values by replaying packets.
skipping to change at page 9, line 45 skipping to change at page 9, line 44
one of the RLOCs specified in the mapping, forcing packets to go via one of the RLOCs specified in the mapping, forcing packets to go via
that RLOC implies that the attacker will gain access to the packets. that RLOC implies that the attacker will gain access to the packets.
Attacks using the LSB are fundamentally involving a time-shifted mode Attacks using the LSB are fundamentally involving a time-shifted mode
of operation as the attack may last as long as the reachability of operation as the attack may last as long as the reachability
information gathered from the LSB is used by the xTR to decide the information gathered from the LSB is used by the xTR to decide the
RLOCs to be used. RLOCs to be used.
3.3. Map-Version 3.3. Map-Version
When the Map-Version bit is set to 1, it indicates that the low-order When the Map-Version bit of the LISP header is set to 1, it indicates
24 bits of the first 32 bits longword of the LISP header contain a that the low-order 24 bits of the first 32 bits longword of the LISP
Source and Destination Map-Version. When a LISP xTR receives a LISP header contain a Source and Destination Map-Version. When a LISP xTR
encapsulated packet with the Map-Version bit set to 1, the following receives a LISP encapsulated packet with the Map-Version bit set to
actions are taken: 1, the following actions are taken:
o It compares the Destination Map-Version found in the header with o It compares the Destination Map-Version found in the header with
the current version of its own configured EID-to-RLOC mapping, for the current version of its own configured EID-to-RLOC mapping, for
the destination EID found in the encapsulated packet. If the the destination EID found in the encapsulated packet. If the
received Destination Map-Version is smaller (i.e., older) than the received Destination Map-Version is smaller (i.e., older) than the
current version, the ETR should apply the SMR procedure described current version, the ETR should apply the SMR procedure described
in [RFC6830] and send a Map-Request with the SMR bit set. in [RFC6830] and send a Map-Request with the SMR bit set.
o If a mapping exists in the EID-to-RLOC Cache for the source EID, o If a mapping exists in the EID-to-RLOC Cache for the source EID,
then it compares the Map-Version of that entry with the Source then it compares the Map-Version of that entry with the Source
skipping to change at page 10, line 35 skipping to change at page 10, line 31
control-plane packets sent in response to the attacker's packet. control-plane packets sent in response to the attacker's packet.
With a spoofing attack and if the xTR considers that the spoofed ITR With a spoofing attack and if the xTR considers that the spoofed ITR
has an outdated mapping, it will send an SMR to the spoofed ITR which has an outdated mapping, it will send an SMR to the spoofed ITR which
can result in performance, amplification, or DoS attack as well. can result in performance, amplification, or DoS attack as well.
Map-Version attackers are inherently cross mode as the Map-Version is Map-Version attackers are inherently cross mode as the Map-Version is
a method to put control information in the data-plane. Moreover, a method to put control information in the data-plane. Moreover,
this vector involves live attackers. Nevertheless, on-path attackers this vector involves live attackers. Nevertheless, on-path attackers
do not take specific advantage over off-path attackers. do not take specific advantage over off-path attackers.
3.4. Echo-Nonce algorithm 3.4. Echo-Nonce
The Nonce-Present and Echo-Nonce bits are used to verifying the The Nonce-Present and Echo-Nonce bits in the LISP header are used to
reachability of an xTR. An testing xTR sets the Echo-Nonce and the verify the reachability of an xTR. A testing xTR sets the Echo-Nonce
Nonce-Present bits in LISP data encapsulated packets and include a and the Nonce-Present bits in LISP data encapsulated packets and
random nonce in the LISP header of packets. Upon reception of these include a random nonce in the LISP header of packets. Upon reception
packets, the tested xTR stores the nonce and echo it whenever it of these packets, the tested xTR stores the nonce and echo it
returns a LISP encapsulated data packets to the testing xTR. The whenever it returns a LISP encapsulated data packets to the testing
reception of the echoed nonce confirms that the tested xTR is xTR. The reception of the echoed nonce confirms that the tested xTR
reachable. is reachable.
An attacker can interfere with the reachability test by sending two An attacker can interfere with the reachability test by sending two
different types of packets: different types of packets:
1. LISP data encapsulated packets with the Nonce-Present bit set and 1. LISP data encapsulated packets with the Nonce-Present bit set and
a random nonce. Such packets are normally used in response to a a random nonce. Such packets are normally used in response to a
reachability test. reachability test.
2. LISP data encapsulated packets with the Nonce-Present and the 2. LISP data encapsulated packets with the Nonce-Present and the
Echo-Nonce bits both set. These packets will force the receiving Echo-Nonce bits both set. These packets will force the receiving
skipping to change at page 11, line 49 skipping to change at page 11, line 45
3.6. Interworking 3.6. Interworking
[RFC6832] defines Proxy-ITR and Proxy-ETR network elements to allow [RFC6832] defines Proxy-ITR and Proxy-ETR network elements to allow
LISP and non-LISP sites to communicate. The Proxy-ITR has LISP and non-LISP sites to communicate. The Proxy-ITR has
functionality similar to the ITR, however, its main purpose is to functionality similar to the ITR, however, its main purpose is to
encapsulate packets arriving from the DFZ 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).
As any other system relying on proxies, LISP interworking can be used As any other system relying on proxies, LISP interworking can be used
by attackers to hide their exact origin in the network. by attackers to hide their exact origin in the network.
3.7. Map-Request messages 3.7. Map-Request messages
A control-plane off-path attacker can exploit Map-Request messages to A control-plane off-path attacker can exploit Map-Request messages to
mount DoS, performance, or amplification attacks. By sending Map- mount DoS, performance, or amplification attacks. By sending Map-
Request messages at high rate, the attacker can overload nodes Request messages at high rate, the attacker can overload nodes
involved in the mapping system. For instance sending Map-Requests at involved in the mapping system. For instance sending Map-Requests at
high rate can considerably increase the state maintained in a Map- high rate can considerably increase the state maintained in a Map-
Resolver or consume CPU cycles on ETRs that have to process the Map- Resolver or consume CPU cycles on ETRs that have to process the Map-
Request packets they receive in their slow path (i.e., performance or Request packets they receive in their slow path (i.e., performance or
DoS attack). When the Map-Reply packet is larger than the Map- DoS attack). When the Map-Reply packet is larger than the Map-
Request sent by the attacker, that yields to an amplification attack. Request sent by the attacker, that yields to an amplification attack.
The attacker can combine the attack with a spoofing attack to The attacker can combine the attack with a spoofing attack to
overload the node to which the spoofed address is actually attached. overload the node to which the spoofed address is actually attached.
It is worth to notice that if the attacker sets the P bit in the Map- It is worth to notice that if the attacker sets the P bit (Probe Bit)
Request, it is legitimate the send the Map-Request directly to the in the Map-Request, it is legitimate the send the Map-Request
ETR instead of passing through the mapping system. directly to the ETR instead of passing through the mapping system.
The SMR bit can be used to mount a variant of these attacks. The SMR bit can be used to mount a variant of these attacks.
For efficiency reasons, Map-Records can be appended to Map-Request For efficiency reasons, Map-Records can be appended to Map-Request
messages. When an xTR receives a Map-Request with appended Map- messages. When an xTR receives a Map-Request with appended Map-
Records, it does the same operations as for the other Map-Request Records, it does the same operations as for the other Map-Request
messages and is so subject to the same attacks. However, it also messages and is so subject to the same attacks. However, it also
installs in its EID-to-RLOC cache the Map-Records contained in the installs in its EID-to-RLOC cache the Map-Records contained in the
Map-Request. An attacker can then use this vector to force the Map-Request. An attacker can then use this vector to force the
installation of mappings in its target xTR. Consequently, the EID- installation of mappings in its target xTR. Consequently, the EID-
to-RLOC cache of the xTR is polluted by potentially forged mappings to-RLOC cache of the xTR is polluted by potentially forged mappings
allowing the attacker to mount any of the attacks categorized in allowing the attacker to mount any of the attacks categorized in
Section 2.2 (see Section 3.8 for more details). It is worth to Section 2.2 (see Section 3.8 for more details). It is worth to
mention that the attacker does not need to forge the mappings present mention that the attacker does not need to forge the mappings present
in the Map-Request to succeed a performance or DoS attack. Indeed, in the Map-Request to succeed a performance or DoS attack. Indeed,
if the attacker owns a large enough EID prefix it can de-aggregate it if the attacker owns a large enough EID prefix it can de-aggregate it
in many small prefixes, each corresponding to another mapping and it in many small prefixes, each corresponding to another mapping and it
them in the xTR cache by the mean of the Map-Request. installs them in the xTR cache by mean of the Map-Request.
Moreover, attackers can use Map Resolver and/or Map Server network Moreover, attackers can use Map Resolver and/or Map Server network
elements to relay its attacks and hide the origin of the attack. elements to relay its attacks and hide the origin of the attack.
Indeed, on the one hand, a Map Resolver is used to dispatch Map- Indeed, on the one hand, a Map Resolver is used to dispatch Map-
Request to the mapping system and, on the other hand, a Map Server is Request to the mapping system and, on the other hand, a Map Server is
used to dispatch Map-Requests coming from the mapping system to ETRs used to dispatch Map-Requests coming from the mapping system to ETRs
that are authoritative for the EID in the Map-Request. that are authoritative for the EID in the Map-Request.
3.8. Map-Reply messages 3.8. Map-Reply messages
skipping to change at page 13, line 24 skipping to change at page 13, line 18
If an attacker manages to send a valid (i.e., in response to a Map- If an attacker manages to send a valid (i.e., in response to a Map-
Request and with the correct nonce) Map-Reply to an ITR, then it can Request and with the correct nonce) Map-Reply to an ITR, then it can
perform any of the attack categorised in Section 2.2 as it can inject perform any of the attack categorised in Section 2.2 as it can inject
forged mappings directly in the ITR EID-to-RLOC cache. For instance, forged mappings directly in the ITR EID-to-RLOC cache. For instance,
if the mapping injected to the ITR points to the address of a node if the mapping injected to the ITR points to the address of a node
controlled by the attacker, it can mount replay, packet manipulation, controlled by the attacker, it can mount replay, packet manipulation,
packet interception and suppression, or DoS attacks as it will packet interception and suppression, or DoS attacks as it will
receive every packet destined to a destination lying in the EID receive every packet destined to a destination lying in the EID
prefix of the injected mapping. In addition, the attacker can inject prefix of the injected mapping. In addition, the attacker can inject
plethora of mappings in the ITR to mount an performance attack by plethora of mappings in the ITR to mount a performance attack by
filling up the EID-to-RLOC cache of the ITR. If the attacker can filling up the EID-to-RLOC cache of the ITR. If the attacker can
also mount an amplification attack as soon as the ITR has to send a also mount an amplification attack as soon as the ITR has to send a
lot of packets to the EIDs matching the injected mapping. In this lot of packets to the EIDs matching the injected mapping. In this
case, the RLOC address associated to the mapping is the address of case, the RLOC address associated to the mapping is the address of
the real target of the attacker and all the traffic of the ITR will the real target of the attacker and all the traffic of the ITR will
be sent to the target which means that with one single packet the be sent to the target which means that with one single packet the
attacker may generate very high traffic towards its final target. attacker may generate very high traffic towards its final target.
If the attacker is a valid ETR in the system it can mount a rogue If the attacker is a valid ETR in the system it can mount a rogue
attack if it uses prefixes over-claiming. In such a scenario, the attack if it uses prefixes over-claiming. In such a scenario, the
attacker ETR replies to a legitimate Map-Request message it received attacker ETR replies to a legitimate Map-Request message it received
with a Map-Reply message that contains an EID-Prefix that is larger with a Map-Reply message that contains an EID-Prefix that is larger
than the prefix owned by the attacker. For instance if the owned than the prefix owned by the attacker. For instance if the owned
prefix is 192.0.2.0/25 but the Map-Reply contains a mapping for prefix is 192.0.2.0/25 but the Map-Reply contains a mapping for
192.0.2.0/24, then the mapping will influence packets destined to 192.0.2.0/24, then the mapping will influence packets destined to
other EIDs than the one attacker has authority on. With such other EIDs than the one attacker has authority on. With such
technique, the attacker can mount the attacks presented above as it technique, the attacker can mount the attacks presented above as it
can (partially) control the mappings installed on its target ITR. To can (partially) control the mappings installed on its target ITR. To
force its target ITR to send a Map-Request, nothing prevents the force its target ITR to send a Map-Request, nothing prevents the
attacker to initiate some communication with the ITR. This method is attacker to initiate some communication with the ITR. This method
particularly interesting for internal attackers that want to control can be used by internal attackers that want to control the mappings
the mappings installed in their site. To that aim, they simply have installed in their site. To that aim, they simply have to collude
to collude with an external attacker ready to over-claim prefixes on with an external attacker ready to over-claim prefixes on behalf of
behalf of the internal attacker. the internal attacker.
It is worth to notice that when the Map-Reply is in response to a It is worth to notice that when the Map-Reply is in response to a
Map-Request sent via the mapping system (i.e., not send directly from Map-Request sent via the mapping system (i.e., not send directly from
the ITR to an ETR), the attacker does not need to use a spoofing the ITR to an ETR), the attacker does not need to use a spoofing
attack to succeed its attack as by design the source IP address of a attack to succeed its attack as by design the source IP address of a
Map-Reply is not known in advance by the ITR. Map-Reply is not known in advance by the ITR.
Map-Request and Map-Reply messages are at the mercy of any type of Map-Request and Map-Reply messages are exposed to any type of
attackers, on-path or off-path but also external or internal attackers, on-path or off-path but also external or internal
attackers. Also, even though they are control message, they can be attackers. Also, even though they are control message, they can be
leveraged by data-plane attackers. As the decision of removing leveraged by data-plane attackers. As the decision of removing
mappings is based on the TTL indicated in the mapping, time-shifted mappings is based on the TTL indicated in the mapping, time-shifted
attackers can take benefit of injecting forged mappings as well. attackers can take benefit of injecting forged mappings as well.
3.9. Map-Register messages 3.9. Map-Register messages
Map-Register messages are sent by ETRs to indicate to the mapping Map-Register messages are sent by ETRs to Map Servers to indicate to
system the EID prefixes associated to them. The Map-Register message the mapping system the EID prefixes associated to them. The Map-
provides an EID prefix and the list of ETRs that are able to provide Register message provides an EID prefix and the list of ETRs that are
Map-Replies for the EID covered by the EID prefix. able to provide Map-Replies for the EID covered by the EID prefix.
As Map-Register messages are protected by an authentication As Map-Register messages are protected by an authentication
mechanism, only a compromised ETR can register itself to its mechanism, only a compromised ETR can register itself to its
allocated Map Server. allocated Map Server.
A compromised ETR can over-claim the prefix it owns in order to A compromised ETR can over-claim the prefix it owns in order to
influence the route followed by Map-Requests for EIDs outside the influence the route followed by Map-Requests for EIDs outside the
scope of its legitimate EID prefix (see Section 3.8 for the list of scope of its legitimate EID prefix (see Section 3.8 for the list of
attacks opened by over-claiming). over-claiming attacks).
A compromised ETR can also de-aggregate its EID prefix in order to A compromised ETR can also de-aggregate its EID prefix in order to
register more EID prefixes than necessary to its Map Servers (see register more EID prefixes than necessary to its Map Servers (see
Section 3.7 for the impact of de-aggregation of prefixes by an Section 3.7 for the impact of de-aggregation of prefixes by an
attacker). attacker).
Similarly, a compromised Map Server can accept invalid registration Similarly, a compromised Map Server can accept invalid registration
or advertise invalid EID prefix to the mapping system. or advertise invalid EID prefix to the mapping system.
3.10. Map-Notify messages 3.10. Map-Notify messages
skipping to change at page 16, line 11 skipping to change at page 15, line 50
The authors would like to thank Ronald Bonica, Albert Cabellos, Ross The authors would like to thank Ronald Bonica, Albert Cabellos, Ross
Callon, Noel Chiappa, Florin Coras, Vina Ermagan, Dino Farinacci, Callon, Noel Chiappa, Florin Coras, Vina Ermagan, Dino Farinacci,
Stephen Farrell, Joel Halpern, Emily Hiltzik, Darrel Lewis, Edward Stephen Farrell, Joel Halpern, Emily Hiltzik, Darrel Lewis, Edward
Lopez, Fabio Maino, Terry Manderson, and Jeff Wheeler for their Lopez, Fabio Maino, Terry Manderson, and Jeff Wheeler for their
comments. comments.
This work has been partially supported by the INFSO-ICT-216372 This work has been partially supported by the INFSO-ICT-216372
TRILOGY Project (www.trilogy-project.org). TRILOGY Project (www.trilogy-project.org).
The work of Luigi Iannone has been partially supported by the ANR-13- The work of Luigi Iannone has been partially supported by the ANR-
INFR-0009 LISP-Lab Project (www.lisp-lab.org) and the EIT KIC ICT- 13-INFR-0009 LISP-Lab Project (www.lisp-lab.org) and the EIT KIC ICT-
Labs SOFNETS Project. Labs SOFNETS Project.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830, Locator/ID Separation Protocol (LISP)", RFC 6830, January
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
(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, Protocol (LISP) Map-Server Interface", RFC 6833, January
January 2013. 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.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, Considerations for Internet Protocols", RFC 6973, July
July 2013. 2013.
8.2. Informative References 8.2. Informative References
[I-D.bagnulo-lisp-threat] [I-D.bagnulo-lisp-threat]
Bagnulo, M., "Preliminary LISP Threat Analysis", Bagnulo, M., "Preliminary LISP Threat Analysis", draft-
draft-bagnulo-lisp-threat-01 (work in progress), bagnulo-lisp-threat-01 (work in progress), July 2007.
July 2007.
[I-D.ietf-lisp-ddt] [I-D.ietf-lisp-ddt]
Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP
Delegated Database Tree", draft-ietf-lisp-ddt-01 (work in Delegated Database Tree", draft-ietf-lisp-ddt-02 (work in
progress), March 2013. progress), October 2014.
[I-D.ietf-lisp-sec] [I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-06 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-07
(work in progress), April 2014. (work in progress), October 2014.
[RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-
Pascual, J., and D. Lewis, "Locator/Identifier Separation Pascual, J., and D. Lewis, "Locator/Identifier Separation
Protocol (LISP) Network Element Deployment Protocol (LISP) Network Element Deployment
Considerations", RFC 7215, April 2014. Considerations", RFC 7215, April 2014.
[Saucez13] [Saucez13]
Saucez, D., Iannone, L., and O. Bonaventure, "The Map-and- Saucez, D., Iannone, L., and O. Bonaventure, "The Map-and-
Encap Locator/Identifier separation paradigm: a Security Encap Locator/Identifier separation paradigm: a Security
Analysis", Solutions for Sustaining Scalability in Analysis", Solutions for Sustaining Scalability in
Internet Growth, IGI Global, 2013. Internet Growth, IGI Global, 2013.
Appendix A. Document Change Log Appendix A. Document Change Log
o Version 11 Posted December 2014.
* Editorial polishing. Clarifications added in few points.
o Version 10 Posted July 2014. o Version 10 Posted July 2014.
* Document completely remodeled according to the discussions on * Document completely remodeled according to the discussions on
the mailing list in the thread the mailing list in the thread http://www.ietf.org/mail-
http://www.ietf.org/mail-archive/web/lisp/current/msg05206.html archive/web/lisp/current/msg05206.html and to address comments
and to address comments from Ronald Bonica and Ross Callon. from Ronald Bonica and Ross Callon.
o Version 09 Posted March 2014. o Version 09 Posted March 2014.
* Updated document according to the review of A. Cabellos. * Updated document according to the review of A. Cabellos.
o Version 08 Posted October 2013. o Version 08 Posted October 2013.
* Addition of a privacy consideration note. * Addition of a privacy consideration note.
* Editorial changes * Editorial changes
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
skipping to change at page 18, line 24 skipping to change at page 18, line 14
o Version 04 Posted February 2013. o Version 04 Posted February 2013.
* Clear statement that the document compares threats of public * Clear statement that the document compares threats of public
LISP deployments with threats in the current Internet LISP deployments with threats in the current Internet
architecture. architecture.
* Addition of a severity level discussion at the end of each * Addition of a severity level discussion at the end of each
section. section.
* Addressed comments from V. Ermagan and D. Lewis' reviews. * Addressed comments from V. Ermagan and D. Lewis' reviews.
* Updated References. * Updated References.
* Further editorial polishing. * Further editorial polishing.
o Version 03 Posted October 2012. o Version 03 Posted October 2012.
* Dropped Reference to RFC 2119 notation because it is not * Dropped Reference to RFC 2119 notation because it is not
actually used in the document. actually used in the document.
 End of changes. 44 change blocks. 
124 lines changed or deleted 129 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/