RFC 7835
Locator/ID Separation Protocol (LISP) Threat Analysis
RFC 7835: Locator/ID Separation Protocol (LISP) Threat Analysis 🦋
Bestie, this is RFC 7835 📜, and it's all about the security risks of LISP. It's Informational, which means it's published for info and isn't a Standards Track spec 💅. It came out in April 2016 and was written by D. Saucez (INRIA), L. Iannone (Telecom ParisTech), and O. Bonaventure (Universite catholique de Louvain) 🫶. The header doesn't say it obsoletes or updates any other RFCs 🌸. The ISSN is 2070-1721 ✨.
Abstract 📝
This doc gives a threat analysis of the Locator/ID Separation Protocol (LISP) 🕵️♀️.
Status of This Memo 🌈
Okay so this doc is not a standards track spec. It's published just for info 💖.
It's a product of the IETF, so it represents what the IETF community agrees on. It got public review and the IESG approved it for publication. Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the details 🧐.
For the latest status, errata, and how to give feedback, go to 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 doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as they stood on the publication date. Please read these carefully, because they spell out your rights and restrictions 📖. Code Components pulled from this doc have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 🎀.
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 . . . . . . . . . . . . . . . . . . . . . . . 191. Introduction ✨
LISP is specified in [RFC6830] 🌸. This doc is the security check. It looks at the potential threats to the current LISP specs if LISP gets deployed on the Internet, which is a public, non-trustable environment 🕵️♀️.
The doc has three main parts 📚. Part one sets up a general threat model, the way attackers think about attacking 🧠. Part two uses that model to describe the LISP-based techniques, and the architecture behind them, that attackers could use to build attacks 🎯. Part three covers mitigation techniques and general solutions to protect LISP and its architecture from attacks 🛡️.
This doc doesn't cover every possible use of LISP (see [RFC6830] and [RFC7215]), and it doesn't cover threats from specific implementations 🙅♀️. It focuses on LISP unicast, plus LISP Interworking [RFC6832], LISP Map-Server [RFC6833], and LISP Map-Versioning [RFC6834] 💖. New threats might show up while deployment keeps going 👀. You're assumed to already know those documents to get this one 🤓.
This doc assumes a generic IP service, so it doesn't discuss how IPv4 and IPv6 differ from a security viewpoint 🌐.
2. Threat Model 💅
This doc assumes attackers can be anywhere on the Internet, either inside LISP sites or outside them 🌍. Attacks can come from one attacker solo or from several attackers working together as a squad 👯.
An attacker is a malicious entity that attacks a target in a network where LISP is (partially) deployed, using LISP and/or its architecture 😈.
An attack is an illegitimate action taken against a target in a network where LISP is (partially) deployed 🚫.
The target is the entity (a device connected to the network, or a network) that's meant to feel the consequences of the attack 🎯. Other entities can get side effects too, even if they're not directly targeted 🫠. A target can be picked specifically (one particular entity) or arbitrarily (any entity) 🎲. An attacker can also go after one or several targets with a single attack 💥.
Section 2.1 covers the modes of operation attackers can use, and Section 2.2 covers the categories of attacks they can build 📋.
2.1. Operation Modes of Attackers 🕰️
Attackers get sorted by their modes of operation, which is about their temporal and spatial diversity, meaning how they're spread out in time and space 🌌. The modes aren't mutually exclusive. Attackers can mix them in any combo, and other modes might show up later 🔀. Attackers also aren't bound by this classification at all, so implementers and deployers always need to do their own risk analysis for themselves 🧐.
2.1.1. On-Path vs. Off-Path Attackers 🛤️
On-path attackers (aka Men-in-the-Middle) can intercept and modify packets between legit communicating entities 😱. They're either sitting right on the normal communication path, by getting access to a node on it or by placing themselves on it, or they're outside the location path but still manage to divert or copy packets sent between the communicating entities 👀. So on-path attackers attack by changing packets that were sent legitimately in the first place 🔁.
An attacker is off-path if it doesn't have access to packets exchanged during the communication, or if there's no communication at all 🙈. For their attacks to work, off-path attackers have to generate packets and inject them into the network 💉.
2.1.2. Internal vs. External Attackers 🏠
An internal attacker launches from a node inside a legit LISP site. It's either a legitimate node of the site, or it exploits a vulnerability to get access to a legit node in there 🔓. Because of where they are, internal attackers are trusted by the site they're in 🥺.
External attackers launch from outside a legit LISP site 🌙.
2.1.3. Live vs. Time-Shifted Attackers ⏰
A live attacker has to stay connected for the whole time the attack is running. So the attack ends as soon as the attacker (or the attack vector being used) gets neutralized 🔌.
A time-shifted attacker runs attacks that stay active even after it disconnects from the Internet 👻.
2.1.4. Control-Plane vs. Data-Plane Attackers 🎛️
A control-plane attacker attacks by using control-plane functionalities, typically the mapping system 🗺️.
A data-plane attacker attacks by using data-plane functionalities 📦.
There's no complete isolation between the control plane and the data plane. So an attacker can operate in the control plane (or data plane) to attack the data plane (or control plane), or it can keep the attacked and targeted planes on the same layer, meaning control plane to control plane or data plane to data plane 🔄.
2.1.5. Cross-Mode Attackers 🧩
The modes attackers use aren't mutually exclusive, so they can combine them to build attacks 💫.
For example, an attacker can launch a control-plane attack directly from inside a LISP site it's able to get temporary access to (internal + control-plane attacker). That creates a vulnerability in the target. Later, from outside and after disconnecting (time-shifted + external attacker), it mounts a data-plane attack that uses that vulnerability 💀.
2.2. Threat Categories 🎀
Attacks can be classified into the eleven following categories 📚. These categories aren't mutually exclusive, and attackers can use them 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 🔁.
2.2.2. Packet Manipulation ✏️
A packet manipulation attack happens when an attacker receives a packet, modifies it (changing some of the information inside), and then sends it on to its final destination. That destination can be the packet's original destination 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 ✨
okay so spoofing is when an attacker sneaks packets into the network while pretending to be somebody else 🎭 they do it by forging source addresses in the packets. it's giving "I'm totally not who you think I am" 💅
and yes, LISP spoofing is basically the same drama as spoofing with any other tunneling tech that's already out there on the Internet 🦋 usually "spoofed packet" just means a packet whose source IP address isn't the real originator's. since LISP uses encapsulation, the fake address could sit in the outer header, the inner header, or both. so that's two main flavors:
- Inner address spoofing: the attacker uses encapsulation and puts a spoofed source address in the inner packet. with data-plane LISP encapsulation, that means faking the source Endpoint Identifier (EID) address of the encapsulated packet 🌸
- Outer address spoofing: the attacker doesn't use encapsulation and just spoofs the source address of the packet. with data-plane LISP encapsulation, that means faking the source Routing Locator (RLOC) address of the encapsulated packet 🎀
these two aren't exclusive, bestie 😭 every combo is possible and each one can power a different kind of attack. for example, an attacker outside a LISP site can craft a packet with a forged source IP address (that's outer address spoofing) and send it to a LISP destination. then a Proxy Ingress Tunnel Router (PITR) encapsulates it, so once it's wrapped up it's now inner address spoofing 🙈 and you can even imagine an attacker forging a packet with encapsulation where both the inner and outer source addresses are fake. chaotic, but iconic 👑
the big plot twist: when inner and outer spoofing are combined, it gets really hard to figure out who the attacker is, because the packet might not contain anything that shows where the attack came from 🕵️♀️
2.2.5. Rogue Attack 🍓
in a rogue attack, the attacker manages to look like a legit source of information without faking its identity. that's the big difference from a spoofing attacker, who is literally lying about who they are 🫶
2.2.6. Denial-of-Service (DoS) Attack 💀
a DoS attack is aimed at a specific targeted service with one goal: knocking it out so it can't operate properly 🚫
2.2.7. Performance Attack 🔥
a performance attack goes after the computational resources of a targeted node (think memory or processor) so the node gets overwhelmed and can't operate properly. it's the "let's drain your battery" energy 🔋
2.2.8. Intrusion Attack 🙈
in an intrusion attack, the attacker gets remote access to a resource (like a host, a router, or a network) or to information they legitimately should never have been able to touch. and these can lead to privacy leakages, which is so not cute 😭
2.2.9. Amplification Attack 📣
in an amplification attack, the traffic the target generates in response is bigger than the traffic the attacker had to send in the first place. so the attacker puts in a little and the target puts out a lot 📈
ngl this one is spicy: in some cases the data plane can be several orders of magnitude faster than the control plane at processing packets 🏎️ and that gap can be exploited to overload the control plane through the data plane, without overloading the data plane itself. sneaky, sneaky 🦊
2.2.10. Passive Monitoring Attacks 👀
an attacker can use pervasive monitoring, which is a technical attack [RFC7258] that goes after information about LISP traffic. that info may or may not get used to mount other kinds of attacks, so it's basically the attacker quietly collecting clues 🧚
2.2.11. Multi-category Attacks 🌈
attack categories aren't mutually exclusive, so any combo can be used to pull off a specific attack. it's like mixing your favorite lip gloss shades to make a new one 💄
for example, one could mount a rogue attack to run a performance attack that starves the memory of an Ingress Tunnel Router (ITR), which then results in a DoS on the ITR. that's three categories in one trench coat 🧥
3. Attack Vectors 🦋
this section covers the attack techniques that attackers may use when they're leveraging LISP and/or its architecture. it's the playbook, bestie 📖
3.1. Gleaning ✨
to cut down the time it takes to get a mapping, LISP has an optional gleaning mechanism. it lets an xTR (Ingress and/or Egress Tunnel Router) learn a mapping straight from the LISP-encapsulated data packets and the Map-Request packets it receives 💫 each encapsulated data packet carries a source RLOC, destination RLOC, source EID, and destination EID. when an xTR gets an encapsulated data packet from a source EID it doesn't have a mapping for yet, it may insert the mapping between the source RLOC and the source EID into its EID-to-RLOC cache. the same trick works when an xTR gets a Map-Request, since that also contains a source EID address and a source RLOC. once a gleaned entry is in the EID-to-RLOC cache, the xTR sends a Map-Request to get the actual mapping for the gleaned EID from the mapping system 🗺️
now the drama. if a packet injected by an off-path attacker, with a spoofed inner address, gets gleaned by an xTR, the attacker can divert traffic meant for the spoofed EID for as long as the xTR keeps using that gleaned entry 😈 this can be part of a replay, packet manipulation, packet interception and suppression, or DoS attack, since the packets get sent to the attacker.
if the attacker's packet has a spoofed outer address instead of a spoofed inner one, it can cause a DoS or a performance attack. traffic that's normally destined for the attacker gets redirected to the spoofed source RLOC, and that can overload the owner of that RLOC so it can't operate properly 🥲
if the injected packet uses both inner and outer spoofing, the attacker can pull off a spoofing, a performance, or an amplification attack. traffic that's normally destined for the spoofed EID address gets sent to the spoofed RLOC address instead. and if the attacked LISP site also sends traffic to that spoofed EID address, that traffic may have a positive amplification factor 📊
gleaning attacks don't only hit the data plane either 🙅♀️ they can also affect the control plane, because a Map-Request gets sent after a gleaned entry is created. so the attacker can cause DoS and performance attacks on the control plane too. for instance, if an attacker sends a packet for each address in a prefix that isn't cached yet in an xTR's EID-to-RLOC cache, the xTR will potentially send a Map-Request for each one of those packets until the mapping is installed. that over-utilizes the control plane, since every packet generates a control-plane event 🤯 the attacker may not even need spoofing for this to work. and the issue can happen even when gleaning is turned off, because whether or not gleaning is used, the ITR may still need to send a Map-Request in response to incoming packets whose EID isn't currently in the cache.
gleaning attacks fundamentally involve a time-shifted mode of operation, since the attack can last as long as the targeted xTR keeps the gleaned entry. [RFC6830] recommends storing gleaned entries for only a few seconds, which limits how long the attack can run ⏳
gleaning attacks always involve external data-plane attackers, but they result in attacks on either the control plane or the data plane 🎯
last thing: the outer spoofed address doesn't need to be the RLOC of a LISP site. it can be any address at all 🌍
3.2. Locator Status Bits 🌸
when the L bit in the LISP header is set to 1, it means the second 32-bit longword of the LISP header contains the Locator-Status-Bits (LSBs). each bit position in that field reflects the status of one of the RLOCs mapped to the source EID found in the encapsulated packet 🔦 how an xTR reacts to a packet like this 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 locators for the prefix tied to the source EID 😏 with an off-path attacker, the attacker has to inject a forged packet into the network with a spoofed inner address. an on-path attacker can manipulate the LSB of legit packets passing through it, so it doesn't need spoofing at all. and instead of messing with the LSB field, an on-path attacker can get the same result (injecting packets with invalid LSB values) by replaying packets 🔁
the LSB field can be used to mount a DoS attack in a couple of ways. the attacker can declare all RLOCs unreachable (all LSBs set to 0), or concentrate all the traffic onto one RLOC (e.g., all but one LSB set to 0), which overloads the RLOC that's pulling in all the traffic from the xTR 🌊 or the attacker can force packets to be sent to RLOCs that aren't actually reachable (e.g., invert LSB values) 🙃
the LSB field can also be used for a replay, a packet manipulation, or a packet interception and suppression attack. if the attacker manages to sit on the path between the xTR and one of the RLOCs in the mapping, forcing packets to go via that RLOC means the attacker gets access to the packets 👀
attacks using the LSB fundamentally involve a time-shifted mode of operation, since the attack can last as long as the xTR keeps using the reachability info it gathered from the LSB to pick RLOCs ⏰
3.3. Map-Version 💜
when the Map-Version bit of the LISP header is set to 1, it means 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 gets a LISP-encapsulated packet with the Map-Version bit set to 1, it does the following:
- 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 📬
- 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 fetch the new mapping. that can lead to a DoS attack (through an excess of signaling traffic), or an amplification attack if the data-plane packet the attacker sent is smaller, or otherwise uses fewer resources, than the control-plane packets sent in response to it 📈 with a spoofing attack, and if the xTR thinks the spoofed ITR has an outdated mapping, it will send an SMR to the spoofed ITR. that can result in a performance, amplification, or DoS attack too 😭
Map-Version attackers are inherently cross-mode, since the Map-Version is a method for putting control information into the data plane 🌉 and this vector involves live attackers. still, on-path attackers don't have a specific advantage over off-path attackers 🫶
3.4. Routing Locator Reachability 🦋
okay so the Nonce-Present and Echo-Nonce bits in the LISP header are how an xTR checks whether another xTR is reachable 🔍. the testing xTR sets both Echo-Nonce and Nonce-Present in its LISP-encapsulated data packets and puts a random nonce in the LISP header of those packets 🎀. when the tested xTR receives them, it stores the nonce and echoes it back whenever it returns a LISP-encapsulated data packet to the testing xTR. if the echoed nonce comes back, the tested xTR is confirmed reachable ✨
but an attacker can mess with this reachability test by sending two different types of packets 🙈:
- LISP-encapsulated data packets with
Nonce-Presentset and a random nonce. these are normally used in response to a reachability test 🌸 - LISP-encapsulated data packets with
Nonce-PresentandEcho-Nonceboth set. these force the receiving ETR to store the received nonce and echo it in the LISP-encapsulated packets it sends. normally they're used as a trigger for a reachability test 💅
the first type is used to make xTRs think another xTR is reachable when it's not 😭. so it's 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 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 them will keep changing the nonce it returns to the remote ITR, which can yield to a performance attack 📉. if the remote ITR tries a nonce reachability test, the test may fail because the ETR may echo an invalid nonce, and that yields to a DoS attack 🥲
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 the liveness of entries in its EID-to-RLOC cache with active probes (as described in Section 6.3 of [RFC6830]), then this may amplify the attack that caused the insertion of the entries being checked 📣
3.5. Instance ID 🧚
LISP lets a 24-bit value called Instance ID be carried in its header ✨. on the ITR, it's used to indicate which local Instance ID was used for encapsulation. 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 so LISP and non-LISP sites can talk to each other 🤝. the Proxy-ITR has functionality similar to the ITR, but 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, but its main purpose is to inject de-encapsulated packets into the DFZ in order to reach non-LISP sites from LISP sites 🚪. since a PITR (or PETR) is a particular case of ITR (or ETR), it's subject to similar attacks as ITRs (or ETRs) 🥀
ngl this is the part where it gets sneaky. like any other system that relies 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 😤. if they send Map-Request messages at a high rate, they 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 attack 🎈. the attacker can also combine the attack with a spoofing attack to overload the node the spoofed address is actually attached to 🫠
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, so it's subject to the same attacks 🥺. however, it also installs the Map-Records contained in the Map-Request into its EID-to-RLOC cache 😬. an attacker can then use this vector to force the installation of mappings in its target xTR. as a result, the EID-to-RLOC cache of the xTR gets polluted by potentially forged mappings, which lets the attacker mount any of the attacks categorized in Section 2.2 (see Section 3.8 for more details) 🫥. note that the attacker doesn't 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, they can de-aggregate it into many small prefixes, each corresponding to another mapping, and install 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 their attacks and hide the origin of the attack 🎭. on the one hand, a Map Resolver is used to dispatch Map-Requests to the mapping system. on the other hand, a Map Server is used to dispatch Map-Requests coming from the mapping system to the 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 depend on the 64-bit nonce that's 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 an ETR doesn't accept Map-Reply messages with an invalid nonce, the risk of an off-path attack is limited 🛡️. still, the nonce only confirms that the Map-Reply received was sent in response to a Map-Request that was sent. it does not validate the contents of that Map-Reply 🫣
if an attacker manages to send a valid Map-Reply to an ITR (i.e., one sent in response to a Map-Request and with the correct nonce), then it can perform any of the attacks categorized in Section 2.2, since it can inject forged mappings directly into the ITR EID-to-RLOC cache 😈. for instance, if the mapping injected into the ITR points to the address of a node controlled by the attacker, they can mount replay, packet manipulation, packet interception and suppression, or DoS attacks, because they'll receive every packet destined to a destination lying in the EID prefix of the injected mapping 🪤. the attacker can also inject a plethora of mappings into the ITR to mount a performance attack by filling up the ITR's EID-to-RLOC cache 🌊. the attacker can also mount an amplification attack if the ITR is sending a large number of packets to the EIDs matching the injected mapping at that time. in this case, the RLOC address associated with the mapping is the address of the attacker's real target, so all the ITR's traffic gets sent to the target, which means one single packet can make the attacker generate very high traffic toward 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 it received with a Map-Reply message that contains an EID prefix larger than the prefix the attacker owns. 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 ones the attacker has authority over 🫨. with this technique, the attacker can mount the attacks presented above, since 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 from initiating some communication with the ITR 📨. this method can be used by internal attackers who want to control the mappings installed in their site. to do that, they simply have to collude with an external attacker who's ready to overclaim prefixes on the internal attacker's behalf 🤫
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 doesn't need to use a spoofing attack to achieve its attack. by design, the source IP address of a Map-Reply isn't known in advance by the ITR 🙃
Map-Request and Map-Reply messages are exposed to any type of attacker: on-path or off-path, and external or internal 🌐. also, even though they're control messages, they can be leveraged by data-plane attackers 🪄. since the decision to remove mappings is based on the TTL indicated in the mapping, time-shifted attackers can take advantage of injecting forged mappings as well ⏳
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 that EID prefix 📋
since Map-Register messages are protected by an authentication mechanism, only a compromised ETR can register itself with 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 with 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 💫
similar to the Map-Request/Map-Reply pair, the Map-Register/Map-Notify pair is protected by a nonce, which makes it difficult for an attacker to inject a falsified notification to an ETR and make the ETR believe the registration succeeded when it didn't 🙌
4. Note on Privacy 🔒
okay so privacy is kinda tricky bc what counts as "private" changes depending on the situation. [RFC6973] says so too, so this doc isn't trying to list every privacy issue in LISP 🙈 BUT the security threats in here can totally feed into privacy threats as defined in Section 5 of [RFC6973]. so yeah, pay attention 👀
ok and here's the thing: any control-plane protocol that's out in the wild on the public Internet is going to be visible. LISP mappings are public in an Internet deployment, so they reveal stuff about the infrastructure and how reachable LISP sites are (aka the addresses of the edge routers) 💅 Depending on how it's deployed, LISP map replies might or might not show more detailed info than what current routing and control protocols already show. it's giving "depends on your setup" energy ✨
5. Threat Mitigation 🛡
most of the threats above can be mitigated with careful deployment and configuration (e.g., filter) 🧹 and with the general rules of security too. like only turn on the features you actually need for your deployment, and check that the info you get from third parties is valid 🫶
the control plane is the most critical part of LISP from a security point of view, and ngl the LISP specs already have an authentication mechanism for mappings registration [RFC6833] 🔐 Combined with LISP-SEC [LISP-SEC], it strongly mitigates threats in non-trustable environments like the Internet. iconic 👑
also, an authentication data field for Map-Request messages and Encapsulated Control messages was allocated [RFC6830] 🎀 This field is a general authentication technique for the LISP control plane that future specs can use while staying backward compatible. the exact technique still has to be designed and defined, so this is the main character setup for later 🦋 To maximally mitigate 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, as specified in [LISP-SEC] and [LISP-DDT] 💜
systematically applying filters and rate limitation, as proposed in [RFC6830], will mitigate most of the threats in this document ✨ To keep the control plane from getting overloaded with actions triggered by data-plane events, those actions should be rate limited 🌸
and lowkey the most important part: all information you learn opportunistically (e.g., with LSB or gleaning) should be used with care until it's verified 🧐 For example, a reachability change learned with LSB should not be used directly to decide the destination RLOC. instead it 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 💀
okay bestie, this is the big one 😭 This document is literally a threat analysis for the Locator/ID Separation Protocol, and it proposes mitigation techniques for it. everything above is the receipts, so go read it if you haven't 🔥
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.
[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 doc builds on the work of Marcelo Bagnulo [PRELIM-LISP-THREAT], where the flooding attack and the reference environment were first described 🙌
the authors want 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 🦋
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📦 where this page comes from
- ietf: rfc7835 2016-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms