Network Working Group                                          D. Saucez
Internet-Draft                                                     INRIA
Intended status: Informational                                L. Iannone
Expires: October 10, 2014 January 5, 2015                               Telecom ParisTech
                                                          O. Bonaventure
                                        Universite catholique de Louvain
                                                           April 8,
                                                            July 4, 2014

                         LISP Threats Analysis
                     draft-ietf-lisp-threats-09.txt
                     draft-ietf-lisp-threats-10.txt

Abstract

   This document proposes a threat analysis of the Locator/Identifier
   Separation Protocol (LISP) if deployed in the Internet. (LISP).

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on October 10, 2014. January 5, 2015.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  On-path Attackers  Threat model . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Off-Path Attackers: Reference Environment
     2.1.  Attacker modes of operation  . . . . . . . . . .  3
   4.  Attack vectors . . . . .  4
       2.1.1.  On-path attackers vs. Off-path attackers . . . . . . .  4
       2.1.2.  Internal attackers vs. External attackers  . . . . . .  4
       2.1.3.  Live attackers vs. Time-shifted attackers  . . . . . .  4
       2.1.4.  Control-plane attackers vs. Data-plane attackers . . .  5
     4.1.  Configured EID-to-RLOC mappings
       2.1.5.  Cross mode attackers . . . . . . . . . . . . .  6
     4.2.  EID-to-RLOC Cache . . . .  5
     2.2.  Threat categories  . . . . . . . . . . . . . . . .  6
     4.3.  Attacks using the data-plane . . . .  5
       2.2.1.  Replay attack  . . . . . . . . . . .  7
       4.3.1.  Attacks not leveraging on the LISP header . . . . . .  7
       4.3.2.  Attacks leveraging on the LISP header . . .  5
       2.2.2.  Packet manipulation  . . . . .  8
     4.4.  Attacks using the control-plane . . . . . . . . . . . .  5
       2.2.3.  Packet interception and suppression  . 11
       4.4.1.  Attacks with Map-Request messages . . . . . . . .  6
       2.2.4.  Spoofing . . 11
       4.4.2.  Attacks with Map-Reply messages . . . . . . . . . . . 12
       4.4.3.  Attacks with Map-Register messages . . . . . . . . . . 13
       4.4.4.  Attacks with Map-Notify messages  6
       2.2.5.  Rogue attack . . . . . . . . . . . . . . . . . 14
   5.  Attack categories . . . .  6
       2.2.6.  Denial of Service (DoS) attack . . . . . . . . . . . .  7
       2.2.7.  Performance attack . . . . . . . . 14
     5.1. . . . . . . . . . .  7
       2.2.8.  Intrusion attack . . . . . . . . . . . . . . . . . . .  7
       2.2.9.  Amplification attack . . . . . 14
       5.1.1.  Description . . . . . . . . . . . .  7
       2.2.10. Multi-category attacks . . . . . . . . . 14
       5.1.2.  Vectors . . . . . . .  7
   3.  Attack vectors . . . . . . . . . . . . . . . . 14
     5.2.  Denial of Service (DoS) . . . . . . . .  7
     3.1.  Gleaning . . . . . . . . . 14
       5.2.1.  Description . . . . . . . . . . . . . . . .  7
     3.2.  Locator Status Bits  . . . . . 14
       5.2.2.  Vectors . . . . . . . . . . . . . .  9
     3.3.  Map-Version  . . . . . . . . . 14
     5.3.  Subversion . . . . . . . . . . . . . .  9
     3.4.  Echo-Nonce algorithm . . . . . . . . . . 15
       5.3.1.  Description . . . . . . . . . 10
     3.5.  Instance ID  . . . . . . . . . . . . 15
       5.3.2.  Vectors . . . . . . . . . . . 11
     3.6.  Interworking . . . . . . . . . . . . 15
   6.  Note on Privacy . . . . . . . . . . . 11
     3.7.  Map-Request messages . . . . . . . . . . . . 16
   7.  IANA Considerations . . . . . . . 12
     3.8.  Map-Reply messages . . . . . . . . . . . . . . 16
   8.  Security Considerations . . . . . . 13
     3.9.  Map-Register messages  . . . . . . . . . . . . . 16
   9.  Acknowledgments . . . . . 14
     3.10. Map-Notify messages  . . . . . . . . . . . . . . . . . . 16
   10. References . 14
   4.  Note on Privacy  . . . . . . . . . . . . . . . . . . . . . . . 14
   5.  IANA Considerations  . . 17
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
     10.2. Informative References 15
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . 17
   Appendix A.  Document Change Log . 15
   7.  Acknowledgments  . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . 15
   8.  References . . . . . . . . . . . . . . . . . 20

1.  Introduction

   The Locator/ID Separation Protocol (LISP) is specified in [RFC6830].
   The present document assess the potential security threats identified
   in the LISP specifications if LISP is . . . . . . . . . 16
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 16
   Appendix A.  Document Change Log . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19

1.  Introduction

   The Locator/ID Separation Protocol (LISP) is specified in [RFC6830].
   The present document assess the potential security threats identified
   in the LISP specifications if LISP is deployed in the Internet (i.e.,
   a public non-trustable environment).

   The document is composed of two three main parts: the first discussing defines the
   techniques
   general threat model that can be used by attackers can follow to succeed attacks mount attacks.  The
   second describing the techniques based on the LISP protocol and architecture; the second
   architecture that attackers can use to construct attacks.  The third
   discussing general solutions to protect the main
   categories of attacks LISP protocol and how to construct them.
   architecture from attacks.

   This document does not consider all the possible uses of LISP as
   discussed in [RFC6830] and [I-D.ietf-lisp-deployment]. [RFC7215].  The document focuses on LISP
   unicast, including as well LISP Interworking [RFC6832], LISP-MS
   [RFC6833], and LISP Map-Versioning [RFC6834].  The reading of these
   documents is a prerequisite for understanding the present document.

   This document assumes a generic IP service and does not discuss the
   difference, from a security viewpoint, between using IPv4 or IPv6.

2.  On-path Attackers

   On-path attackers are attackers  Threat model

   This document assumes that are able to capture and modify
   all attackers can be located anywhere in the packets exchanged between an Ingress Tunnel Router (ITR)
   Internet (either in LISP sites or outside LISP sites) and
   an Egress Tunnel Router (ETR).  To cope with such an attacker,
   cryptographic techniques such as those used that
   attacks can be mounted either by IPSec ([RFC4301]) are
   required.  As with IP, LISP relies on higher layer cryptography to
   secure packet payloads from on path attacks, so this document does
   not consider on-path attackers.

   Similarly, a time-shifted attack is an attack where single attacker or by the
   collusion of several attackers.

   An attacker is
   temporarily on a malicious entity that performs the path between two communicating hosts.  While it action of
   attacking a target in a network where LISP is
   on-path, the attacker sends specially crafted packets or modifies
   packets exchanged (partially) deployed by
   leveraging the communicating hosts in order to disturb LISP protocol and/or architecture.

   An attack is the
   packet flow (e.g., by action of performing an illegitimate action on a man
   target in the middle attack).  An
   important issue for time-shifted attacks a network where LISP is the duration (partially) deployed.

   The target of the an attack once is the attacker has left entity (i.e., a device connected to
   the path between network or a network) that is aimed to undergo the two
   communicating hosts.  This documents does consequences
   of an attack.  Other entities can potentially undergo side effects of
   an attack, even though they are not consider time-shifted
   attacks.

3.  Off-Path Attackers: Reference Environment directly targeted by the attack.
   The reference environment shown in target of an attack can be selected specifically, i.e., a
   particular entity, or arbitrarily, i.e., any entity.  Finally, an
   attacker can aim at attacking one or several targets with a single
   attack.

   Section 2.1 specifies the figure below is considered
   throughout this document.  There are two hosts attached different modes of operation that attackers
   can follow to LISP
   routers: HA mount attacks and HB.  HA is attached to Section 2.2 specifies the two LISP xTRs LR1 and LR2,
   which in turn are attached to two different ISPs.  HB is attached
   categories of attacks that attackers can build.

2.1.  Attacker modes of operation

   Attackers can be classified according to the two LISP xTRs LR3 and LR4.  HA and HB are the EIDs following four modes of
   operation, i.e., the two
   hosts.  LR1, LR2, LR3, temporal and LR4 are the RLOCs spacial locality of the xTRs.  PxTR is a
   proxy xTR and MR/MS plays the roles of Map Server and/or Map
   Resolver.

                +-----+
                | HA  |
                +-----+
                   | EID: HA
                   |
                -----------------
                   |          |
                +-----+    +-----+
                | LR1 |    | LR2 |
                +-----+    +-----+
                   |          |
                   |          |
                +-----+    +-----+
                |ISP1 |    |ISP2 |
                +-----+    +-----+
                   |          |
   +------+     +----------------+     +-----+
   | PxTR |-----|                |-----| SA  |
   +------+     |                |     +-----+
                |    Internet    |
   +-------+    |                |     +-----+
   | MR/MS |----|                |-----| NSA |
   +-------+    +----------------+     +-----+
                   |          |
                +-----+    +-----+
                | LR3 |    | LR4 |
                +-----+    +-----+
                   |          |
                -------------------
                              |
                              | EID: HB
                           +-----+
                           | HB  |
                           +-----+

                        Figure 1: Reference Network

   We consider two off-path attacker.

2.1.1.  On-path attackers with different capabilities:

   SA  is an off-path attacker that is vs. Off-path attackers

   On-path attackers, also known as Men-in-the-Middle, are able to send spoofed packets,
       i.e.,
   intercept and modify packets with between legitimate communicating
   entities.  On-path attackers are located either directly on the
   normal communication path (either by gaining access to a different source IP address than its
       assigned IP address.  SA stands for Spoofing Attacker.  To
       perform some of node on the attacks described in this document SA needs
   path or by placing themselves directly on the path) or outside the
   location path but manage to be in deviate or gain a non-LISP site.

   NSA copy of packets sent
   between the communication entities.  On-path attackers hence mount
   their attacks by modifying packets initially sent legitimately
   between communication entities.

   An attacker is an called off-path attacker that is only able if it does not have access to send
   packets whose
       source address is its assigned IP address.  NSA stands for Non
       Spoofing Attacker.

   It should be noted that with LISP, packet spoofing exchanged during the communication or if there is slightly
   different than no
   communication.  To succeed their attacks, off-path attackers must
   hence generate packets and inject them in the current Internet.  Generally the term "spoofed
   packet" indicates network.

2.1.2.  Internal attackers vs. External attackers

   An internal attacker launches its attack from a packet containing node located within a source IP address that
   legitimate LISP site.  Such an attacker is not
   the one either a legitimate node
   of the actual originator site or it exploits a vulnerability to gain access to a
   legitimate node in the site.  Because of their location, internal
   attackers are trusted by the packet.  Since LISP uses
   encapsulation, site they are in.

   On the spoofed address could be in contrary, an external attacker launches its attacks from the outer header
   outside of a legitimate LISP site.

2.1.3.  Live attackers vs. Time-shifted attackers

   A live attacker mounts attacks for which it must remain connected as
   well
   long as in the inner header, this translates in two types of
   spoofing:

   EID Spoofing: attack is mounted.  In other words, the originator attacker must
   remain active for the whole duration of the packet puts in it a spoofed EID.
         The packet will be normally encapsulated by attack.  Consequently,
   the ITR of attack ends as soon as the site attacker (or a PITR if the source site used attack vector)
   is not LISP enabled).

   RLOC Spoofing: neutralized.

   On the originator of the packet generates directly a
         LISP-encapsulated packet with contrary, a spoofed source RLOC.

   Note time-shifted attacker mounts attacks that remain
   active after it disconnects from the two types of spoofing are not mutually exclusive,
   rather all combinations are possible Internet.

2.1.4.  Control-plane attackers vs. Data-plane attackers

   A control-plane attacker mounts its attack by using control-plane
   functionalities, typically the mapping system.

   A data-plane attacker mounts its attack by using data-plane
   functionalities.

   As there is no strict delimitation between the control-plane and could be used the
   data-plane, an attacker can operate in the control-plane (resp. data-
   plane) to perform
   different kind of attacks.

   In mount attacks targeting the reference environment, both SA data-plane (resp. control-
   plane) or keep the attacked and NSA targeted planes at the same layer
   (i.e., from control-plane to control-plane or from data-plane to
   data-plane).

2.1.5.  Cross mode attackers are capable

   The attacker modes of sending LISP encapsulated data packets and LISP control packets.
   This means that SA is able to perform both RLOC operation are not mutually exclusive and EID spoofing
   while NSA can only perform EID spoofing.  They may also send other
   types of IP packets such as ICMP messages.  We assume that both hence
   attackers can query combine them to mount attacks.

   For example, an attacker can launch an attack using the LISP mapping system (e.g., through control-plane
   directly from within a public
   Map Resolver) LISP site to obtain the mappings for both HA which it got temporary access
   (i.e., internal + control-plane attacker) to create a vulnerability
   on its target and HB.

4.  Attack vectors

   This section presents techniques later on (i.e., time-shifted + external attacker)
   mount an attack on the data plane (i.e., data-plane attacker) that
   leverages the vulnerability.

2.2.  Threat categories

   Attacks can be used by attackers classified according to
   succeed attacks leveraging the LISP protocol nine following categories.

2.2.1.  Replay attack

   A replay attack happens when an attacker retransmits at a later time,
   and architecture.  This
   section focuses on without modifying it, a packet (or a sequence of packets) that
   has already been transmitted.

2.2.2.  Packet manipulation

   A packet manipulation attack happens when an attacker receives a
   packet, modifies the techniques while Section 5 presents packet (i.e., changes some information contained
   in the
   attacks packet) and finally transmits the packet to its final
   destination that can be succeeded while using these techniques.

4.1.  Configured EID-to-RLOC mappings

   Each xTR maintains a set of configured mappings related to the EID-
   Prefixes that are "behind" the xTR [RFC6830].  Where "behind" means
   that at least one initial destination of the xTR's globally visible IP addresses is packet or
   another one.

2.2.3.  Packet interception and suppression

   In a
   RLOC for those EID-Prefixes.

   As these mappings are determined by configuration.  This means that packet interception and suppression attack, the only way to attack this data structure is by gaining privileged
   access to attacker
   captures the xTR.  As such, packet and drops it is out of before it can reach its final
   destination.

2.2.4.  Spoofing

   With a spoofing attack, the scope of LISP attacker injects packets in the network
   pretending being another node.  Spoofing attacks are made by forging
   source addresses in packets.

   It should be noted that with LISP, packet spoofing is similar to
   propose any mechanism to protect routers and, hence, it is no further
   analyzed
   other existing tunneling technology currently deployed in this document.

4.2.  EID-to-RLOC Cache

   The EID-to-RLOC Cache (also called the Map-Cache) is
   Internet.  Generally the data
   structure that stores term "spoofed packet" indicates a copy packet
   containing a source IP address that is not the one of the mappings retrieved from a remote
   ETR's mapping via actual
   originator of the packet.  Hence, since LISP control-plane.  Attacks against this data
   structure uses encapsulation, the
   spoofed address could happen either when be in the mappings are first installed outer header as well as in the cache or by corrupting (poisoning) inner
   header, this translates in two types of spoofing.

   Inner address spoofing:  the mappings already
   present attacker uses encapsulation and uses a
         spoofed source address in the cache.

   Cache poisoning attacks are used inner packet.  In case of data-
         plane LISP encapsulation, that corresponds to alter (any combination of) spoof the
   following parts source
         EID address of the mappings installed in encapsulated packet.

   Outer address spoofing:  the EID-to-RLOC Cache:

   o  EID prefix

   o  RLOC list

   o  RLOC priority

   o  RLOC weight

   o  RLOC reachability

   o  Mapping TTL

   o  Mapping version

   o  Mapping Instance ID

   Cache poisoning attacks can be performed by attackers from attacker does not use encapsulation and
         spoofs the
   outside source address of the attacked LISP network but also directly from packet.

   Note that the
   inside.  As a matter two types of spoofing are not mutually exclusive,
   rather all combinations are possible and could be used to perform
   different kind of fact, end-hosts behind attacks.  For example, an ITR attacker not in a LISP
   site can use the
   data-plane to overflow the ITR's EID-to-RLOC Cache by sending packets
   to non-popular EID prefixes (similar to scan attack but generate a packet with a
   different goal).  In such forged source IP address (i.e.,
   outer address spoofing) and forward it to a scenario the ITR may evict popular (in-
   use) entries from the map-cache disrupting the normal operation of
   the network LISP destination.  The
   packet is then eventually encapsulated by forcing cache miss [Florin13].

4.3.  Attacks using a PITR so that once
   encapsulated the data-plane

   The data-plane attack corresponds to a inner address spoofing.  One
   can also imagine an attacker forging a packet with encapsulation
   where both inner an outer source addresses are spoofed.

   It is constituted of important to notice that the operations combination of encapsulation,
   decapsulation, inner and forwarding as well as outer
   spoofing makes the content identification of the EID-to-
   RLOC Cache and configured EID-to-RLOC mappings attacker complex as specified in the
   original LISP document ([RFC6830]).

4.3.1.  Attacks
   packet may not leveraging on the LISP header

   An attacker can inject packets into flows without using the LISP
   header, i.e., with contain information that permits to detect the N, L, E, V, and I bits ([RFC6830]).

   Taking notation origin
   of the reference environment (Figure 1), to inject attack.

2.2.5.  Rogue attack

   In a
   packet in rogue attack the HA->HB flow, a spoofing off-path attacker (SA) could
   send manages to appear as a LISP encapsulated packet whose legitimate
   source is set of information, without faking its identity (as opposed to a
   spoofing attacker).

2.2.6.  Denial of Service (DoS) attack

   A Denial of Service (DoS) attack aims at disrupting a specific
   targeted service to make it unable to operate properly.

2.2.7.  Performance attack

   A performance attacks aims at exploiting computational resources
   (e.g., memory, processor) of a targeted node so to make it unable to LR1
   operate properly.

2.2.8.  Intrusion attack

   In an intrusion attack the attacker gains remote access to a resource
   (e.g., a host, a router, or LR2 and
   destination LR3 a network) or LR4.  The packet will reach HB as if information that it
   normally doesn't have access to.  Intrusion attacks can lead to
   privacy leakages.

2.2.9.  Amplification attack

   In an amplification attack, the packet
   was sent traffic generated by host HA.  This the target of
   the attack in response to the attack is not different from today's Internet
   where a spoofing off-path larger than the traffic that
   the attacker may inject data packets in must generate.

2.2.10.  Multi-category attacks

   Attacks categories are not mutually exclusive and any
   flow.  A non-spoofing off-path attacker (NSA) could only send combination can
   be used to perform specific attacks.

   For example, one can mount a
   packet whose source address is set rogue attack to its assigned IP address.  The
   destination address perform a performance
   attack starving the memory of an ITR resulting in a DoS on the encapsulated packet could ITR.

3.  Attack vectors

   This section presents techniques that can be LR3 or LR4.

4.3.1.1.  Gleaning Attacks

   In order used by attackers to
   succeed attacks leveraging the LISP protocol and/or architecture.

3.1.  Gleaning

   To reduce the time required to obtain a mapping, [RFC6830]
   proposes the optional
   gleaning mechanism that allows an ITR xTR to directly learn a mapping from the
   LISP data encapsulated packets and the Map-Request packets that it
   receives.  LISP data encapsulated packet contains data packets contain a source RLOC,
   destination RLOC, source EID and destination EID.  When an ITR xTR
   receives a data an encapsulated data 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 EID-to-RLOC Cache.
   Gleaning could also

   The same technique can be used when an ITR xTR 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 EID-to-RLOC cache, the
   LISP ITR xTR
   sends a Map-Request to retrieve the actual mapping for the gleaned
   EID from the mapping system.  [RFC6830] recommends storing the
   gleaned entries for only a few seconds.

   An attacker can send LISP encapsulated packets to host HB with host
   HA's EID and if the xTRs that serve host HB do not store

   If a mapping
   for host HA at that time.  The xTR will store the gleaned entry and
   use it to return the packets sent packet injected by host HB.  In parallel, the ETR
   will send a Map-Request to retrieve the mapping for HA but until the
   reception of the Map-Reply, host HB will exchange packets with the
   attacker instead of HA.

   Similarly, if an off-path attacker knows that hosts HA and HB that
   resides in different sites will exchange information at a given time
   the attacker could send to LR1 (resp. LR3) with a LISP data encapsulated
   packet whose source RLOC is its IP spoofed inner
   address and contains an IP packet
   whose source is set to HB (resp. HA).  The attacker chooses a packet
   that will not trigger gleaned by an answer, for example xTR then the last part of a
   fragmented packet.  Upon reception of these packets, LR1 and LR3
   install gleaned entries that point to attacker may divert the attacker.  If host HA is
   willing traffic
   meant to be delivered to establish a flow with host HB at that time, the packets
   that they exchange will pass through the attacker spoofed EID as long as the gleaned entry
   is active on used by the xTRs.

   By itself, an xTR.  This attack made solely using gleaning cannot last long,
   however it should can be noted that with current network capacities, a
   large amount used as part of replay,
   packet manipulation, packet interception and suppression, or DoS
   attacks as the packets might be exchanged during even are sent to the attacker.

   If the packet sent by the attacker contains a small
   fraction spoofed outer address
   instead of time.

4.3.1.2.  Threats concerning Interworking

   [RFC6832] defines Proxy-ITR and Proxy-ETR network elements to allow
   LISP and non-LISP sites to communicate.  The Proxy-ITR has
   functionality similar a spoofed inner address then it can succeed a DoS or a
   performance attack as the traffic normally destined to the ITR, however, its main purpose is attacker
   will be redirected to
   encapsulate packets arriving the spoofed source RLOC.  Such traffic may
   overload the owner of the spoofed source RLOC, preventing it from
   operating properly.

   If the DFZ in order packet injected uses both inner and outer spoofing, the
   attacker can succeed a spoofing, a performance, or an amplification
   attack as traffic normally destined to reach the spoofed EID address will
   be sent to the spoofed RLOC address.  If the attacked LISP
   sites.  A Proxy-ETR has functionality similar site also
   generates traffic to the ETR, however,
   its main purpose spoofed EID address, such traffic may have a
   positive amplification factor.

   A gleaning attack does not only impact the data-plane but can also
   have repercussions on the control-plane as a Map-Request is to inject de-encapsulated packets sent
   after the creation of a gleaned entry.  The attacker can then succeed
   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
   in the DFZ in
   order 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
   leads to reach non-LISP Sites from LISP sites.  As an over-utilisation of the control-plane as each packet
   generates a PITR (resp.
   PETR) is control-plane event.  For succeeding this example, the
   attacker may not need to use spoofing.

   Gleaning attacks are fundamentally involving a particular case time-shifted mode of ITR (resp. ETR), it
   operation as the attack may last as long as the gleaned entry is subject to same
   attacks than ITRs (resp. ETR).

   PxTRs can be targeted kept
   by attacks aiming the targeted xTR.  Nevertheless, [RFC6830] recommends to influence traffic between
   LISP and non-LISP sites store the
   gleaned entries for only a few seconds which limits the duration of
   the attack.

   Gleaning attacks always involve external data-plane attackers but also to launch relay attacks.
   results in attacks on either the control-plane or data-plane.

   It is worth to notice that when PITR and PETR functions are
   separated, attacks targeting nodes that collocate PITR and PETR
   functionality are ineffective.

4.3.2.  Attacks leveraging on the LISP header

   The main LISP document [RFC6830] defines several flags that modify outer spoofed address does not need to
   be the interpretation RLOC of the a LISP header in data packets.  In this
   section, we discuss how site an off-path attacker could exploit this LISP
   header.

4.3.2.1.  Attacks using the may be any address.

3.2.  Locator Status Bits

   When the L bit is set to 1, it indicates that the second 32-bits
   longword of the LISP header contains the Locator Status Bits.  In
   this field, each bit position reflects the status of one of the RLOCs
   mapped to the source EID found in source EID found in the encapsulated packet.  The
   reaction of a LISP xTR that receives such a packet is left as
   operational choice in [RFC6830].

   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
   prefix associated to the source EID.  In case of an off-path
   attacker, the attacker must inject a forged packet in the network
   with a spoofed inner address.  An on-path attacker can manipulate the
   LSB of legitimate packets passing through it and hence does not need
   to use spoofing.  Instead of manipulating the LSB field, an on-path
   attacker can also obtain the encapsulated packet.  In
   particular, a packet same result of injecting packets with the L bit
   invalid LSB values by replaying packets.

   The LSB field can be leveraged to succeed a DoS attack by either
   declaring all RLOCs as unreachable (all LSB set and to 0), or by
   concentrating all Locator Status Bits the traffic to one RLOC (e.g., all but one LSB set
   to zero indicates that none of 0) and hence overloading the locators of RLOC concentrating all the encapsulated
   source EID traffic
   from the xTR, or by forcing packets to be sent to RLOCs that are reachable.
   actually not reachable (e.g., invert LSB values).

   The reaction of LSB field can also be used to mount a LISP ETR that receives
   such replay, a packet is not clearly described in [RFC6830].

   An attacker can send
   manipulation, or a data packet with interception and suppression attack.
   Indeed, if the L bit set attacker manages to 1 be on the path between the xTR and some
   or all Locator Status Bits set to zero.  Therefore, by blindly
   trusting
   one of the Locator Status Bits communication going on can be
   altered or forced RLOCs specified in the mapping, forcing packets to go through a particular set of locators.

4.3.2.2. via
   that RLOC implies that the attacker will gain access to the packets.

   Attacks using the LSB are fundamentally involving a time-shifted mode
   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
   RLOCs to be used.

3.3.  Map-Version bit

   The optional

   When the Map-Version bit is used set to indicate whether 1, it indicates that the low-
   order low-order
   24 bits of the first 32 bits longword of the LISP header contain a
   Source and Destination Map-Version.  When a LISP ETR xTR receives a LISP
   encapsulated packet with the Map-Version bit set to 1, the following
   actions are taken:

   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 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 [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,
      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.

   An off-path

   A cross-mode attacker could can use the Map-Version bit to force an ETR to
   send Map-Request messages.  The attacker could retrieve the current
   source and destination Map-Version for both HA and HB.  Based on this
   information, it could send mount a spoofed packet with DoS
   attack, an older Source Map-
   Version amplification attack, or Destination Map-Version.  If a spoofing attack.  For instance
   if the size of mapping cached at the Map-Request
   message xTR is larger than the size of outdated, the smallest LISP-encapsulated
   packet that could trigger such xTR will send a message, this could lead
   Map-Request to
   amplification attacks (see Section 4.4.1) so that more bandwidth is
   consumed on retrieve the target (because new mapping which can yield to a DoS
   attack (by excess of signalling traffic) or an amplification attack
   if the larger packets) than the
   bandwidth necessary at data-plane packet sent by the attacker side.

4.3.2.3.  Attacks using is smaller than the Nonce-Present
   control-plane packets sent in response to the attacker's packet.
   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
   can result in performance, amplification, or DoS attack as well.

   Map-Version attackers are inherently cross mode as the Map-Version is
   a method to put control information in the data-plane.  Moreover,
   this vector involves live attackers.  Nevertheless, on-path attackers
   do not take specific advantage over off-path attackers.

3.4.  Echo-Nonce bits algorithm

   The Nonce-Present and Echo-Nonce bits are used when to verifying the
   reachability of a remote ETR.  Assume that LR3 wants to verify that
   LR1 receives the packets that it sends.  LR3 can set an xTR.  An testing xTR sets the Echo-Nonce and the
   Nonce-Present bits in LISP data encapsulated packets and include a
   random nonce in these the LISP header of packets.  Upon reception of these
   packets, LR1 will store the tested xTR stores the nonce sent by LR3 and echo it when whenever it
   returns a LISP encapsulated data packets to LR3.

   A spoofing off-path the testing xTR.  The
   reception of the echoed nonce confirms that the tested xTR is
   reachable.

   An attacker (SA) could can interfere with this the reachability test by sending two
   different types of packets:

   1.  LISP data encapsulated packets with the Nonce-Present bit set and
       a random nonce and the appropriate source and destination RLOCs. nonce.  Such packets are normally used in response to a
       reachability test.

   2.  LISP data encapsulated packets with the Nonce-Present and the
       Echo-Nonce bits both set and the appropriate source and
       destination RLOCs. set.  These packets will force the receiving
       ETR to store the received nonce and echo it in the LISP
       encapsulated packets that it sends.  These packets are normally
       used as trigger for a reachability test.

   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 single packet that causes an ITR packets is used to
   believe make xTRs think that the ETR it is testing an other
   xTR is reachable while in reality it is not reachable.  To increase the success likelihood of such attack, not.  It is hence a way to mount a DoS
   attack (i.e., the attacker should create ITR will send its packet to a massive amount of packets carrying all
   possible nonce values. non-reachable ETR
   while it should use another one).

   The second type of packet packets could be exploited to attack the nonce-
   based reachability test.  Consider a spoofing off-path  If the 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 have a different random nonce.  The nonce, the ETR that
   receives such packets will continuously change the nonce that it
   returns to the remote ITR. ITR, which can yield to a performance attack.
   If the remote ITR starts tries 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 may echo an invalid nonce.  This hence yields to a
   DoS attack.

   In this case the ITR will consider the ETR not
   reachable.  The success of this test depends on the ratio between the
   amount case of packets sent by the legitimate ITR and an on-path attacker, a packet manipulation attack is
   necessary to mount the spoofing off-
   path attack.  To mount such an attack, an off-path
   attacker (SA).

4.3.2.4.  Attacks using the must mount an outer address spoofing attack.

3.5.  Instance ID bits

   LISP allows to carry in its header a 24-bits value called "Instance
   ID" and used on the ITR to indicate which local Instance ID has been
   used for encapsulation, while on the ETR can be used to select the
   forwarding table
   and used for forwarding the decapsulated packet.

   The Instance ID increases exposure to attacks ([RFC6169]) as if an
   off-path attacker can randomly guess a valid Instance ID value to get
   access to network that might not been accessible in normal
   conditions.  However, such attacks target end-systems, which is out
   of the scope of this document.

4.4.  Attacks using the control-plane

   In this section, we discuss the different types of attacks that could
   occur when an off-path attacker sends control-plane packets.  We
   focus on the packets that are sent directly ITR to indicate which local Instance ID has been used
   for encapsulation, while on the ETR and do not
   analyze the particularities of instance ID decides the
   forwarding table to use to forward the decapsulated packet in the different
   LISP indexing sub-
   system.

4.4.1.  Attacks with Map-Request messages site.

   An off-path attacker could send Map-Request packets to a victim ETR.
   In theory, (either a Map-Request packet is only used control-plane or data-plane attacker) can use
   the instance ID functionality to solicit mount an answer intrusion attack.

3.6.  Interworking

   [RFC6832] defines Proxy-ITR and
   as such it should not lead Proxy-ETR network elements to security problems.  However, the allow
   LISP
   specification [RFC6830] contains several particularities that could
   be exploited by an off-path attacker. and non-LISP sites to communicate.  The first possible exploitation is Proxy-ITR has
   functionality similar to the RLOC record P bit.  The RLOC
   record P bit ITR, however, its main purpose is used to probe
   encapsulate packets arriving from the reachability of remote ETRs.  In
   our reference environment, LR3 could probe DFZ in order to reach LISP
   sites.  A Proxy-ETR has functionality similar to the reachability of LR1 by
   sending a Map-Request with ETR, however,
   its main purpose is to inject de-encapsulated packets in the RLOC record P bit set.  LR1 would
   reply by sending DFZ in
   order to reach non-LISP Sites from LISP sites.  As a Map-Reply message with the RLOC record P bit set
   and the PITR (resp.
   PETR) is a particular case of ITR (resp. ETR), it is subject to same nonce as
   attacks than ITRs (resp. ETR).

   As any other system relying on proxies, LISP interworking can be used
   by attackers to hide their exact origin in the network.

3.7.  Map-Request message. messages

   A spoofing control-plane off-path attacker (SA) could use the RLOC record P bit to
   force a victim ETR to send a Map-Reply to the spoofed source address
   of the can exploit Map-Request message.  As messages to
   mount DoS, performance, or amplification attacks.  By sending Map-
   Request messages at high rate, the Map-Reply attacker can be larger than overload nodes
   involved in the
   Map-Request message, there is mapping system.  For instance sending Map-Requests at
   high rate can considerably increase the state maintained in a risk of amplification attack. Map-
   Requests are usually smaller than a hundred bytes while
   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
   DoS attack).  When the maximum
   size of a Map-Reply (without considering any MTU constrain) can be
   above 1 MB, largely bigger packet is larger than the message Map-
   Request sent by the attacker.
   These numbers are however theoretical values not considering
   transport layer limitations and it is more likely attacker, that yields to an amplification attack.
   The attacker can combine the reply will
   contain only one record attack with at most a dozen of locators, limiting so spoofing attack to
   overload the amplification factor.

   Similarly, node to which the spoofed address is actually attached.

   It is worth to notice that if a non-spoofing off-path the attacker (NSA) sends a Map-
   Request with sets the RLOC record P bit set, in the Map-
   Request, it will receive a Map-Reply
   with is legitimate the RLOC record P bit set.

   An amplification attack could be launched by a spoofing off-path
   attacker (SA) as follows.  Consider an attacker SA and EID-Prefix
   192.0.2.0/24 and a victim ITR, SA could send spoofed Map-Request
   messages whose source EID addresses are all the addresses inside
   192.0.2.0/24 and source RLOC address is the victim ITR.  Upon
   reception of these Map-Request messages, directly to the
   ETR would send large
   Map-Reply messages, for each instead of passing through the addresses back to the victim ITR. mapping system.

   The Map-Request message may also contain the SMR bit.  Upon reception bit can be used to mount a variant of these attacks.

   For efficiency reasons, Map-Records can be appended to Map-Request
   messages.  When an xTR receives a Map-Request message with appended Map-
   Records, it does the SMR bit, an ETR must return to the
   source of same operations as for the other Map-Request message a Map-Request message
   messages and is so subject to retrieve the corresponding mapping.  Note that according to [RFC6830] same attacks.  However, it also
   installs in its EID-to-RLOC cache the SMR-
   triggered Map-Request might be sent through Map-Records contained in the mapping system,
   depending on
   Map-Request.  An attacker can then use this vector to force the number
   installation of RLOCs mappings in its target xTR.  Consequently, the locators set.  This raises
   similar problems as the RLOC record P bit discussed above except that
   as EID-
   to-RLOC cache of the Map-Request messages are smaller than Map-Reply messages, xTR is polluted by potentially forged mappings
   allowing the
   risk attacker to mount any of amplification the attacks categorized in
   Section 2.2 (see Section 3.8 for more details).  It is reduced.  This is not true anymore
   if the ETR append worth to
   mention that the Map-Request messages its own Map-Records.
   This mechanism is meant attacker does not need to reduce forge the delay in mapping distribution
   since mapping information is provided mappings present
   in the Map-Request message.

   Furthermore, appending Map-Records to Map-Request messages allows an
   off-path attacker to generate succeed a (spoofed performance or not) Map-Request message DoS attack.  Indeed,
   if the attacker owns a large enough EID prefix it can de-aggregate it
   in many small prefixes, each corresponding to another mapping and include it
   them in the Map-Reply portion xTR cache by the mean of the message mapping for EID
   prefixes that it does not serve. Map-Request.

   Moreover, attackers can use Map Resolver and/or Map Server network
   elements to perform relay attacks.  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 used to dispatch Map-Requests
   coming from the mapping system to ETRs that are authoritative for the
   EID in the Map-Request.

4.4.2.  Attacks with Map-Reply messages

   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.

   There are two different types of Map-Reply messages:

   Positive Map-Reply:  These messages contain a Map-Record binding an
         EID-Prefix to one or more RLOCs.

   Negative Map-Reply:  These 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.

   Positive Map-Reply messages are its attacks and hide the origin of the attack.
   Indeed, on the one hand, a Map Resolver is used to map EID-Prefixes onto RLOCs.
   Negative Map-Reply messages are dispatch Map-
   Request to the mapping system and, on the other hand, a Map Server is
   used to indicate non-LISP prefixes.
   ITRs can, if needed, be configured dispatch Map-Requests coming from the mapping system to send all traffic destined ETRs
   that are authoritative for
   non-LISP prefixes to a Proxy-ETR. the EID in the Map-Request.

3.8.  Map-Reply messages

   Most of the security of the Map-Reply messages depends on the 64 bits
   nonce that is included in a Map-Request and returned in the Map-
   Reply.  If an ETR does not accept Map-Reply messages with an invalid
   nonce, the risk of attack is acceptable limited given the size of the nonce (64
   bits).  However,  Nevertheless, the nonce only confirms that the Map-Reply
   received was sent in response to response to a Map-Request sent, it does not
   validate the contents of that Map-Reply.

   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
   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,
   if the mapping injected to the ITR points to the address of a node
   controlled by the attacker, it can mount replay, packet manipulation,
   packet interception and suppression, or DoS attacks as it will
   receive every packet destined to a destination lying in the EID
   prefix of the injected mapping.  In addition, the attacker can inject
   plethora of mappings in the ITR to mount an performance attack by
   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
   lot of packets to the EIDs matching the injected mapping.  In this
   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
   be sent to the target which means that with one single packet the
   attacker may generate very high traffic towards its final target.

   If the attacker is a valid ETR in the system it can mount a Map-Request sent, rogue
   attack if it does not
   validate the contents of that Map-Reply. uses prefixes over-claiming.  In addition, an such a scenario, the
   attacker could perform EID-to-RLOC Cache overflow
   attack by de-aggregating (i.e., splitting an EID prefix into
   artificially smaller EID prefixes) either positive or negative
   mappings.

   In presence of malicious ETRs, overclaiming attacks are possible.
   Such an attack happens when and ETR replies to a legitimate Map-
   Request Map-Request message it received
   with a Map-Reply message that contains an EID-Prefix that is larger
   than the prefix owned by the site that
   encompasses the EID of the Map-Request. attacker.  For instance if the prefix owned by the site
   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
   other EIDs than the one the LISP site attacker has authority on.

   A malicious ETR might also fragment  With such
   technique, the attacker can mount the attacks presented above as it
   can (partially) control the mappings installed on its configured EID-to-RLOC target ITR.  To
   force its target ITR to send a Map-Request, nothing prevents the
   attacker to initiate some communication with the ITR.  This method is
   particularly interesting for internal attackers that want to control
   the mappings so installed in their site.  To that ITR's might aim, they simply have
   to install much more mappings than
   really necessary.  This collude with an external attacker ready to over-claim prefixes on
   behalf of the internal attacker.

   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
   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
   Map-Reply is called de-aggregation attack.

4.4.3.  Attacks with not known in advance by the ITR.

   Map-Request and Map-Reply messages are at the mercy of any type of
   attackers, on-path or off-path but also external or internal
   attackers.  Also, even though they are control message, they can be
   leveraged by data-plane attackers.  As the decision of removing
   mappings is based on the TTL indicated in the mapping, time-shifted
   attackers can take benefit of injecting forged mappings as well.

3.9.  Map-Register messages

   Map-Register messages are sent by ETRs to indicate to the mapping
   system the EID prefixes associated to them.  The Map-Register message
   provides an EID prefix and the list of ETRs that are able to provide
   Map-Replies for the EID covered by the EID prefix.

   As Map-Register messages are protected by an authentication
   mechanism, only a compromised ETR can register itself to its
   allocated Map Server.

   A compromised ETR can perform an overclaiming attack over-claim the prefix it owns in order to
   influence the route followed by Map-Requests for EIDs outside the
   scope of its legitimate EID prefix. prefix (see Section 3.8 for the list of
   attacks opened by over-claiming).

   A compromised ETR can also perform a deaggregation attack de-aggregate its EID prefix in order to
   register more EID prefixes than necessary to its Map Servers. Servers (see
   Section 3.7 for the impact of de-aggregation of prefixes by an
   attacker).

   Similarly, a compromised Map Server can accept invalid registration
   or advertise invalid EID prefix to the indexing sub-system.

4.4.4.  Attacks with mapping system.

3.10.  Map-Notify messages

   Map-Notify messages are sent by a Map Server to an ETR to acknowledge
   the good reception and processing of a Map-Register message.

   A compromised ETR using EID that it is not authoritative for can send
   a Map-Register with the M-bit set and a spoofed source address to
   force the Map Server to send a Map-Notify message to the spoofed
   address and then succeed a relay attack.  Similarly to the pair Map-
   Request/Map-Reply, the pair Map-Register/Map-Notify is protected by a
   nonce making it hard for an attacker to inject a falsified
   notification to an ETR to make this ETR believe that the registration
   succeeded while it has not.

5.  Attack categories

5.1.  Intrusion

5.1.1.  Description

   With an intrusion attack an attacker gains remote access to some
   resources (e.g., a host, a router, or a network) that are normally
   denied to her.

5.1.2.  Vectors

   Intrusion attacks can be mounted using:

   o  Spoofing EID or RLOCs

   o  Instance ID bits

5.2.  Denial of Service (DoS)

5.2.1.  Description

   A Denial of Service (DoS) attack aims at disrupting a specific
   targeted service either by exhausting the resources of the victim up
   to the point that it is not able to provide a reliable service to
   legit traffic and/or systems or by exploiting vulnerabilities to make
   the targeted service unable to operate properly.

5.2.2.  Vectors

   Denial of Service attacks can be mounted using
   o  Gleaning

   o  Interworking

   o  Locator Status Bits

   o  Map-Version bit

   o  Nonce-Present and Echo-Nonce bits

   o  Map-Request message

   o  Map-Reply message

   o  Map-Register message

   o  Map-Notify message

5.3.  Subversion

5.3.1.  Description

   With subversion an attacker can gain access (e.g., using
   eavesdropping or impersonation) ETR to restricted or sensitive
   information such as passwords, session tokens, or any other
   confidential information.  This type acknowledge
   the good reception and processing of attack is usually carried out
   in a way such that the target does not even notice the attack.  When
   the attacker is positioned on Map-Register message.

   Similarly to the path of pair Map-Request/Map-Reply, the target traffic, it is
   called a Man-in-the-Middle attack.  However, this pair Map-Register/
   Map-Notify is not protected by a
   requirement to carry out and eavesdropping attack.  Indeed the
   attacker might be able, nonce making it hard for instance through an intrusion attack on attacker to
   inject a
   weaker system, either falsified notification to duplicate or even re-direct the traffic, in
   both cases having access an ETR to make this ETR believe
   that the raw packets.

5.3.2.  Vectors

   Subversion attacks can be mounted using

   o  Gleaning

   o  Locator Status Bits

   o  Nonce-Present and the Echo-Nonce bits

   o  Map-Request messages

   o  Map-Reply messages

6. registration succeeded while it has not.

4.  Note on Privacy

   As presented by [RFC6973], universal privacy considerations are
   impossible to establish as the privacy definition may vary from one
   to another.  As a consequence, this document does not aim at
   identifying privacy issues related to the LISP protocol but it is
   necessary to highlight that security threats identified in this
   document could play a role in privacy threats as defined in section 5
   of [RFC6973].

7.

   Note, however, that like public deployments of any other control
   plane protocol, in an Internet deployment mappings are public and
   hence provide information about the infrastructure and reachability
   of LISP sites (i.e., the addresses of the edge routers).

5.  IANA Considerations

   This document makes no request to IANA.

8.

6.  Security Considerations

   This document is devoted to threat analysis of the Locator/Identifier
   Separation Protocol and is then a piece of choice to understand the
   security risks at stake while deploying LISP in non-trustable
   environment.

   The purpose of this document is not to provide recommendations to
   protect against attacks, however most of threats can be prevented
   with careful deployment and configuration (e.g., filter) and also by
   applying the general rules in security that consist in activating
   only features that are necessary in the deployment and verifying the
   validity of the information obtained from third parties.  More
   detailed recommendations are given in [Saucez13].

   The control-plane is probably the most critical part of LISP from a
   security viewpoint and it is worth to notice that the specifications
   already offer authentication mechanism for Map-Register messages
   ([RFC6833]) and that [I-D.ietf-lisp-sec] and [I-D.ietf-lisp-ddt] are
   clearly going in the direction of a secure control-plane.

9.

7.  Acknowledgments

   This document builds upon the draft of Marcelo Bagnulo
   ([I-D.bagnulo-lisp-threat]), where the flooding attack and the
   reference environment were first described.

   The authors would like to thank Ronald Bonica, Albert Cabellos, Ross
   Callon, Noel Chiappa, Florin Coras, Vina Ermagan, Dino Farinacci,
   Stephen Farrell, Joel Halpern, Emily Hiltzik, Darrel Lewis, Edward
   Lopez, Fabio Maino, Terry Manderson, and Jeff Wheeler for their
   comments.

   This work has been partially supported by the INFSO-ICT-216372
   TRILOGY Project (www.trilogy-project.org).

   The work of Luigi Iannone has been partially supported by the ANR-13-
   INFR-0009 LISP-Lab Project (www.lisp-lab.org) and the EIT KIC ICT-
   Labs SOFNETS Project.

10.

8.  References

10.1.

8.1.  Normative References

   [RFC6169]  Krishnan, S., Thaler, D., and J. Hoagland, "Security
              Concerns with IP Tunneling", RFC 6169, April 2011.

   [RFC6830]  Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
              Locator/ID Separation Protocol (LISP)", RFC 6830,
              January 2013.

   [RFC6832]  Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
              "Interworking between Locator/ID Separation Protocol
              (LISP) and Non-LISP Sites", RFC 6832, January 2013.

   [RFC6833]  Fuller, V. and D. Farinacci, "Locator/ID Separation
              Protocol (LISP) Map-Server Interface", RFC 6833,
              January 2013.

   [RFC6834]  Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
              Separation Protocol (LISP) Map-Versioning", RFC 6834,
              January 2013.

   [RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
              Morris, J., Hansen, M., and R. Smith, "Privacy
              Considerations for Internet Protocols", RFC 6973,
              July 2013.

10.2.

8.2.  Informative References

   [Florin13]
              Coras, F., Domingo-Pascual, J., Lewis, D., and A.
              Cabellos-Aparicio, "An Analytical Model for Loc/ID
              Mappings Caches",  Technical Report. arXiv:1312.1378v2,
              2013, <http://arxiv.org/pdf/1312.1378v2.pdf>.

   [I-D.bagnulo-lisp-threat]
              Bagnulo, M., "Preliminary LISP Threat Analysis",
              draft-bagnulo-lisp-threat-01 (work in progress),
              July 2007.

   [I-D.ietf-lisp-ddt]
              Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP
              Delegated Database Tree", draft-ietf-lisp-ddt-01 (work in
              progress), March 2013.

   [I-D.ietf-lisp-deployment]

   [I-D.ietf-lisp-sec]
              Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
              Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-06
              (work in progress), April 2014.

   [RFC7215]  Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-
              Pascual, J., and D. Lewis, "LISP "Locator/Identifier Separation
              Protocol (LISP) Network Element Deployment
              Considerations", draft-ietf-lisp-deployment-12
              (work in progress), January 2014.

   [I-D.ietf-lisp-sec]
              Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D.,
              and O. Bonaventure, "LISP-Security (LISP-SEC)",
              draft-ietf-lisp-sec-05 (work in progress), October 2013.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005. 7215, April 2014.

   [Saucez13]
              Saucez, D., Iannone, L., and O. Bonaventure, "The Map-and-
              Encap Locator/Identifier separation paradigm: a Security
              Analysis",  Solutions for Sustaining Scalability in
              Internet Growth, IGI Global, 2013.

Appendix A.  Document Change Log

   o  Version 10 Posted July 2014.

      *  Document completely remodeled according to the discussions on
         the mailing list in the thread
         http://www.ietf.org/mail-archive/web/lisp/current/msg05206.html
         and to address comments from Ronald Bonica and Ross Callon.

   o  Version 09 Posted March 2014.

      *  Updated document according to the review of A. Cabellos.

   o  Version 08 Posted October 2013.

      *  Addition of a privacy consideration note.

      *  Editorial changes

   o  Version 07 Posted October 2013.

      *  This version is updated according to the thorough review made
         during October 2013 LISP WG interim meeting.

      *  Brief recommendations put in the security consideration
         section.

      *  Editorial changes

   o  Version 06 Posted October 2013.

      *  Complete restructuration, temporary version to be used at
         October 2013 interim meeting.

   o  Version 05 Posted August 2013.

      *  Removal of severity levels to become a short recommendation to
         reduce the risk of the discussed threat.

   o  Version 04 Posted February 2013.

      *  Clear statement that the document compares threats of public
         LISP deployments with threats in the current Internet
         architecture.

      *  Addition of a severity level discussion at the end of each
         section.

      *  Addressed comments from V. Ermagan and D. Lewis' reviews.

      *  Updated References.

      *  Further editorial polishing.

   o  Version 03 Posted October 2012.

      *  Dropped Reference to RFC 2119 notation because it is not
         actually used in the document.

      *  Deleted future plans section.

      *  Updated References

      *  Deleted/Modified sentences referring to the early status of the
         LISP WG and documents at the time of writing early versions of
         the document.

      *  Further editorial polishing.

      *  Fixed all ID nits.

   o  Version 02 Posted September 2012.

      *  Added a new attack that combines overclaiming over-claiming and de-
         aggregation (see Section 4.4.2). 3.8).

      *  Editorial polishing.

   o  Version 01 Posted February 2012.

      *  Added discussion on LISP-DDT.

   o  Version 00 Posted July 2011.

      *  Added discussion on LISP-MS>.

      *  Added discussion on Instance ID in Section 4.3.2. ID.

      *  Editorial polishing of the whole document.

      *  Added "Change Log" appendix to keep track of main changes.

      *  Renamed "draft-saucez-lisp-security-03.txt.

Authors' Addresses

   Damien Saucez
   INRIA
   2004 route des Lucioles BP 93
   06902 Sophia Antipolis Cedex
   France

   Email: damien.saucez@inria.fr

   Luigi Iannone
   Telecom ParisTech
   23, Avenue d'Italie, CS 51327
   75214 PARIS Cedex 13
   France

   Email: luigi.iannone@telecom-paristech.fr

   Olivier Bonaventure
   Universite catholique de Louvain
   Place St. Barbe 2
   Louvain la Neuve
   Belgium

   Email: olivier.bonaventure@uclouvain.be