NETLMM Working Group K. Weniger Internet-Draft G. Velev Expires: October 22, 2007 Panasonic April 20, 2007 Proxy Mobile IPv6 and Mobile IPv6 interworking issues draft-weniger-netlmm-pmipv6-mipv6-issues-00 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 22, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Weniger & Velev Expires October 22, 2007 [Page 1] Internet-Draft PMIPv6-MIPv6 interworking issues April 2007 Abstract This document discusses issues that may arise if Proxy Mobile IPv6 and Mobile IPv6 are used together. Solutions for those issues are currently out of scope. The purpose of this document is to agree on a comprehensive list of interworking issues and to trigger the discussion of solutions. Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. List of PMIPv6-MIPv6 interworking issues . . . . . . . . . . . 5 3.1. Issue #1: Mobility mode selection . . . . . . . . . . . . 5 3.2. Issue #2: MIPv6 de-registration Binding Update deletes PMIPv6 binding cache entry . . . . . . . . . . . . . . . . 5 3.3. Issue #3: Race condition between Binding Update and Proxy Binding Update messages . . . . . . . . . . . . . . 5 3.4. Issue #4: Mismatch of binding cache lookup key . . . . . . 6 3.5. Issue #5: Use of wrong home agent or LMA after handover . 6 3.6. Issue #6: Redirection attack against mobile nodes outside PMIP domain due to compromised MAG . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 6.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Weniger & Velev Expires October 22, 2007 [Page 2] Internet-Draft PMIPv6-MIPv6 interworking issues April 2007 1. Terminology 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 [1]. Furthermore, the terminology defined in [2] and [3] is used. Weniger & Velev Expires October 22, 2007 [Page 3] Internet-Draft PMIPv6-MIPv6 interworking issues April 2007 2. Introduction The NETLMM WG is standardizing Proxy Mobile IPv6 [3], a Mobile IPv6- based protocol for localized mobility management. This protocol allows the network to manage the mobility of mobile nodes, e.g., to enable IP mobility of nodes that do not implement Mobile IPv6. There are various scenarios, in which Mobile IPv6 (MIPv6) [2] and Proxy Mobile IPv6 (PMIPv6) can be used together. In [4], the following interworking scenarios are presented: 1. PMIPv6 and MIPv6 are used in a hierarchical manner. In this scenario, a mobile node's MIPv6-CoA equals the MN-HoA. 2. Transitioning between PMIPv6 and MIPv6. In this scenario, a mobile node's MIPv6-HoA equals the MN-HoA. Home agent and LMA are co-located. 3. Other co-existence of PMIPv6 and MIPv6 nodes in the same network, where neither MIPv6-CoA nor MIPv6-HoA equals MN-HoA. The home agent and LMA are typically co-located in this scenario and a mobility session of a specific mobile node is handled either exclusively by MIPv6 or exclusively by PMIPv6. This draft intends to document all issues that may arise in any of these interworking scenarios. Issues specific to extensions of PMIPv6 or MIPv6 like IPv4 support, route optimization, MONAMI6 or NEMO etc. are currently out of scope of this document. Solutions for the issues are currently out of scope as well and may be specified in future versions of this document or in a companion document. However, note that some of the interworking issues may be solvable by (pre-)configuration or may be handled at system-level by other SDOs. Weniger & Velev Expires October 22, 2007 [Page 4] Internet-Draft PMIPv6-MIPv6 interworking issues April 2007 3. List of PMIPv6-MIPv6 interworking issues 3.1. Issue #1: Mobility mode selection This issue can arise in all interworking scenarios. [3] discusses that a MAG shall be able to announce the visited prefix to a MIPv6- enabled node instead of the home prefix, so that the mobile node can use MIPv6 to manage the mobility by itself. The issue is how the MAG can figure out which prefix to announce. 3.2. Issue #2: MIPv6 de-registration Binding Update deletes PMIPv6 binding cache entry When the mobile node moves from a MIPv6 foreign network to the PMIPv6 home domain in scenario 2, the MAG registers the mobile node at the LMA by sending a Proxy Binding Update. Subsequently, the LMA updates the mobile node's binding cache entry with the MAG address and the MAG emulates the mobile node's home link. Upon detection of the home link, the mobile node will send a de-registration Binding Update to its home agent. According to [2], the home agent would delete the binding cache entry after accepting the de-registration Binding Update, i.e., it would delete the proxy binding cache entry that was just established by the MAG. Hence, packets arriving at the LMA and destined for the mobile node would not be forwarded to the mobile node anymore. 3.3. Issue #3: Race condition between Binding Update and Proxy Binding Update messages There are two variants of this issue, which apply to scenario 1 and 2, respectively. The fundamental reason for this issue is that MIPv6 and PMIPv6 use different mechanisms for handling re-ordering of registration messages and that they are sent by different entities. Whereas Binding Update messages are ordered by a sequence numbers and sent by the mobile node, Proxy Binding Update messages are ordered by a timestamp option and sent by MAGs. The first variant of the issue can occur in scenario 2. Let's assume the mobile performs a handover from a MAG1 to a MAG2 in its PMIP home domain and shortly thereafter the mobile node moves out of the PMIP domain to an AR, where it configures a new MIPv6-CoA and sends a Binding Update message to its home agent. If now the Proxy Binding Update message from MAG2 is delayed so that it reaches the LMA after the Binding Update, the binding cache entry at the LMA would wrongly point to MAG2. Unless a new Binding Update is sent by the mobile node, packets are not forwarded to the mobile node, since the mobile node has already left MAG2. This may result in a significant packet loss. A similar situation can occur if the mobile node moves from Weniger & Velev Expires October 22, 2007 [Page 5] Internet-Draft PMIPv6-MIPv6 interworking issues April 2007 one AR to another and shortly thereafter enters the PMIP home domain. A second variant of this issue can occur in scenario 1. When the mobile node enters a PMIP domain, it may configure a MIPv6-CoA and register this at its home agent before the Proxy Binding Update sent by the MAG reaches the LMA. This can happen, e.g., if the home prefix is announced to the mobile node before the MAG sends the corresponding Proxy Binding Update. In such case, packets arriving at the LMA are not forwarded to the mobile node until the Proxy Binding Update is received at the LMA, which may result in some packet loss. 3.4. Issue #4: Mismatch of binding cache lookup key MIPv6 uses the home address as lookup key for the binding cache, whereas PMIPv6 uses the NAI as lookup key. In some situations, the LMA may not even know the mobile node's home address. Hence, the LMA or home agent in scenario 2 may not be able to update the same binding cache entry when receiving both Binding Update and Proxy Binding Update messages. Consequently, two different binding cache entries for the same node may be created by the LMA or home agent, which may result in ambiguous forwarding entries and significant packet loss. 3.5. Issue #5: Use of wrong home agent or LMA after handover This issues can arise in scenario 2 when multiple home agents and LMAs are deployed on the home link. If the mobile node moves from a MIPv6 foreign network to the PMIP home domain, the MAG must send the Proxy Binding Update to the particular LMA that is co-located with the home agent which maintains the active binding cache entry of the mobile node. If a different LMA is assigned to the MAG, packets addressed to the mobile node's home address do not reach the mobile node anymore. Similarly, if the mobile node moves from the PMIP home domain to a MIPv6 foreign network, the mobile node must send the Binding Update to the particular home agent that is co-located with the LMA which maintains the active proxy binding cache entry of the mobile node. If the mobile node selects a different home agent, packets addressed to the mobile node's home address do not reach the mobile node. 3.6. Issue #6: Redirection attack against mobile nodes outside PMIP domain due to compromised MAG A MAG authorized to update the LMA's binding cache entry can update the entry of any mobile node registered at this LMA by sending a Proxy Binding Update with the mobile node's NAI. In deployment scenarios where an authorized MAG can be compromised by an attacker, Weniger & Velev Expires October 22, 2007 [Page 6] Internet-Draft PMIPv6-MIPv6 interworking issues April 2007 the attacker can redirect traffic for any mobile node in the PMIP domain to itself. Note that the mobile node does not need to be attached to the compromised MAG to allow this attack, i.e., this can be an off-path attack. In scenario 2, this threat is extended to MIPv6, because an authorized MAG must be able to modify a MIPv6 binding cache entry. Consequently, a compromised MAG can redirect traffic to itself which is destined for mobile nodes located outside the PMIP domain. Weniger & Velev Expires October 22, 2007 [Page 7] Internet-Draft PMIPv6-MIPv6 interworking issues April 2007 4. Security Considerations This document only discusses issues that arise when combining two protocols. It does not propose any new mechanisms that require security considerations. Weniger & Velev Expires October 22, 2007 [Page 8] Internet-Draft PMIPv6-MIPv6 interworking issues April 2007 5. Acknowledgements We would like to thank everybody that contributed to compiling the list of issue presented in this document. Many of the issues were presented by Gerardo Giaretta at the MIP6 WG during IETF#68 in Prague. The scenarios and some of the issues were mentioned by the authors of [3] and [4] in their documents or on the mailing list. Weniger & Velev Expires October 22, 2007 [Page 9] Internet-Draft PMIPv6-MIPv6 interworking issues April 2007 6. References 6.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [3] Gundave, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-00 (work in progress), April 2007. 6.2. Informative References [4] Devarapalli, V., Gundave, S., Chowdhury, K., and A. Muhanna, "Proxy Mobile IPv6 and Mobile IPv6 interworking", draft-devarapalli-netlmm-pmipv6-mipv6-00 (work in progress), April 2007. Weniger & Velev Expires October 22, 2007 [Page 10] Internet-Draft PMIPv6-MIPv6 interworking issues April 2007 Authors' Addresses Kilian A. Weniger Panasonic R&D Center Germany Monzastr. 4c Langen 63225 Germany Email: kilian.weniger@eu.panasonic.com Genadi Velev Panasonic R&D Center Germany Monzastr. 4c Langen 63225 Germany Email: genadi.velev@eu.panasonic.com Weniger & Velev Expires October 22, 2007 [Page 11] Internet-Draft PMIPv6-MIPv6 interworking issues April 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Weniger & Velev Expires October 22, 2007 [Page 12]