Network Working Group J. Kempf Internet-Draft DoCoMo USA Labs Expires: October 19, 2006 C. Vogt Universitaet Karlsruhe (TH) April 17, 2006 Security Threats to Network-based Localized Mobility Management draft-ietf-netlmm-threats-00.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 October 19, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document discusses security threats to NETLMM-based mobility management with a focus on threats on the interface between mobile nodes and access routers. Threats to the NETLMM protocol itself, which runs between the access routers and mobility anchor points, are similar to those faced by other protocols between network entities like routers. These threats are handled in the NETLMM protocol specification. In contrast, threats on the interface between mobile Kempf & Vogt Expires October 19, 2006 [Page 1] Internet-Draft Security Threats to NetLMM April 2006 nodes and access routers are different, because the access routers are presenting the NETLMM domain as a single subnet, in order to allow mobile nodes to continue using the same IP address as they move from one access router to another. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. NETLMM Architecture . . . . . . . . . . . . . . . . . . . . . 3 3. Outline of Threats . . . . . . . . . . . . . . . . . . . . . . 5 4. Threats to IPv6 Address to Mobile Node Identifier Mapping . . 6 4.1 Roaming at a Victim's Costs . . . . . . . . . . . . . . . 6 4.2 Off-Path Eavesdropping . . . . . . . . . . . . . . . . . . 7 4.3 Denial of Service . . . . . . . . . . . . . . . . . . . . 7 5. Threats to Access Router Functions . . . . . . . . . . . . . . 8 6. Threats to Location Privacy . . . . . . . . . . . . . . . . . 8 6.1 Threats from Nodes within the NETLMM Domain . . . . . . . 9 6.2 Threats from Nodes At Any Location . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 11 9. Informative References . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . 14 Kempf & Vogt Expires October 19, 2006 [Page 2] Internet-Draft Security Threats to NetLMM April 2006 1. Introduction The NETLMM architecture supports movement of IPv6 mobile nodes within a localized mobility management domain with minimal involvement on the part of the mobile node itself. 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 link movement detection may be needed and of course driver software for link layer movement is always required. More on the localized mobility management problem can be found in [3]. In this document, threats to the protocols involved in implementing the NETLMM architecture are discussed. The document focuses on threats on the mobile node to access router interface. Threats to the NETLMM protocol itself, which runs on the access router to mobility anchor point interface are briefly described, but detailed requirements and solutions for security for the NETLMM protocol are handled in the requirements and NETLMM protocol specification documents [1][4]. While a default IP-based protocol for the interface between mobile nodes and access routers has been specified [2], that interface is the focus of this document because the protocol running across it can potentially be completely handled by the wireless link protocol without any IP involvement. This document is intended to provide guidance to developers linking the NETLMM protocol to such wireless link protocols so that they know what the potential security threats are. 1.1 Terminology Mobility terminology in this document follows that in [5], with those revisions and additions from [3] and [4]. 2. NETLMM Architecture Figure 1 depicts the NETLMM architecture. A mobility anchor point (MAP) manages routing for packets to mobile nodes as they move through the NETLMM domain. The MAP communicates with a collection of access routers (AR_1 through AR_n in Figure 1). Each access router is connected to a collection of wireless access points (AP_1 through AP_m in Figure 1) that provide wireless access links to mobile nodes. Kempf & Vogt Expires October 19, 2006 [Page 3] Internet-Draft Security Threats to NetLMM April 2006 The access routers handle routing updates to the MAP when a new mobile node moves onto the IP link controlled by the access router. In order for the mobile node to keep its address constant across the NETLMM domain, the access routers must all advertise the same IPv6 subnet prefixes to mobile nodes on their link, and the internal gateway protocol (IGP) used to distribute routes to routers throughout the IGP routing domain must target the MAP as the last hop router for those IPv6 subnet prefixes that span IP links in the NETLMM domain. The MAP tunnels packets to and from the access routers, changing to a new access router when a routing update from a new access router indicates that an mobile node has moved. NETLMM Domain +-------+ | MAP | +-------+ @ @ @ @ @ @ @ AR-MAP @ @ Interface @ @ @ +------+ +------+ | AR_1 | ... | AR_n | +------+ +------+ * * * * MN-AR * * * Interface * * * * * * * * * * /\ /\ /\ / \ ... / \ ... / \ / AP \ / AP \ / AP \ / AP_1 \ / AP_i \ / AP_m \ -------- -------- -------- +--+ +--+ +--+ |MN|----->|MN|----->|MN|-----> +--+ +--+ +--+ Figure 1: Protocol Interfaces in the NETLMM Architecture Kempf & Vogt Expires October 19, 2006 [Page 4] Internet-Draft Security Threats to NetLMM April 2006 3. Outline of Threats The threats for the NETLMM architecture break down into two parts: o Threats on the interface between mobile nodes and access routers. o Threats on the interface between the access routers and a MAP. Threats on the interface between mobile nodes and access routers are, in many respects, similar to threats [6] against the IPv6 Neighbor Discovery protocol, except that rather than being confined to a single IP link, the threat potential is distributed across the last hops of the NETLMM domain. The interface between mobile nodes and access routers may run the default IP protocol [2], or it may run a wireless link technology-specific protocol. Threats on this interface are discussed in detail in the following sections. The threats on the interface between access routers and a MAP are of the same nature as the threats that an IGP for routing faces. Specifically, a rogue MAP or a rouge access router can end up injecting incorrect tunnels or host routes for mobile nodes. This may result in traffic being siphoned off, facilitating impersonation of the mobile node or the mobile node's peer, or in traffic being dropped, resulting in a DoS attack on the mobile node. Rouge access routers and MAPs can be handled with the same security measures used by IGPs for standard IP routing. Since these threats are specific to the NETLMM protocol, which runs across the interface between the access routers and a MAP, they are discussed in the NETLMM protocol specification [1]. The document also identifies specific security measures for the NETLMM protocol. Another threat on the interface between access routers and the MAP is DoS against network entities. Here, an attacker manages to obtain a globally routable IP address of an access router, a MAP, or some other network entity, 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 attacker to extract information on the topology of the NETLMM domain. It is still possible for an attacker to perform address scanning if access routers and MAPs 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. Network operators need to take these considerations into account, and ensure that their internal network topologies are sparsely populated. Kempf & Vogt Expires October 19, 2006 [Page 5] Internet-Draft Security Threats to NetLMM April 2006 4. Threats to IPv6 Address to Mobile Node Identifier Mapping A mobile node identifies itself to the NETLMM domain based on an identifier that is conceptually independent of its IP and link-layer addresses. For packets to be later recognized as coming from the mobile node, the mobile node's identity is tied to its IP address, or possibly to any other identifier which shows up in the packets (e.g., the link-layer address or an IPsec SPI), during the initial authentication procedure. Without lack of generality, it is assumed in the following that the mobile node's IP address is used for this purpose. Per se, a mapping between the mobile-node identifier and the IP address is insufficient to protect the mobile node against impersonation by a third party. Specifically, the following attacks are conceivable. 4.1 Roaming at a Victim's Costs Given that regular IP packets do not carry a signature of the mobile node or a comparable proof of origin, an attacker may trick the NETLMM domain into accepting packets, sent by the attacker from the mobile node's IP address, and charging any forwarding services or other due services to the mobile node's account. This allows the attacker to roam across the entire NETLMM domain and communicate at the mobile node's costs. The attacker not necessarily needs to be a customer of the NETLMM domain since it does not have to authenticate itself to the NETLMM domain. It rather waits for the mobile node to accomplish the authentication procedure. The attacker must also record the mobile node's IP address so that it can later forge packets that appear to be coming from the mobile node. The attack may or may not overlap with a period during which the mobile node itself communicates, and the attacker may or may not be on the same link as the mobile node while the attack proceeds. The duration of the attack depends on how long a refresh interval the NETLMM domain imposes on the mobile node's authentication. This threat can be eliminated if appropriate per-packet authentication is used for packets that the mobile node sends. The packets can be authenticated either on the link layer or on the IP layer, provided that the IP address, based on which the NETLMM domain identifies the packets as coming from the mobile node, is covered by the protection and securely bound to the authentication context. A possible mechanism for link-layer authentication is a combination Kempf & Vogt Expires October 19, 2006 [Page 6] Internet-Draft Security Threats to NetLMM April 2006 of IEEE 802.11i technology and a function in the access router that verifies whether or not an inbound packet's IP source address is bound to the link-layer encryption keys. At the IP layer, IPsec AH provides appropriate protection. Note that IPsec ESP is not sufficient as it does not cover a packet's IP header. A related attack shows the importance of a secure binding between a mobile node's IP address and the keys it uses for per-packet authentication: Failure to provide such a binding allows an attacker, who is itself a customer of the NETLMM domain, to authenticate to the NETLMM domain, obtain the keys for per-packet authentication, and then spoof its IP source address to be the address of some third node. The attacker can thus roam and communicate at its victim's costs. 4.2 Off-Path Eavesdropping If an attacker can forge a victim's mobile-node identifier or generate packets that appear to originate from the victim, the attacker can siphon off packets meant for the victim and redirect them to its own location. The perpetrator can inspect these packets, effectively waging an "off-path" eavesdropping attack. However, it is impossible for the attacker to forward the packets on to the victim given that the attacker and the victim use the same IP address. The compromised communication session is therefore highly likely to abort before the attack causes significant damage. The described redirection attack resembles a related man-in-the- middle attack identified in [8]. In that attack, the impersonator manages to redirect packets exchanged between a victim and the victim's peer via itself. Packets thus eventually reach their intended destination, although the attacker can eavesdrop on them or modify them on the fly. The triangular routing becomes possible because the attacker uses a different IP address than its victim. The NETLMM architecture mitigates this attack to some extent in that the attacker cannot redirect a third node's packets unless it somehow duplicates that node's IP address. 4.3 Denial of Service A similar attack strategy to the one described in Section 4.2 causes denial of service to a victim. Again, the attacker forges the victim's mobile-node identifier or generates packets that appear to originate from the victim, and it thereby redirects the packets meant for the victim to its own location. Any request that the victim sends to nodes located elsewhere than its local link will Kempf & Vogt Expires October 19, 2006 [Page 7] Internet-Draft Security Threats to NetLMM April 2006 consequently solicit responses that the NETLMM domain will route to the attacker's location. As a result, the victim is unable to communicate. This attack is limited in that the attacker can only redirect the victim's packets to its own location because it must obtain the victim's IP address. This is a natural limitation of the NETLMM architecture because packets are only forwarded to links where the destination node is known (or believed) to be present. 5. Threats to Access Router Functions An attacker that is able to set up a bogus access router can trick mobile nodes into sending their packets to the attacker. The attacker can thus act as an active or passive man in the middle, possibly forwarding the victim's packets to their actual destination via a path outside the NETLMM domain. Return packets sent by the victim's peer are likely to be delivered through the NETLMM domain, however. The attacker may hence not be able to manipulate those packets, although it may still read them. A more sophisticated attacker can impersonate an access router and act as a NAT box at the same time. It tricks a victim into accepting it as its default router and forwards the victim's packets, after manipulation, with an IP source address through which it is itself reachable. Unless the victim's peer expects a particular IP address, it will send any responses "back" to the attacker. The attacker can read and/or manipulate these packets and finally deliver them to the victim. Essentially, a NETLMM domain is subject to attacks against access routers in the same way as any conventional IPv6 domain. These threats are due to vulnerabilities of the IPv6 Neighbor Discovery protocol, and are as such identified in [6]. In particular, impersonating an access router requires the attacker to send spoofed Router Advertisement messages, which can be precluded, or at least mitigated to a reasonable extent, by SeND [7]. 6. Threats to Location Privacy The location privacy of mobile nodes may be compromised if their identities can somehow be associated to their IP or MAC addresses. This may happen if mobile-node identifiers can be read from the Kempf & Vogt Expires October 19, 2006 [Page 8] Internet-Draft Security Threats to NetLMM April 2006 protocol executed on the interface between mobile nodes and access routers, if the NETLMM protocol run between access routers and the MAP leaks the mobile-node identifiers, or if an attacker manages to steal confidential information from a NETLMM database. Certainly, an attacker may also be able to infer a mobile node's identity from other sources, e.g., from information extracted from application- layer payloads sent or received by the mobile node. But those attacks are not specific to NETLMM and hence outside the scope of this document. Threats to location privacy that are specific to NETLMM can conceptually be separated into threats that emanate from nodes which are themselves within the NETLMM domain and threats that may also come from nodes outside the NETLMM domain. 6.1 Threats from Nodes within the NETLMM Domain An attacker within the localized mobility management domain can obtain location information through the usual IPv6 Neighbor Discovery mechanisms. E.g., the attacker can obtain the IP address of a victim within the localized mobility management domain and multicasts a Neighbor Solicitation message to resolve this IP address to the victim's link-layer address. If the attacker receives a Neighbor Advertisement message in response, it knows that the victim is present somewhere in the NETLMM domain. The obtained location information may be more precise depending on how far beyond the local link IPv6 Neighbor Discovery messages are forwarded by the NETLMM routing fabric. In case such messages are kept link-local, the attacker can even conclude from a received Neighbor Advertisement message that the victim is on the same link. Likewise, the attacker can use Duplicate Address Detection to determine whether another node is within the localized mobility management domain or on the local link. The attacker multicasts a Neighbor Solicitation message to the solicited-node multicast address for the victim's address. If a Neighbor Advertisement message returns, the attacker knows that the victim is somewhere in the localized mobility management domain or on the local link, depending on whether or not NETLMM routers forward Duplicate Address Detection signaling. IPv6 Neighbor Discovery messages are normally of link-local scope and as such not forwarded by routers. This is based on the prerequisite that prefix sets of different links are disjunct. However, links within a NETLMM domain all use the same set of prefixes. While this does not necessarily imply that address-resolution messages need to Kempf & Vogt Expires October 19, 2006 [Page 9] Internet-Draft Security Threats to NetLMM April 2006 be distributed across an entire NETLMM domain (link-local redirects may also be feasible), it does imply that messages exchanged for the purpose of Duplicate Address Detection would have to. More precise location information can only be acquired from a position where the links incoming to and outgoing from the MAP can be monitored. An attacker in this position can listen to the NETLMM protocol traffic between the MAP and the different access routers and thus derive the link where its victim is currently attached to. The attacker may even be able to reasonably track its victim if it has access to only a subset of the links to and from the MAP. 6.2 Threats from Nodes At Any Location Furthermore, a mobile node's presence within the NETLMM domain is also implied by the prefix of its IP source address. Correspondent nodes can identify the NETLMM domain and coarsely localize the mobile node based on this address, as they could do with any other IP node. The NETLMM architecture blurs the resolution of such location information to some extent in that the IP source address does not contain information about the link within the NETLMM domain where the mobile node currently is. Tracing tools such as "traceroute" may allow the correspondent node (or any other node with the mobile node's IP address) to obtain the IP addresses of some routers on the path to the mobile node. But since packets are tunneled on the sub- path between the MAP and the mobile node's current access router, the acquired information may not be sufficient to actually locate the mobile node. The location tracker does not necessarily have to be a correspondent node of its victim. The attacker may also be another node, both outside and within the NETLMM domain, provided that it has somehow obtained the victim's IP address. This threat can be eliminated by filtering tracing attempts at the NETLMM domain gateways. 7. Security Considerations This document deals with the security of the NETLMM architecture. Kempf & Vogt Expires October 19, 2006 [Page 10] Internet-Draft Security Threats to NetLMM April 2006 8. Acknowledgment The authors would like to thank Phil Roberts for his comments and suggestions regarding the initial version of this document. Kempf & Vogt Expires October 19, 2006 [Page 11] Internet-Draft Security Threats to NetLMM April 2006 9. Informative References [1] "NETLMM Protocol Specification (TBD)", IETF Working Group Item (work in progress). [2] "NETLMM Mobile-Node Access-Router Protocol Specification (TBD)", IETF Working Group Item (work in progress). [3] Kempf, J., "Problem Statement for IP Local Mobility", IETF Internet Draft draft-kempf-netlmm-nohost-ps-00.txt (work in progress), June 2005. [4] Kempf, J., "Requirements and Gap Analysis for IP Local Mobility", IETF Internet Draft draft-kempf-netlmm-nohost-req-00.txt (work in progress), July 2005. [5] Manner, J. and M. Kojo, "Mobility Related Terminology", IETF Request for Comments 3753, June 2004. [6] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", IETF Request for Comments 3756, May 2004. [7] Aura, T., "Cryptographically Generated Addresses (CGA)", IETF Request for Comments 3972, March 2005. [8] 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. Authors' Addresses 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 Kempf & Vogt Expires October 19, 2006 [Page 12] Internet-Draft Security Threats to NetLMM April 2006 Christian Vogt Institute of Telematics Universitaet Karlsruhe (TH) P.O. Box 6980 76128 Karlsruhe Germany Email: chvogt@tm.uka.de Kempf & Vogt Expires October 19, 2006 [Page 13] Internet-Draft Security Threats to NetLMM April 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. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Kempf & Vogt Expires October 19, 2006 [Page 14]