--- 1/draft-ietf-lisp-threats-09.txt 2014-07-04 08:14:29.113792053 -0700 +++ 2/draft-ietf-lisp-threats-10.txt 2014-07-04 08:14:29.153793003 -0700 @@ -1,769 +1,727 @@ Network Working Group D. Saucez Internet-Draft INRIA Intended status: Informational L. Iannone -Expires: October 10, 2014 Telecom ParisTech +Expires: January 5, 2015 Telecom ParisTech O. Bonaventure Universite catholique de Louvain - April 8, 2014 + 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. + Separation Protocol (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. + This Internet-Draft will expire on 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 . . . . . . . . . . . . . . . . . . . . . . 3 - 3. Off-Path Attackers: Reference Environment . . . . . . . . . . 3 - 4. Attack vectors . . . . . . . . . . . . . . . . . . . . . . . . 5 - 4.1. Configured EID-to-RLOC mappings . . . . . . . . . . . . . 6 - 4.2. EID-to-RLOC Cache . . . . . . . . . . . . . . . . . . . . 6 - 4.3. Attacks using the data-plane . . . . . . . . . . . . . . . 7 - 4.3.1. Attacks not leveraging on the LISP header . . . . . . 7 - 4.3.2. Attacks leveraging on the LISP header . . . . . . . . 8 - 4.4. Attacks using the control-plane . . . . . . . . . . . . . 11 - 4.4.1. Attacks with Map-Request messages . . . . . . . . . . 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 . . . . . . . . . . . 14 - 5. Attack categories . . . . . . . . . . . . . . . . . . . . . . 14 - 5.1. Intrusion . . . . . . . . . . . . . . . . . . . . . . . . 14 - 5.1.1. Description . . . . . . . . . . . . . . . . . . . . . 14 - 5.1.2. Vectors . . . . . . . . . . . . . . . . . . . . . . . 14 - 5.2. Denial of Service (DoS) . . . . . . . . . . . . . . . . . 14 - 5.2.1. Description . . . . . . . . . . . . . . . . . . . . . 14 - 5.2.2. Vectors . . . . . . . . . . . . . . . . . . . . . . . 14 - 5.3. Subversion . . . . . . . . . . . . . . . . . . . . . . . . 15 - 5.3.1. Description . . . . . . . . . . . . . . . . . . . . . 15 - 5.3.2. Vectors . . . . . . . . . . . . . . . . . . . . . . . 15 - 6. Note on Privacy . . . . . . . . . . . . . . . . . . . . . . . 16 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 - Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 18 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 + 2. Threat model . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2.1. Attacker modes of operation . . . . . . . . . . . . . . . 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 + 2.1.5. Cross mode attackers . . . . . . . . . . . . . . . . . 5 + 2.2. Threat categories . . . . . . . . . . . . . . . . . . . . 5 + 2.2.1. Replay attack . . . . . . . . . . . . . . . . . . . . 5 + 2.2.2. Packet manipulation . . . . . . . . . . . . . . . . . 5 + 2.2.3. Packet interception and suppression . . . . . . . . . 6 + 2.2.4. Spoofing . . . . . . . . . . . . . . . . . . . . . . . 6 + 2.2.5. Rogue attack . . . . . . . . . . . . . . . . . . . . . 6 + 2.2.6. Denial of Service (DoS) attack . . . . . . . . . . . . 7 + 2.2.7. Performance attack . . . . . . . . . . . . . . . . . . 7 + 2.2.8. Intrusion attack . . . . . . . . . . . . . . . . . . . 7 + 2.2.9. Amplification attack . . . . . . . . . . . . . . . . . 7 + 2.2.10. Multi-category attacks . . . . . . . . . . . . . . . . 7 + 3. Attack vectors . . . . . . . . . . . . . . . . . . . . . . . . 7 + 3.1. Gleaning . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 3.2. Locator Status Bits . . . . . . . . . . . . . . . . . . . 9 + 3.3. Map-Version . . . . . . . . . . . . . . . . . . . . . . . 9 + 3.4. Echo-Nonce algorithm . . . . . . . . . . . . . . . . . . . 10 + 3.5. Instance ID . . . . . . . . . . . . . . . . . . . . . . . 11 + 3.6. Interworking . . . . . . . . . . . . . . . . . . . . . . . 11 + 3.7. Map-Request messages . . . . . . . . . . . . . . . . . . . 12 + 3.8. Map-Reply messages . . . . . . . . . . . . . . . . . . . . 13 + 3.9. Map-Register messages . . . . . . . . . . . . . . . . . . 14 + 3.10. Map-Notify messages . . . . . . . . . . . . . . . . . . . 14 + 4. Note on Privacy . . . . . . . . . . . . . . . . . . . . . . . 14 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 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 main parts: the first discussing the - techniques that can be used by attackers to succeed attacks based on - the LISP protocol and architecture; the second discussing the main - categories of attacks and how to construct them. + The document is composed of three main parts: the first defines the + general threat model that attackers can follow to mount attacks. The + second describing the techniques based on the LISP protocol and + architecture that attackers can use to construct attacks. The third + discussing general solutions to protect the LISP protocol and + architecture from attacks. This document does not consider all the possible uses of LISP as - discussed in [RFC6830] and [I-D.ietf-lisp-deployment]. 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. + discussed in [RFC6830] and [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 +2. Threat model - On-path attackers are attackers that are able to capture and modify - all the packets exchanged between an Ingress Tunnel Router (ITR) and - an Egress Tunnel Router (ETR). To cope with such an attacker, - cryptographic techniques such as those used 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. + This document assumes that attackers can be located anywhere in the + Internet (either in LISP sites or outside LISP sites) and that + attacks can be mounted either by a single attacker or by the + collusion of several attackers. - Similarly, 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. This documents does not consider time-shifted - attacks. + An attacker is a malicious entity that performs the action of + attacking a target in a network where LISP is (partially) deployed by + leveraging the LISP protocol and/or architecture. -3. Off-Path Attackers: Reference Environment + An attack is the action of performing an illegitimate action on a + target in a network where LISP is (partially) deployed. - The reference environment shown in the figure below is considered - throughout this document. There are two hosts attached to LISP - routers: HA and HB. HA is attached to the two LISP xTRs LR1 and LR2, - which in turn are attached to two different ISPs. HB is attached to - the two LISP xTRs LR3 and LR4. HA and HB are the EIDs of the two - hosts. LR1, LR2, LR3, and LR4 are the RLOCs of the xTRs. PxTR is a - proxy xTR and MR/MS plays the roles of Map Server and/or Map - Resolver. + The target of an attack is the entity (i.e., a device connected to + the network or a network) that is aimed to undergo the consequences + of an attack. Other entities can potentially undergo side effects of + an attack, even though they are not directly targeted by the attack. + The 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. - +-----+ - | HA | - +-----+ - | EID: HA - | - ----------------- - | | - +-----+ +-----+ - | LR1 | | LR2 | - +-----+ +-----+ - | | - | | - +-----+ +-----+ - |ISP1 | |ISP2 | - +-----+ +-----+ - | | - +------+ +----------------+ +-----+ - | PxTR |-----| |-----| SA | - +------+ | | +-----+ - | Internet | - +-------+ | | +-----+ - | MR/MS |----| |-----| NSA | - +-------+ +----------------+ +-----+ - | | - +-----+ +-----+ - | LR3 | | LR4 | - +-----+ +-----+ - | | - ------------------- - | - | EID: HB - +-----+ - | HB | - +-----+ + Section 2.1 specifies the different modes of operation that attackers + can follow to mount attacks and Section 2.2 specifies the different + categories of attacks that attackers can build. - Figure 1: Reference Network +2.1. Attacker modes of operation - We consider two off-path attackers with different capabilities: + Attackers can be classified according to the following four modes of + operation, i.e., the temporal and spacial locality of the attacker. - 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. SA stands for Spoofing Attacker. To - perform some of the attacks described in this document SA needs - to be in a non-LISP site. +2.1.1. On-path attackers vs. Off-path attackers - NSA is an off-path attacker that is only able to send packets whose - source address is its assigned IP address. NSA stands for Non - Spoofing Attacker. + On-path attackers, also known as Men-in-the-Middle, are able to + intercept and modify packets between legitimate communicating + entities. On-path attackers are located either directly on the + normal communication path (either by gaining access to a node on the + path or by placing themselves directly on the path) or outside the + location path but manage to deviate or gain a copy of packets sent + between the communication entities. On-path attackers hence mount + their attacks by modifying packets initially sent legitimately + between communication entities. - 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 that is not - the one of the actual originator of the packet. Since LISP uses - encapsulation, the spoofed address could be in the outer header as - well as in the inner header, this translates in two types of - spoofing: + An attacker is called off-path attacker if it does not have access to + packets exchanged during the communication or if there is no + communication. To succeed their attacks, off-path attackers must + hence generate packets and inject them in the network. - 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 - (or a PITR if the source site is not LISP enabled). +2.1.2. Internal attackers vs. External attackers - RLOC Spoofing: the originator of the packet generates directly a - LISP-encapsulated packet with a spoofed source RLOC. + An internal attacker launches its attack from a node located within a + legitimate LISP site. Such an attacker is either a legitimate node + of the 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 site they are in. - Note that the two types of spoofing are not mutually exclusive, - rather all combinations are possible and could be used to perform - different kind of attacks. + On the contrary, an external attacker launches its attacks from the + outside of a legitimate LISP site. - In the reference environment, both SA and NSA attackers are capable - of sending LISP encapsulated data packets and LISP control packets. - This means that SA is able to perform both RLOC and EID spoofing - while NSA can only perform EID spoofing. They may also send other - types of IP packets such as ICMP messages. We assume that both - attackers can query the LISP mapping system (e.g., through a public - Map Resolver) to obtain the mappings for both HA and HB. +2.1.3. Live attackers vs. Time-shifted attackers -4. Attack vectors + A live attacker mounts attacks for which it must remain connected as + long as the attack is mounted. In other words, the attacker must + remain active for the whole duration of the attack. Consequently, + the attack ends as soon as the attacker (or the used attack vector) + is neutralized. - This section presents techniques that can be used by attackers to - succeed attacks leveraging the LISP protocol and architecture. This - section focuses on the techniques while Section 5 presents the - attacks that can be succeeded while using these techniques. + On the contrary, a time-shifted attacker mounts attacks that remain + active after it disconnects from the Internet. -4.1. Configured EID-to-RLOC mappings +2.1.4. Control-plane attackers vs. Data-plane attackers - 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 of the xTR's globally visible IP addresses is a - RLOC for those EID-Prefixes. + A control-plane attacker mounts its attack by using control-plane + functionalities, typically the mapping system. - As these mappings are 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. + A data-plane attacker mounts its attack by using data-plane + functionalities. -4.2. EID-to-RLOC Cache + As there is no strict delimitation between the control-plane and the + data-plane, an attacker can operate in the control-plane (resp. data- + plane) to mount attacks targeting the data-plane (resp. control- + plane) or keep the attacked and targeted planes at the same layer + (i.e., from control-plane to control-plane or from data-plane to + data-plane). - The EID-to-RLOC Cache (also called the Map-Cache) is the data - structure that stores a copy of the mappings retrieved from a remote - ETR's mapping via the LISP control-plane. Attacks against this data - structure could happen either when the mappings are first installed - in the cache or by corrupting (poisoning) the mappings already - present in the cache. +2.1.5. Cross mode attackers - Cache poisoning attacks are used to alter (any combination of) the - following parts of the mappings installed in the EID-to-RLOC Cache: + The attacker modes of operation are not mutually exclusive and hence + attackers can combine them to mount attacks. - o EID prefix + For example, an attacker can launch an attack using the control-plane + directly from within a LISP site to which it got temporary access + (i.e., internal + control-plane attacker) to create a vulnerability + on its target and later on (i.e., time-shifted + external attacker) + mount an attack on the data plane (i.e., data-plane attacker) that + leverages the vulnerability. - o RLOC list +2.2. Threat categories - o RLOC priority + Attacks can be classified according to the nine following categories. - o RLOC weight +2.2.1. Replay attack - o RLOC reachability + A replay attack happens when an attacker retransmits at a later time, + and without modifying it, a packet (or a sequence of packets) that + has already been transmitted. - o Mapping TTL +2.2.2. Packet manipulation - o Mapping version + A packet manipulation attack happens when an attacker receives a + packet, modifies the packet (i.e., changes some information contained + in the packet) and finally transmits the packet to its final + destination that can be the initial destination of the packet or + another one. - o Mapping Instance ID +2.2.3. Packet interception and suppression - Cache poisoning attacks can be performed by attackers from the - outside of the attacked LISP network but also directly from the - inside. As a matter of fact, end-hosts behind an ITR can use the - data-plane to overflow the ITR's EID-to-RLOC Cache by sending packets - to non-popular EID prefixes (similar to scan attack but with a - different goal). In such a scenario the ITR may evict popular (in- - use) entries from the map-cache disrupting the normal operation of - the network by forcing cache miss [Florin13]. + In a packet interception and suppression attack, the attacker + captures the packet and drops it before it can reach its final + destination. -4.3. Attacks using the data-plane +2.2.4. Spoofing - The data-plane is constituted of the operations of encapsulation, - decapsulation, and forwarding as well as the content of the EID-to- - RLOC Cache and configured EID-to-RLOC mappings as specified in the - original LISP document ([RFC6830]). + With a spoofing attack, the attacker injects packets in the network + pretending being another node. Spoofing attacks are made by forging + source addresses in packets. -4.3.1. Attacks not leveraging on the LISP header + It should be noted that with LISP, packet spoofing is similar to any + other existing tunneling technology currently deployed in the + Internet. Generally the term "spoofed packet" indicates a packet + containing a source IP address that is not the one of the actual + originator of the packet. Hence, since LISP uses encapsulation, the + spoofed address could be in the outer header as well as in the inner + header, this translates in two types of spoofing. - An attacker can inject packets into flows without using the LISP - header, i.e., with the N, L, E, V, and I bits ([RFC6830]). + Inner address spoofing: the attacker uses encapsulation and uses a + spoofed source address in the inner packet. In case of data- + plane LISP encapsulation, that corresponds to spoof the source + EID address of the encapsulated packet. - Taking notation of the reference environment (Figure 1), to inject a - packet in the HA->HB flow, a spoofing off-path attacker (SA) could - 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. A non-spoofing off-path attacker (NSA) could only send a - packet whose source address is set to its assigned IP address. The - destination address of the encapsulated packet could be LR3 or LR4. + Outer address spoofing: the attacker does not use encapsulation and + spoofs the source address of the packet. -4.3.1.1. Gleaning Attacks + Note that the two types of spoofing are not mutually exclusive, + rather all combinations are possible and could be used to perform + different kind of attacks. For example, an attacker not in a LISP + site can generate a packet with a forged source IP address (i.e., + outer address spoofing) and forward it to a LISP destination. The + packet is then eventually encapsulated by a PITR so that once + encapsulated the 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. - In order to reduce the time required to obtain a mapping, [RFC6830] - proposes the gleaning mechanism that 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 an ITR - receives a data encapsulated packet coming from a source EID for + It is important to notice that the combination of inner and outer + spoofing makes the identification of the attacker complex as the + packet may not contain information that permits to detect the origin + of the attack. + +2.2.5. Rogue attack + + In a rogue attack the attacker manages to appear as a legitimate + source 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 + 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 a network) or 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 traffic generated by the target of + the attack in response to the attack is larger than the traffic that + the attacker must generate. + +2.2.10. Multi-category attacks + + Attacks categories are not mutually exclusive and any combination can + be used to perform specific attacks. + + For example, one can mount a rogue attack to perform a performance + attack starving the memory of an ITR resulting in a DoS on the ITR. + +3. Attack vectors + + This section presents techniques that can be 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, the optional + gleaning mechanism allows an xTR to directly learn a mapping from the + LISP data encapsulated packets and the Map-Request packets that it + receives. LISP encapsulated data packets contain a source RLOC, + destination RLOC, source EID and destination EID. When an xTR + receives 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 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 EID-to-RLOC cache, the - LISP ITR sends a Map-Request to retrieve the 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 a mapping - for host HA at that time. The xTR will store the gleaned entry and - use it to return the packets sent by host HB. In parallel, the ETR - 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) 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. If host HA is - willing to establish a flow with host HB at that time, the packets - that they exchange will pass through the attacker as long as the - gleaned entry is active on the xTRs. + The same technique can be used when an 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 xTR + sends a Map-Request to retrieve the actual mapping for the gleaned + EID from the mapping system. - By itself, an attack made solely using gleaning cannot last long, - however it should be noted that with current network capacities, a - large amount of packets might be exchanged during even a small - fraction of time. + If a packet injected by an off-path attacker and with a spoofed inner + address is gleaned by an xTR then the attacker may divert the traffic + meant to be delivered to the spoofed EID as long as the gleaned entry + is used by the xTR. This attack can be used as part of replay, + packet manipulation, packet interception and suppression, or DoS + attacks as the packets are sent to the attacker. -4.3.1.2. Threats concerning Interworking + If the packet sent by the attacker contains a spoofed outer address + instead of a spoofed inner address then it can succeed a DoS or a + performance attack as the traffic normally destined to the attacker + will be redirected to the spoofed source RLOC. Such traffic may + overload the owner of the spoofed source RLOC, preventing it from + operating properly. - [RFC6832] defines Proxy-ITR and Proxy-ETR network elements to allow - LISP and non-LISP sites to communicate. The Proxy-ITR has - functionality similar to the ITR, however, its main purpose is to - encapsulate packets arriving from the DFZ in order to reach LISP - sites. A Proxy-ETR has functionality similar to the ETR, however, - its main purpose is to inject de-encapsulated packets in the DFZ in - order to reach non-LISP Sites from LISP sites. As a PITR (resp. - PETR) is a particular case of ITR (resp. ETR), it is subject to same - attacks than ITRs (resp. ETR). + If the 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 the spoofed EID address will + be sent to the spoofed RLOC address. If the attacked LISP site also + generates traffic to the spoofed EID address, such traffic may have a + positive amplification factor. - PxTRs can be targeted by attacks aiming to influence traffic between - LISP and non-LISP sites but also to launch relay attacks. + A gleaning attack does not only impact the data-plane but can also + have repercussions on the control-plane as a Map-Request is 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 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 an over-utilisation of the control-plane as each packet + generates a control-plane event. For succeeding this example, the + attacker may not need to use spoofing. - It is worth to notice that when PITR and PETR functions are - separated, attacks targeting nodes that collocate PITR and PETR - functionality are ineffective. + Gleaning attacks are fundamentally involving a time-shifted mode of + operation as the attack may last as long as the gleaned entry is kept + by the targeted xTR. Nevertheless, [RFC6830] recommends to store the + gleaned entries for only a few seconds which limits the duration of + the attack. -4.3.2. Attacks leveraging on the LISP header + Gleaning attacks always involve external data-plane attackers but + results in attacks on either the control-plane or data-plane. - The main LISP document [RFC6830] 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. + It is worth to notice that the outer spoofed address does not need to + be the RLOC of a LISP site an may be any address. -4.3.2.1. Attacks using the Locator Status Bits +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 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 [RFC6830]. + mapped to the 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]. - An attacker can send a data packet with the L bit set to 1 and some - or all Locator Status Bits set to zero. Therefore, by blindly - trusting the Locator Status Bits communication going on can be - altered or forced to go through a particular set of locators. + 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 same result of injecting packets with + invalid LSB values by replaying packets. -4.3.2.2. Attacks using the Map-Version bit + The LSB field can be leveraged to succeed a DoS attack by either + declaring all RLOCs as unreachable (all LSB set to 0), or by + concentrating all the traffic to one RLOC (e.g., all but one LSB set + to 0) and hence overloading the RLOC concentrating all the traffic + from the xTR, or by forcing packets to be sent to RLOCs that are + actually not reachable (e.g., invert LSB values). - The optional Map-Version bit is used to indicate whether the low- - order 24 bits of the first 32 bits longword of the LISP header - contain a 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: + The LSB field can also be used to mount a replay, a packet + manipulation, or a packet interception and suppression attack. + Indeed, if the attacker manages to be on the path between the xTR and + one of the RLOCs specified in the mapping, forcing packets to go via + that RLOC implies that the attacker will gain access to the packets. + + 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 + + When the Map-Version bit is set to 1, it indicates that the low-order + 24 bits of the first 32 bits longword of the LISP header contain a + Source and Destination Map-Version. When a LISP 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 attacker could 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 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 Section 4.4.1) so that more bandwidth is - consumed on the target (because of the larger packets) than the - bandwidth necessary at the attacker side. + A cross-mode attacker can use the Map-Version bit to mount a DoS + attack, an amplification attack, or a spoofing attack. For instance + if the mapping cached at the xTR is outdated, the xTR will send a + Map-Request to retrieve the new mapping which can yield to a DoS + attack (by excess of signalling traffic) or an amplification attack + if the data-plane packet sent by the attacker is smaller than the + 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. -4.3.2.3. Attacks using the Nonce-Present and the Echo-Nonce bits + 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. - 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 these - packets, LR1 will store the nonce sent by LR3 and echo it when it - returns LISP encapsulated data packets to LR3. +3.4. Echo-Nonce algorithm - A spoofing off-path attacker (SA) could interfere with this - reachability test by sending two different types of packets: + The Nonce-Present and Echo-Nonce bits are used to verifying the + reachability of 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 the LISP header of packets. Upon reception of these + packets, the tested xTR stores the nonce and echo it whenever it + returns a LISP encapsulated data packets to the testing xTR. The + reception of the echoed nonce confirms that the tested xTR is + reachable. + + An attacker can interfere with 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. + a random 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. These packets will force the receiving ETR to - store the received nonce and echo it in the LISP encapsulated - packets that it sends. - - 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 to - believe that the ETR it is testing is reachable while in reality it - is not reachable. To increase the success likelihood of such attack, - the attacker should create a massive amount of packets carrying all - possible nonce values. + Echo-Nonce bits both 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 second type of packet could be exploited to attack 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 depends on the ratio between the - amount of packets sent by the legitimate ITR and the spoofing off- - path attacker (SA). + The first type of packets is used to make xTRs think that an other + xTR is reachable while it is not. It is hence a way to mount a DoS + attack (i.e., the ITR will send its packet to a non-reachable ETR + while it should use another one). -4.3.2.4. Attacks using the Instance ID bits + The second type of packets could be exploited to attack the nonce- + based reachability test. If the attacker sends a continuous flow of + packets that each have a different random nonce, the ETR that + receives such packets will continuously change the nonce that it + returns to the remote ITR, which can yield to a performance attack. + If the remote ITR tries a nonce-reachability test, this test may fail + because the ETR may echo an invalid nonce. This hence yields to a + DoS attack. - 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 used for forwarding the decapsulated packet. + In the case of an on-path attacker, a packet manipulation attack is + necessary to mount the attack. To mount such an attack, an off-path + attacker must mount an outer address spoofing attack. - 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. +3.5. Instance ID -4.4. Attacks using the control-plane + 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 the instance ID decides the + forwarding table to use to forward the decapsulated packet in the + LISP site. - 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 to the ETR and do not - analyze the particularities of the different LISP indexing sub- - system. + An attacker (either a control-plane or data-plane attacker) can use + the instance ID functionality to mount an intrusion attack. -4.4.1. Attacks with Map-Request messages +3.6. Interworking - 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 [RFC6830] contains several particularities that could - be exploited by an off-path attacker. + [RFC6832] defines Proxy-ITR and Proxy-ETR network elements to allow + LISP and non-LISP sites to communicate. The Proxy-ITR has + functionality similar to the ITR, however, its main purpose is to + encapsulate packets arriving from the DFZ in order to reach LISP + sites. A Proxy-ETR has functionality similar to the ETR, however, + its main purpose is to inject de-encapsulated packets in the DFZ in + order to reach non-LISP Sites from LISP sites. As a PITR (resp. + PETR) is a particular case of ITR (resp. ETR), it is subject to same + attacks than ITRs (resp. ETR). - The first possible exploitation is the RLOC record P bit. The RLOC - record P bit is used to probe the reachability of remote ETRs. In - our reference environment, LR3 could probe the reachability of LR1 by - sending a Map-Request with the RLOC record P bit set. LR1 would - reply by sending a Map-Reply message with the RLOC record P bit set - and the same nonce as in the Map-Request message. + As any other system relying on proxies, LISP interworking can be used + by attackers to hide their exact origin in the network. - A spoofing off-path attacker (SA) could use the RLOC record P bit to - force a victim ETR to send a Map-Reply to the spoofed source address - of the Map-Request message. As the Map-Reply can be larger than the - Map-Request message, there is a risk of amplification attack. Map- - Requests are usually smaller than a hundred bytes while the maximum - size of a Map-Reply (without considering any MTU constrain) can be - above 1 MB, largely bigger than the message sent by the attacker. - These numbers are however theoretical values not considering - transport layer limitations and it is more likely that the reply will - contain only one record with at most a dozen of locators, limiting so - the amplification factor. +3.7. Map-Request messages - Similarly, if a non-spoofing off-path attacker (NSA) sends a Map- - Request with the RLOC record P bit set, it will receive a Map-Reply - with the RLOC record P bit set. + A control-plane off-path attacker can exploit Map-Request messages to + mount DoS, performance, or amplification attacks. By sending Map- + Request messages at high rate, the attacker can overload nodes + involved in the mapping system. For instance sending Map-Requests at + high rate can considerably increase the state maintained in a Map- + Resolver or consume CPU cycles on ETRs that have to process the Map- + Request packets they receive in their slow path (i.e., performance or + DoS attack). When the Map-Reply packet is larger than the Map- + Request sent by the attacker, that yields to an amplification attack. + The attacker can combine the attack with a spoofing attack to + overload the node to which the spoofed address is actually attached. - 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, the ETR would send large - Map-Reply messages, for each of the addresses back to the victim ITR. + It is worth to notice that if the attacker sets the P bit in the Map- + Request, it is legitimate the send the Map-Request directly to the + ETR instead of passing through the mapping system. - 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. Note that according to [RFC6830] the SMR- - triggered Map-Request might be sent through the mapping system, - depending on the number of RLOCs in the locators set. This raises - similar problems as the RLOC record 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. + The SMR bit can be used to mount a variant of these attacks. - Furthermore, appending Map-Records to Map-Request messages allows an - off-path attacker to generate a (spoofed or not) Map-Request message - and include in the Map-Reply portion of the message mapping for EID - prefixes that it does not serve. + For efficiency reasons, Map-Records can be appended to Map-Request + messages. When an xTR receives a Map-Request with appended Map- + Records, it does the same operations as for the other Map-Request + messages and is so subject to the same attacks. However, it also + installs in its EID-to-RLOC cache the Map-Records contained in the + Map-Request. An attacker can then use this vector to force the + installation of mappings in its target xTR. Consequently, the EID- + to-RLOC cache of the xTR is polluted by potentially forged mappings + allowing the attacker to mount any of the attacks categorized in + Section 2.2 (see Section 3.8 for more details). It is worth to + mention that the attacker does not need to forge the mappings present + in the Map-Request to succeed a performance or DoS attack. Indeed, + if the attacker owns a large enough EID prefix it can de-aggregate it + in many small prefixes, each corresponding to another mapping and it + them in the xTR cache by the mean of the 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. + elements to relay its attacks and hide the origin of the attack. + Indeed, on the one hand, a Map Resolver is used to dispatch Map- + 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. - Positive Map-Reply messages are used to map EID-Prefixes onto RLOCs. - Negative Map-Reply messages are used to indicate non-LISP prefixes. - ITRs can, if needed, be configured to send all traffic destined for - non-LISP prefixes to a Proxy-ETR. +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 given the size of the nonce - (64 bits). However, the nonce only confirms that the Map-Reply + nonce, the risk of attack is limited given the size of the nonce (64 + bits). Nevertheless, the nonce only confirms that the Map-Reply received was sent in response to a Map-Request sent, it does not validate the contents of that Map-Reply. - In addition, an 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. + 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. - In presence of malicious ETRs, overclaiming attacks are possible. - Such an attack happens when and ETR replies to a legitimate 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. For instance if the prefix - owned by the site is 192.0.2.0/25 but the Map-Reply contains a - mapping for 192.0.2.0/24, then the mapping will influence packets - destined to other EIDs than the one the LISP site has authority on. + If the attacker is a valid ETR in the system it can mount a rogue + attack if it uses prefixes over-claiming. In such a scenario, the + attacker ETR replies to a legitimate Map-Request message it received + with a Map-Reply message that contains an EID-Prefix that is larger + than the prefix owned by the attacker. For instance if the owned + 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 attacker has authority on. With such + technique, the attacker can mount the attacks presented above as it + can (partially) control the mappings installed on its 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 installed in their site. To that aim, they simply have + to collude with an external attacker ready to over-claim prefixes on + behalf of the internal attacker. - A malicious ETR might also fragment its configured EID-to-RLOC - mappings so that ITR's might have to install much more mappings than - really necessary. This attack is called de-aggregation attack. + 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 not known in advance by the ITR. -4.4.3. Attacks with Map-Register messages + 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 in order to + A compromised ETR can over-claim the prefix it owns in order to influence the route followed by Map-Requests for EIDs outside the - scope of its legitimate EID prefix. + scope of its legitimate EID prefix (see Section 3.8 for the list of + attacks opened by over-claiming). - A compromised ETR can also perform a deaggregation attack in order to - register more EID prefixes than necessary to its Map Servers. + A compromised ETR can also de-aggregate its EID prefix in order to + register more EID prefixes than necessary to its Map 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. + or advertise invalid EID prefix to the mapping system. -4.4.4. Attacks with Map-Notify messages +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) to restricted or sensitive - information such as passwords, session tokens, or any other - confidential information. This type 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 the path of the target traffic, it is - called a Man-in-the-Middle attack. However, this is not a - requirement to carry out and eavesdropping attack. Indeed the - attacker might be able, for instance through an intrusion attack on a - weaker system, either to duplicate or even re-direct the traffic, in - both cases having access to 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 + 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. -6. Note on Privacy +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. IANA Considerations + 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. Security Considerations +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. Acknowledgments +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, 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. + 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. References - -10.1. Normative References +8. References - [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security - Concerns with IP Tunneling", RFC 6169, April 2011. +8.1. Normative References [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 @@ -772,60 +730,57 @@ [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. 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, . +8.2. Informative References [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] - Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- - Pascual, J., and D. Lewis, "LISP Network Element - Deployment Considerations", draft-ietf-lisp-deployment-12 - (work in progress), January 2014. - [I-D.ietf-lisp-sec] - 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. + Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. + Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-06 + (work in progress), April 2014. - [RFC4301] Kent, S. and K. Seo, "Security Architecture for the - Internet Protocol", RFC 4301, December 2005. + [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- + Pascual, J., and D. Lewis, "Locator/Identifier Separation + Protocol (LISP) Network Element Deployment + Considerations", RFC 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 @@ -876,34 +831,34 @@ * 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 and de- - aggregation (see Section 4.4.2). + * Added a new attack that combines over-claiming and de- + aggregation (see Section 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. + * Added discussion on Instance 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