idnits 2.17.1 draft-weniger-netlmm-pmipv6-mipv6-issues-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 281. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 292. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 299. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 305. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 20, 2007) is 6215 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3775 (ref. '2') (Obsoleted by RFC 6275) == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-proxymip6-00 == Outdated reference: A later version (-01) exists of draft-devarapalli-netlmm-pmipv6-mipv6-00 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETLMM Working Group K. Weniger 3 Internet-Draft G. Velev 4 Expires: October 22, 2007 Panasonic 5 April 20, 2007 7 Proxy Mobile IPv6 and Mobile IPv6 interworking issues 8 draft-weniger-netlmm-pmipv6-mipv6-issues-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on October 22, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document discusses issues that may arise if Proxy Mobile IPv6 42 and Mobile IPv6 are used together. Solutions for those issues are 43 currently out of scope. The purpose of this document is to agree on 44 a comprehensive list of interworking issues and to trigger the 45 discussion of solutions. 47 Table of Contents 49 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 3. List of PMIPv6-MIPv6 interworking issues . . . . . . . . . . . 5 52 3.1. Issue #1: Mobility mode selection . . . . . . . . . . . . 5 53 3.2. Issue #2: MIPv6 de-registration Binding Update deletes 54 PMIPv6 binding cache entry . . . . . . . . . . . . . . . . 5 55 3.3. Issue #3: Race condition between Binding Update and 56 Proxy Binding Update messages . . . . . . . . . . . . . . 5 57 3.4. Issue #4: Mismatch of binding cache lookup key . . . . . . 6 58 3.5. Issue #5: Use of wrong home agent or LMA after handover . 6 59 3.6. Issue #6: Redirection attack against mobile nodes 60 outside PMIP domain due to compromised MAG . . . . . . . . 6 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 63 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 65 6.2. Informative References . . . . . . . . . . . . . . . . . . 10 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 67 Intellectual Property and Copyright Statements . . . . . . . . . . 12 69 1. Terminology 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in [1]. 75 Furthermore, the terminology defined in [2] and [3] is used. 77 2. Introduction 79 The NETLMM WG is standardizing Proxy Mobile IPv6 [3], a Mobile IPv6- 80 based protocol for localized mobility management. This protocol 81 allows the network to manage the mobility of mobile nodes, e.g., to 82 enable IP mobility of nodes that do not implement Mobile IPv6. There 83 are various scenarios, in which Mobile IPv6 (MIPv6) [2] and Proxy 84 Mobile IPv6 (PMIPv6) can be used together. In [4], the following 85 interworking scenarios are presented: 87 1. PMIPv6 and MIPv6 are used in a hierarchical manner. In this 88 scenario, a mobile node's MIPv6-CoA equals the MN-HoA. 90 2. Transitioning between PMIPv6 and MIPv6. In this scenario, a 91 mobile node's MIPv6-HoA equals the MN-HoA. Home agent and LMA 92 are co-located. 94 3. Other co-existence of PMIPv6 and MIPv6 nodes in the same network, 95 where neither MIPv6-CoA nor MIPv6-HoA equals MN-HoA. The home 96 agent and LMA are typically co-located in this scenario and a 97 mobility session of a specific mobile node is handled either 98 exclusively by MIPv6 or exclusively by PMIPv6. 100 This draft intends to document all issues that may arise in any of 101 these interworking scenarios. Issues specific to extensions of 102 PMIPv6 or MIPv6 like IPv4 support, route optimization, MONAMI6 or 103 NEMO etc. are currently out of scope of this document. Solutions for 104 the issues are currently out of scope as well and may be specified in 105 future versions of this document or in a companion document. 106 However, note that some of the interworking issues may be solvable by 107 (pre-)configuration or may be handled at system-level by other SDOs. 109 3. List of PMIPv6-MIPv6 interworking issues 111 3.1. Issue #1: Mobility mode selection 113 This issue can arise in all interworking scenarios. [3] discusses 114 that a MAG shall be able to announce the visited prefix to a MIPv6- 115 enabled node instead of the home prefix, so that the mobile node can 116 use MIPv6 to manage the mobility by itself. The issue is how the MAG 117 can figure out which prefix to announce. 119 3.2. Issue #2: MIPv6 de-registration Binding Update deletes PMIPv6 120 binding cache entry 122 When the mobile node moves from a MIPv6 foreign network to the PMIPv6 123 home domain in scenario 2, the MAG registers the mobile node at the 124 LMA by sending a Proxy Binding Update. Subsequently, the LMA updates 125 the mobile node's binding cache entry with the MAG address and the 126 MAG emulates the mobile node's home link. Upon detection of the home 127 link, the mobile node will send a de-registration Binding Update to 128 its home agent. According to [2], the home agent would delete the 129 binding cache entry after accepting the de-registration Binding 130 Update, i.e., it would delete the proxy binding cache entry that was 131 just established by the MAG. Hence, packets arriving at the LMA and 132 destined for the mobile node would not be forwarded to the mobile 133 node anymore. 135 3.3. Issue #3: Race condition between Binding Update and Proxy Binding 136 Update messages 138 There are two variants of this issue, which apply to scenario 1 and 139 2, respectively. The fundamental reason for this issue is that MIPv6 140 and PMIPv6 use different mechanisms for handling re-ordering of 141 registration messages and that they are sent by different entities. 142 Whereas Binding Update messages are ordered by a sequence numbers and 143 sent by the mobile node, Proxy Binding Update messages are ordered by 144 a timestamp option and sent by MAGs. 146 The first variant of the issue can occur in scenario 2. Let's assume 147 the mobile performs a handover from a MAG1 to a MAG2 in its PMIP home 148 domain and shortly thereafter the mobile node moves out of the PMIP 149 domain to an AR, where it configures a new MIPv6-CoA and sends a 150 Binding Update message to its home agent. If now the Proxy Binding 151 Update message from MAG2 is delayed so that it reaches the LMA after 152 the Binding Update, the binding cache entry at the LMA would wrongly 153 point to MAG2. Unless a new Binding Update is sent by the mobile 154 node, packets are not forwarded to the mobile node, since the mobile 155 node has already left MAG2. This may result in a significant packet 156 loss. A similar situation can occur if the mobile node moves from 157 one AR to another and shortly thereafter enters the PMIP home domain. 159 A second variant of this issue can occur in scenario 1. When the 160 mobile node enters a PMIP domain, it may configure a MIPv6-CoA and 161 register this at its home agent before the Proxy Binding Update sent 162 by the MAG reaches the LMA. This can happen, e.g., if the home 163 prefix is announced to the mobile node before the MAG sends the 164 corresponding Proxy Binding Update. In such case, packets arriving 165 at the LMA are not forwarded to the mobile node until the Proxy 166 Binding Update is received at the LMA, which may result in some 167 packet loss. 169 3.4. Issue #4: Mismatch of binding cache lookup key 171 MIPv6 uses the home address as lookup key for the binding cache, 172 whereas PMIPv6 uses the NAI as lookup key. In some situations, the 173 LMA may not even know the mobile node's home address. Hence, the LMA 174 or home agent in scenario 2 may not be able to update the same 175 binding cache entry when receiving both Binding Update and Proxy 176 Binding Update messages. Consequently, two different binding cache 177 entries for the same node may be created by the LMA or home agent, 178 which may result in ambiguous forwarding entries and significant 179 packet loss. 181 3.5. Issue #5: Use of wrong home agent or LMA after handover 183 This issues can arise in scenario 2 when multiple home agents and 184 LMAs are deployed on the home link. If the mobile node moves from a 185 MIPv6 foreign network to the PMIP home domain, the MAG must send the 186 Proxy Binding Update to the particular LMA that is co-located with 187 the home agent which maintains the active binding cache entry of the 188 mobile node. If a different LMA is assigned to the MAG, packets 189 addressed to the mobile node's home address do not reach the mobile 190 node anymore. Similarly, if the mobile node moves from the PMIP home 191 domain to a MIPv6 foreign network, the mobile node must send the 192 Binding Update to the particular home agent that is co-located with 193 the LMA which maintains the active proxy binding cache entry of the 194 mobile node. If the mobile node selects a different home agent, 195 packets addressed to the mobile node's home address do not reach the 196 mobile node. 198 3.6. Issue #6: Redirection attack against mobile nodes outside PMIP 199 domain due to compromised MAG 201 A MAG authorized to update the LMA's binding cache entry can update 202 the entry of any mobile node registered at this LMA by sending a 203 Proxy Binding Update with the mobile node's NAI. In deployment 204 scenarios where an authorized MAG can be compromised by an attacker, 205 the attacker can redirect traffic for any mobile node in the PMIP 206 domain to itself. Note that the mobile node does not need to be 207 attached to the compromised MAG to allow this attack, i.e., this can 208 be an off-path attack. In scenario 2, this threat is extended to 209 MIPv6, because an authorized MAG must be able to modify a MIPv6 210 binding cache entry. Consequently, a compromised MAG can redirect 211 traffic to itself which is destined for mobile nodes located outside 212 the PMIP domain. 214 4. Security Considerations 216 This document only discusses issues that arise when combining two 217 protocols. It does not propose any new mechanisms that require 218 security considerations. 220 5. Acknowledgements 222 We would like to thank everybody that contributed to compiling the 223 list of issue presented in this document. Many of the issues were 224 presented by Gerardo Giaretta at the MIP6 WG during IETF#68 in 225 Prague. The scenarios and some of the issues were mentioned by the 226 authors of [3] and [4] in their documents or on the mailing list. 228 6. References 230 6.1. Normative References 232 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 233 Levels", BCP 14, RFC 2119, March 1997. 235 [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 236 IPv6", RFC 3775, June 2004. 238 [3] Gundave, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. 239 Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-00 (work 240 in progress), April 2007. 242 6.2. Informative References 244 [4] Devarapalli, V., Gundave, S., Chowdhury, K., and A. Muhanna, 245 "Proxy Mobile IPv6 and Mobile IPv6 interworking", 246 draft-devarapalli-netlmm-pmipv6-mipv6-00 (work in progress), 247 April 2007. 249 Authors' Addresses 251 Kilian A. Weniger 252 Panasonic R&D Center Germany 253 Monzastr. 4c 254 Langen 63225 255 Germany 257 Email: kilian.weniger@eu.panasonic.com 259 Genadi Velev 260 Panasonic R&D Center Germany 261 Monzastr. 4c 262 Langen 63225 263 Germany 265 Email: genadi.velev@eu.panasonic.com 267 Full Copyright Statement 269 Copyright (C) The IETF Trust (2007). 271 This document is subject to the rights, licenses and restrictions 272 contained in BCP 78, and except as set forth therein, the authors 273 retain all their rights. 275 This document and the information contained herein are provided on an 276 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 277 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 278 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 279 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 280 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 281 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 283 Intellectual Property 285 The IETF takes no position regarding the validity or scope of any 286 Intellectual Property Rights or other rights that might be claimed to 287 pertain to the implementation or use of the technology described in 288 this document or the extent to which any license under such rights 289 might or might not be available; nor does it represent that it has 290 made any independent effort to identify any such rights. Information 291 on the procedures with respect to rights in RFC documents can be 292 found in BCP 78 and BCP 79. 294 Copies of IPR disclosures made to the IETF Secretariat and any 295 assurances of licenses to be made available, or the result of an 296 attempt made to obtain a general license or permission for the use of 297 such proprietary rights by implementers or users of this 298 specification can be obtained from the IETF on-line IPR repository at 299 http://www.ietf.org/ipr. 301 The IETF invites any interested party to bring to its attention any 302 copyrights, patents or patent applications, or other proprietary 303 rights that may cover technology that may be required to implement 304 this standard. Please address the information to the IETF at 305 ietf-ipr@ietf.org. 307 Acknowledgment 309 Funding for the RFC Editor function is provided by the IETF 310 Administrative Support Activity (IASA).