Mobility Extensions W. Haddad Internet-Draft G. Tsirtsis Intended status: Informational Qualcomm Expires: January 15, 2009 B. Lim Panasonic S. Krishnan Ericsson F. Dupont ISC July 14, 2008 Mobile IPv6 Residual Threats draft-haddad-mext-mip6-residual-threats-02 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 January 15, 2009. Haddad, et al. Expires January 15, 2009 [Page 1] Internet-Draft MIPv6 Residual Threats July 2008 Abstract This memo aims to highlight specific "residual" threats in Mobile IPv6 protocol. We call these threats "residual" simply because they were rightfully deemed not urgent during the design of Mobile IPv6 protocol. However, these threats are somehow benefiting from new mechanisms and/or extensions built on top of Mobile IPv6 protocol to improve their effects and likelihood. Hence, our main goal is to motivate designers to re-assess their potential taking into consideration these new mechanisms. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 4 3. Residual Threats Associated with a Malicious Mobile Node . . . 5 3.1. Violating Trust between the Mobile Node and its Home Agent . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Violating Trust between a Multihomed Mobile Node and its Home Agents . . . . . . . . . . . . . . . . . . . . . 6 3.3. Creating Routing Loops Among Home Agents . . . . . . . . . 8 4. Exploiting Multihoming to Defeat Ingress Filtering . . . . . . 10 5. Exploiting Neighbor Discovery in a MIPv6 Environment . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Haddad, et al. Expires January 15, 2009 [Page 2] Internet-Draft MIPv6 Residual Threats July 2008 1. Introduction Mobile IPv6 protocol design (described in [MIPv6]) involved extensive security analysis in order to evaluate the potential of each threat and suggest defensive measures when necessary or avoid adding complexities in case a security weakness was deemed acceptable (i.e., does not make IPv6 Internet more secure than without IP mobility). However, these weaknesses have been implicitly inherited in new mobility mechanisms and/or extensions built on top of MIPv6 which may in turn have increased their effects and thus, made them more attractive. This memo aims to describe these residual threats and to motivate designers to re-assess their potential in the light of what has been added so far to MIPv6 protocol. Haddad, et al. Expires January 15, 2009 [Page 3] Internet-Draft MIPv6 Residual Threats July 2008 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [TERM]. Haddad, et al. Expires January 15, 2009 [Page 4] Internet-Draft MIPv6 Residual Threats July 2008 3. Residual Threats Associated with a Malicious Mobile Node 3.1. Violating Trust between the Mobile Node and its Home Agent The trust model adopted in MIPv6 protocol assumes that the mobile node (MN) will always refrain from misusing the relationship it forges with its home agent (HA). In return, the HA should treat any legitimate information sent by the MN as being trustable. For example, the HA will accept any new care-of address (CoA) claimed by the MN and sent in a valid binding update (BU) message(s). In fact, there are two interrelated factors for expecting a well behaving MN. First, the MN is expected to be fully aware about the HA tracing capabilities coupled with a strong authentication. Second, there is a high probability that the victim will complain to the operator in which case, the MN is quickly identified and punitive actions can be taken against it. However, the situation changes when the first factor is no longer valid. This is the case where a user gains access to the operator network without strong identification (e.g., prepaid phone card). In such scenario, a malicious behavior can go unpunished since the operator is unable to trace the user. The malicious behavior can consist of sending to the HA a valid BU message carrying a fake CoA, which triggers traffic redirection towards the victim. While the target can always complain to the attacker's operator, the latter can do little or nothing about it (of course, the attack will eventually stop when the credit on the prepaid card is entirely consumed or the prepaid card itself expires). Note that while some countries have imposed some restrictions on using prepaid card, e.g, by requiring additional identification and denying roaming service, other countries are still allowing them without control. In fact, the lack of any reachability test between the MN and its HA, prior to or after sending a BU message, enables a malicious MN to launch a flooding attack against any potential target by simply claiming a new CoA which seems to be topologically located within the targeted network. Without testing the new CoA reachability, the HA will simply re-route data packets to the new CoA, i.e., targeted network, and the attacker can keep sending acknowledgment (ACK) messages to all its CN(s) in order to maintain the attack as long as needed. Note that this type of attack is not new and has been analyzed in [MROD]. In fact, when the route optimization (RO) mode is used, the impact of such attack is mitigated by imposing a periodic return routability procedure. Another way to protect against this attack is to deploy ingress filtering (described in [INGRESS]). Haddad, et al. Expires January 15, 2009 [Page 5] Internet-Draft MIPv6 Residual Threats July 2008 Moreover, new added extensions to MIPv6 may enhance launching flooding attack through the HA. This is due to the MN's ability to register multiple CoAs with the HA. Such scenario is better described in [Multih_Sec] and is analyzed in the next section. 3.2. Violating Trust between a Multihomed Mobile Node and its Home Agents Multiple Care-of Address registration (MCoA) protocol (described in [MCoA]) extends the MIPv6 protocol to enable a multi-interface MN to register multiple CoAs at its HA. The fundamental difference between MIPv6 and MCoA is that for a given home address (HoA) in MIPv6, the MN is only able to bind a primary 'fake' CoA. Hence, this implies that once a malicious MN binds the 'fake' CoA at HA, that MN loses its ability to use that HoA for communication. However, in MCoA, with the ability to bind several CoAs to a single HoA, a malicious MN could bind a mixture of 'real' and 'fake' CoAs. The MN can still use the HoA for communication by directing control traffic towards its 'real' CoA. Likewise in the trust model described in [MROD] between the MN and its HA, it permits the HA to always acknowledge any binding that the MN requests. This trust relationship is further strengthened when one assume that ingress filtering is being used such that when the HA receives a BU message from the MN stating its CoA as the source address, the HA trusts that the incoming packets do indeed originate from the specified source address. In addition, the HA also trusts the routing infrastructure, i.e., that packets forwarded by the HA would be sent to the intended destination. This assumption makes it possible for the HA to somewhat trust the MN if the MN sends the binding of each CoA individually (e.g., one BU message per CoA). Even with ingress filtering deployed worldwide in all networks, the problem of the flooding attack described above could still be achieved in the Multiple Care-of Address registration (MCoA) protocol where the MN is able to use multiple binding identifier options in a single binding update message to the home agent for registration purposes. With the care-of addresses embedded inside the BU message, it is not possible for ingress filtering to be used to verify these CoAs. Figure 1 shows an example on how MCoA could be used to initiate the redirection attack. Haddad, et al. Expires January 15, 2009 [Page 6] Internet-Draft MIPv6 Residual Threats July 2008 [Start of packet header] Source Address : CoA Destination Address : HA's address [Mobility Options] Binding Unique Identifier: BID1 Binding Unique Identifier: BID2 Care-of Address : V1's address Binding Unique Identifier: BID3 Care-of Address : V2's address [End of packet header] Figure 1: Binding update message for MCoA CoA is a valid care-of address owned by MN. MN is attempting to bind addresses of two victims, V1 and V2, at HA in order to launch an attack towards the victims. When HA receives this BU message, it will accept it based on the following. First, the BU message is deemed authorized as the correct IPSec SA is used for the message. Second, the trust relationship that HA has with the routing infrastructure allows it to understand that this BU message is sent from MN. Finally, after the first two checks have succeeded, the trust relationship that HA has with the MN permits it to trust the care-of addresses that are specified in this BU message. Hence, the binding cache at HA will record three bindings for MN tied to MN's home address (HoA) as shown in Figure 2 below. Binding 1 [HoA, CoA , BID1] Binding 2 [HoA, V1's address, BID2] Binding 2 [HoA, V2's address, BID3] Figure 2: Binding Cache at Home Agent The lack of any reachability test between the mobile node and its HA, prior to or after sending a BU message, enables a malicious MN to launch a network flooding attack against any potential target by Haddad, et al. Expires January 15, 2009 [Page 7] Internet-Draft MIPv6 Residual Threats July 2008 simply claiming new care-of addresses. 3.3. Creating Routing Loops Among Home Agents In MIPv6, it is possible for a malicious MN to create a routing loop amongst HAs. This can be achieved when a MN binds one home address located on a first HA to another home address on a second HA. This type of binding will force HAs to route the same packet among each other without knowledge that a routing loop has been created. Such looping problem is limited to cases where a MN has multiple HAs. For the single case, MIPv6 has a policy at the HA to prevent the binding of one home address to another home address hosted by the same home agent. Figure 3 below shows such threat of routing loop between home agents. +-----+ | | | I | cccc +-----+ Binding cache | N |------| HA1 | [HoA1, HoA2] HoA1 | T | +-----+ +----+ | E | | MN |------| R | +----+ | N | cccc +-----+ Binding cache HoA2 | E |------| HA2 | [HoA2, HoA1] | T | +-----+ | | +-----+ Figure 3: Packet flooding attack scenario The mobile node (MN) sends a binding update (BU) message to its first home agent (HA1) to bind its home address (HoA1) to a care-of address (HoA2). Since HoA2 is not a home address on HA1, HA1 accepts this binding thinking that HoA2 is indeed a CoA. Likewise, on HA2, MN sends a BU to bind its home address (HoA2) to a care-of address (HoA1). Such bindings created among the two HAs create a routing loop between them. For example, when HA1 wants to forward a packet (shown as 'c') from a CN to MN, HA1 searches the binding cache to find the relevant MN's CoA. In this case, HA1 tunnels the packet to MN via HoA2. This will cause HA2 to intercept the packet for MN. Now, at HA2, it sees that the packet is addressed to HoA2. Searching the respective binding entry in its binding cache, HA2 will tunnel this packet to MN via HoA1. This will cause HA1 to intercept the packet for MN. This repetition will continue until one of the HA discover that it can no longer encapsulate the packet (i.e., due to the tunnel encapsulation limit == 0 described in [GPT6]). In this case, the packet would be dropped and a flood of error message will Haddad, et al. Expires January 15, 2009 [Page 8] Internet-Draft MIPv6 Residual Threats July 2008 be sent between both HAs to indicate that the packet has failed to reach its intended destination (the MN). Thus, it can be seen that such attacks consumes the resources of the home agent and if launched in full scale (e.g., multiple sets of HoAs) could 'shut down' the HA. Haddad, et al. Expires January 15, 2009 [Page 9] Internet-Draft MIPv6 Residual Threats July 2008 4. Exploiting Multihoming to Defeat Ingress Filtering A malicious multi-homed node can also use its multiple interfaces to emulate a home network and defeat ingress filtering. This is the case when an attacker with two interfaces (A) and (B) starts its attack by establishing sessions with a set of correspondent nodes (CNs) using (A)'s IPv6 address then at some point, attaches (B) to the targeted network and triggers a return routability (RR) procedure with the CN. As the RR procedure involves exchanging HoTI/HoT messages, the MN will use (A)'s IPv6 address for that purpose and receives a home keygen token. Then the MN exchanges a CoTI/CoT messages using (B)'s IPv6 address as a CoA and obtain a care-of keygen token. A BU message is then sent to the CN and the data traffic is redirected to (B). At some point, the MN detaches itself from the targeted network and start sending legitimate ACK messages via a legitimate address to each CN causing a flooding attack. Such scenario is mitigated by the fact that the MN MUST periodically repeat the RR procedure which means that it has to exchange CoTI/CoT messages with each CN. However, if the MN manages to position itself on-path with at least one CN without detaching (A) then it will be able to keep the attack as long as needed. Note that this attack becomes easier if the MN does not have to periodically repeat the RR procedure as a result of establishing a long lifetime security association with the CN, e.g., when the enhanced RO mode ([ERO]) is used. Haddad, et al. Expires January 15, 2009 [Page 10] Internet-Draft MIPv6 Residual Threats July 2008 5. Exploiting Neighbor Discovery in a MIPv6 Environment Note: It may be asserted that this attack is related to Neighbor Discovery Protocol (described in [NDP]). However, our main goal is to convey a description about its potential which may go well beyond the local link when applied in a MIPv6 context. This threat offers a malicious node two edges. It requires first that the attacker be attached to the same foreign link as the MN, and the discovery of the MN's home agent IP address as well as the MN's IP home address (which may not pose a serious problem). After learning these two information, the attacker advertises the MN's home prefix on the link thus leading the MN to believe that it has returned to its home network. Such information will prompt the MN to send a BU message to its HA to request de-registration. However, such early de-registration may not be possible as the foreign network may have activated ingress filtering. But the main goal for the attacker is to get a valid copy of the MN's BU message and such goal is achieved. If the malicious node concludes that the MN is still receiving data packets tunneled by the HA to its current CoA, then it will get involved in the MN de-registeration procedure by forwarding the BU message to the MN's HA on another interface where ingress filtering is not activated (i.e., under the assumption that the attacker is multihomed). Upon receiving the BU message, the HA will de-register the MN and stops tunneling data packets to the MN's CoA. In addition, the HA sends back a BA message which will never reach the MN. From that moment, the data traffic sent by the CN(s) stops at the MN's home network. However, the lack of ACK messages sent by the MN will prompt the CN(s) at some point to halt sending data traffic and eventually tear down the session(s). However, the situation gets worse if the malicious node decides to push further in his attack by sending fake ACK messages to the CN(s), i.e., using the MN's home address. In such situation, the CN(s) will keep sending data traffic to the MN's HA (where they eventually get discarded) and thus, may cause severe disruption within the home access network, possibly leading to a network flooding attack in some specific topologies. Note that as they may be more than one MN attached to the same foreign link and using the same home prefix, such attack may lead to collective de-registration. Haddad, et al. Expires January 15, 2009 [Page 11] Internet-Draft MIPv6 Residual Threats July 2008 6. Security Considerations This document is about security analysis of some specific parts in the MIPv6 protocol. Haddad, et al. Expires January 15, 2009 [Page 12] Internet-Draft MIPv6 Residual Threats July 2008 7. References 7.1. Normative References [ERO] Vogt, C., Arkko, J., and W. Haddad, "Enhanced Route Optimization for Mobile IPv6", RFC 4866, June 2006. [GPT6] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6", RFC 2473, December 1998. [INGRESS] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", RFC 2827, May 2000. [MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support for IPv6", RFC 3775, June 2004. [MROD] Nikander, P., Arkko, J., Aura, T., and E. Nordmark, "Mobile IPv6 version 6 Route Optimization Security Design Background", RFC 4225, December 2005. [NDP] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [TERM] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", RFC 2119, BCP , March 1997. 7.2. Informative References [MCoA] Wakikawa, R., Ernst, T., Nagami, K., and V. Devarapalli, "Multiple Care-of Addresses Registration", Internet Draft, draft-ietf-monami6-multiplecoa-08.txt, May 2008. [Multih_Sec] Lim, B., Ng, C., and K. Aso, "Verification of Care-of Addresses in Multiple Bindings Registration", Internet Draft, draft-lim-mext-multiple-coa-verify-01.txt, February 2008. Haddad, et al. Expires January 15, 2009 [Page 13] Internet-Draft MIPv6 Residual Threats July 2008 Authors' Addresses Wassim Haddad Qualcomm 500 Somerset Corporate Blvd Bridgewater, New Jersey 08807 US Phone: +908 938 5027 Email: whaddad@qualcomm.com Georges Tsirtsis Qualcomm London UK Phone: +908 443 8174 Email: tsirtsis@qualcomm.com Benjamin Lim Panasonic Singapore Laboratories Pte Ltd Blk 1022 Tai Seng Ave #06-3530 Tai Seng Industrial Estate Singapore 534415 Phone: +65 65505478 Email: benjamin.limck@sg.panasonic.com Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada Phone: +1 514 345 7900 Email: Suresh.Krishnan@ericsson.com Francis Dupont ISC Rennes France Email: Francis.Dupont@fdupont.fr Haddad, et al. Expires January 15, 2009 [Page 14] Internet-Draft MIPv6 Residual Threats July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Haddad, et al. Expires January 15, 2009 [Page 15]