Network Working Group C. Vogt Internet-Draft Universitaet Karlsruhe (TH) Expires: December 25, 2006 J. Kempf DoCoMo USA Labs June 23, 2006 Security Threats to Network-based Localized Mobility Management draft-ietf-netlmm-threats-01.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 December 25, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document discusses security threats to NETLMM mobility management. Threats to NETLMM occur on two interfaces: the access router/localized mobility anchor interface and the access router/ mobile node interface. Threats to the access router/localized mobility anchor interface are threats to the NETLMM protocol itself. This document discusses threats on these two interfaces. Vogt & Kempf Expires December 25, 2006 [Page 1] Internet-Draft Security Threats to NetLMM June 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Threats to the AR/LMA Interface . . . . . . . . . . . . . . . 4 2.1 Unauthorized AR . . . . . . . . . . . . . . . . . . . . . 4 2.2 Unauthorized LMA . . . . . . . . . . . . . . . . . . . . . 5 2.3 Man in the Middle Attack . . . . . . . . . . . . . . . . . 5 2.4 Denial of Service Attack on the LMA . . . . . . . . . . . 5 3. Threats to the MN-AR Interface . . . . . . . . . . . . . . . . 6 3.1 Mobile Node Identity . . . . . . . . . . . . . . . . . . . 6 3.2 Impersonation on Handover . . . . . . . . . . . . . . . . 7 3.3 Off-Link Attacks . . . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Informative References . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . 11 Vogt & Kempf Expires December 25, 2006 [Page 2] Internet-Draft Security Threats to NetLMM June 2006 1. Introduction The NETLMM architecture supports movement of IPv6 mobile nodes within a localized mobility management domain with no specialized support on the mobile node for localized mobility management. In contrast to architectures where there is no localized mobility management support or where localized mobility management support is provided by a host- based solution, in the NETLMM architecture, the mobile node is able to keep its IP address constant within the localized mobility management domain as it moves, avoiding the signaling overhead required to change the address. Software specifically for localized mobility management is not required on the mobile node, though software for IP movement detection may be needed and, of course, driver software for link-layer movement is always required. More on the network-based localized mobility management architecture can be found in [1]. In the NETLMM architecture, a localized mobility anchor (LMA) maintains routes for mobile nodes. Packets to and from mobile nodes (MNs) on the last hop wireless links are routed through the LMA. When a MN moves from one access router (AR) to another, the route for the mobile node on the LMA is updated by the ARs. The NETLMM architecture therefore has two interfaces: 1. The AR to LMA interface where route update signaling occurs. 2. The MN to AR interface where movement detection and IP handover signaling occurs. The NETLMM architecture specifies no standardized protocol on the MN/AR interface. The network must be informed when a mobile node having an IP address moves from one access router to another, but how that occurs is not part of the NETLMM protocol. The mechanism can be entirely implemented by the wireless link protocol, such as is common for cellular networks. In that case, the IP layer never detects any movement, even though the mobile node may be moving from one link to another handled by a different access router. If the wireless link protocol does not handle movement detection and IP handover, however, support at the IP level is required. In that case, the mobile node must perform IP signaling for active movement detection. The access router uses this signaling to infer mobile node movement. More about IP level movement detection and NETLMM can be found in the NETLMM MN-AR interface document [2]. The NETLMM protocol itself is defined on the AR/LMA interface, and is specified in [3]. This document discusses threats to security on the NETLMM interfaces. Vogt & Kempf Expires December 25, 2006 [Page 3] Internet-Draft Security Threats to NetLMM June 2006 The discussion in this document focuses only on NETLMM signaling traffic, both for the NETLMM protocol itself and for signaling on the MN/AR interface that signals mobile node movement to the network. Details on how the threats are handled by the NETLMM protocol and the IP MN/AR interface are discussed in [3] and [2] respectively. 1.1 Terminology Mobility terminology in this document follows that in [4], with those revisions and additions from [1] and [5]. In addition, the following definition is used: Network access identity A identity established for the mobile node with the network during network access authentication that allows the network to unambiguously identify the mobile node for signaling purposes. For example, a wireless link session key established by the wireless link layer, the Network Access Identifier (NAI) [6], or the SEND public key [7] may serve as the identifier associated with the network access identity. 2. Threats to the AR/LMA Interface In this section, threats to the AR/LMA interface are discussed. Since the information propagated between the AR and LMA is routing updates, the threats on this interface are similar to the threats experienced by two routers exchanging routing information with a routing protocol. One difference is that the AR and LMA need not be separated by a single hop, whereas routing updates are usually propagated by flooding, so two routers exchanging routing information are usually separated by a single hop. 2.1 Unauthorized AR An AR that is not authorized to propagate NETLMM routing updates can result in serious damage to the security of a localized mobility management domain. The AR can redirect traffic from MNs on the AR's lst hop link arbitrarily, without authorization from the MN. The AR can ignore routing updates from the LMA so that the victim MNs lose their traffic. An unauthorized AR can also intercept, inspect, and redirect data plane traffic for mobile nodes on its last hop interface, but this threat is common for any last hop router. Vogt & Kempf Expires December 25, 2006 [Page 4] Internet-Draft Security Threats to NetLMM June 2006 Note that this threat applies not just to an AR that is compromised, but also to an off-path attacker that manages to forge the identity of an authorized AR, and thereby spoof the LMA into conducting NETLMM protocol signaling as if the attacker were legitimate. Such an attack could be conducted transiently, to selectively disable traffic for particular mobile nodes at particular times. 2.2 Unauthorized LMA An unauthorized LMA can ignore routing updates from legitimate ARs, or forge routing updates for MNs in order to redirect or deny traffic to victims. Since data plane traffic for mobile nodes routes through the LMA, a rogue LMA can also intercept, inspect, and redirect data plane traffic for mobile nodes on ARs supported by the LMA. A piece of malware might further manipulate the LMA's routing table such that all packets are directed towards a single AR, resulting in a DoS attack against that AR and its attached link. Again, these are the same threats experienced by any intermediate router in the network. Note that these threats apply not just to a LMA that is compromised, but also to an off-path attacker that manages to forge the identity of an authorized LMA, and thereby spoof the ARs in a localized mobility domain into conducting NETLMM protocol signaling as if the attacker were legitimate. Such an attack could be conducted transiently, to selectively disable traffic for particular mobile nodes or ARs at particular times. 2.3 Man in the Middle Attack An unauthorized intermediate router or other node that manages to interject itself between the AR and LMA is in a position to intercept, inspect, and redirect NETLMM protocol signaling traffic between an authorized LMA and authorized ARs handling mobility management for the localized mobility management domain. If the attacker can masquerade as an AR to the LMA and as the LMA to the ARs, it may be in a position to spoof both sides into believing that they have a secure link. The attacker can then utilize the information derived from the NETLMM protocol signaling for various purposes. 2.4 Denial of Service Attack on the LMA An attacker could launch a denial-of-service attack on the LMA by sending packets to arbitrary IP addresses with a prefix from the NETLMM domain. The LMA is in a topological position through which Vogt & Kempf Expires December 25, 2006 [Page 5] Internet-Draft Security Threats to NetLMM June 2006 all data-plane traffic goes, so it would have to process the flooding packets and perform a routing table lookup for each of them. The LMA could discard packets for which the destination IP address is not registered in the routing table. But other packets would have to be encapsulated and forwarded. There would also be some damage to the target AR and its link. In a related attack, the attacker manages to obtain a globally routable IP address of an LMA or a different network entity within the NETLMM domain, and perpetrates a DoS attack against that IP address. In general, NETLMM-based mobility management is somewhat more resistant to DoS attacks than host-based localized mobility management because nodes within the domain need never obtain a globally routable IP address of any entity within the NETLMM domain. As a consequence, a compromised node cannot pass such an IP address off to an attacker, limiting the ability of an unauthorized attacker to extract information on the topology of the NETLMM domain. It is still possible for an attacker to perform address scanning if ARs and LMAs have globally routable IP addresses, or for a compromise to happen in another way, but the much larger IPv6 address space makes address scanning considerably more time consuming. 3. Threats to the MN-AR Interface In order to detect IP level handovers of mobile nodes, NETLMM access routers utilize handover signaling between the mobile node and the access router. For cellular-type interfaces, such signaling occurs at the wireless link layer, and the IP stack never sees any change when the mobile node moves from one AR to an AR on a different link. For non-cellular interfaces, such as 802.11 or wired Ethernet-type interfaces, link layer signaling may not hide IP handover from the IP stack. The IP stack may need to perform movement detection in response to some kind of link layer hint that a change in access point has occurred. This signaling may involve extensions of IPv6 Neighbor Discovery [8] or it may involve DHCP [9] or it may involve some link-specific IP level mechanism. In any case, the security threats to the handover signaling that triggers NETLMM routing updates are the same, and are described in this section. 3.1 Mobile Node Identity In order for NETLMM to be able to definitively identify a mobile node upon handover, the mobile node must establish a network access identity when it initially enters the network. For example, a mobile node may initially authenticate itself to the NETLMM domain based on Vogt & Kempf Expires December 25, 2006 [Page 6] Internet-Draft Security Threats to NetLMM June 2006 its NAI and an AAA-based protocol. This identifier is conceptually independent of the mobile node's IP or link-layer addresses. In some wireless networks, the network access identity must be re-established on every handover between access points. NETLMM requires that the access network establish a binding between the network access identity and the IP addresses that the mobile node self-configures (if address auto-configuration is used) or that it is assigned (if stateful address configuration is used). This binding is used by the AR to definitively and unambiguously deduce that a mobile node has handed over into the AR's last hop subnet, thereby providing the trigger for NETLMM route update signaling to the LMA. The binding between the initial mobile-node authentication and the IPv6 addresses must be robust to spoofing, for it would otherwise facilitate impersonation of the mobile node by a third party. Lacking this binding, the following attacks are conceivable. 3.2 Impersonation on Handover An attacker that is able to forge an MN's network access identity can use this capability to fabricate handover signaling, thereby tricking the AR into believing that the victim has handed over into the AR's last hop subnet. The AR will then perform route update signaling with the LMA, causing the LMA to redirect traffic to the attacker. The attacker can utilize this capability to examine and discard traffic that legitimately belongs to the MN, as a means of denying the MN service or to snoop the MN's traffic. If the attacker can interpose between the MN and the network during router discovery and address configuration, the attacker can mount a man in the middle attack on the MN, spoofing the MN into believing it has a legitimate connection with the network. 3.3 Off-Link Attacks Depending on the exact nature of the handover signaling, an impersonation attack could be mounted from off link. Off-link attacks are possible in cases where the NETLMM domain consists of multiple access routers serving multiple last hop links. If the security on network access identity establishment is weak, or the IP level movement detection signaling is unprotected so that the network cannot definitively link the signaling back to the legitimate mobile node network access identity, then an attacker from another link could spoof IP level movement detection signaling for a victim mobile node and thereby steal the mobile node's traffic. Off-link attacks can be prevented at the link-layer. E.g., they are Vogt & Kempf Expires December 25, 2006 [Page 7] Internet-Draft Security Threats to NetLMM June 2006 not possible with cellular-style protocols, where the handover signaling is completely controlled by the wireless link layer, because an attacker must be on the same link with the MN in order to disrupt the negotiation with the network. Cellular-style protocols also have other cryptographic and noncryptographic barriers to attack at the link layer, which make mounting an impersonation attack, both on-link and off-link, very difficult. For non-cellular-style protocols, however, it may be possible for an off-link attacker to mount an impersonation attack. 4. Security Considerations The document describes threats to the NETLMM protocol [3] and to the MN-AR interface functions necessary to support network-based mobility management [2]. Mitigation measures for these threats, and the security considerations associated with those measures, are described in the respective drafts that discuss the NETLMM protocol and the MN-AR interface. 5. Acknowledgment The authors would like to thank Gregory Daley, Gerardo Giaretta, Julien Laganier, Phil Roberts, and Vidya Narayanan for their comments and suggestions regarding this document. Vogt & Kempf Expires December 25, 2006 [Page 8] Internet-Draft Security Threats to NetLMM June 2006 6. Informative References [1] Kempf, J., "Problem Statement for IP Local Mobility", IETF Internet Draft draft-ietf-netlmm-nohost-ps-01.txt (work in progress), April 2006. [2] Laganier, J. and S. Narayanan, "Network-based Localized Mobility Management Interface between Mobile Node and Access Router", IETF Internet Draft draft-ietf-netlmm-mn-ar-if-00.txt (work in progress), April 2006. [3] "NETLMM Protocol Specification (TBD)", IETF Working Group Item (work in progress). [4] Manner, J. and M. Kojo, "Mobility Related Terminology", IETF Request for Comments 3753, June 2004. [5] Kempf, J., "Goals for Network-based Localized Mobility Management (NETLMM)", IETF Internet Draft draft-ietf-netlmm-nohost-req-01.txt (work in progress), April 2006. [6] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", IETF Request for Comments 4282, December 2005. [7] Aura, T., "Cryptographically Generated Addresses (CGA)", IETF Request for Comments 3972, March 2005. [8] 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-00.txt (work in progress), February 2006. [9] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", IETF Internet Draft draft-ietf-dna-protocol-00.txt (work in progress), February 2006. [10] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", IETF Request for Comments 3756, May 2004. [11] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. Nordmark, "Mobile IP Version 6 Route Optimization Security Design Background", IETF Request for Comments 4225, December 2005. Vogt & Kempf Expires December 25, 2006 [Page 9] Internet-Draft Security Threats to NetLMM 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 181 Metro Drive, Suite 300 San Jose, CA 95110 USA Phone: +1 408 451 4711 Email: kempf@docomolabs-usa.com Vogt & Kempf Expires December 25, 2006 [Page 10] Internet-Draft Security Threats to NetLMM June 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 December 25, 2006 [Page 11] Internet-Draft Security Threats to NetLMM June 2006 Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Vogt & Kempf Expires December 25, 2006 [Page 12]