One document matched: draft-saucez-lisp-security-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY DraftLISP PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lisp.xml'>
<!ENTITY LISPThreat PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bagnulo-lisp-threat.xml'>
<!ENTITY DraftALT PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-lisp-alt-04.xml'>
<!ENTITY DraftCONS PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.meyer-lisp-cons.xml'>
<!ENTITY DraftNERD PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.lear-lisp-nerd.xml'>
<!ENTITY DraftMS PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lisp-ms.xml'>
<!ENTITY DraftMULTICAST PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lisp-multicast.xml'>
<!ENTITY DraftINTERWORK PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-lisp-interworking.xml'>
<!ENTITY rfc4301 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4301.xml'>
<!ENTITY DraftTCPMSEC PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-tcpm-tcp-security.xml'>
<!ENTITY DraftVERSIONING PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.iannone-lisp-mapping-versioning.xml'>
<!ENTITY DraftSIDR PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sidr-arch.xml'>
<!ENTITY rfc3704 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3704.xml'>
<!ENTITY rfc5386 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5386.xml'>
]>
<rfc category="info" docName="draft-saucez-lisp-security-01" ipr="trust200902">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<front>
<title abbrev="LISP Security">
LISP Security Threats
</title>
<author fullname="Damien Saucez" initials="D." surname="Saucez" >
<organization> Universite catholique de Louvain
</organization>
<address>
<postal>
<street>Place St. Barbe 2</street>
<city>Louvain la Neuve</city>
<country>Belgium</country>
</postal>
<email>damien.saucez@uclouvain.be</email>
</address>
</author>
<author fullname="Luigi Iannone" initials="L." surname="Iannone">
<organization> TU Berlin - Deutsche Telekom Laboratories AG</organization>
<address>
<postal>
<street>Ernst-Reuter Platz 7</street>
<city>Berlin</city>
<country>Germany</country>
</postal>
<email> luigi@net.t-labs.tu-berlin.de </email>
</address>
</author>
<author fullname="Olivier Bonaventure" initials="O." surname="Bonaventure">
<organization> Universite catholique de Louvain
</organization>
<address>
<postal>
<street>Place St. Barbe 2</street>
<city>Louvain la Neuve</city>
<country>Belgium</country>
</postal>
<email>olivier.bonaventure@uclouvain.be</email>
</address>
</author>
<date/>
<abstract>
<t>This draft analyses some of the threats against the security of
the Locator/Identifier Separation Protocol and proposes a set of
recommendations to mitigate some of the identified security risks.
</t>
</abstract>
</front>
<middle>
<!-- Requirements Notation -->
<section title="Requirements notation">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as
described in <xref target="RFC2119"/>.</t>
</section>
<!-- END Requirements Notation -->
<!-- Introduction -->
<section title="Introduction">
<t>The Locator/ID Separation Protocol (LISP) is defined in
<xref target="I-D.ietf-lisp"/>. The present document aims at
identifying threats in the current LISP specification. We also
propose some recommendations on mechanisms that could improve the
security of LISP against off-path attackers. This document builds
upon <xref target="I-D.bagnulo-lisp-threat"/>.
</t>
<t> This document is split in two main parts. The first discusses
the LISP data-plane and the second the LISP control-plane.
</t>
<t> The LISP data-plane consists of LISP packet encapsulation,
decapsulation, and forwarding and includes the LISP-Cache and
LISP-Database data structures used to perform these operations.
</t>
<t> The LISP control-plane consists in the mapping distribution
system, which can be one of the mapping distribution systems
proposed so far (e.g., <xref target="I-D.ietf-lisp"/>,
<xref target="I-D.ietf-lisp-alt"/>,
<xref target="I-D.ietf-lisp-ms"/>,
<xref target="I-D.meyer-lisp-cons"/>, and
<xref target="I-D.lear-lisp-nerd"/>), and the Map-Request
and Map-Reply messages.
</t>
<t> This document does not consider all the possible utilizations
of LISP as discussed in <xref target="I-D.ietf-lisp"/>. In the
current version, we focus on LISP unicast and briefly consider the
ALT mapping system described <xref target="I-D.ietf-lisp-alt"/>.
Later versions of this document will include a deeper analysis of
the ALT mapping system, as well as the analysis of the security
issues in multicast LISP
(<xref target="I-D.ietf-lisp-multicast"/>), interworking between
LISP and the legacy IPv4 and IPv6 Internet
(<xref target="I-D.ietf-lisp-interworking"/>), and LISP-MS
(<xref target="I-D.ietf-lisp-ms"/>).
</t>
<t> Furthermore, here we assume a generic IP service and do not
discuss the difference from a security viewpoint between using
IPv4 or IPv6.
</t>
</section>
<!-- END Introduction -->
<!-- Definition of Terms -->
<section title="Definition of Terms">
<t> The present document does not introduce any new term, compared
to the main LISP specification. For a complete list of terms
please refer to <xref target="I-D.ietf-lisp"/>.
</t>
</section>
<!-- END Definition of Terms -->
<!-- Reference Environment -->
<section title="Reference Environment" anchor="refenv">
<t>Throughout this document we consider the reference environment
shown in the figure below. There are two hosts attached to LISP
routers: HA and HB. HA is attached to LISP xTR LR1 and LR2 that
are attached to two different ISPs. HB is attached to LISP xTR LR3
and LR4. HA and HB are the EIDs of the two hosts. LR1, LR2, LR3
and LR4 are the RLOCs of the xTRs.
</t>
<figure anchor='net1' title="Reference Network">
<artwork>
+----+
| HA |
+----+
| EID: HA
|
-----------------
| |
+----+ +----+
|LR1 | |LR2 |
+----+ +----+
| |
| |
+----+ +----+
|ISP1| |ISP2|
+----+ +----+ +----+
| | +--| SA |
+----------------+ | +----+
| |--+
| Internet | +----+
| |-----| NSA|
+----------------+ +----+
| |
| |
+----+ +----+
|LR3 | | LR4|
+----+ +----+
| |
-------------------
|
| EID: HB
+---+
| HB|
+---+
</artwork>
</figure>
<t> We consider two off-path attackers with different
capabilities:
<list style='hanging' hangIndent="4">
<t hangText="SA">
is an off-path attacker that is able to send spoofed packets,
i.e., packets with a different source IP address than its
assigned IP address.
</t>
<t hangText="NSA">
is an off-path attacker that is only able to send packets
whose source address is its assigned IP address.
</t>
</list>
</t>
<t> It should be noted that with LISP, packet spoofing is slightly
different than in the current Internet. Generally the term
"spoofed packet" indicates a packet containing a source IP address
which is not the one of the actual originator of the packet. Since
LISP uses encapsulation, this translates in two types of spoofing:
<list style="hanging" hangIndent="6">
<t hangText="EID Spoofing:">
the originator of the packet puts in it a spoofed EID. The
packet will be normally encapsulated by the ITR of the site.
</t>
<t hangText="RLOC Spoofing:">
the originator of the packet generates directly a
LISP-encapsulated packet with a spoofed source RLOC.
</t>
</list>
Note that the two types of spoofing are not mutually exclusive,
rather all combinations are possible and can be used to perform
several kind of attacks.
</t>
<t> In our reference environment, SA is able to perform both RLOC
and EID spoofing while NSA can only perform EID spoofing. Both
attackers are capable of sending LISP encapsulated data packets
and LISP control packets. They may also send other types of IP
packets such as ICMP messages. We assume that both attackers
can query the LISP mapping system to obtain the mappings for both
HA and HB.
</t>
<!-- SubSection On-Path Attackers -->
<section title="On-path Attackers">
<t> Besides the off-path attackers that we consider in this
document, there are other types of attackers. On-path attackers
are attackers that are able to capture and modify all the
packets exchanged between an ITR and an ETR. To cope with such
an attacker, cryptographic techniques such as those used by
IPSec are required. We do not consider that LISP has to cope
with such attackers.
</t>
<t> Mobile IP has also considered time-shifted attacks from
on-path attackers. A time-shifted attack is an attack where the
attacker is temporarily on the path between two communicating
hosts.
While it is on-path, the attacker sends specially crafted
packets or modifies packets exchanged by the communicating hosts
in order to disturb the packet flow (e.g., by performing a
man in the middle attack). An important issue for time-shifted
attacks is the duration of the attack once the attacker has left
the path between the two communicating hosts. We do not consider
time-shifted attacks in this document.
</t>
</section>
<!-- END SubSection On Path... -->
</section>
<!-- END Reference Environment -->
<!-- Data-Plane Threats -->
<section title="Data-Plane Threats">
<t>This section discusses threats and attacks related to the
LISP data-plane. More precisely, we discuss the operations
of encapsulation, decapsulation, and forwarding as well as the
content of the LISP-Cache and LISP-Database as specified in the
original LISP document (<xref target="I-D.ietf-lisp"/>).
</t>
<t>We start considering the two main data structures of LISP,
namely the LISP Database and the LISP Cache. Then, we look at the
data plane attacks that can be performed by a spoofing off-path
attacker (SA) and discuss how they can be mitigated by the LISP
xTRs. In this analysis, we assume that the LR1 and LR2 (resp. LR3
and LR4) xTRs maintain a LISP Cache that contains the required
mapping entries to allow HA and HB to exchange packets.
</t>
<!-- LISP-Database -->
<section title="LISP-Database Threats">
<t> The LISP Database on each xTR maintains the set of mappings
related to the EID-Prefixes that are "behind" the xTR. Where
"behind" means that at least one of the xTR's globally-visible IP
addresses is a RLOC for those EID-Prefixes.
</t>
<t> As described in <xref target="I-D.ietf-lisp"/>, the LISP
Database content is determined by configuration. This means that
the only way to attack this data structure is by gaining
privileged access to the xTR. As such, it is out of the scope of
LISP to propose any mechanism to protect routers and, hence, it is
no further analyzed in this document.
</t>
</section>
<!-- END LISP Database -->
<!-- LISP-Cache -->
<section title="LISP-Cache Threats" anchor="lc-threats">
<t> A key component of the overall LISP architecture is the
LISP-Cache. The LISP-Cache is the data structure that stores the
bindings between EID and RLOC (namely the "mappings") to be used
later on. Attacks against this data structure can happen either
when the mappings are first installed in the cache (see also
<xref target="cp-threats"/>) or by corrupting (poisoning) the
mappings already present in the cache.
</t>
<!-- Cache Poisoning -->
<section title="LISP-Cache poisoning" anchor="lc-poison">
<t> The content of the LISP-Cache can be poisoned by spoofing
LISP encapsulated packets. Example of LISP-Cache poisoning
are:
<list style="hanging" hangIndent="6">
<t hangText="Fake mapping:"> The cache contains entirely
fake mappings that do not originate from an authoritative
mapping server. This can be achieved either through gleaning
as described in <xref target="gleaning"/> or by attacking
the control-plane as described in
<xref target="cp-threats"/>.
</t>
<t hangText="EID Poisoning:"> The EID-Prefix in a specific
mapping is not owned by the originator of the entry.
Similarly to the previous case, this can be achieved either
through gleaning as described in <xref target="gleaning"/>
or by attacking the control-plane as described in
<xref target="cp-threats"/>.
</t>
<t hangText="EID redirection/RLOC poisoning:"> The
EID-Prefix in the mapping is not bound to (located by) the
set of RLOCs present in the mapping. This can result in
packets being redirected elsewhere, eavesdropped, or even
blackholed. Note that not necessarily all RLOCs are
fake/spoofed. The attack works also if only part of the
RLOCs, the highest priority ones, are compromised.
Again, this can be achieved either through the gleaning as
described in <xref target="gleaning"/> or by attacking the
control-plane as described in <xref target="cp-threats"/>.
</t>
<t hangText="Reachability poisoning:"> The reachability
information stored in the mapping could be poisoned,
redirecting the packets to a subset of the RLOCs (or even
stopping it if locator status bits are all set to 0). If
reachability information is not verified through the
control-plane this attack can be simply achieved by sending
a spoofed packet with swapped or all locator status bits
reset. The same result can be obtained by attacking the
control-plane as described in <xref target="cp-threats"/>.
</t>
<t hangText="Traffic Engineering information poisoning:">
The LISP protocol defines two attributes associated to
each RLOC in order to perform inbound Traffic Engineering:
namely priority and weight.
By injecting fake TE attributes, the attacker is able to
break load balancing policies and concentrate all the
traffic on a single RLOC or put more load on a RLOC than
what is expected, creating congestion.
Corrupting the TE attributes can be achieved by attacking
the control-plane as described in
<xref target="cp-threats"/>.
</t>
<t hangText="Mapping TTL poisoning:"> The LISP protocol
associates a Time-To-Live to each mapping that, once
expired, allows to delete a mapping from the LISP-Cache (or
forces a Map-Request/Map-Reply exchange to refresh it if
still needed). By injecting fake TTL values, an attacker can
either shrink the Cache (using very short TTL), thus
creating an excess of cache miss causing a DoS on the
mapping system, or it can increase the size of the cache by
putting very high TTL values, up to a cache overflow (see
<xref target="lc-oflow"/>).
Corrupting the TTL can be achieved by attacking the
control-plane as described in <xref target="cp-threats"/>.
</t>
<t hangText="Instance ID poisoning:"> The LISP
protocol allows to use an 24-bit identifier to select the
forwarding table to use on the decapsulating ETR to forward
the decapsulated packet. By spoofing this attribute the
attacker is able to redirect or blackhole inbound traffic.
Corrupting the Instance ID attribute can be achieved by
attacking the control-plane as described in
<xref target="cp-threats"/>.
</t>
<t hangText="Map-Version poisoning:"> The LISP
protocol allows to associate a version number to mappings
(<xref target="I-D.iannone-lisp-mapping-versioning"/>).
The LISP header can transport source and destination
map-versions, describing which version of the mapping have
been used to select the source and the destination RLOCs of
the LISP encapsulated packet. By spoofing this attribute the
attacker is able to trigger Map-Request on the receiving
xTR. Corrupting the Map-Version attribute can be achieved
either by attacking the control-plane as described in
<xref target="cp-threats"/> or by using spoofed packets as
described in <xref target="veratk"/>.
</t>
</list>
If the above listed attacks succeed, the attacker has the
means of controlling the traffic.
</t>
</section>
<!-- END Cache Poisoning -->
<!-- Cache Overflow -->
<section title="LISP-Cache overflow" anchor="lc-oflow">
<t> Depending on how the LISP Cache is managed (e.g., LRU
vs. LFU) and depending on its size, an attacker can try to
fill the cache with fake mappings. Once the cache is full,
some mappings will be replaced by new fake ones, causing
traffic disruption.
</t>
<t>This can be achieved either through the gleaning as
described in <xref target="gleaning"/> or by attacking the
control-plane as described in <xref target="cp-threats"/>.
</t>
<t> Another way to generate a LISP-Cache overflow is by
injecting mapping with a fake and very large TTL value. In
this case the cache will keep a large amount of mappings
ending with a completely full cache. This type of attack can
also be performed through the control-plane.
</t>
</section>
<!-- END Cache Overflow -->
</section>
<!-- END LISP-Cache -->
<!-- Attacks without LISP Header -->
<section title="Attacks not leveraging on the LISP header" anchor="nolispatk">
<t> We first consider an attacker that sends packets without
exploiting the LISP header, i.e., with the N, L, E, V, and I bits
reset (<xref target="I-D.ietf-lisp"/>).
</t>
<t> To inject a packet in the HA-HB flow, a spoofing off-path
attacker (SA) can send a LISP encapsulated packet whose source
is set to LR1 or LR2 and destination LR3 or LR4. The packet will
reach HB as if the packet was sent by host HA. This is not
different from today's Internet where a spoofing off-path
attacker may inject data packets in any flow. Several existing
techniques can be used by hosts to prevent such attacks from
affecting established flows, e.g., <xref target="RFC4301"/> and
<xref target="I-D.ietf-tcpm-tcp-security"/> .
</t>
<t> On the other hand, a non-spoofing off-path attacker (NSA)
can only send a packet whose source address is set to its
assigned IP address. The destination address of the encapsulated
packet can be LR3 or LR4. When the LISP ETR that serves HB
receives the encapsulated packet, it can consult its LISP-cache
and verify that NSA is not a valid source address for LISP
encapsulated packets containing a packet sent by HA. This
verification is only possible if the ETR already has a valid
mapping for HA. Otherwise, and to avoid such data packet
injection attacks, the LISP ETR should reject the packet and
possibly query the mapping system to obtain a mapping for the
encapsulated source EID (HA).
</t>
</section>
<!-- END Attacks without LISP Header -->
<!-- Attacks with LISP header -->
<section title="Attacks leveraging on the LISP header" anchor="lispatk">
<t> The latest LISP draft <xref target="I-D.ietf-lisp"/> defines
several flags that modify the interpretation of the LISP header
in data packets. In this section, we discuss how an off-path
attacker could exploit this LISP header.
</t>
<!-- Locator Status Bits -->
<section title="Attacks using the Locator Status Bits">
<t> When the L bit is set to 1, it indicates that the second
32-bits longword of the LISP header contains the
Locator Status Bits. In this field, each bit position reflects
the status of one of the RLOCs mapped to the source EID found
in the encapsulated packet. In particular, a packet with the
L bit set and all Locator Status Bits set to zero indicates
that none of the locators of the encapsulated source EID are
reachable. The reaction of a LISP ETR that receives such a
packet is not clearly described in
<xref target="I-D.ietf-lisp"/>.
</t>
<t> A spoofing off-path attacker (SA) can send a data packet
with the L bit set to 1, all Locator Status Bits set to zero, a
spoofed source RLOC (e.g. LR1), destination LR3, and
containing an encapsulated packet whose source is HA.
If LR3 blindly trust the Locator Status Bits of the received
packet it will set LR1 and LR2 as unreachable, possibly
disrupting ongoing communication.
</t>
<t> Locator Status Bits can be blindly trusted only in secure
environments. In the general unsecured Internet environment,
the safest practice for xTRs is to confirm the reachability
change through the mapping system. In the above example, LR3
should note that something as changed in the Locator Status
Bits and query the mapping system in order to confirm
status of the RLOCs of the source EID.
</t>
<t> A similar attack could occur by setting only one Locator
Status Bit to 1, e.g., the one that corresponds to the source
RLOC of the packet.
</t>
<t> If a non-spoofing off-path attacker (NSA) sends a data packet
with the L bit set to 1 and all Locator Status Bits set to
zero, this packet will contain the source address of the
attacker. Similarly as in <xref target="nolispatk"/>, if the
xTR accepts the packet without checking the LISP Cache for a
mapping that binds the source EID and the source RLOC of the
received packet, then the same observation like for the the
spoofing attacker (SA) apply.
</t>
<t> Otherwise, if the xTR does make the check through the LISP
Cache, it should reject the packet because its source address
is not one of the addresses listed as RLOCs for the source
EID. Nevertheless, in this case a Map-Request should be sent,
which can be used to perform Denial of Service attacks. Indeed
an attacker can frequently change the Locator Status Bits in
order to trigger a large amount of Map-Requests.
Rate limitation, as described in
<xref target="I-D.ietf-lisp"/>, does not allow to send high
number of such a request, resulting in the attacker saturating
the rate with these spoofed packets.
</t>
</section>
<!-- END Locator Status Bits -->
<!-- Map-Version Bit -->
<section title="Attacks using the Map-Version bit" anchor="veratk">
<t> The Map-Version bit is used to indicate whether the
low-order 24 bits of the first 32 bits word of the LISP header
contain an Source and Destination Map-Version. When a LISP ETR
receives a LISP encapsulated packet with the Map-Version bit
set to 1, the following actions are taken:
</t>
<t>
<list style='symbols'>
<t> It compares the Destination Map-Version found in the
header with the current version of its own mapping, in the
LISP Database, for the destination EID found in the
encapsulated packet. If the received Destination
Map-Version is smaller (i.e., older) than the current
version, the ETR should apply the SMR procedure described
in <xref target="I-D.ietf-lisp"/> and send a Map-Request
with the SMR bit set.
</t>
<t> If a mapping exists in the LISP Cache for the source
EID, then it compares the Map-Version of that entry with
the Source Map-Version found in the header of the packet.
If the stored mapping is older (i.e., the Map-Version is
smaller) than the source version of the LISP encapsulated
packet, the xTR should send a Map-Request for the source
EID.
</t>
</list>
</t>
<t> A spoofing off-path attacker (SA) could use the
Map-Version bit to force an ETR to send Map-Request messages.
The attacker can retrieve the current source and destination
Map-Version for both HA and HB. Based on this information, it
can send a spoofed packet with an older Source Map-Version or
Destination Map-Version. If the size of the Map-Request
message is larger than the size of the smallest
LISP-encapsulated packet that could trigger such a message,
this could lead to amplification attacks (see
<xref target="mapreqatk"/>). Fortunately,
<xref target="I-D.ietf-lisp"/> recommends to rate limit the
Map-Request messages that are sent by an xTR. This prevents
the amplification attack, but there is a risk of Denial of
Service attack if an attacker sends packets with Source and
Destination Map-Versions that frequently change. In this case,
the ETR could consume all its rate by sending Map-Request
messages in response to these spoofed packets.
</t>
<t> A non-spoofing off-path attacker (NSA) cannot success in
such an attack if the destination xTR rejects the LISP
encapsulated packets that are not sent by one of the RLOCs
mapped to the included source EID. If it is not the case, the
attacker can be able to perform attacks concerning the
Destination Map Version number as for the spoofing off-path
attacker (SA).
</t>
</section>
<!-- END Map-Version Bit -->
<!-- Nonce Bits -->
<section title="Attacks using the Nonce-Present and the Echo-Nonce bits">
<t> The Nonce-Present and Echo-Nonce bits are used when
verifying the reachability of a remote ETR. Assume that LR3
wants to verify that LR1 receives the packets that it
sends. LR3 can set the Echo-Nonce and the Nonce-Present bits
in LISP data encapsulated packets and include a random nonce
in these packets. Upon reception of this packet, LR1 will
store the nonce sent by LR3 and echo it when it returns LISP
encapsulated data packets to LR3.
</t>
<t>A spoofing off-path attacker (SA) could interfere with this
reachability test by sending two different types of packets:
<list style='numbers'>
<t> LISP data encapsulated packets with the Nonce-Present
bit set and a random nonce and the appropriate source
and destination RLOCs.
</t>
<t> LISP data encapsulated packets with the Nonce-Present
and the Echo-Nonce bits both set and the appropriate
source and destination RLOCs. These packets will force the
receiving ETR to store the received nonce and echo it in
the LISP encapsulated packets that it sends.
</t>
</list>
</t>
<t> The first type of packet should not cause any major problem
to ITRs. As the reachability test uses a 24 bits nonce, it is
unlikely that an off-path attacker could send a packet that
causes an ITR to believe that the ETR it is testing is
reachable while in reality it is not reachable.
</t>
<t>The second type of packet could be exploited to create a
Denial of Service attack against the nonce-based reachability
test. Consider a spoofing off-path attacker (SA) that sends a
continuous flow of spoofed LISP data encapsulated packets that
contain the Nonce-Present and the Echo-Nonce bit and each
packet contains a different random nonce. The ETR that
receives such packets will continuously change the nonce that
it returns to the remote ITR. If the remote ITR starts a
nonce-reachability test, this test may fail because the ETR
has received a spoofed LISP data encapsulated packet with a
different random nonce and never echoes the real nonce. In
this case the ITR will consider the ETR not reachable. The
success of this test will of course depend on the ratio
between the amount of packets sent by the legitimate ITR and
the spoofing off-path attacker (SA).
</t>
<t>Packets sent by a non-spoofing off-path attacker (NSA) can
cause similar problem if no check is done with the LISP Cache
(see <xref target="nolispatk"/> for the LISP Cache check).
Otherwise, if the check is performed the packets will be
rejected by the ETR that receives them and cannot cause
problems.
</t>
</section>
<!-- END Nonce Bits -->
</section>
<!-- Attacks with LISP header -->
</section>
<!-- END Data-Plane Threats -->
<!-- Control-Plane Threats -->
<section title="Control Plane Threats" anchor="cp-threats">
<t> In this section, we discuss the different types of attacks that
can 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 analyze the particularities of a LISP mapping system.
The ALT mapping system is discussed in <xref target="alt"/>.
</t>
<!-- Map-Request Attacks -->
<section title="Attacks with Map-Request messages" anchor="mapreqatk">
<t> An off-path attacker could send Map-Request packets to a
victim ETR. In theory, a Map-Request packet is only used to
solicit an answer and as such it should not lead to security
problems. However, the LISP specification
<xref target="I-D.ietf-lisp"/> contains several particularities
that could be exploited by an off-path attacker.
</t>
<t>The first possible exploitation is the P bit. The P bit is
used to probe the reachability of remote ETRs in the control
plane. In our reference environment, LR3 could probe the
reachability of LR1 by sending a Map-Request with the P bit
set. LR1 would reply by sending a Map-Reply message with the P
bit set and the same nonce as in the Map-Request message.
</t>
<t> A spoofing off-path attacker (SA) could use the P bit to
force a victim ETR to send a Map-Reply to the spoofed source
address of the Map-Request message. As the Map-Reply can be
larger than the Map-Request message, there is a risk of
amplification attack.
Considering only IPv4 addresses, a Map-Request has a size of 32
bytes at least, considering one single ITR address and no
Mapping Protocol Data. The Map-Reply instead has a size of
28+(N*12) bytes, where N is the number of RLOCs. Since there
is no hard limit in the number of RLOCs that can be associated
to an EID-Prefix, the packet can easily grow large.
</t>
<t> Any ISP with a large number of potential RLOCs for a given
EID-Prefix should carefully ponder the best trade-off between the
number of RLOCs through which it wants that the EID is
reachable and the consequences that an amplification attack
can produce.
</t>
<t> It should be noted that the maximum rate of Map-Reply
messages should apply to all Map-Replies and also be associated
to each destination that receives Map-Reply messages. Otherwise,
a possible amplification attack could be launched by a spoofing
off-path attacker (SA) as follows. Consider an attacker SA and
and EID-Prefix p/P and a victim ITR.
To amplify a Denial of Service attack against the victim ITR, SA
could send spoofed Map-Request messages whose source EID
addresses are all the addresses inside p/P and source RLOC
address is the victim ITR. Upon reception of these Map-Request
messages, the ETR would send large Map-Reply messages for each
of the addresses inside p/P back to the victim ITR.
</t>
<t> If a non-spoofing off-path attacker (NSA) sends a
Map-Request with the P bit set, it will receive a Map-Reply with
the P bit set. This does not raise security issues besides the
usual risk of overloading a victim ETR by sending too many
Map-Request messages.
</t>
<t> 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 source of the Map-Request message a Map-Request
message to retrieve the corresponding mapping. This raises
similar problems as the P bit discussed above except that as the
Map-Request messages are smaller than Map-Reply messages, the
risk of amplification attacks is reduced.
This is not true anymore if the ETR append to the Map-Request
messages its own Map-Records. This mechanism is meant to reduce
the delay in mapping distribution since mapping information is
provided in the Map-Request message.
</t>
<t> Furthermore, appending Map-Records to Map-Request messages
represents a major security risk since an off-path attacker
could generate a (spoofed or not) Map-Request message and
include in the Map-Reply portion of the message mapping for
EID prefixes that it does not serve. This could lead to various
types of redirection and denial of service attacks. An xTR
should not process the Map-Records information that it receives in
a Map-Request message.
</t>
</section>
<!-- Map-Request Attacks -->
<!-- Map-Reply Attacks -->
<section anchor="mapreply" title="Attacks with Map-Reply messages">
<t> In this section we analyze the attacks that could occur when
an off-path attacker sends directly Map-Reply messages to
ETRs without using one of the proposed LISP mapping systems.
</t>
<t> There are two different types of Map-Reply messages:
<list style='hanging' hangIndent="6">
<t hangText="Positive Map-Reply:"> This messages contain a
Map-Record binding an EID-Prefix to one or more RLOCs.
</t>
<t hangText="Negative Map-Reply:"> This messages contain a
Map-Record for an EID-Prefix with an empty locator-set and
specifying an action, which may be either Drop, Natively
forward, or Send Map-Request.
</t>
</list>
</t>
<t> Positive Map-Reply messages are used to map EID-Prefixes onto
RLOCs. Negative Map-Reply messages are used to support PTR and
interconnect the LISP Internet with the legacy Internet.
</t>
<t> Most of the security of the Map-Reply messages depend on the
64 bits nonce that is included in a Map-Request and returned in
the Map-Reply. An ETR must never accept a Map-Request message
whose nonce does not match one of the pending Map-Request
messages. If an ETR does not accept Map-Reply messages with an
invalid nonce, the risk of attack is very small given the size
of the nonce (64 bits).
</t>
<t> Note, however, that the nonce only confirms that the
Map-Reply was sent by the ETR that received the Map-Request. It
does not validate the content of the Map-Reply message.
</t>
</section>
<!-- Map-Reply Attacks -->
<!-- Gleaning Attacks -->
<section anchor="gleaning" title="Gleaning Attacks">
<t> A third type of attack involves the gleaning mechanism
proposed in <xref target="I-D.ietf-lisp"/> and discussed in
<xref target="Saucez09"/>.
In order to reduce the time required to obtain a mapping,
<xref target="I-D.ietf-lisp"/> allows an ITR to learn a mapping
from the LISP data encapsulated packets and the Map-Request
packets that it receives. LISP data encapsulated packet contains
a source RLOC, destination RLOC, source EID and destination
EID. When a ITR receives a data encapsulated packet coming
from a source EID for which it does not already know a mapping,
it may insert the mapping between the source RLOC and the source
EID in its LISP Cache. Gleaning can also be used when an ITR
receives a Map-Request as the Map-Request also contains a source
EID address and a source RLOC. Once a gleaned entry has been
added to the cache, the LISP ITR sends a Map-Request to retrieve
the mapping for the gleaned EID from the mapping system.
<xref target="I-D.ietf-lisp"/> recommends to store the gleaned
entries for only a few seconds.
</t>
<t> The first risk of gleaning is the ability to temporarily
hijack an identity. Consider an off-path attacker that wants to
temporarily hijack host HA's identity and send packets to host
HB with host HA's identity. If the xTRs that serve host HB do
not store a mapping for host HA, a non-spoofing off-path
attacker (NSA) could send a LISP encapsulated data packet to LR3
or LR4. The ETR will store the gleaned entry and use it to
return the packets sent by host HB to the attacker. In parallel,
the ETR will send a Map-Request to retrieve the mapping for
HA. During a few seconds or until the reception of the
Map-Reply, host HB will exchange packets with the attacker that
has hijacked HA's identity. Note that the attacker could in
parallel send lots of Map-Requests or lots of LISP data
encapsulated packets with random sources to force the xTR that
is responsible for host HA to send lots of Map-Request messages
in order to force it to exceed its rate limit for control plane
messages. This could further delay the arrival of the Map-Reply
message on the requesting ETR.
</t>
<t> Gleaning also introduces the possibility of a
man-in-the-middle attack. Consider an off-path attacker that
knows that hosts HA and HB that reside in different sites will
exchange information at time t. An off-path attacker could use
this knowledge to launch a man-in-the-middle attack if the xTRs
that serve the two hosts do not have mapping for the other
EID. For this, the attacker sends to LR1 (resp. LR3) a LISP data
encapsulated packet whose source RLOC is its IP address and
contains an IP packet whose source is set to HB (resp. HA). The
attacker chooses a packet that will not trigger an answer, for
example the last part of a fragmented packet. Upon reception of
these packets, LR1 and LR3 install gleaned entries that point to
the attacker. As explained above, the attacker could, at the
same time, send lots of packets to LR1 and LR3 to force them to
exhaust their control plane rate limit. This will extend the
duration of the gleaned entry. If host HA establishes a flow
with host HB at that time, the packets that they exchange will
first pass through the attacker.
</t>
<t> In both cases, the attack only lasts for a few
seconds (unless the attacker is able to exhaust the rate
limitation). However it should be noted that today
a large amount of packets may be exchanged during even a small
fraction of time.
</t>
</section>
<!-- END Gleaning Attacks -->
</section>
<!-- END Control-Plane Threats -->
<!-- Malicius xTRs -->
<section anchor="malicious" title="Threats with Malicious xTRs">
<t> In this section, we discuss the threats that could be caused
by malicious xTRs. We consider the reference environment below
where EL1 is a malicious or compromised xTR. This malicious
xTR serves a set of hosts that includes HC. The other xTR and
hosts in this network play the same role as in the reference
environment described in <xref target="refenv"/>.
</t>
<figure anchor='net2' title="Malicious xTRs' Reference Environment">
<artwork>
+----+
| HA |
+----+
| EID: HA
|
-----------------
| |
+----+ +----+
|LR1 | |LR2 |
+----+ +----+
| |
| |
+----+ +----+
|ISP1| |ISP2| |
+----+ +----+ +----+ |
| | +--| EL1|--| EID: HC
+----------------+ | +----+ | +----+
| |--+ |----| HC |
| Internet | | +----+
| |
+----------------+
| |
| |
+----+ +----+
|LR3 | | LR4|
+----+ +----+
| |
--------------------
|
| EID: HB
+----+
| HB |
+----+
</artwork>
</figure>
<t> Malicious xTRs are probably the most serious threat to the
LISP control plane from a security viewpoint. To understand the
problem, let us consider the following scenario. Host HC and HB
exchange packets with host HA. As all these hosts reside in LISP
sites, LR1 and LR2 store mappings for HB and HC. Thus, these xTRs
may need to exchange LISP control plane packets with EL1, e.g., to
perform reachability tests or to refresh expired mappings (e.g., if
HC's mapping has a small TTL).
</t>
<t> A first threat against the LISP control plane is when EL1
replies to a legitimate Map-Request message sent by LR1 or LR2
with a Map-Reply message that contains an EID-Prefix that is
larger than the prefix owned by the site attached to EL1. This
could allow EL1 to attract packets destined to other EIDs than the
EIDs that are attached to EL1.
</t>
<t> Another possible attack is a Denial of Service attack by
sending a Negative Map-Reply message for a coarser prefix without
any locator and with the Drop action. Such a Negative Map-Reply
indicates that the ETR that receives it should discard all
packets. The current LISP specification briefly discusses this
problem <xref target="I-D.ietf-lisp"/>, but the proposed solutions
does not solve the problem.
</t>
<t> Another concern with malicious xTRs is the possibility of
Denial of Service attacks. A first attack is the flooding attack
that was described in <xref target="I-D.bagnulo-lisp-threat"/>.
This attack allows a malicious xTR to redirect traffic to a
victim. The malicious xTR first defines a mapping for HC with two
RLOCs: its own RLOC (EL1) and the RLOC of the victim (e.g., LR3).
The victim's RLOC is set as unreachable in the mapping.
HC starts a large download from host HA. Once the download starts,
the malicious xTR updates its Locator Status Bits, changes
the mapping's version number or sets the SMR bit such that LR1
updates its LISP Cache to send all packets destined to HC to the
victim's RLOC. Instead of downloading from HA, the attacker could
also send packets that trigger a response (e.g., ICMP, TCP SYN,
DNS request, ...) to HA. HA would then send its response and its
xTR would forward it to the victim's RLOC.
</t>
<t> An important point to note about this flooding attack is that
it reveals a potential problem in the LISP architecture. A LISP
ITR relies on the received mapping and possible reachability
information to select the RLOC of the ETR that it uses to reach a
given EID or block of EIDs. However, if the ITR made a mistake,
e.g., due to configuration, implementation or other types of
errors and has chosen a RLOC that does not serve the
destination EID, there is no easy way for the LISP ETR to inform
the ITR of its mistake. A possible solution could be to force
a ETR to perform a reachability test with the selected ITR as soon
as it selects it. This will be analyzed in the next version of
this document.
</t>
</section>
<!-- END Malicius xTRs -->
<!-- ALT -->
<section title="Security of the ALT Mapping System" anchor="alt">
<t> One of the assumptions in <xref target="I-D.ietf-lisp"/> is
that the mapping system is more secure than sending Map-Request
and Map-Reply messages directly. We analyze this assumption in
this section by analyzing the security of the ALT mapping
system.
</t>
<t> The ALT mapping system is basically a manually configured
overlay of GRE tunnels between ALT routers. BGP sessions are
established between ALT routers that are connected through such a
tunnel. An ALT router advertises the EID prefixes that it serves
over its BGP sessions with neighboring ALT routers and the
EID-Prefixes that it has learned from neighboring ALT routers.
</t>
<t> The ALT mapping system is in fact a discovery system that
allows any ALT router to discover the ALT router that is
responsible for a given EID-Prefix. To obtain a mapping from the
ALT system, an ITR sends a packet containing a Map-Request on
the overlay. This Map-Request is sent inside a packet whose
destination is the requested EID. The Map-Request is routed on the
overlay until it reaches the ALT router that advertised initially
the prefix that contains the requested EID. This ALT router then
replies directly by sending a Map-Reply to the RLOC of the
requesting ITR.
</t>
<t> The security of the ALT mapping system depends on many
factors, including:
<list style='symbols'>
<t> The security of the intermediate ALT routers.
</t>
<t> The validity of the BGP advertisements sent on the ALT
overlay.
</t>
</list>
</t>
<t> Unfortunately, experience with BGP on the global Internet has
shown that BGP is subject to various types of misconfiguration
problems and security attacks. The SIDR working group is
developing a more secure inter-domain routing architecture to solve
this problem (<xref target="I-D.ietf-sidr-arch"/>).
</t>
<t> The security of the intermediate ALT routers is another
concern. A malicious intermediate ALT router could manipulate the
received BGP advertisements and also answer to received
Map-Requests without forwarding them to their final destination on
the overlay. This could lead to various types of redirection
attacks. Note that in contrast with a regular IP router that could
also manipulate in transit packets, when a malicious or
compromised ALT router replies to a Map-Request, it can redirect
legitimate traffic for a long period of time by sending an invalid
Map-Reply message. Thus, the impact of a malicious ALT router
could be much more severe than a malicious router in today's
Internet.
</t>
</section>
<!-- END ALT -->
<!-- Discussion -->
<section title="Discussion">
<t> To mitigate the impact of attacks against LISP, the following
recommendations should be followed.
</t>
<t>First, the use of some form of filtering can help in avoid or
at least mitigate some types of attacks.
<list style='symbols'>
<t> On ETRs, packets should be decapsulated only if the
destination EID is effectively part of the EID-Prefix downstream
the ETR. Further, still on ETRs, packets should be decapsulated
only if a mapping for the source EID is present in the
LISP-Cache and has been obtained through the mapping system (not
gleaned).
</t>
<t> On ITRs, packets should be encapsulated only if the source
EID is effectively part of the EID-Prefix downstream the
ITR. Further, still on ITRs, packets should be encapsulated only
if a mapping obtained from the mapping system is present in the
LISP Cache (no Data-Probing).
</t>
</list>
</t>
<t> Note that this filtering, since complete mappings need to be
installed in both ITRs and ETRs, can introduce a higher connection
setup latency and hence potentially more packets drops due to the
lack of mappings in the LISP Cache.
</t>
<t> While the gleaning mechanism allows to start encapsulating
packets to a certain EID in parallel with the Map-Request to
obtain a mapping when a new flow is established, it creates
important security risks since it allows attackers to perform
identity hijacks. Although the duration of these identity hijacks
is limited (except the case of rate limitation exhaustion), their
impact can be severe. A first option would be to disable gleaning
until the security concerns are solved. A second option would be
to strictly limit the number of packets that can be forwarded via
a gleaned entry. Overall the benefits of gleaning, i.e., avoiding
the loss of the first packet of a flow, seems very small compared
to the associated security risks. Furthermore, measurements
performed in data centers show that today's Internet often operate
with packet loss ratio of 1 or 2 percentage (<xref target="Chu"/>).
These packet loss ratio are probably already orders of magnitude
larger than the improvement provided by the gleaning mechanism.
</t>
<t> With the increasing deployment of spoofing prevention
techniques such as <xref target="RFC3704"/> or SAVI
<xref target="SAVI"/>, it can be expected that attackers will
become less capable of sending packets with a spoofed source
address. To prevent packet injection attacks from non-spoofing
attackers (NSA), ETRs should always verify that the source RLOC of
each received LISP data encapsulated packet corresponds to one of
the RLOCs listed in the mappings for the source EID found in the
inner packet. An alternative could be to use existing IPSec
techniques <xref target="RFC4301"/>and when necessary including
perhaps <xref target="RFC5386"/> to establish an authenticated
tunnel between the ITR and the ETR.
</t>
<t> <xref target="I-D.ietf-lisp"/> recommends to rate limit
the control messages that are sent by a xTR. This limit is
important to deal with denial of service attacks. However, a
strict limit, e.g., implemented with a token bucket, on all the
Map-Request and Map-Reply messages sent by a xTR is not
sufficient. A xTR should distinguish between different types of
control plane packets:
<list style='numbers'>
<t> The Map-Request messages that it sends to refresh expired
mapping information.
</t>
<t> The Map-Request messages that it sends to obtain mapping
information because one of the served hosts tried to contact an
external EID.
</t>
<t> The Map-Request messages that it sends as reachability
probes.
</t>
<t> The Map-Reply messages that it sends as response to
reachability probes.
</t>
<t> The Map-Request messages that it sends to support gleaning.
</t>
</list>
</t>
<t> These control plane messages are used for different
purposes. Fixing a global rate limit for all control plane
messages increases the risk of Denial of Service attacks if a
single type of control plane message can exceed the configured
limit. This risk could be mitigated by either specifying a rate
for each of the five types of control plane messages. Another
option could be to define a maximum rate for all control plane
messages, and prioritize the control plane messages according to
the list above (with the highest priority for message type 1).
</t>
<t> In <xref target="I-D.ietf-lisp"/>, there is no mechanism that
allows a xTR to verify the validity of the content a Map-Reply
message that it receives. Besides the attacks discussed earlier in
the document, a time-shifted attack where an attacker is able to
modify the content of a Map-Reply message but then needs to move
off-path could also create redirection attacks. The nonce only
allows a xTR to verify that a Map-Reply responds to a previously
sent Map-Request message. The LISP Working Group should explore
solutions that allow to verify the binding between EID-Prefixes
and their RLOCS. Having such kind of mechanism would allow ITRs to
ignore non-verified mappings, thus increasing security.
</t>
<t> LISP Working Group should consider developing secure
mechanisms to allow an ETR to indicate to an ITR that it does
not serve a particular EID or block of EIDs in order to mitigate
the flooding attacks.
</t>
<t> Finally, there is also the risk of Denial of Service attack
against the LISP Cache. We have discussed these attacks when
considering external attackers with, e.g., the gleaning mechanism
and in <xref target="lc-threats"/>.
If an ITR has a limited LISP Cache, a malicious or compromised
host residing in the site that it serves could generate packets to
random destinations to force the ITR to issue a large number of
Map-Requests whose answers could fill its cache. Faced with such
misbehaving hosts, LISP ITR should be able to limit the percent
of Map-Requests that it sends for a given source EID.
</t>
</section>
<!-- END Discussion -->
<!-- Doc Status and Plans -->
<section anchor="docstatus" title="Document Status and Plans">
<t>In this document, we have analyzed some of the security threats
that affect the Locator/Identifier Separation Protocol (LISP). We
have focused our analysis on unicast traffic and considered both
the LISP data and control planes and provided some recommendations
to improve the security of LISP.
</t>
<t> Revisions of this document will document the security threats
of other parts of the LISP architecture, including but not limited
to:
<list style="symbols">
<t> Instance ID attribute.
</t>
<t> LISP Multicast.
</t>
<t> LISP Map-Server.
</t>
</list>
</t>
</section>
<!-- END Doc Status and Plans -->
<section title="IANA Considerations">
<t>This document makes no request to IANA.</t>
</section>
<section title="Security Considerations">
<t> Security considerations are the core of this document and do
not need to be further discussed in this section.
</t>
</section>
<!-- Acknowledgements -->
<section anchor="ack" title="Acknowledgements">
<t>The flooding attack and the reference environment were first
described in Marcelo Bagnulo's draft
<xref target="I-D.bagnulo-lisp-threat"/>.
</t>
<t> This work has been partially supported by the
INFSO-ICT-216372 TRILOGY Project (www.trilogy-project.org).
</t>
</section>
<!-- END Acknowledgements -->
</middle>
<back>
<references title='Normative References'>
&rfc2119;
&DraftLISP;
&DraftALT;
&DraftMS;
&DraftMULTICAST;
&DraftINTERWORK;
</references>
<references title='Informative References'>
&LISPThreat;
&DraftCONS;
&DraftNERD;
&rfc4301;
&DraftTCPMSEC;
&DraftVERSIONING;
&DraftSIDR;
&rfc3704;
&rfc5386;
<reference anchor="Saucez09" target="">
<front>
<title>How to mitigate the effect of scans on mapping systems
</title>
<author initials='D.' surname="Saucez" fullname='Damien Suacez'>
<organization/>
</author>
<author initials='L.' surname="Iannone" fullname='Luigi Iannone'>
<organization/>
</author>
</front>
<seriesInfo name="" value="Submitted to the Trilogy Summer School on Future Internet"/>
</reference>
<reference anchor="Chu" target="http://tools.ietf.org/wg/savi/">
<front>
<title>Tuning TCP Parameters for the 21st Century
</title>
<author initials='H.' surname="Jerry Chu"><organization/></author>
<date month='July' year='2009'/>
</front>
<seriesInfo name="" value="75th IETF, Stockholm"/>
</reference>
<reference anchor="SAVI" target="http://tools.ietf.org/wg/savi/">
<front>
<title>Source Address Validation Improvements Working Group
</title>
<author>
<organization>IETF</organization>
</author>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 08:39:07 |