idnits 2.17.00 (12 Aug 2021) /tmp/idnits24991/draft-sdecugis-mextkbitissues-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 330. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 341. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 348. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 354. -- 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 (December 19, 2007) is 5267 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 279, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 285, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 288, 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 December 19, 2007 5 Expires: June 21, 2008 7 Key Management Mobility Capability (K) flag in Mobile IPv6 BU/BA 8 messages. 9 draft-sdecugis-mextkbitissues-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 June 21, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 Mobile IPv6 specification (RFC 3775) introduces a flag called "Key 45 Management Mobility Capability (K)" to use during the home 46 registration procedure (BU/BA exchange.) This document describes the 47 sequences of events that occur when this flag is not used by the 48 implementation. It also highlights the requirements that this flag 49 puts on the interface between the MIPv6 entity and the IKE entity. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.2. Dynamic keying . . . . . . . . . . . . . . . . . . . . . . 3 56 1.3. Movement . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.4. Requirements Language . . . . . . . . . . . . . . . . . . . 4 58 2. Problem statement . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.1. Scenario 1: HA updates its endpoints (K=1), MN does 60 not (K=0). . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.2. Scenario 2: MN updates its endpoints(K=1), HA does not 62 (K=0). . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 66 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 68 6.2. Informative References . . . . . . . . . . . . . . . . . . 7 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 Intellectual Property and Copyright Statements . . . . . . . . . . 9 72 1. Introduction 74 This introduction presents briefly the Mobile IPv6 dynamic keying, 75 and the exact meaning of the 'K' flag in BU/BA messages. Previous 76 knowledge of the Mobile IPv6 RFC 3775 [RFC3775], IPsec RFC 4301 77 [RFC4301], and IKEv2 RFC 4306 [RFC4306] RFC 4877 [RFC4877] RFCs is 78 highly recommended. 80 1.1. Mobile IPv6 82 Mobile IPv6 provides the ability for a node (called "Mobile Node", 83 MN) to be reachable at a permanent IPv6 address (its "Home Address", 84 HoA) while its point of attachment to the network is changing (the 85 temporary IPv6 address is called the "Care-of Address", CoA). One of 86 the routers serving the prefix of the HoA has a special role in the 87 mobility (this router is called the "Home Agent", HA.) Basically, 88 the MN registers its CoA to its HA, then the traffic directed to the 89 HoA is tunneled to the MN at its CoA. The correspondents can always 90 use the HoA to reach the MN. 92 1.2. Dynamic keying 94 Mobile IPv6 also makes mandatory the use of IPsec to protect the 95 messages (Binding Update, Binding Acknowledgement -- BU / BA) 96 involved during the MN's registration to its HA. Dynamic keying 97 represents the situation where a Key Management Protocol (such as IKE 98 or IKEv2) is used for negotiating the Security Association ("SA") 99 pair that will protect the BU/BA exchange (and optionnally other 100 messages). We can distinguish two steps in the KMP exchanges. 101 First, the peers negociate a secured channel ("IKE_SA"), based on 102 some trust mechanism (shared key, certificates, ...). Then, using 103 this secured channel, the peers can negociate the SA parameters for 104 protecting the BU/BA and optionnally other traffic. Since the BU/BA 105 exchange has not yet been completed when the SA are negociated, the 106 HoA cannot be used, and therefore the IKE_SA is negociated using the 107 CoA on the MN side. The child SA (the IPsec SA that protects the 108 BU/BA) is established between the HoA and the HA. 110 1.3. Movement 112 When the MN changes its CoA, the IPsec rules are updated to reflect 113 this change. For the transport-mode SA, there is no update needed 114 since the SA are established between the HoA and the HA. The tunnel- 115 mode SA and SP entries must be updated. The IKE_SA (used only to 116 protect IKE messages) endpoints may or may not be updated. The "K 117 flag" as discussed in this document is meant to represent the ability 118 of the peer to update the IKE_SA endpoints. 120 1.4. Requirements Language 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 2. Problem statement 128 It has already been proved that if both peers (MN and HA) behave in 129 the same way with regards to updating their IKE_SA endpoints or not, 130 then the sequence of signaling messages on movements results in 131 smooth operation. 133 This document will consider the situation where the peers behave 134 differently (one peer updates the IKE_SA endpoint, the other does 135 not.) The purpose is to highlight the value of the information 136 negociated through the (K) flag. 138 The initial state for both scenario is as follow: 140 MN is on a Foreign Link 1 (with CoA1) and registered to its HA. 141 We have the following links: 143 * IKE_SA established between CoA1 and HA 145 * SA1 (transport) between HoA and HA. 147 * SA2 (tunnel) between CoA1 and HA. 149 Then MN moves to Foreign Link 2 with CoA2. 151 2.1. Scenario 1: HA updates its endpoints (K=1), MN does not (K=0). 153 Step 1: The BU message is sent using SA1. 155 * SA2 is updated on the MN to CoA2. 157 Step 2: The HA receives the BU. 159 * It updates its IKE_SA remote endpoint 161 * It updates its SA2 remote endpoint. 163 * It sends the BA using SA1. 165 Now, we have two possibilities concerning the next IKE message: 167 1. The MN needs to send an IKE message to the HA. 168 In this case, since the IKE_SA source address is not valid 169 anymore, we have to establish a new IKE_SA using the CoA2 170 address. This is the same behavior as case K=0 for both hosts. 171 Instead of establishing a new IKE_SA, the MN may choose to use 172 another available address as source address to send the IKE 173 message. This must be done with care, since the HoA must not be 174 used. In that case it is the same as case K=1 for both hosts. 176 2. The HA needs to send an IKE message to the MN. 177 In this case, the MN receives the message. It may choose to 178 update its IKE_SA local endpoint according to the dst address in 179 the message, in which case the exchange will succeed. It may 180 also choose to discard the message silently. In that case, the 181 HA will end up in being unable to negociate the SA and therefore 182 mark the IKE_SA (and all its CHILD_SA in IKEv2) as dead. 183 Negotiation of a new IKE_SA will happen only when a new ACQUIRE 184 message occurs. 186 Note that the second case is less likely to happen than the first, 187 since the MN is always the initiator of first IKE exchanges and 188 shorter lifetime values should be used for SA on the MN. 190 2.2. Scenario 2: MN updates its endpoints(K=1), HA does not (K=0). 192 Step 1: The BU message is sent using SA1. 194 * SA2 is updated on the MN to CoA2. 196 * IKE_SA is updated on the MN to CoA2. 198 Step 2: The HA receives the BU. 200 * SA2 is updated on the HA. 202 Then, again, we have two possibilities concerning the next IKE 203 message: 205 1. If MN wants to send an IKE message to HA. 206 HA receives a message from a new unknown address, with a valid 207 SPI identifier. Implementation may choose to discard silently 208 the message (to protect against DoS attacks for example). In 209 this case, the MN receives no answer and invalidates the IKE_SA 210 and the dependent SA. New negotiation will have to occur later, 211 which is time-consuming. During this timeframe, upper-layer flow 212 is interrupted. Implementation may also choose to accept the 213 message from the unknown IP address. In that case, the reply 214 will be sent to the new address, and it is equivalent as if the 215 HA had updated the IKE_SA endpoints. 217 2. If HA wants to send an IKE message to MN. 218 It sends the message to the wrong address (CoA1). It results in 219 the IKE_SA (and CHILD_SAs) being invalidated after the timeout 220 (and retries, which may last for some minutes). This situation 221 will prevent the HA from being able to forward packets to the MN 222 and may be complicated to resolve (will need to wait for MN to 223 detect dead peer and re-establish a new IKE_SA). This will 224 result in an even bigger interruption in upper-layer flow. 226 3. Conclusion 228 Here is a summary of the several possibilities in dynamic keying 229 after a movement. 231 o If both MN and HA have the capability of updating the IKE session 232 endpoints, then there is no need to re-create a session after 233 movement and we have no additionnal interuption in the upper-layer 234 flow, but the handover time. 236 o If both peers do not have this ability, then next time an IKE 237 message needs to be exchanged, it will results in creating a new 238 IKE session. In the usual case, we do not need to wait for an IKE 239 timeout, since the MN can not use the old address anymore. 241 o If one peer updates the IKE session endpoint and the other does 242 not, it results in a bad situation where we have to wait for IKE 243 timeout (several minutes) before re-establishing a clean IKE 244 session. Upper-layer traffic may be interrupted during this 245 delay. 247 To ensure smooth operation, when the (K) flag negotiation after BU/BA 248 exchange has shown that the remote peer does not support the IKE 249 session movement, the local host MUST NOT update its IKE session 250 endpoints after a movement. 252 We can shorten the delay by deleting the broken IKE_SA after the 253 movement occurs (after BA has been emitted and received). An 254 implementation SHOULD require this deletion when the remote peer does 255 not support the IKE_SA movement. This would force next message to 256 trigger an ACQUIRE and a new IKE session to be established. 258 Note that if the support for migrating the IKE session is mandatory, 259 as is the support for migrating the tunnel-mode SA, then is 260 simplifies the problem and removes the need for (K) flag. 262 4. IANA Considerations 264 This memo includes no request to IANA. 266 5. Security Considerations 268 This is not relevant for this draft. 270 6. References 272 6.1. Normative References 274 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 275 Requirement Levels", BCP 14, RFC 2119, March 1997. 277 6.2. Informative References 279 [I-D.narten-iana-considerations-rfc2434bis] 280 Narten, T. and H. Alvestrand, "Guidelines for Writing an 281 IANA Considerations Section in RFCs", 282 draft-narten-iana-considerations-rfc2434bis-08 (work in 283 progress), October 2007. 285 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 286 June 1999. 288 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 289 Text on Security Considerations", BCP 72, RFC 3552, 290 July 2003. 292 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 293 in IPv6", RFC 3775, June 2004. 295 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 296 Internet Protocol", RFC 4301, December 2005. 298 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 299 RFC 4306, December 2005. 301 [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 302 IKEv2 and the Revised IPsec Architecture", RFC 4877, 303 April 2007. 305 Author's Address 307 Sebastien Decugis 308 University of Tokyo 309 Keio University Murai Lab., 144-8 Ogura, Saiwai-ku 310 Kawasaki, Kanagawa 212-0054 311 JP 313 Phone: +81 44 580 1600 314 Email: sdecugis@hongo.wide.ad.jp 316 Full Copyright Statement 318 Copyright (C) The IETF Trust (2007). 320 This document is subject to the rights, licenses and restrictions 321 contained in BCP 78, and except as set forth therein, the authors 322 retain all their rights. 324 This document and the information contained herein are provided on an 325 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 326 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 327 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 328 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 329 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 330 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 332 Intellectual Property 334 The IETF takes no position regarding the validity or scope of any 335 Intellectual Property Rights or other rights that might be claimed to 336 pertain to the implementation or use of the technology described in 337 this document or the extent to which any license under such rights 338 might or might not be available; nor does it represent that it has 339 made any independent effort to identify any such rights. Information 340 on the procedures with respect to rights in RFC documents can be 341 found in BCP 78 and BCP 79. 343 Copies of IPR disclosures made to the IETF Secretariat and any 344 assurances of licenses to be made available, or the result of an 345 attempt made to obtain a general license or permission for the use of 346 such proprietary rights by implementers or users of this 347 specification can be obtained from the IETF on-line IPR repository at 348 http://www.ietf.org/ipr. 350 The IETF invites any interested party to bring to its attention any 351 copyrights, patents or patent applications, or other proprietary 352 rights that may cover technology that may be required to implement 353 this standard. Please address the information to the IETF at 354 ietf-ipr@ietf.org. 356 Acknowledgment 358 Funding for the RFC Editor function is provided by the IETF 359 Administrative Support Activity (IASA).