idnits 2.17.00 (12 Aug 2021) /tmp/idnits24136/draft-sdecugis-mext-kbit-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 18. -- Found old boilerplate from RFC 3978, Section 5.2b on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 435. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 446. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 453. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 459. -- The document has an RFC 3978 Section 5.2(b) Derivative Works Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (January 15, 2008) is 5240 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.narten-iana-considerations-rfc2434bis' is defined on line 384, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 390, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 393, but no explicit reference was found in the text == Outdated reference: draft-narten-iana-considerations-rfc2434bis has been published as RFC 5226 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Decugis 3 Internet-Draft University of Tokyo 4 Intended status: Informational January 15, 2008 5 Expires: July 18, 2008 7 Issues of the Key Management Mobility Capability (K) flag in Mobile 8 IPv6. 9 draft-sdecugis-mext-kbit-issues-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 This document may not be modified, and derivative works of it may not 18 be created. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on July 18, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 Mobile IPv6 specification (RFC 3775) introduces a flag called "Key 45 Management Mobility Capability (K)" that is used during home 46 registration procedure. This document describes the behavior of 47 implementations when the capability is supported or not. The purpose 48 of this description is to highlight the expected behavior of 49 implementations at the end of home registration process with regards 50 to the exchanged (K) flag value. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 1.2. Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.3. Dynamic keying . . . . . . . . . . . . . . . . . . . . . . 3 58 1.4. Movement . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Implementation dependent behavior . . . . . . . . . . . . . . 4 60 2.1. Local address is not usable . . . . . . . . . . . . . . . 4 61 2.2. Unexpected source address . . . . . . . . . . . . . . . . 4 62 3. Description of movement and consequences . . . . . . . . . . . 5 63 3.1. CASE1: No support for movement. . . . . . . . . . . . . . 6 64 3.1.1. MN sends next IKE message . . . . . . . . . . . . . . 6 65 3.1.2. HA sends next IKE message . . . . . . . . . . . . . . 6 66 3.2. CASE2: Only MN's IKE session is updated. . . . . . . . . . 7 67 3.2.1. MN sends next IKE message . . . . . . . . . . . . . . 7 68 3.2.2. HA sends next IKE message . . . . . . . . . . . . . . 7 69 3.3. CASE3: Only HA's IKE session is updated. . . . . . . . . . 7 70 3.3.1. MN sends next IKE message . . . . . . . . . . . . . . 7 71 3.3.2. HA sends the next IKE message . . . . . . . . . . . . 8 72 3.4. CASE4: Both peers update the IKE session . . . . . . . . . 8 73 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 79 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 Intellectual Property and Copyright Statements . . . . . . . . . . 11 83 1. Introduction 85 This introduction briefly presents the use of dynamic keying with 86 Mobile IPv6, and the exact meaning of the 'K' flag in BU/BA messages. 87 Previous knowledge of the Mobile IPv6 [RFC3775], IPsec [RFC4301], and 88 IKEv2 [RFC4306] [RFC4877] RFCs is highly recommended. 90 This document mainly deals with IKEv2 protocol, but it applies to IKE 91 also with very few differences. 93 1.1. Requirements Language 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC 2119 [RFC2119]. 99 1.2. Mobile IPv6 101 Mobile IPv6 provides the ability for a node (called "Mobile Node", 102 MN) to be reachable at a permanent IPv6 address (its "Home Address", 103 HoA) while its point of attachment to the network is changing (the 104 temporary IPv6 address is called the "Care-of Address", CoA). One of 105 the routers serving the prefix of the HoA has a special role in the 106 mobility (this router is called the "Home Agent", HA.) Basically, 107 the MN registers its CoA to its HA, then the traffic directed to the 108 HoA is tunneled to the MN at its CoA. The correspondents can always 109 use the HoA to reach the MN. 111 1.3. Dynamic keying 113 Mobile IPv6 also makes mandatory the use of IPsec to protect the 114 messages (Binding Update, Binding Acknowledgement -- BU / BA) 115 involved during the MN's registration with its HA. Dynamic keying 116 represents the situation where a Key Management Protocol (such as IKE 117 or IKEv2) is used to negotiate the Security Association ("SA") pair 118 that will protect the BU/BA exchange and optionally other messages. 119 We can distinguish two steps in the KMP exchanges. First, the peers 120 negotiate a secured channel ("IKE_SA"), based on some trust mechanism 121 (shared key, certificates, ...). Then, using this secured channel, 122 the peers can negotiate the SA parameters for protecting the BU/BA 123 and optionally other SA parameters for other kinds of traffic. Since 124 the BU/BA exchange has not yet been completed when the SA are 125 negotiated, the HoA cannot be used, and therefore the CoA is used for 126 the negotiation of the IKE_SA on the MN side. The child SA (the 127 IPsec SA that protects the BU/BA) is established between the HoA and 128 the HA. 130 1.4. Movement 132 When the MN changes its CoA, the IPsec rules are updated to reflect 133 this change. For the transport-mode SA, there is no update needed 134 since the SA are established between the HoA and the HA. The tunnel- 135 mode SA and SP entries MUST be updated, as required by RFC 3775. The 136 IKE_SA (used only to protect IKE messages) endpoints may or may not 137 be updated. The "K flag" as discussed in this document is meant to 138 represent the ability of the peer to update the IKE_SA endpoints. 140 2. Implementation dependent behavior 142 In order to describe properly the implementation behavior, we have to 143 make some assumptions on the reaction to some events, when this 144 reaction is not clearly defined by a RFC. 146 2.1. Local address is not usable 148 When an IKE session is established, the IKE module stores both the 149 local and remote IPv6 addresses of this session. In Mobile IPv6, it 150 may happen that the local address is not available anymore. In this 151 case, if a new IKE message is to be sent using this session, the 152 implementation may have two different behaviors, depending if a 153 fallback mechanism is available or not. 155 o It may just fail to send the message, and consider the IKE session 156 as dead. It means that the IKE session is removed, as well as 157 dependent SA. Next time an ACQUIRE message is received, a new IKE 158 session will be established. How the source address will be 159 determined is outside the scope of this document. This behavior 160 will be later referenced as IMPL_1A. 162 o It may otherwise try to use another available address as the 163 source of the message. Note that the HoA MUST NOT be used in this 164 case. This behavior will be later referenced as IMPL_1B. Note 165 that in the case where the IKE module is able to determine the 166 correct CoA to use, then we can assume that the module has the Key 167 Management Mobility Capability. 169 2.2. Unexpected source address 171 Once an IKE session is established, the IKE module may receive an IKE 172 message with a source address different from the address that was 173 stored in the IKE session. Once again we may have different 174 implementation behaviors. 176 o The IKE module may choose to simply discard the message. Even 177 though there is no assumption in the RFC about the source address 178 of the message, nothing forbids this behavior either. It can be 179 used as a protection against some DoS attacks, for example. This 180 behavior will be referenced as IMPL_2A. 182 o More likely, the IKE module will process the message. In this 183 case, according to IKEv2 specification, the reply MUST be sent to 184 the source address of the message. This new address additionally 185 may or may not be stored in the IKE session, to be used next time 186 a message has to be sent to the remote peer. This behavior will 187 be referenced as IMPL_2B. Note that since the outer IP source 188 address is not protected, it is not recommended to store this 189 address. 191 3. Description of movement and consequences 193 For the remaining of this document, we are considering the following 194 initial situation: 196 MN is on a Foreign Link 1 (with CoA1) and registered to its HA. 197 The following SA are established: 199 * IKE_SA established between CoA1 and HA 201 * SA1 (transport) between HoA and HA. 203 * SA2 (tunnel) between CoA1 and HA. 205 Then MN moves to Foreign Link 2 with CoA2. The MIPv6 module on MN 206 detects the movement and sends a new BU to its HA, protected by 207 SA1. HA replies a BA. SA2 is updated on MN and on HA, and now 208 established between CoA2 and HA. 210 Now we will consider the following situations. "k=0" means that the 211 change of IP address of the MN is not notified to the IKE session in 212 IKE module. "k=1" means that the IKE session is updated with the new 213 CoA. 215 +-------------------+ 216 | MN | 217 +---------+---------+ 218 | k = 0 | k = 1 | 219 +--------------+---------+---------+ 220 | | k = 0 | CASE1 | CASE2 | 221 | HA +-------+---------+---------+ 222 | | k = 1 | CASE3 | CASE4 | 223 +------+-------+---------+---------+ 225 Matrix of situations. 227 Figure 1 229 3.1. CASE1: No support for movement. 231 In this case, neither MN nor HA update their IKE session after 232 movement. 234 3.1.1. MN sends next IKE message 236 We are now considering the case where MN needs to send the next IKE 237 message. This is more likely to happen, since MN is the initiator of 238 IKE session. 240 o If MN behaves as described in IMPL_1A, then the IKE session is 241 destroyed on MN side, with consequence that the SA (SA1 and SA2) 242 are also destroyed (immediately in IKEv2, after expiry in IKE). 243 In this case, the upper-layer traffic that was protected by SA2 is 244 interrupted. HA is not notified, and will not be able to send 245 anything to the MN until a new IKE session is established, and SA1 246 and SA2 renegotiated. This will happen on next ACQUIRE message on 247 MN (provided that the IKE module is able to pickup the proper IP 248 address.) 250 o If MN behaves as described in IMPL_1B, then the situation is the 251 same as in CASE2, as long as the packet reaches the HA. 252 Otherwise, for example if the chosen IP address belongs to a 253 private network, then the IKE module will have to timeout before 254 cleaning the IKE session and dependent SA. 256 3.1.2. HA sends next IKE message 258 It may also happen that HA needs to send an IKE message to the MN (to 259 check for its liveness for example.) In that case, since the message 260 is sent to the old CoA, no answer will be received and the IKE 261 session will be deleted after a timeout (and the SA in the case of 262 IKEv2). Since MN is not notified of the change, it may continue to 263 send encrypted packets which will be lost. This situation will last 264 until the MN initiates a new IKE exchange -- which could take a long 265 time, during which the upper-layer flow is interrupted. 267 3.2. CASE2: Only MN's IKE session is updated. 269 3.2.1. MN sends next IKE message 271 In this situation, the MN is able to send the correct message to HA. 272 If HA behaves as described in IMPL_2A, the IKE message is ignored, 273 resulting in the IKE session being destroyed after a timeout on MN. 274 The HA will not be able to send anything to the MN until MN initiates 275 a new IKE session. It's the same as in CASE1. 277 If the HA behaves as described in IMPL_2B, the IKE message is 278 received correctly and the IKE session survives. Depending on 279 whether the new MN CoA is saved in the IKE session on HA's side, the 280 situation described here bellow when HA needs to send a message can 281 occur later or otherwise we are in the same situation as in CASE4 (no 282 problem). 284 3.2.2. HA sends next IKE message 286 Since the HA IKE session does not have the new CoA of the MN, the IKE 287 message sent by HA receives no reply. This will result in HA 288 detecting the session is broken after a timeout, and the session 289 being removed. It's the same situation as in CASE1, the interruption 290 in upper-layer flow will last until the MN has to send a new IKE 291 message, detect the problem, and establish a new IKE session and 292 dependent SA, which can last very long time. 294 3.3. CASE3: Only HA's IKE session is updated. 296 3.3.1. MN sends next IKE message 298 As in CASE1, we have two possibilities for MN. In case it behaves as 299 described in IMPL_1A, we have the same consequences, the IKE session 300 is destroyed on MN, and child SAs also. The HA is not notified. In 301 case the MN behaves as described in IMPL_1B, the IKE message is sent 302 using another IP source address (but not the HoA). In this case, if 303 the CoA is selected, all goes well as described in CASE4. If another 304 address is selected, the packet may or may not reach the HA, or be 305 rejected by the HA (IMPL_2A or IMPL_2B.) If the HA accepts the 306 packet, then we are in the same situation as CASE4 (all OK, no 307 interruption in upper-layer flow.) Otherwise, the MN will let the 308 session timeout and discard the SA. The upper-layer flow is 309 interrupted until a new IKE session is negotiated. 311 3.3.2. HA sends the next IKE message 313 Here the behavior depends on if the MN's IKE module behaves as 314 described in IMPL_2A or IMPL_2B. In the first case, then the HA will 315 not receive a reply, and delete the IKE session after a timeout. The 316 upper-layer flow is broken until MN has to send a new IKE message -- 317 very long time. In the other case (MN behaves as described in 318 IMPL_2B), HA receives a reply and the IKE session is not broken. In 319 that case, the upper-layer flow is not interrupted. 321 3.4. CASE4: Both peers update the IKE session 323 In this case, the movement is transparent to IKE modules. Note that 324 there may be issues in the timing of events, in the case where the 325 movement occurs during an IKE exchange, but it is outside the scope 326 of this document. 328 4. Conclusion 330 As we have seen previously, only the situation where both MN and HA 331 update their IKE session with the new Care-of Address will result in 332 smooth operation. If the HA does not update the IKE session 333 endpoints, there is a possibility to be faced with a situation where 334 the upper-layer traffic is interrupted and it will be restored only 335 when MN needs to send a new IKE message, which means very long 336 interruption. If the HA updates its IKE session, but not the MN, the 337 result is better but depending on MN's IKE implementation. 339 The conclusion to this analysis are as follow: 341 o To ensure a smooth operation, we need to have both peers support 342 the migration of their IKE session endpoints. 344 o In other cases, detected thanks to the (K) flag in BU / BA 345 exchanges, then we can avoid very long interruption in upper-layer 346 flow by forcing the deletion of the IKE session and all child SAs 347 after each movement. This avoids the case where HA got rid of the 348 SA and waits for the MN to detect something is going wrong. 350 In addition, the (K) flag is a feature negotiated by the MIPv6 351 module, but representing a capability of the IKE module. It should 352 therefore be negotiated locally between the IKE module and the MIPv6 353 module. 355 As a final note, the recommendation is that the support for migrating 356 the IKE session should be made mandatory, in which case the (K) flag 357 should be deprecated. In case it is not possible, then at least it 358 should be requested that the IKE session is destroyed immediately 359 after the movement is completed, in the case where at least one host 360 does not support IKE session movement. 362 5. Contributors 364 Thanks to Arnaud Ebalard, Shinta Sugimoto and Francis Dupont for 365 their reviews and comments. 367 6. IANA Considerations 369 This memo includes no request to IANA. 371 7. Security Considerations 373 This is not relevant for this draft. 375 8. References 377 8.1. Normative References 379 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 380 Requirement Levels", BCP 14, RFC 2119, March 1997. 382 8.2. Informative References 384 [I-D.narten-iana-considerations-rfc2434bis] 385 Narten, T. and H. Alvestrand, "Guidelines for Writing an 386 IANA Considerations Section in RFCs", 387 draft-narten-iana-considerations-rfc2434bis-08 (work in 388 progress), October 2007. 390 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 391 June 1999. 393 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 394 Text on Security Considerations", BCP 72, RFC 3552, 395 July 2003. 397 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 398 in IPv6", RFC 3775, June 2004. 400 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 401 Internet Protocol", RFC 4301, December 2005. 403 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 404 RFC 4306, December 2005. 406 [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 407 IKEv2 and the Revised IPsec Architecture", RFC 4877, 408 April 2007. 410 Author's Address 412 Sebastien Decugis 413 University of Tokyo 414 Keio University Murai Lab., 144-8 Ogura, Saiwai-ku 415 Kawasaki, Kanagawa 212-0054 416 JP 418 Phone: +81 44 580 1600 419 Email: sdecugis@hongo.wide.ad.jp 421 Full Copyright Statement 423 Copyright (C) The IETF Trust (2008). 425 This document is subject to the rights, licenses and restrictions 426 contained in BCP 78, and except as set forth therein, the authors 427 retain all their rights. 429 This document and the information contained herein are provided on an 430 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 431 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 432 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 433 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 434 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 435 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 437 Intellectual Property 439 The IETF takes no position regarding the validity or scope of any 440 Intellectual Property Rights or other rights that might be claimed to 441 pertain to the implementation or use of the technology described in 442 this document or the extent to which any license under such rights 443 might or might not be available; nor does it represent that it has 444 made any independent effort to identify any such rights. Information 445 on the procedures with respect to rights in RFC documents can be 446 found in BCP 78 and BCP 79. 448 Copies of IPR disclosures made to the IETF Secretariat and any 449 assurances of licenses to be made available, or the result of an 450 attempt made to obtain a general license or permission for the use of 451 such proprietary rights by implementers or users of this 452 specification can be obtained from the IETF on-line IPR repository at 453 http://www.ietf.org/ipr. 455 The IETF invites any interested party to bring to its attention any 456 copyrights, patents or patent applications, or other proprietary 457 rights that may cover technology that may be required to implement 458 this standard. Please address the information to the IETF at 459 ietf-ipr@ietf.org. 461 Acknowledgment 463 Funding for the RFC Editor function is provided by the IETF 464 Administrative Support Activity (IASA).