RFC 4832

RFC 4832: Security Threats to Network-Based Localized Mobility Management (NETLMM) 🦋

Okay bestie, so this is RFC 4832, and it's all about the security threats hiding in NETLMM (network-based localized mobility management) 🌸 It's an Informational doc from the Network Working Group, dated April 2007. It was written by C. Vogt (Universitaet Karlsruhe (TH)) and J. Kempf (DoCoMo USA Labs) 👑 Its title block has no Obsoletes or Updates line, so it doesn't obsolete or update anything 💅

Status of This Memo ✨

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited 🎀

Copyright Notice

Copyright (C) The IETF Trust (2007). 🌈

Abstract

So the TL;DR: this document discusses security threats to network-based localized mobility management 🧚 Threats may show up on two interfaces. One is the interface between a localized mobility anchor and a mobile access gateway. The other is the interface between a mobile access gateway and a mobile node. Threats to the former interface impact the localized mobility management protocol itself 😭

Table of Contents

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
  1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
2.  Threats to Interface between LMA and MAG . . . . . . . . . . .  3
  2.1.  LMA Compromise or Impersonation  . . . . . . . . . . . . .  3
  2.2.  MAG Compromise or Impersonation  . . . . . . . . . . . . .  4
  2.3.  Man-in-the-Middle Attack . . . . . . . . . . . . . . . . .  6
3.  Threats to Interface between MAG and Mobile Node . . . . . . .  6
  3.1.  Mobile Node Compromise or Impersonation  . . . . . . . . .  7
  3.2.  Man-in-the-Middle Attack . . . . . . . . . . . . . . . . .  9
4.  Threats from the Internet  . . . . . . . . . . . . . . . . . . .  9
5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 10
7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
  7.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
  7.2.  Informative References . . . . . . . . . . . . . . . . . . 10

1. Introduction ✨

The network-based localized mobility management (NETLMM) architecture [1] supports movement of IPv6 mobile nodes locally within a domain, and it doesn't require mobility support in the mobile nodes' network stacks 🦋 A mobile node can keep its IP address constant as it moves from link to link, which skips the signaling overhead and latency that come with changing the IP address 💖 Software specifically for localized mobility management is not required on the mobile node. IP-layer movement detection software may be necessary, though, and driver software for link-layer mobility is prerequisite 🫶

The IP addresses of mobile nodes have a prefix that routes to a localized mobility anchor (LMA) [3]. The LMA maintains an individual route for each registered mobile node. Any particular mobile node's route terminates at a mobile access gateway (MAG) [3], which is the one the mobile node attaches to at its current access link 🌸 MAGs are responsible for updating the mobile node's route on the LMA as the mobile node moves. A MAG detects the arrival of a mobile node on its local access link based on handoff signaling that the mobile node pursues. The MAG may additionally monitor connectivity of the mobile node, so it can recognize when the mobile node has left the local access link. So the localized mobility management architecture has two interfaces:

1. The interface between a MAG and an LMA where route update signaling occurs.
2. The interface between a mobile node and its current MAG where handoff signaling and other link maintenance signaling occur.

The localized mobility management architecture demands no specific protocol for a MAG to detect the arrival or departure of mobile nodes to and from its local access link, and to initiate route update signaling with an LMA as a result 🧚 An appropriate mechanism may be entirely implemented at the link layer, which is super common for cellular networks. In that case, the IP layer never detects any movement, even when a mobile node moves from one link to another handled by a different MAG 🙈 If the link layer doesn't provide the necessary functionality, the mobile node must perform IP-layer movement detection and auto-configuration signaling, and that's what provides the trigger for the MAG to update its route on the LMA. A mobile node identity, established by the localized mobility management domain when the mobile node initially connects and authenticates, lets the MAG ascribe the decisive link- or IP-layer signaling to the correct mobile node 🎀 Some wireless access technologies may require the mobile node identity to be reestablished on every link-layer handoff.

Vulnerabilities in either interface of the localized mobility management architecture may entail new security threats that go beyond the ones that already exist in IPv6 😈 Potential attack objectives may be to consume network services at the cost of a legitimate mobile node, interpose in a mobile node's communications and possibly impersonate the mobile node from a position off-link, operate under the disguise of a false or non-existing identity, or cause denial of service to a mobile node or to the localized mobility management domain as a whole. This document identifies and discusses security threats on both interfaces of the localized mobility management architecture. It's limited to threats that are peculiar to localized mobility management. Threats to IPv6 in general are documented in [4] 💅

1.1. Terminology 💖

The terminology in this document follows the definitions in [2], with those revisions and additions from [1]. In addition, the following definition is used:

Mobile Node Identity

An identity established for the mobile node when initially connecting to the localized mobility management domain. It allows the localized mobility management domain to definitively and unambiguously identify the mobile node upon handoff for route update signaling purposes. The mobile node identity is conceptually independent of the mobile node's IP or link-layer addresses, but it must be securely bound to the mobile node's handoff signaling 🔥

2. Threats to Interface between LMA and MAG 👑

The localized mobility management protocol executed on the interface between an LMA and a MAG serves to establish, update, and tear down routes for data plane traffic of mobile nodes 🌈 Threats to this interface can be separated into three groups: compromise or impersonation of a legitimate LMA, compromise or impersonation of a legitimate MAG, and man-in-the-middle attacks.

2.1. LMA Compromise or Impersonation 💀

A compromised LMA can ignore route updates from a legitimate MAG in order to deny service to a mobile node. It may also be able to trick a legitimate MAG into creating a new, incorrect route, which prepares the MAG to receive redirected traffic of a mobile node. It may cause the traffic forwarded by a MAG to be redirected to a different LMA, or it may simply have the MAG drop an existing route in order to deny the mobile node service 😭 Since data plane traffic for mobile nodes routes through the LMA, a compromised LMA can also intercept, inspect, modify, or drop such traffic, or redirect it to a destination in collusion with the attacker. The attack can be conducted transiently, to selectively disable traffic for any particular mobile node or MAG at particular times.

Moreover, a compromised LMA may manipulate its routing table such that all packets are directed towards a single MAG. This may result in a denial-of-service attack against that MAG and its attached access link 🙈

These threats also emanate from an attacker who tricks a MAG into believing that it is a legitimate LMA. This attacker can cause the MAG to conduct route update signaling with the attacker instead of with the legitimate LMA, which enables it to ignore route updates from the MAG, or to induce incorrect route changes at the MAG as described above, in order to redirect or deny a mobile node's traffic. The attacker does not necessarily have to be on the original control plane path between the legitimate LMA and the MAG, provided that it can somehow make its presence known to the MAG. Failure to mutually authenticate when establishing an association between an LMA and a MAG would allow an attacker to establish itself as a rogue LMA 🚨

The attacker may further be able to intercept, inspect, modify, drop, or redirect data plane traffic to and from a mobile node. This is obvious if the attacker is on the original data plane path between the legitimate LMA and the mobile node's current MAG, which may happen independently of whether the attacker is on the original control plane path. If the attacker is not on this path, it may be able to leverage the localized mobility management protocol to redefine the prefix that the mobile node uses in IP address configuration. The attacker can then specify a prefix that routes to itself. Whether or not outgoing data plane packets sourced by the mobile node can be interfered with by an attacker off the original data plane path depends on the specific data plane forwarding mechanism within the localized mobility management domain. For example, if IP-in-IP encapsulation or an equivalent approach is used for outbound data plane packets, the packets can be forced to be routed through the attacker. On the other hand, standard IP routing may cause the packets to be relayed via a legitimate LMA, and hence to circumvent the attacker 🦋

2.2. MAG Compromise or Impersonation ✨

okay so bestie, this one is a whole vibe 😭 a compromised MAG can redirect a mobile node's traffic onto its local access link ANY way it wants, and the mobile node never gave permission 💀 this is giving malicious stub router energy, where the attacker injects a bogus host route for the mobile node. 🦋

here's the tea 🍵 forging a subnet prefix in link state or distance vector routing protocols usually needs a bunch of routers working together to actually change where packets go. BUT a bogus host route is super specific, and legit routers advertise broader stuff, so the bogus route wins anyway. so the attack can work even if no other routers are backing it up 😤 the big difference is that normal routing redirection hits the routing tables of multiple routers, whereas in localized mobility management it only involves the compromised MAG and an LMA. less drama, but still not it 💅

and it gets worse 🫠 a compromised MAG can just ignore that a mobile node is on its access link and never register it at an LMA. result? the mobile node loses all its traffic 😭 the MAG can also deregister the mobile node at the serving LMA while pretending the mobile node powered down. the mobile node then has to redo the network access authentication procedure, and the compromised MAG can keep blocking that over and over until the mobile node moves to a different MAG 💀 the mobile node is supposed to be able to handle this, but the recovery can take forever and wreck ongoing sessions 🌧️

denial of service against an LMA is also on the menu 🍓 the compromised MAG can convince an LMA that a huge pile of mobile nodes are attached, so the LMA creates a routing table entry for every single one of those fake nodes. the table grows so much that the LMA might start rejecting legit route update requests 😩 forwarding for data plane packets can slow down because route lookups take longer, and control plane responsiveness can suffer for the same reason. 🐢

another side effect is that the LMA, and the whole localized mobility management domain with it, gets more open to flooding packets from external attackers (see Section 4) 👀 with all those superfluous routes, a flood packet sent to a random IP address in the domain is more likely to match a routing table entry at the LMA. that packet then gets tunneled to a MAG, which does address resolution on the local access link. meanwhile, fewer flood packets get dropped right at the LMA because there's no matching entry to reject them. main character problems, honestly 🎀

all of this is not just a compromised MAG situation either 🙈 an attacker who counterfeits the identity of a legit MAG can act like an authorized MAG toward mobile nodes AND engage an LMA in route update signaling. and then there's the replay move 😈 the attacker eavesdrops on signaling packets between a legit MAG and an LMA and replays them later. these attacks can happen transiently, so the attacker can selectively shut down traffic for a specific mobile node at specific times 🥀

2.3. Man-in-the-Middle Attack 🕵️‍♀️

an attacker who slides in between a legit LMA and a legit MAG can act as a man in the middle for BOTH control plane signaling and data plane traffic 😱 if they're on the original control plane path, they can forge, modify, or drop route update packets. that can set up wrong routes or remove routes that are actively being used. if they're on the original data plane path, they can intercept, inspect, modify, drop, and redirect data plane packets going to or coming from a mobile node. 🙃

a compromised switch or router sitting between an LMA and a MAG can cause the same kind of chaos 💀 any switch or router on the control plane path can forge, modify, or drop control plane packets and mess up route establishment. any switch or router on the data plane path can intercept, inspect, modify, and drop data plane packets, or rewrite IP headers to send them off their original path. the nerve 🙄

an attacker between an LMA and a MAG can also impersonate the MAG toward the LMA, and the other way around, in route update signaling 🎭 the attacker can mess with route establishment even if they're NOT on the original control plane path. an attacker off the original data plane path can do something similar so that inbound packets for the mobile node go from the LMA to the attacker, then to the mobile node's MAG, and finally to the mobile node 🗺️ as explained in Section 2.1, it depends on the specific data plane forwarding mechanism in the localized mobility management domain whether the attacker can influence the route of outgoing data plane packets from the mobile node. it's a whole thing, bestie 🧚

3. Threats to Interface between MAG and Mobile Node 🎀

okay so the MAG keeps track of when mobile nodes arrive on and leave its local access link, using link-layer or IP-layer mechanisms 👀 whatever signaling on the access link is actually the deciding factor MUST be securely bound to the mobile node's identity 🔒 the MAG uses that binding to attribute the signaling to the mobile node, and then starts route update signaling with an LMA. 💅 the binding MUST be robust to spoofing, because otherwise a third party could impersonate the mobile node, cause denial of service, or pull off man-in-the-middle attacks 😭🫶

3.1. Mobile Node Compromise or Impersonation 🎭

okay bestie, so an attacker who can forge the mobile node identity of a mobile node can trick a MAG into redirecting data plane packets for that mobile node over to the attacker 😱. they can pull this off against a mobile node on the same link as them, or against a mobile node on a different link. if it's on-link, the redirect of packets from the mobile node to the attacker happens internally inside the MAG, and there's zero route update signaling between the MAG and an LMA 🙈. on-link attacks are totally possible in a regular IPv6 network [4] that doesn't use Secure Neighbor Discovery [5] 💀

off-link impersonation is a whole different vibe 🦋. the attacker has to fabricate handoff signaling for the mobile node so the MAG thinks the mobile node just handed over onto the MAG's access link. this is conceivable both when the attacker and the mobile node sit on separate links connected to different MAGs, and when they're on separate, possibly virtual per-mobile-node links that connect to the same MAG. in the first case, two MAGs would think they see the mobile node, and both would independently do route update signaling with the LMA. in the second case, route update signaling is likely to be done only once, and the redirect of packets from the mobile node to the attacker is internal to the MAG. the good news is the mobile node can always get its traffic back from the attacker by running another round of handoff signaling 💖. the not-so-good news is standard mobile nodes are generally not prepared to fight this kind of attack, and even where network stacks have suitable functionality, the attack might not be noticeable early enough at the link or IP layer to quickly put countermeasures in place 😭. so the attack is disruptive at a minimum, and it may potentially persist until the mobile node starts signaling again on a later handoff.

impersonation attacks can be prevented at the link layer 🔐, particularly with cellular technologies, where the handoff signaling between the mobile node and the network must be authenticated and is completely controlled by the wireless link layer. cellular access technologies provide a variety of cryptographic and non-cryptographic attack barriers at the link layer, which makes mounting an impersonation attack, both on-link and off-link, very difficult. however, for non-cellular technologies that don't require link-layer authentication and authorization during handoff, impersonation attacks may be possible.

an attacker that can forge handoff signaling may also cause denial of service against the localized mobility management domain 🚫. they can trick a MAG into believing that a large number of mobile nodes have attached to the local access link, and induce it to start route update signaling with an LMA for each mobile node it assumes is on link. the result is superfluous signaling overhead on the control plane, plus a high number of needless entries in the LMA's and MAG's routing tables 🗑️. that unexpected growth of the routing tables may eventually make the LMA reject legitimate route update requests, and it may make the MAG ignore handoffs of legitimate mobile nodes onto its local access link. it may also decrease the LMA's and MAG's forwarding speed for inbound and outbound data plane packets due to higher route lookup latencies, and for the same reason slow down their responsiveness to control plane packets. an adverse side effect is that the LMA, and hence the localized mobility management domain as a whole, becomes more susceptible to flooding packets from external attackers (see Section 4) 🌊. the high number of superfluous routes raises the probability that a flooding packet, sent to a random IP address within the domain, matches an existing routing table entry at the LMA and gets tunneled to a MAG, which then performs address resolution on the local access link. meanwhile, fewer flooding packets can be dropped directly at the LMA based on a nonexistent routing table entry.

a threat related to the ones above, but not limited to handoff signaling, is IP spoofing [6] 🕵️. attackers use IP spoofing mostly for reflection attacks or to hide their identities. the threat can be reasonably contained by a wide deployment of network ingress filtering [7] in routers, especially within access networks 🛡️. this technique prevents IP spoofing to the extent that it ensures topological correctness of IP source address prefixes in to-be-forwarded packets. where the technique is deployed in an access router, packets are forwarded only if the prefix of their IP source address is valid on the router's local access link. an attacker can still use a false interface identifier in combination with an on-link prefix. but since reflection attacks typically aim at off-link targets, and enforcing topologically correct IP address prefixes also limits the effectiveness of identity concealment, network ingress filtering has proven adequate so far. on the other hand, prefixes are not limited to a specific link in a localized mobility management domain, so merely ensuring topological correctness through ingress filtering becomes insufficient. an additional mechanism for IP address ownership verification is necessary to prevent an attacker from sending packets with an off-link IP source address 🙅‍♀️

3.2. Man-in-the-Middle Attack 😈

an attacker that can interpose between a mobile node and a MAG during link- and/or IP-layer handoff signaling may be able to pull off a man-in-the-middle attack on the mobile node 👀. they spoof the mobile node into believing that it has a legitimate connection with the localized mobility management domain, which is giving total fake-bestie energy. the attacker can then intercept, inspect, modify, or drop data plane packets sourced by or destined to the mobile node 💀

4. Threats from the Internet 🌍✨

a localized mobility management domain uses individual host routes for data plane traffic of different mobile nodes, each one between an LMA and a MAG. creating, maintaining, and deleting these routes causes control traffic within the localized mobility management domain 📡. these characteristics are transparent to mobile nodes as well as external correspondent nodes, but the functional differences within the domain may influence the impact that a denial-of-service attack from the outside world can have on the domain.

a denial-of-service attack on an LMA may be launched by sending packets to arbitrary IP addresses that are potentially in use by mobile nodes within the localized mobility management domain 🎯. like a border router, the LMA sits in a topological position through which a substantial amount of data plane traffic goes, so it must process the flooding packets and perform a routing table lookup for each of them 😩. the LMA can discard packets for which the IP destination address is not registered in its routing table. but other packets must be encapsulated and forwarded. a target MAG, as well as any mobile nodes attached to that MAG's local access link, is also likely to suffer damage, because the unrequested packets must be decapsulated and consume link bandwidth as well as processing capacity on the receivers 🥲. this threat is in principle the same as for denial of service on a regular IPv6 border router, but because the routing table lookups may enable the LMA to drop part of the flooding packets early on or, on the contrary, additional tunneling workload is required for packets that cannot be dropped, the impact of an attack against localized mobility management may be different 🤔

in a related attack, the attacker manages to obtain a globally routable IP address of an LMA or a different network entity within the localized mobility management domain, and perpetrates a denial-of-service attack against that IP address 🎀. localized mobility management is, in general, somewhat resistant to such an attack, because mobile nodes never need to obtain a globally routable IP address of any entity within the localized mobility management domain 🙌. hence, a compromised mobile node cannot pass such an IP address off to a remote attacker, which limits the feasibility of extracting information on the topology of the localized mobility management domain. it is still possible for an attacker to perform IP address scanning if MAGs and LMAs have globally routable IP addresses, but the much larger IPv6 address space makes scanning considerably more time consuming ⏳

5. Security Considerations 🔒⚠️

this is the serious part, bestie, so read it carefully 🫣

this document describes threats to network-based localized mobility management. these may either occur on the interface between an LMA and a MAG, or on the interface between a MAG and a mobile node. mitigation measures for the threats, as well as the security considerations associated with those measures, are described in the respective protocol specifications [3][8] for the two interfaces 🛠️

6. Acknowledgments 🫶💜

the authors would like to thank the NETLMM working group, especially Jari Arkko, Charles Clancy, Gregory Daley, Vijay Devarapalli, Lakshminath Dondeti, Gerardo Giaretta, Wassim Haddad, Andy Huang, Dirk von Hugo, Julien Laganier, Henrik Levkowetz, Vidya Narayanan, Phil Roberts, and Pekka Savola (in alphabetical order) for valuable comments and suggestions regarding this document 🌸

7. References 📚

7.1. Normative References

[1] Kempf, J., Ed., "Problem Statement for Network-Based Localized Mobility Management", RFC 4830, April 2007.

[2] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.

7.2. Informative References

[3] Levkowetz, H., Ed., "The NetLMM Protocol", Work in Progress, October 2006.

[4] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.

[5] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.

[6] CERT Coordination Center, "CERT Advisory CA-1996-21 TCP SYN Flooding and IP Spoofing Attacks", September 1996.

[7] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.

[8] Laganier, J., Narayanan, S., and F. Templin, "Network-based Localized Mobility Management Interface between Mobile Node and Access Router", Work in Progress, June 2006.

Authors' Addresses 🦋

Christian Vogt
Institute of Telematics
Universitaet Karlsruhe (TH)
P.O. Box 6980
76128 Karlsruhe
Germany

EMail: chvogt@tm.uka.de


James Kempf
DoCoMo USA Labs
3240 Hillview Avenue
Palo Alto, CA 94304
USA

EMail: kempf@docomolabs-usa.com

Full Copyright Statement ✨

Okay bestie, this is the legal bit at the very end, and yes it's boring, but we still need it. 🫶

Copyright (C) The IETF Trust (2007). 💜

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. So the usual rules from BCP 78 apply, and the authors still keep whatever rights they didn't give away. 📜

Heads up: this document and everything in it is provided "AS IS". THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, including, but not limited to, any warranty that using the information here won't infringe any rights, and any implied warranties of merchantability or fitness for a particular purpose. 🙈

Intellectual Property

The IETF doesn't take a position on whether any Intellectual Property Rights (or other rights) that someone might claim over the technology in this document are valid, or how far they reach. It also doesn't say whether any license under those rights would or wouldn't be available. And it hasn't independently tried to find out what rights exist, so no promises there. 🦋 If you want to know how rights work for RFC documents, check out BCP 78 and BCP 79. 📚

Copies of IPR disclosures sent to the IETF Secretariat, plus any assurances that licenses will be available, can be found in the IETF's online IPR repository at http://www.ietf.org/ipr. The same goes for the results of any attempt to get a general license or permission to use proprietary rights for implementers or users of this spec. 💅

The IETF also invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Just send that info to the IETF at ietf-ipr@ietf.org. Bestie, speak up if you spot something! 🔥

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society. 🌸 Thank you to the Internet Society for keeping the RFC Editor running, because without it there would be no RFCs for us to read and obsess over. 🫶✨

---

That's the whole spec, bestie. You made it through! 🎀💖