Network Working Group C. Vogt Internet-Draft Universitaet Karlsruhe (TH) Expires: February 22, 2007 J. Kempf DoCoMo USA Labs August 21, 2006 Security Threats to Network-Based Localized Mobility Management draft-ietf-netlmm-threats-03.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 22, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document discusses security threats to network-based localized mobility management. Threats may occur on two interfaces: the interface between an LMA and a MAG, as well as the interface between a MAG and a mobile node. Threats to the former interface impact the localized mobility management protocol itself. Vogt & Kempf Expires February 22, 2007 [Page 1] Internet-Draft Security Threats to NETLMM August 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Threats to Interface between LMA and MAG . . . . . . . . . . . 4 2.1 LMA Compromise or Impersonation . . . . . . . . . . . . . 4 2.2 MAG Compromise or Impersonation . . . . . . . . . . . . . 5 2.3 Man in the Middle Attack . . . . . . . . . . . . . . . . . 7 3. Threats to Interface between MAG and Mobile Node . . . . . . . 8 3.1 Mobile Node Compromise or Impersonation . . . . . . . . . 8 3.2 Man in the Middle Attack . . . . . . . . . . . . . . . . . 10 4. Threats from the Internet . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1 Normative References . . . . . . . . . . . . . . . . . . . 13 8.2 Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . 17 Vogt & Kempf Expires February 22, 2007 [Page 2] Internet-Draft Security Threats to NETLMM August 2006 1. Introduction The network-based localized mobility management (NETLMM) architecture [1] supports movement of IPv6 mobile nodes locally within a domain without requiring mobility support in the mobile nodes' network stacks. A mobile node can keep its IP address constant as it moves from link to link, avoiding the signaling overhead and latency associated with changing the IP address. While software specifically for localized mobility management is not required on the mobile node, IP-layer movement detection software may be necessary, 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). The LMA maintains an individual route for each registered mobile node. Any particular mobile node's route terminates at a mobile access gateway (MAG) which the mobile node uses as a default router on 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 in order to recognize when the mobile node has left the local access link. The localized mobility management architecture therefore 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 occurs. The localized mobility management architecture specifies no standardized protocol for a MAG to detect the arrival or departure of mobile nodes on its local link and accordingly initiate route update signaling with the LMA. An appropriate mechanism may be entirely implemented at the link layer, such as is 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 does not provide the necessary functionality, the mobile node must perform active IP-layer movement detection signaling so as to trigger route update signaling at the MAG. In either case, the decisive handoff signaling is bound to a mobile node identity, which is established when the mobile node initially connects to the domain. For some wireless access technologies, the mobile node identity may have to be re-established on every link-layer handoff. Vulnerabilities in either interface of the localized mobility Vogt & Kempf Expires February 22, 2007 [Page 3] Internet-Draft Security Threats to NETLMM August 2006 management architecture may entail new security threats which go beyond those that already exist in IPv6. Potential attack objectives may be to roam at the cost of a legitimate mobile node, interpose in a mobile node's communications from a position off link, 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 is limited to threats which are peculiar to localized mobility management; threats to IPv6 in general are documented in [3]. 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 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 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 routing updates from a legitimate MAG, or forge routing updates for a victim mobile node in order to redirect or deny the mobile node's traffic. Since data plane traffic for mobile nodes routes through the LMA, a compromised LMA can also intercept, inspect, modify, redirect, or drop such traffic on a MAG Vogt & Kempf Expires February 22, 2007 [Page 4] Internet-Draft Security Threats to NETLMM August 2006 supported by the LMA. 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 DoS attack against that MAG and its attached link. These threats also emanate from an attacker which 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, enabling it to ignore route updates from the MAG, or forge route updates in order to redirect or deny a victim 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. E.g., the IP address of a mobility anchor point in hierarchical Mobile IPv6 mobility management [4] may be proliferated across a domain hop by hop in Router Advertisement messages. Failure to properly authenticate a comparable mechanism for localized mobility management would allow an attacker to establish itself as a rogue LMA. The attacker may further be able to intercept, inspect, modify, redirect, or drop 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 independent of whether or not 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. E.g., if IP-in-IP encapsulation or an equivalent per-mobile-node approach is used for outbound data plane packets, the packets will route through the attacker. On the other hand, standard IP routing may cause the packets to be relayed via the legitimate LMA and hence to circumvent the attacker. 2.2 MAG Compromise or Impersonation A compromised MAG can redirect a victim mobile node's traffic onto its local access link arbitrarily, without authorization from the mobile node. This threat is similar to an attack on a typical Vogt & Kempf Expires February 22, 2007 [Page 5] Internet-Draft Security Threats to NETLMM August 2006 routing protocol where a malicious stub router injects a bogus host route for the mobile node. In general, forgery of a subnet prefix in link state or distance vector routing protocols requires support of multiple routers in order to obtain a meaningful change in forwarding behavior. But a bogus host route is likely to take precedence over the routing information advertised by legitimate routers, which is usually less specific, hence the attack should succeed even if the attacker is not supported by other routers. A difference between redirection in a routing protocol and redirection in localized mobility management is that the former impacts the routing tables of multiple routers, whereas the latter involves only the compromised MAG and an LMA. Moreover, a compromised MAG can ignore the presence of a mobile node on its local access link and refrain from registering the mobile node at an LMA. The mobile node then loses its traffic. The compromised MAG may further be able to cause interruption to a mobile node by deregistering the mobile node at the LMA, pretending that the mobile node has powered down. The mobile node then needs to reinitiate the network access authentication procedure, which the compromised MAG may prevent repeatedly until the mobile node moves to a different MAG. The mobile node should be able to handle this situation, but the recovery process may be lengthy and hence impair ongoing communication sessions to a significant extent. Attacks that the MAG can mount on its access link interface are common for any regular IPv6 access router [3]. Denial of service against an LMA is another threat of MAG subversion. The compromised MAG can trick the LMA into believing that a high number of mobile nodes have attached to the MAG. The LMA will then establish a routing table entry for each of the non-existing mobile nodes. The unexpected growth of the routing table may eventually cause the LMA to reject legitimate route update requests. It may also decrease the forwarding speed for data plane packets due to higher route lookup latencies, and it may for the same reason slow down the responsiveness to control plane packets. Another adverse side effect of a high number of routing table entries 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 increases the probability that a flooding packet, sent to a random IP address within the localized mobility management domain, matches an existing routing table entry at the LMA and gets tunneled to a MAG, which in turn performs address resolution [5] on the local access link. At the same time, fewer flooding packets can be dropped directly at the LMA due to a nonexistent routing table entry. Vogt & Kempf Expires February 22, 2007 [Page 6] Internet-Draft Security Threats to NETLMM August 2006 All of these threats apply not just to a MAG that is compromised, but also to an attacker that manages to counterfeit the identity of an authorized MAG in interacting with both mobile nodes and an LMA. Such an attacker can behave towards mobile nodes like a legitimate MAG and engage an LMA in route update signaling. In a related attack, the perpetrator eavesdrops on signaling packets exchanged between an authorized MAG and an LMA and replays these packets at a later time. These attacks may be conducted transiently, to selectively disable traffic for any particular mobile node at particular times. 2.3 Man in the Middle Attack An attacker that manages to interject itself between a legitimate LMA and a legitimate MAG can act as a man in the middle with respect to both control plane signaling and data plane traffic. If the attacker is on the original control plane path, it can forge, modify, or drop route update packets so as to cause the establishment of incorrect routes or the removal of routes that are in active use. Similarly, an attacker on the original data plane path can intercept, inspect, modify, redirect, and drop data plane packets sourced by or destined to a victim mobile node. A compromised router located between an LMA and a MAG may cause similar damage. Any router on the control plane path can forge, modify, or drop control plane packets, and thereby interfere with route establishment. Any router on the data plane path can intercept, inspect, modify, and drop data plane packets, or rewrite IP headers so as to divert the packets from their original path. An attacker between an LMA and a MAG may further impersonate the MAG towards the LMA and vice versa in route update signaling. The attacker can so interfere with route establishment even if it is not on the original control plane path between the LMA and the MAG. An attacker off the original data plane path may undertake the same to cause inbound data plane packets destined to the mobile node to be routed first from the LMA to the attacker, and from there to the mobile node's MAG and finally to the mobile node itself. As explained in Section 2.1, here, too, it depends on the specific data plane forwarding mechanism within the localized mobility management domain whether or not the attacker can influence the route of outgoing data plane packets sourced by the mobile node. Vogt & Kempf Expires February 22, 2007 [Page 7] Internet-Draft Security Threats to NETLMM August 2006 3. Threats to Interface between MAG and Mobile Node A MAG monitors the mobile nodes' link-layer handoff signaling or IP- layer movement detection signaling in order to detect the arrival and departure of mobile nodes and accordingly initiate route updates with the LMA. Cellular access technologies utilize only the signaling at the wireless link layer, and the IP stack never sees any change when the mobile node moves from one MAG to a MAG on a different link. For non-cellular access technologies, such as IEEE 802.11 or wired Ethernet, the link-layer signaling may not hide a handoff from the IP layer. Instead, IP-layer movement detection signaling may have to be performed in response to a notification from the link layer that a change in link-layer attachment has occurred. This signaling may involve extensions [6] for IPv6 Neighbor Discovery [5], DHCPv6 [7], or additional technology-specific functionality at the IP layer. Although the mobile node identity is conceptually independent of the mobile node's IP or link-layer addresses in either case, it must be securely bound to whatever handoff signaling of the mobile node is decisive for route updates on the MAG-LMA interface, be it via an address or otherwise. A MAG uses this binding to deduce when the mobile node has handed over onto the MAG's local access link, and possibly when the mobile node leaves the local access link again, thereby providing the trigger for route update signaling to an LMA. The binding must be robust to spoofing because it would otherwise facilitate impersonation of the mobile node by a third party, denial of service, or man-in-the-middle attacks. 3.1 Mobile Node Compromise or Impersonation An attacker that is able to forge the mobile node identity of a neighboring victim mobile node may be able to trick its MAG into redirecting the mobile node's packets to itself. Such an on-link attack is common for any regular IPv6 network [3]. However, if handoff signaling cannot definitively and unambiguously be linked back to the legitimate mobile node identity, an attacker may further be capable of fabricating handoff signaling of a victim mobile node that currently attaches to a different link. The attacker can thus trick its MAG into believing that the mobile node has handed over onto the MAG's access link. The MAG will then initiate route update signaling to an LMA, causing the LMA to redirect inbound data plane packets for the mobile node to the attacker's MAG and finally to the attacker itself. The attacker can so examine the packets that legitimately belong to the mobile node, or discard the packets in order to deny the mobile node service. The same can happen if a MAG accepts from the attacker replayed handoff signaling packets which the attacker has previously recorded from the legitimate mobile node. Vogt & Kempf Expires February 22, 2007 [Page 8] Internet-Draft Security Threats to NETLMM August 2006 The above attack is conceivable both if the attacker and the mobile node are on links that connect to different MAGs, as well as if they are on separate links connecting to the same MAG. In the former case, two MAGs would think they see the mobile node and both would independently perform route update signaling with the LMA. In the latter case, route update signaling is likely to be performed only once, and the redirection of packets from the mobile node to the attacker is internal to the MAG. The mobile node can always recapture its traffic back from the attacker through another run of handoff signaling. But standard mobile nodes are generally not prepared to counteract this kind of attack, and even where network stacks include suitable functionality, the attack may not be noticeable early enough at the link or IP layer to quickly institute countermeasures. The attack is therefore disruptive at a minimum, and may potentially persist until the mobile node initiates signaling again upon a subsequent handoff. Off-link impersonation attacks can be prevented at the link layer. E.g., they are not possible with cellular access technologies, where the handoff signaling is completely controlled by the wireless link layer. Here, an attacker must be on the same link as the victim mobile node in order to disrupt the negotiation between the mobile node and the network. Cellular access technologies also provide other cryptographic and non-cryptographic attack barriers at the link layer, which make mounting an impersonation attack, both on-link and off-link, very difficult. For non-cellular access technologies, however, off-link impersonation attacks may be possible. An attacker which can forge handoff signaling messages may also cause denial of service against the localized mobility management domain. The attacker can trick a MAG into believing that a large number of mobile nodes have attached to the local access link and thus induce it to initiate route update signaling with an LMA for each mobile node assumed on link. The result of such an attack is both superfluous signaling overhead on the control plane as well as a high number of needless entries in the LMA's and MAG's routing tables. The unexpected growth of the routing tables may eventually cause the LMA to reject legitimate route update requests, and it may cause the MAG to ignore handoffs of legitimate mobile nodes on 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 it may for the same reason slow down their responsiveness to control plane packets. An adverse side effect of this attack 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 increases the probability that a flooding packet, sent to a random IP address within the localized mobility management Vogt & Kempf Expires February 22, 2007 [Page 9] Internet-Draft Security Threats to NETLMM August 2006 domain, matches an existing routing table entry at the LMA and gets tunneled to a MAG, which in turn performs address resolution [5] on the local access link. At the same time, fewer flooding packets can be dropped directly at the LMA due to a nonexistent routing table entry. A threat related to the ones identified above, but not limited to handoff signaling, is IP spoofing [8][9]. 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 [10] in access network routers. 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 the enforcement of 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 an attacker may be able to send packets with an off-link IP source address despite the presence of network ingress filtering. This could make IP spoofing again more attractive. 3.2 Man in the Middle Attack An attacker which can interpose between a victim mobile node and a MAG during handoff signaling, router discovery, and IP address configuration can mount a man-in-the-middle attack on the mobile node, spoofing the mobile node into believing that it has a legitimate connection with the localized mobility management domain. The attacker can thus intercept, inspect, modify, or selectively drop packets sourced by or destined to the mobile node. 4. Threats from the Internet A localized mobility management domain uses host routes for data plane traffic and hence deviates from the standard IPv6 longest- prefix-match routing. Creation, maintenance, and deletion of tese host routes in addition cause 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 Vogt & Kempf Expires February 22, 2007 [Page 10] Internet-Draft Security Threats to NETLMM August 2006 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 which are potentially in use by mobile nodes within the localized mobility management domain. Like a border router, the LMA is 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 the MAG's local access link are also likely to suffer damage because the unrequested packets must be decapsulated and consume link bandwidth as well as processing capacities on the receivers. This threat is in principle the same as for denial of service on a regular IPv6 border router, but because either the routing table lookup enables the LMA to drop a flooding packet early on or, on the contrary, additional tunneling workload is required, the impact of an attack against localized mobility management may be different. In a related attack, the villain 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 need never obtain a globally routable IP address of any entity within the localized mobility management domain. A compromised mobile node hence cannot pass such an IP address off to a remote attacker, limiting 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 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 [11][12] for the two interfaces. Vogt & Kempf Expires February 22, 2007 [Page 11] Internet-Draft Security Threats to NETLMM August 2006 6. IANA Considerations This document has no actions for IANA. 7. Acknowledgment The authors would like to thank the NETLMM working group, especially Jari Arkko, 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. Vogt & Kempf Expires February 22, 2007 [Page 12] Internet-Draft Security Threats to NETLMM August 2006 8. References 8.1 Normative References [1] Kempf, J., "Problem Statement for Network-based Localized Mobility Management", IETF Internet Draft draft-ietf-netlmm-nohost-ps-04.txt (work in progress), June 2006. [2] Manner, J. and M. Kojo, "Mobility Related Terminology", IETF Request for Comments 3753, June 2004. 8.2 Informative References [3] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", IETF Request for Comments 3756, May 2004. [4] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", IETF Request for Comments 4140, August 2005. [5] Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", IETF Internet Draft draft-ietf-ipv6-2461bis-07.txt (work in progress), May 2006. [6] Kempf, J., Narayanan, S., Nordmark, E., Pentland, B., and JH. Choi, "Detecting Network Attachment in IPv6 Networks (DNAv6)", IETF Internet Draft draft-ietf-dna-protocol-01.txt (work in progress), June 2006. [7] Droms, R., Bound, J., Volz, B., Lemon, T., E., C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", IETF Request for Comments 3315, July 2003. [8] CERT Coordination Center, "CERT Advisory CA-1996-21 TCP SYN Flooding and IP Spoofing Attacks", September 1996. [9] CERT Coordination Center, "CERT Advisory CA-1998-01 Smurf IP Denial-of-Service Attacks", January 1998. [10] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", IETF Request for Comments 2827, May 2000. [11] Giaretta, G., "NetLMM Protocol", IETF Internet Draft draft-giaretta-netlmm-dt-protocol-00.txt (work in progress), June 2006. Vogt & Kempf Expires February 22, 2007 [Page 13] Internet-Draft Security Threats to NETLMM August 2006 [12] Laganier, J., Narayanan, S., and F. Templin, "Network-based Localized Mobility Management Interface between Mobile Node and Access Router", IETF Internet Draft draft-ietf-netlmm-mn-ar-if-01.txt (work in progress), June 2006. [13] Aura, T., "Cryptographically Generated Addresses (CGA)", IETF Request for Comments 3972, March 2005. [14] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", IETF Request for Comments 4282, December 2005. 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 181 Metro Drive, Suite 300 San Jose, CA 95110 USA Phone: +1 408 451 4711 Email: kempf@docomolabs-usa.com Appendix A. Change Log The following is a list of technical changes that were made from version 02 to version 03 of the document. Editorial revisions are not explicitly mentioned. o Changed the terminology from "network access identity" to "mobile node identity" as the previous term was frequently confused with the different "network access identifier" (NAI). Removed the Vogt & Kempf Expires February 22, 2007 [Page 14] Internet-Draft Security Threats to NETLMM August 2006 special "Network Access Identity" subsection in Section 3. The mobile node identity is now first mentioned in Section 1, which fits well with the nutshell description of the NETLMM architecture. The security requirements of the mobile node identifier are discussed in the introductory text of Section 3. This makes more sense than a special subsection because the text, on one hand, provides the necessary basis to understand the following subsections, while on the other hand, it does not really explain an attack itself. o Section 1: Extended the description of conceptual actors in the localized mobility management architecture and added a summary of potential attack objectives and attack targets. o Section 3.1: Granularity of ingress filtering may be coarser in a localized mobility mangement domain. It may also allow off-link IP spoofing since prefixes are not limited to a specific link. o Section 2.2: The threat of replay attacks was not mentioned in this section. It was added. o Section 3.1: The threat of replay attacks was not mentioned in this section. It was added. o Section 2.2: Causing spurious route updates may lead to DoS against the localized mobility management domain. This threat was missing in the discussion of this section and it was added. o Section 3.1: Causing spurious route updates may lead to DoS against the localized mobility management domain. This threat was missing in the discussion of this section and it was added. o Section 4: Moved DoS attack against a localized mobility management domain from the Internet to a separate section because it is not specific to either interface within the domain. o Revised the document with respect to the recent agreement the addressing model. o Revised the document with respect to the the possibility that there may be more than one LMA. The text was initially written under the assumption that the LMA is unique. o References split into normative and informative references. The following is a list of technical changes that were made from version 01 to version 02 of the document. Editorial revisions are not explicitly mentioned. Vogt & Kempf Expires February 22, 2007 [Page 15] Internet-Draft Security Threats to NETLMM August 2006 o Section 2.1: Included DoS/flooding attack against MAG. Also clarified how a malicious node off the control plane path between the authorized LMA and one or multiple target MAGs could impersonate the authorized LMA against the MAGs. Such an attacker could use various means to interfere with data plane traffic even if it is off the original data plane path between the legitimate LMA and the MAGs. o Section 2.2: Malicious MAG may deregister an actively communicating mobile node, without consent of the mobile node. o Section 2.3: Included related threats pertaining to MITM between LMA and MAG, which were formerly described in other sections. o Section 4: Included description of DoS/flooding attack against LMA, including its impact on the target MAGs, their links, and the target mobile nodes. o Section 3: Revised the structure of this section. Threats are now divided into attacks against a mobile node's network access identity; impersonation of a mobile node, both from the mobile node's link and from off link; as well as man-in-the-middle attacks. o Section 1: The binding with the network access identity may be with the authentication keys associated with the mobile node's IP address, not necessarily with the IP addresses themselves. o Section 3.1: Off-link attack may be mounted from a link that connects to a different MAG than the victim mobile node's MAG. Vogt & Kempf Expires February 22, 2007 [Page 16] Internet-Draft Security Threats to NETLMM August 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). 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. Vogt & Kempf Expires February 22, 2007 [Page 17] Internet-Draft Security Threats to NETLMM August 2006 Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Vogt & Kempf Expires February 22, 2007 [Page 18]