diff options
Diffstat (limited to 'doc/rfc/rfc7835.txt')
| -rw-r--r-- | doc/rfc/rfc7835.txt | 1067 |
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc7835.txt b/doc/rfc/rfc7835.txt new file mode 100644 index 0000000..f40bc60 --- /dev/null +++ b/doc/rfc/rfc7835.txt @@ -0,0 +1,1067 @@ + + + + + + +Internet Engineering Task Force (IETF) D. Saucez +Request for Comments: 7835 INRIA +Category: Informational L. Iannone +ISSN: 2070-1721 Telecom ParisTech + O. Bonaventure + Universite catholique de Louvain + April 2016 + + + Locator/ID Separation Protocol (LISP) Threat Analysis + +Abstract + + This document provides a threat analysis of the Locator/ID Separation + Protocol (LISP). + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7835. + +Copyright Notice + + Copyright (c) 2016 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. + + + + + +Saucez, et al. Informational [Page 1] + +RFC 7835 LISP Threats April 2016 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2.1. Operation Modes of Attackers . . . . . . . . . . . . . . 4 + 2.1.1. On-Path vs. Off-Path Attackers . . . . . . . . . . . 4 + 2.1.2. Internal vs. External Attackers . . . . . . . . . . . 4 + 2.1.3. Live vs. Time-Shifted Attackers . . . . . . . . . . . 5 + 2.1.4. Control-Plane 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 . . . . . . . . . . . . . . . . . 6 + 2.2.3. Packet Interception and Suppression . . . . . . . . . 6 + 2.2.4. Spoofing . . . . . . . . . . . . . . . . . . . . . . 6 + 2.2.5. Rogue Attack . . . . . . . . . . . . . . . . . . . . 7 + 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. Passive Monitoring Attacks . . . . . . . . . . . . . 7 + 2.2.11. Multi-category Attacks . . . . . . . . . . . . . . . 8 + 3. Attack Vectors . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.1. Gleaning . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.2. Locator Status Bits . . . . . . . . . . . . . . . . . . . 9 + 3.3. Map-Version . . . . . . . . . . . . . . . . . . . . . . . 10 + 3.4. Routing Locator Reachability . . . . . . . . . . . . . . 11 + 3.5. Instance ID . . . . . . . . . . . . . . . . . . . . . . . 12 + 3.6. Interworking . . . . . . . . . . . . . . . . . . . . . . 12 + 3.7. Map-Request Messages . . . . . . . . . . . . . . . . . . 12 + 3.8. Map-Reply Messages . . . . . . . . . . . . . . . . . . . 13 + 3.9. Map-Register Messages . . . . . . . . . . . . . . . . . . 15 + 3.10. Map-Notify Messages . . . . . . . . . . . . . . . . . . . 15 + 4. Note on Privacy . . . . . . . . . . . . . . . . . . . . . . . 15 + 5. Threat Mitigation . . . . . . . . . . . . . . . . . . . . . . 16 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 17 + 7.2. Informative References . . . . . . . . . . . . . . . . . 17 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 + + + + + + + + + + +Saucez, et al. Informational [Page 2] + +RFC 7835 LISP Threats April 2016 + + +1. Introduction + + The Locator/ID Separation Protocol (LISP) is specified in [RFC6830]. + This document provides an assessment of the potential security + threats for the current LISP specifications if LISP is deployed in + the Internet (i.e., a public non-trustable environment). + + The document is composed of three main parts. The first part defines + a general threat model that attackers use to mount attacks. The + second part, using this threat model, describes the techniques based + on LISP and its architecture that attackers may use to construct + attacks. The third part discusses mitigation techniques and general + solutions to protect LISP and its architecture from attacks. + + This document does not consider all the possible uses of LISP as + discussed in [RFC6830] and [RFC7215] and does not cover threats due + to specific implementations. The document focuses on LISP unicast, + including as well LISP Interworking [RFC6832], LISP Map-Server + [RFC6833], and LISP Map-Versioning [RFC6834]. Additional threats may + be discovered in the future while deployment continues. The reader + is assumed to be familiar with these documents 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. Threat Model + + 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. + + An attacker is a malicious entity that performs the action of + attacking a target in a network where LISP is (partially) deployed by + leveraging LISP and/or its architecture. + + An attack is the action of performing an illegitimate action on a + target in a network where LISP is (partially) deployed. + + 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 to attack one or several targets with a single + attack. + + + +Saucez, et al. Informational [Page 3] + +RFC 7835 LISP Threats April 2016 + + + 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. + +2.1. Operation Modes of Attackers + + In this document, attackers are classified according to their modes + of operation, i.e., the temporal and spacial diversity of the + attacker. These modes are not mutually exclusive; they can be used + by attackers in any combination, and other modes may be discovered in + the future. Further, attackers are not at all bound by our + classification scheme, so implementers and those deploying will + always need to do additional risk analysis for themselves. + +2.1.1. On-Path vs. Off-Path Attackers + + 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. + + An attacker is called an off-path attacker if it does not have access + to packets exchanged during the communication or if there is no + communication. In order for their attacks to succeed, off-path + attackers must hence generate packets and inject them in the network. + +2.1.2. Internal vs. External Attackers + + 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. + + On the contrary, an external attacker launches its attacks from the + outside of a legitimate LISP site. + + + + + + + + + + +Saucez, et al. Informational [Page 4] + +RFC 7835 LISP Threats April 2016 + + +2.1.3. Live vs. Time-Shifted Attackers + + 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. + + On the contrary, a time-shifted attacker mounts attacks that remain + active after it disconnects from the Internet. + +2.1.4. Control-Plane 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 complete isolation between the control plane and the + data plane, an attacker can operate in the control plane (or data + plane) to mount attacks targeting the data plane (or 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). + +2.1.5. Cross-Mode Attackers + + The modes of operation used by attackers are not mutually exclusive; + hence, attackers can combine them to mount attacks. + + For example, an attacker can launch an attack using the control plane + directly from within a LISP site to which it is able to get 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. + +2.2. Threat Categories + + Attacks can be classified according to the eleven following + categories. These categories are not mutually exclusive and can be + used by attackers in any combination. + +2.2.1. Replay Attack + + A replay attack happens when an attacker retransmits a packet (or a + sequence of packets) without modifying it. + + + +Saucez, et al. Informational [Page 5] + +RFC 7835 LISP Threats April 2016 + + +2.2.2. Packet Manipulation + + 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, which can be the initial destination of the packet or a + different one. + +2.2.3. Packet Interception and Suppression + + In a packet interception and suppression attack, the attacker + captures the packet and drops it before it can reach its final + destination. + +2.2.4. Spoofing + + With a spoofing attack, the attacker injects packets in the network + pretending to be another node. Spoofing attacks are made by forging + source addresses in packets. + + It should be noted that with LISP, packet spoofing is similar to + spoofing with 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 + 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 to two types of + spoofing. + + 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 spoofing the source + Endpoint Identifier (EID) address of the encapsulated packet. + + Outer address spoofing: The attacker does not use encapsulation and + spoofs the source address of the packet. In case of data-plane + LISP encapsulation, that corresponds to spoofing the source + Routing Locator (RLOC) address of the encapsulated packet. + + Note that the two types of spoofing are not mutually exclusive; + rather, all combinations are possible and could be used to perform + different kinds of attacks. For example, an attacker outside 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 Proxy Ingress Tunnel + Router (PITR) so that once encapsulated, the attack corresponds to an + inner address spoofing. One can also imagine an attacker forging a + + + + +Saucez, et al. Informational [Page 6] + +RFC 7835 LISP Threats April 2016 + + + packet with encapsulation where both inner and outer source addresses + are spoofed. + + It is important to note that the combination of inner and outer + spoofing makes the identification of the attacker complex as the + packet may not contain information that allows detection of 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 DoS attack aims to disrupt a specific targeted service to make it + unable to operate properly. + +2.2.7. Performance Attack + + A performance attack aims to exploit computational resources (e.g., + memory, processor) of a targeted node so as 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 legitimately should not have accessed. 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. + + In some cases, the data plane can be several orders of magnitude + faster than the control plane at processing packets. This difference + can be exploited to overload the control plane via the data plane + without overloading the data plane. + +2.2.10. Passive Monitoring Attacks + + An attacker can use pervasive monitoring, which is a technical attack + [RFC7258] that targets information about LISP traffic that may or may + not be used to mount other types of attacks. + + + +Saucez, et al. Informational [Page 7] + +RFC 7835 LISP Threats April 2016 + + +2.2.11. Multi-category Attacks + + Attack 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 Ingress Tunnel Router (ITR) + resulting in a DoS on the ITR. + +3. Attack Vectors + + This section presents attack techniques that may be used by attackers + when leveraging LISP and/or its architecture. + +3.1. Gleaning + + To reduce the time required to obtain a mapping, the optional + gleaning mechanism defined for LISP allows an xTR (Ingress and/or + Egress Tunnel Router) to directly learn a mapping from the LISP- + encapsulated data 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. + 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. + + 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. + + If the packet sent by the attacker contains a spoofed outer address + instead of a spoofed inner address, then it can achieve 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. + + If the packet injected uses both inner and outer spoofing, the + attacker can achieve a spoofing, a performance, or an amplification + attack as traffic normally destined to the spoofed EID address will + + + +Saucez, et al. Informational [Page 8] + +RFC 7835 LISP Threats April 2016 + + + 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. + + 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 achieve + 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-utilization of the control plane as each + packet generates a control-plane event. In order for this attack to + succeed, the attacker may not need to use spoofing. This issue can + occur even if gleaning is turned off since whether or not gleaning is + used, the ITR may need to send a Map-Request in response to incoming + packets whose EID is not currently in the cache. + + Gleaning attacks fundamentally involve a time-shifted mode of + operation as the attack may last as long as the gleaned entry is kept + by the targeted xTR. [RFC6830] recommends storing the gleaned + entries for only a few seconds, which limits the duration of the + attack. + + Gleaning attacks always involve external data-plane attackers but + result in attacks on either the control plane or data plane. + + Note that the outer spoofed address does not need to be the RLOC of a + LISP site; it may be any address. + +3.2. Locator Status Bits + + When the L bit in the LISP header is set to 1, it indicates that the + second 32-bit longword of the LISP header contains the Locator- + Status-Bits (LSBs). In this field, each bit position reflects the + status of one of the RLOCs mapped to the source EID found in the + encapsulated packet. The reaction of a LISP xTR that receives such a + packet is left as an operational choice in [RFC6830]. + + When an attacker sends a LISP-encapsulated packet with an + illegitimately crafted LSB to an xTR, it can influence the xTR's + choice of the locators for the prefix associated with 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. + + + +Saucez, et al. Informational [Page 9] + +RFC 7835 LISP Threats April 2016 + + + The LSB field can be leveraged to mount a DoS attack by either + declaring all RLOCs as unreachable (all LSBs set to 0), 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 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 fundamentally involve 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 of the LISP header is set to 1, it indicates + that the low-order 24 bits of the first 32-bit 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 Egress Tunnel Router (ETR) should apply the + Solicit-Map-Request (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. + + 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 signaling traffic) or an amplification attack if + the data-plane packet sent by the attacker is smaller, or otherwise + uses fewer resources, than the control-plane packets sent in response + + + +Saucez, et al. Informational [Page 10] + +RFC 7835 LISP Threats April 2016 + + + 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 a 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 have a specific advantage over off-path attackers. + +3.4. Routing Locator Reachability + + The Nonce-Present and Echo-Nonce bits in the LISP header are used to + verify the reachability of an xTR. A testing xTR sets the Echo-Nonce + and the Nonce-Present bits in LISP-encapsulated data packets and + includes a random nonce in the LISP header of the packets. Upon + reception of these packets, the tested xTR stores the nonce and + echoes it whenever it returns a LISP-encapsulated data packet 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-encapsulated data packets with the Nonce-Present bit set and + a random nonce. Such packets are normally used in response to a + reachability test. + + 2. LISP-encapsulated data packets with the Nonce-Present and the + 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 a trigger for a reachability test. + + The first type of packets are used to make xTRs think that another + xTR is reachable when 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 + when it should use another one). + + 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. + + + + +Saucez, et al. Informational [Page 11] + +RFC 7835 LISP Threats April 2016 + + + 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. + + If an xTR chooses to periodically check with active probes the + liveness of entries in its EID-to-RLOC cache (as described in + Section 6.3 of [RFC6830]), then this may amplify the attack that + caused the insertion of entries being checked. + +3.5. Instance ID + + LISP allows a 24-bit value called Instance ID to be carried in its + header; it's used on the ITR to indicate which local Instance ID has + been used for encapsulation, while on the ETR, the Instance ID + decides which forwarding table to use to forward the decapsulated + packet in the LISP site. + + An attacker (either a control-plane or data-plane attacker) can use + the Instance ID functionality to mount an intrusion attack. + +3.6. 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 to the ITR; however, its main purpose is to + encapsulate packets arriving from the Default-Free Zone (DFZ) in + order to reach LISP sites. A Proxy Egress Tunnel Router (PETR) 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 (or PETR) is a particular case of + ITR (or ETR), it is subject to similar attacks as ITRs (or ETRs). + + 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 Messages + + A control-plane off-path attacker can exploit Map-Request messages to + mount DoS, performance, or amplification attacks. By sending Map- + Request messages at a high rate, the attacker can overload nodes + involved in the mapping system. For instance, sending Map-Requests + at a 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 + + + + + +Saucez, et al. Informational [Page 12] + +RFC 7835 LISP Threats April 2016 + + + attack. The attacker can combine the attack with a spoofing attack + to overload the node to which the spoofed address is actually + attached. + + Note that if the attacker sets the P bit (Probe Bit) in the Map- + Request, the Map-Request will be legitimately sent directly to the + ETR instead of passing through the mapping system. + + The SMR 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 with appended Map- + Records, it does the same operations as for the other Map-Request + messages and so is 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). Note that the + attacker does not need to forge the mappings present in the Map- + Request to achieve 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 + installs them in the xTR cache by means of the Map-Request. + + Moreover, attackers can use Map Resolver and/or Map Server network + 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. + +3.8. Map-Reply Messages + + Most of the security risks associated with Map-Reply messages will + depend on the 64-bit nonce that is included in a Map-Request and + returned in the Map-Reply. Given the size of the nonce (64 bits), if + a best current practice is used [RFC4086] and if an ETR does not + accept Map-Reply messages with an invalid nonce, the risk of an off- + path attack is limited. 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. + + 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 attacks categorized in Section 2.2 as it can + inject forged mappings directly in the ITR EID-to-RLOC cache. For + + + +Saucez, et al. Informational [Page 13] + +RFC 7835 LISP Threats April 2016 + + + 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 a plethora of mappings in the ITR to mount a performance + attack by filling up the EID-to-RLOC cache of the ITR. The attacker + can also mount an amplification attack if the ITR at that time is + sending a large number of packets to the EIDs matching the injected + mapping. In this case, the RLOC address associated with the mapping + is the address of the real target of the attacker, so 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 rogue + attack if it uses prefix overclaiming. In such a scenario, the + attacker ETR replies to a legitimate Map-Request message that it + received with a Map-Reply message that contains an EID prefix that is + larger than the prefix owned by the attacker. For example, 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 + EIDs other than the one the 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 + can be used by 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 overclaim prefixes on behalf of + the internal attacker. + + Note that when the Map-Reply is in response to a Map-Request sent via + the mapping system (i.e., not sent directly from the ITR to an ETR), + the attacker does not need to use a spoofing attack to achieve its + attack as by design the source IP address of a Map-Reply is not known + in advance by the ITR. + + Map-Request and Map-Reply messages are exposed to any type of + attackers, on-path or off-path but also external or internal + attackers. Also, even though they are control messages, 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 advantage of injecting forged mappings as well. + + + + + + + +Saucez, et al. Informational [Page 14] + +RFC 7835 LISP Threats April 2016 + + +3.9. Map-Register Messages + + Map-Register messages are sent by ETRs to Map Servers to indicate to + the mapping system the EID prefixes associated with 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 overclaim the prefix it owns in order to + influence the route followed by Map-Requests for EIDs outside the + scope of its legitimate EID prefix (see Section 3.8 for the list of + overclaiming attacks). + + 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 an invalid + registration or advertise an invalid EID prefix to the mapping + system. + +3.10. Map-Notify Messages + + Map-Notify messages are sent by a Map Server to an ETR to acknowledge + the reception and processing of a Map-Register message. + + Similarly, to the pair Map-Request/Map-Reply, the pair Map-Register/ + Map-Notify is protected by a nonce making it difficult for an + attacker to inject a falsified notification to an ETR to make this + ETR believe that the registration succeeded when it has not. + +4. Note on Privacy + + As reviewed in [RFC6973], universal privacy considerations are + difficult to establish as the privacy definitions may vary for + different scenarios. As a consequence, this document does not aim to + identify privacy issues related to the LISP protocol, but the + security threats identified in this document could play a role in + privacy threats as defined in Section 5 of [RFC6973]. + + Similar to public deployments of any other control-plane protocol, in + an Internet deployment, LISP mappings are public and hence provide + information about the infrastructure and reachability of LISP sites + (i.e., the addresses of the edge routers). Depending upon deployment + + + +Saucez, et al. Informational [Page 15] + +RFC 7835 LISP Threats April 2016 + + + details, LISP map replies might or might not provide finer-grained + and more detailed information than is available with currently + deployed routing and control protocols. + +5. Threat Mitigation + + Most of the above threats can be mitigated with careful deployment + and configuration (e.g., filter) and also by applying the general + rules of security, e.g., only activating features that are necessary + for the deployment and verifying the validity of the information + obtained from third parties. + + The control plane is the most critical part of LISP from a security + viewpoint, and it is worth noticing that the LISP specifications + already offer an authentication mechanism for mappings registration + [RFC6833]. This mechanism, combined with LISP-SEC [LISP-SEC], + strongly mitigates threats in non-trustable environments such as the + Internet. Moreover, an authentication data field for Map-Request + messages and Encapsulated Control messages was allocated [RFC6830]. + This field provides a general authentication mechanism technique for + the LISP control plane that future specifications may use while + staying backward compatible. The exact technique still has to be + designed and defined. To maximally mitigate the threats on the + mapping system, authentication must be used, whenever possible, for + both Map-Request and Map-Reply messages and for messages exchanged + internally among elements of the mapping system, such as specified in + [LISP-SEC] and [LISP-DDT]. + + Systematically applying filters and rate limitation, as proposed in + [RFC6830], will mitigate most of the threats presented in this + document. In order to minimize the risk of overloading the control + plane with actions triggered from data-plane events, such actions + should be rate limited. + + Moreover, all information opportunistically learned (e.g., with LSB + or gleaning) should be used with care until they are verified. For + example, a reachability change learned with LSB should not be used + directly to decide the destination RLOC but instead should trigger a + rate-limited reachability test. Similarly, a gleaned entry should be + used only for the flow that triggered the gleaning procedure until + the gleaned entry has been verified [Trilogy]. + +6. Security Considerations + + This document provides a threat analysis and proposes mitigation + techniques for the Locator/ID Separation Protocol. + + + + + +Saucez, et al. Informational [Page 16] + +RFC 7835 LISP Threats April 2016 + + +7. References + +7.1. Normative References + + [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The + Locator/ID Separation Protocol (LISP)", RFC 6830, + DOI 10.17487/RFC6830, January 2013, + <http://www.rfc-editor.org/info/rfc6830>. + + [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, + "Interworking between Locator/ID Separation Protocol + (LISP) and Non-LISP Sites", RFC 6832, + DOI 10.17487/RFC6832, January 2013, + <http://www.rfc-editor.org/info/rfc6832>. + + [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation + Protocol (LISP) Map-Server Interface", RFC 6833, + DOI 10.17487/RFC6833, January 2013, + <http://www.rfc-editor.org/info/rfc6833>. + + [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID + Separation Protocol (LISP) Map-Versioning", RFC 6834, + DOI 10.17487/RFC6834, January 2013, + <http://www.rfc-editor.org/info/rfc6834>. + + [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., + Morris, J., Hansen, M., and R. Smith, "Privacy + Considerations for Internet Protocols", RFC 6973, + DOI 10.17487/RFC6973, July 2013, + <http://www.rfc-editor.org/info/rfc6973>. + +7.2. Informative References + + [LISP-DDT] Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP + Delegated Database Tree", Work in Progress, + draft-ietf-lisp-ddt-03, April 2015. + + [LISP-SEC] Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. + Saucez, "LISP-Security (LISP-SEC)", Work in Progress, + draft-ietf-lisp-sec-10, October 2015. + + [PRELIM-LISP-THREAT] + Bagnulo, M., "Preliminary LISP Threat Analysis", Work in + Progress, draft-bagnulo-lisp-threat-01, July 2007. + + + + + + + +Saucez, et al. Informational [Page 17] + +RFC 7835 LISP Threats April 2016 + + + [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, + "Randomness Requirements for Security", BCP 106, RFC 4086, + DOI 10.17487/RFC4086, June 2005, + <http://www.rfc-editor.org/info/rfc4086>. + + [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, DOI 10.17487/RFC7215, April + 2014, <http://www.rfc-editor.org/info/rfc7215>. + + [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an + Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May + 2014, <http://www.rfc-editor.org/info/rfc7258>. + + [Trilogy] Saucez, D. and L. Iannone, "How to mitigate the effect of + scans on mapping systems", Trilogy Future Internet Summer + School, 2009. + +Acknowledgments + + This document builds upon the document by Marcelo Bagnulo + [PRELIM-LISP-THREAT], where the flooding attack and the reference + environment was first described. + + The authors would like to thank Ronald Bonica, Deborah Brungard, + 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 <http://www.trilogy-project.org>. + + The work of Luigi Iannone has been partially supported by the + ANR-13-INFR-0009 LISP-Lab Project <http://www.lisp-lab.org> and the + EIT KIC ICT-Labs SOFNETS Project. + + + + + + + + + + + + + + +Saucez, et al. Informational [Page 18] + +RFC 7835 LISP Threats April 2016 + + +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: ggx@gigix.net + + + Olivier Bonaventure + Universite catholique de Louvain + Place St. Barbe 2 + Louvain la Neuve + Belgium + + Email: olivier.bonaventure@uclouvain.be + + + + + + + + + + + + + + + + + + + + + + + + + +Saucez, et al. Informational [Page 19] + |