idnits 2.17.1 draft-vogt-mip6-early-binding-updates-00.txt: -(4): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. == 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (February 4, 2004) is 7359 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) -- Looks like a reference, but probably isn't: 'Handover' on line 471 -- Possible downref: Normative reference to a draft: ref. '3' Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group C. Vogt, Ed. 2 Internet-Draft R. Bless 3 Expires: August 4, 2004 M. Doll 4 T. K�fner 5 Univ. of Karlsruhe, Germany 6 February 4, 2004 8 Early Binding Updates for Mobile IPv6 9 draft-vogt-mip6-early-binding-updates-00 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on August 4, 2004. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 The long latency associated with Mobile IPv6's home-address and 40 care-of-address tests can significantly impact delay-sensitive 41 applications. We propose a modified binding-update procedure that 42 evades the latency of both address tests. The modified binding update 43 runs in half, or less, of the time that a standard binding update 44 takes. Moreover, the modified binding update is nearly equivalent to 45 the standard procedure with respect to security, and it increases the 46 resources required at the correspondent node only marginally. The 47 modification is realized as an optional, and fully 48 backward-compatible, extension to Mobile IPv6. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Standard Binding Updates . . . . . . . . . . . . . . . . . . . 6 58 4. Early Binding Updates . . . . . . . . . . . . . . . . . . . . 9 59 4.1 Protocol Specification . . . . . . . . . . . . . . . . . . . . 10 60 4.2 Concurrent Care-of Address Tests . . . . . . . . . . . . . . . 14 61 4.3 Initial Care-of Address Registration . . . . . . . . . . . . . 15 63 5. Efficiency Considerations . . . . . . . . . . . . . . . . . . 16 64 5.1 Standard Binding Updates . . . . . . . . . . . . . . . . . . . 16 65 5.2 Early Binding Updates . . . . . . . . . . . . . . . . . . . . 18 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 68 6.1 Decoupled Address Tests . . . . . . . . . . . . . . . . . . . 21 69 6.2 Concurrent Care-of Address Tests . . . . . . . . . . . . . . . 23 71 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 24 73 8. Protocol Configuration Variables . . . . . . . . . . . . . . . 24 75 References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 79 Intellectual Property and Copyright Statements . . . . . . . . 27 81 1. Introduction 83 Mobility Support for IPv6 [1], or Mobile IPv6, allows a mobile node 84 to change its point of network attachment without loosing 85 higher-level communications connections. A mobile node has a 86 preferably permanent "home address", by means of which the mobile 87 node can be identified. In addition, the mobile node has a "care-of 88 address", which is a topologically correct IP address at the mobile 89 node's current location. The care-of address changes whenever the 90 mobile node moves to a different location. If a mobile node and a 91 correspondent node use route optimization, the correspondent node 92 maintains a "binding" between the mobile node's home address and 93 current care-of address. When the mobile node attaches to a different 94 network, it initiates a "binding update", i.e., it signals to the 95 correspondent node its new care-of address. We assume the application 96 of route optimization in this document. 98 Mobile IPv6 uses a "return routability" procedure to verify a binding 99 update with respect to authenticity and validity. The return 100 routability encompasses two tests: A home-address test authenticates 101 the mobile node. It provides reasonable assurance to the 102 correspondent node that the mobile node is the legitimate owner of 103 the IP address which the mobile node claims to own as its home 104 address. A care-of-address test checks the validity of the new 105 care-of address. It provides reasonable assurance to the 106 correspondent node that the mobile node is reachable through the IP 107 address which the mobile node wishes to register as its care-of 108 address. 110 The return routability requires a minimum of processing resources and 111 state at both the mobile node and the correspondent node. 112 Furthermore, it does not depend on a trusted infrastructure, which 113 would be expensive to build and maintain. A shortfall, however, is 114 that the two address tests, though typically performed in parallel, 115 constitute a considerable fraction of the binding-update latency. 116 Both tests are potentially run over very long distances. This makes 117 it difficult for delay-sensitive applications to hold up service 118 quality when the mobile node changes its point of network attachment. 120 In this document, we propose a strategy, Early Binding Updates, to 121 move both address tests out of the critical period during which a new 122 care-of address cannot yet be used. We find that an Early Binding 123 Update runs in half, or less, of the time that a binding update 124 defined in [1] takes. Moreover, we show that an Early Binding Update 125 is nearly equivalent to the standard procedure with respect to 126 security, and that it increases the resources required at the 127 correspondent node only marginally. To facilitate differentiation, we 128 will henceforth call the binding update defined in [1] a "standard 129 binding update". 131 Early Binding Updates are a minor extension to standard binding 132 updates. They are fully compatible to the binding-update procedure 133 defined in [1], in particular with the return routability. Early 134 Binding Updates use two new messages, both of which have no effect if 135 either communication end-point does not support them. All messages 136 related to standard binding updates remain unchanged and retain their 137 original meaning. We are currently working on a more detailed 138 specification of Early Binding Updates including message formats and 139 additions to [1]. The specification will be published in a future 140 version of this Internet Draft. 142 Section 2 provides a brief overview on Early Binding Updates. The 143 overview is assumed to be sufficient for a hurried reader who does 144 not want to read the in-depth discussion of the subsequent sections. 145 Section 3 is a recap on the standard binding-update procedure defined 146 in [1]. Section 4 provides the details of Early Binding Updates. We 147 analyze the efficiency of Early Binding Updates in Section 5. 148 Implications on security are examined in Section 6. We conclude in 149 Section 7. 151 2. Overview 153 In this section, we briefly describe Early Binding Updates. This 154 section is assumed to be a sufficient survey for a hurried reader. We 155 refer to Section 4 for more details on Early Binding Updates. Section 156 3 provides a recap on standard binding updates. 158 Early Binding Updates are a strategy to move both address test out of 159 the critical period during which a new care-of address cannot yet be 160 used. With Early Binding Updates, a mobile node executes a 161 home-address test whenever a handover is imminent. If handovers 162 cannot be anticipated, the mobile node may periodically repeat the 163 home-address test. Either way, the mobile node has at hand a fresh 164 Home Keygen Token when it changes its point of network attachment, 165 and it does not need to wait for a lengthy home-address test during 166 the binding update. Furthermore, the care-of-address test is executed 167 in parallel with sending data to and from the new care-of address. 168 This way, the mobile node does not need to wait for a lengthy 169 care-of-address test during the binding update either. Note that [1] 170 suggests running both address tests after a handover. However, the 171 mobile node may trigger a home-address test before it moves without 172 violating the protocol procedure. 174 We introduce two new messages: an Early Binding Update message and an 175 Early Binding Acknowledgement message. When the mobile node detects 176 that it has moved to a different network, it configures a new care-of 177 address. The mobile node then sends to the correspondent node an 178 Early Binding Update message in order to tentatively register the new 179 care-of address with the correspondent node. The mobile node just 180 needs a Home Keygen Token to authenticate the Early Binding Update 181 message. The mobile node may request the correspondent node to return 182 an Early Binding Acknowledgement message by raising a flag in the 183 Early Binding Update message. A conservative mobile node would wait 184 for the Early Binding Acknowledgement message before using its new 185 care-of address. An optimistic mobile node would start using its new 186 care-of address as soon as having dispatched the Early Binding Update 187 message. Whether conservative or optimistic, with Early Binding 188 Updates, the mobile node can use its new care-of address about one 189 round-trip time sooner than with standard binding updates. 191 Having sent the Early Binding Update message, the mobile node 192 initiates a care-of-address test as defined in [1]. When the 193 care-of-address test completes, the mobile node sends to the 194 correspondent node a standard Binding Update message as defined in 195 [1]. The Binding Update message is to have the correspondent node 196 change the status of the care-of-address registration from tentative 197 to regular. 199 When the correspondent node receives the Early Binding Update message 200 from the mobile node, it creates a tentative binding-cache entry with 201 the mobile node's new care-of address. The correspondent node uses 202 the mobile node's new care-of address as soon as the binding-cache 203 entry is in place. Thus, with Early Binding Updates, the 204 correspondent node can use the mobile node's new care-of address 205 about one round-trip time sooner than with standard binding updates. 206 A tentative binding-cache entry's lifetime is limited to a few 207 seconds, within which the correspondent node expects the mobile node 208 to run a successful care-of-address test. When the correspondent node 209 receives the Binding Update message, it extends the lifetime of the 210 mobile node's tentative binding-cache entry to the regular lifetime 211 proposed in [1]. The tentative binding-cache entry will be deleted, 212 if the Binding Update message fails to be delivered to the 213 correspondent node during the binding-cache entry's lifetime - which 214 clearly is the case if the mobile node fails to run a successful 215 care-of-address test. Further data packets will then be sent via the 216 mobile node's home agent. 218 Early Binding Updates are a fully backward-compatible extension to 219 the binding-update procedure defined in [1]. All messages related to 220 standard binding updates remain unchanged and retain their original 221 meaning. Moreover, a mobile node may initiate an Early Binding Update 222 without knowing whether or not this optimization is supported by the 223 correspondent node. If the correspondent node does not support Early 224 Binding Updates, the mobile node's Early Binding Update message has 225 no effect, and the binding-update procedure is automatically reduced 226 to the standard procedure. 228 3. Standard Binding Updates 230 This section is a recap on the standard binding-update procedure, 231 which allows a mobile node to register its care-of address with a 232 correspondent node. The procedure is depicted in Figure 1. The 233 complete definition can be found in [1]. 235 Mobile Node Home Agent Correspondent Node 237 ~~~~~ [Handover] 239 Binding Update (1) 240 |-------------------->| 242 Home Test Init (2) 243 |-------------------->|-------------------->| 245 Care-of Test Init (3) 246 |------------------------------------------>| 248 Binding Acknowledgement (4) 249 |<--------------------| 251 Home Test (5) 252 |<--------------------|<--------------------| 254 Care-of Test (6) 255 |<------------------------------------------| 257 Binding Update (7) 258 |------------------------------------------>| 260 Binding Acknowledgement (8) 261 |<------------------------------------------| 263 Figure 1: Standard Binding Update 265 When the mobile node detects that it has moved to a different 266 network, it configures a new care-of address. The mobile node then 267 sends to its home agent a Binding Update message (1). The Binding 268 Update message informs the home agent about the mobile node's new 269 care-of address. It is authenticated by means of an IPsec security 270 association between the mobile node and the home agent. 272 After this, the mobile node sends to the correspondent node two 273 messages in parallel: a Home Test Init message and a Care-of Test 274 Init message. The Home Test Init message (2) is tunneled to the 275 mobile node's home agent, and forwarded on to the correspondent node. 276 The Home Test Init message includes a random Home Init Cookie. The 277 Home Init Cookie will be returned by the correspondent node in the 278 Home Test message. Both the Home Test Init message and the Home Test 279 message are protected by IPsec on the path between the mobile node 280 and the mobile node's home agent. They are unprotected on the path 281 between the mobile node's home agent and the correspondent node. On 282 the latter path, a malicious node may potentially eavesdrop on the 283 Home Init Cookie and return it in a spoofed Home Test message. For 284 this reason, having to return the cookie restricts the sender of the 285 Home Test message to the path between the mobile node's home agent 286 and the correspondent node. The mobile node considers this a 287 sufficient proof that the Home Test message was generated by the 288 correspondent node itself. 290 The Care-of Test Init message (3) does not go through the mobile 291 node's home agent. It takes the direct path to the correspondent 292 node. The Care-of Test Init message includes a random Care-of Init 293 Cookie. The Care-of Init Cookie will be returned by the correspondent 294 node in the Care-of Test message. Both the Care-of Test Init and the 295 Care-of Test messages are not protected by IPsec. A malicious node 296 may potentially eavesdrop on the Care-of Init Cookie and return it in 297 a spoofed Care-of Test message. For this reason, having to return the 298 cookie restricts the sender of the Care-of Test message to the path 299 between the mobile node and the correspondent node. The mobile node 300 considers this a sufficient proof that the Care-of Test message was 301 generated by the correspondent node itself. 303 When the home agent receives the Binding Update message, it registers 304 the mobile node's new care-of address. If the home agent maintains an 305 IPsec tunnel to the mobile node, it also updates the corresponding 306 security association to the new care-of address [2]. The home agent 307 sends back to the mobile node a Binding Acknowledgement message (4) 308 to indicate successful care-of-address registration. The Binding 309 Acknowledgement message is authenticated by means of an IPsec 310 security association between the mobile node and the home agent. 312 When the correspondent node receives the Home Test Init message, it 313 sends back to the mobile node a Home Test message (5). The Home Test 314 message is directed to the mobile node's home address, hence passes 315 the mobile node's home agent. The Home Test message contains a Home 316 Keygen Token, a Home Nonce Index, and the Home Init Cookie copied 317 from the Home Test Init message. The Home Keygen Token will be used 318 by the mobile node when producing the Binding Management Key, as 319 described below. The Home Nonce Index identifies a random value based 320 on which the correspondent node has computed the Home Keygen Token. 321 The mobile node will include the Home Nonce Index in the subsequent 322 Binding Update message to allow the correspondent node to reproduce 323 the Home Keygen Token. 325 Likewise, upon receiving the Care-of Test Init message, the 326 correspondent node sends back to the mobile node a Care-of Test 327 message (6). The Care-of Test message is directed to the mobile 328 node's new care-of address, hence does not pass the mobile node's 329 home agent. The Care-of Test message contains a Care-of Keygen Token, 330 a Care-of Nonce Index, and the Care-of Init Cookie copied from the 331 Care-of Test Init message. The Care-of Keygen Token will be used by 332 the mobile node when producing the Binding Management Key, as 333 described below. The Care-of Nonce Index identifies a random value 334 based on which the correspondent node has computed the Care-of Keygen 335 Token. The mobile node will include the Care-of Nonce Index in the 336 subsequent Binding Update message to allow the correspondent node to 337 reproduce the Care-of Keygen Token. 339 The mobile node uses the Home Keygen Token and the Care-of Keygen 340 Token to produce a secret key, the Binding Management Key, shared 341 with the correspondent node. The Binding Management Key is a one-way 342 hash on the concatenation of the Home Keygen Token and the Care-of 343 Keygen Token. 345 The mobile node then generates a Binding Update message (7) to be 346 sent to the correspondent node. The Binding Update message contains a 347 message-authentication code produced with the Binding Management Key. 348 It also contains the Home Nonce Index and the Care-of Nonce Index. 349 The mobile node may request the correspondent node to return a 350 Binding Acknowledgement message by raising the A-flag in the Binding 351 Update message. A conservative mobile node would wait for the Binding 352 Acknowledgement message before using its new care-of address. An 353 optimistic mobile node would start using its new care-of address as 354 soon as having dispatched the Binding Update message. 356 When the correspondent node receives the Binding Update message, it 357 can reproduce the Home Keygen Token and the Care-of Keygen Token with 358 the help of the two nonce indices. The tokens, in turn, allow the 359 correspondent node to reproduce the Binding Management Key. The 360 correspondent node can then compute what the message-authentication 361 code in the Binding Update message should look like. If the result 362 matches the message-authentication code in the Binding Update 363 message, the correspondent node can assume two things. First, the 364 mobile node must have received the Home Keygen Token in order to 365 construct the Binding Management Key with which the 366 message-authentication code was produced. Therefore, the mobile node 367 is the legitimate owner of the home address with high probability, 368 since the Home Keygen Token was sent, as part of the Home Test 369 message, to the mobile node's home address. Second, the mobile node 370 must have received the Care-of Keygen Token in order to construct the 371 Binding Management Key. Hence, the mobile node is apparently 372 reachable through the new care-of address, since the Care-of Keygen 373 Token was sent, as part of the Care-of Test message, to the mobile 374 node's care-of address. Beyond this, the message-authentication code 375 validates the Binding Update message's integrity. 377 Provided that the message-authentication code coming along with the 378 Binding Update message is correct, the correspondent node creates a 379 binding-cache entry with the mobile node's new care-of address. The 380 correspondent node uses the mobile node's new care-of address as soon 381 as the binding-cache entry is in place. In case the A-flag in the 382 Binding Update message is set, the correspondent node sends back to 383 the mobile node a Binding Acknowledgement message (8) to indicate 384 successful care-of-address registration. 386 4. Early Binding Updates 388 In this section, we specify the procedure of Early Binding Updates, 389 our proposed modification of the standard binding-update procedure. 391 Early Binding Updates evade the latency of the two address tests 392 associated with a standard binding update. For this, the two address 393 tests are temporally decoupled. A mobile node executes a home-address 394 test whenever a handover is imminent. If handovers cannot be 395 anticipated, the mobile node may periodically repeat the home-address 396 test. Either way, the mobile node has at hand a fresh Home Keygen 397 Token when it changes its point of network attachment, and it does 398 not need to wait for a lengthy home-address test during the binding 399 update. The care-of-address test is performed after having signaled 400 the new care-of address to the correspondent node, and in parallel 401 with sending data to and from the new care-of address. [1] suggests 402 running both tests in parallel and after a handover. However, the 403 mobile node may trigger a home-address test before it moves without 404 violating the protocol procedure. 406 We introduce two new messages: an Early Binding Update message and an 407 Early Binding Acknowledgement message. The mobile node sends to the 408 correspondent node an Early Binding Update message when it wants to 409 register a new care-of address without yet having accomplished a 410 care-of-address test. The mobile node may request the correspondent 411 node to return an Early Binding Acknowledgement message. All messages 412 of the standard binding-update procedure remain unchanged and retain 413 their original meaning. Hence, a mobile node may initiate an Early 414 Binding Update without knowledge of whether or not the correspondent 415 node supports this. In case the correspondent node does not support 416 Early Binding Updates, the binding update is automatically reduced to 417 the standard procedure. 419 We provide a detailed specification of Early Binding Updates in 420 Section 4.1. We elaborate on the concurrent care-of-address test in 421 Section 4.2. In Section 4.3, we discuss the special case of 422 registering a care-of address without having done a home-address test 423 in advance. 425 4.1 Protocol Specification 427 This section provides a detailed specification of Early Binding 428 Updates. The procedure is summarized in Figure 2. 430 A mobile node triggers a home-address test, steps (1) and (2) in 431 Figure 2, whenever a handover is imminent. If handovers cannot be 432 anticipated, the mobile node may periodically repeat the home-address 433 test. Either way, the mobile node has at hand a fresh Home Keygen 434 Token when it changes its point of network attachment. The Home Test 435 Init and Home Test messages used for an Early Binding Update are the 436 same as the ones used for a standard binding update. 438 The time after which the mobile node repeats the home-address test 439 should be conservatively determined as the minimum time, 440 MAX_TOKEN_LIFETIME [1], a token is expected to be valid. 441 Alternatively, one might consider adding a Lifetime option to the 442 Home Test message to explicitly indicate the time after which the 443 Home Keygen Token becomes expired. The Lifetime option could help the 444 mobile node determine when to initiate the next home-address test. 445 The introduction of a new option would not interfere with Mobile IPv6 446 implementations that do not support Early Binding Updates. The new 447 option would simply be ignored and skipped by a node that does not 448 recognize the option. See section 6.1.5 of [1] for details on this. 450 The Home Test Init and Home Test messages are typically protected by 451 an IPsec tunnel between the home agent and the mobile node [2]. The 452 home agent must update the corresponding security association to the 453 mobile node's new care-of address when the mobile node changes its 454 point of network attachment. With Early Binding Updates, the 455 care-of-address change does not affect a home-address test, because 456 the home-address test is performed before the mobile node moves. This 457 is a difference to a standard binding update, where a home agent must 458 update the security association when it receives a Binding Update 459 message from the mobile node. Otherwise, the Home Test message could 460 not be delivered back to the mobile node through the IPsec tunnel 461 [2]. 463 Mobile Node Home Agent Correspondent Node 465 Home Test Init (1) 466 |-------------------->|-------------------->| 468 Home Test (2) 469 |<--------------------|<--------------------| 471 ~~~~~ [Handover] 473 Binding Update (3) 474 |-------------------->| 476 Early Binding Update (4) 477 |------------------------------------------>| 479 Care-of Test Init (5) 480 |------------------------------------------>| 482 Binding Acknowledgement (6) 483 |<--------------------| 485 Early Binding Acknowledgement (7) 486 |<------------------------------------------| 488 Care-of Test (8) 489 |<------------------------------------------| 491 Binding Update (9) 492 |------------------------------------------>| 494 Binding Acknowledgement (10) 495 |<------------------------------------------| 497 Figure 2: Early Binding Update 499 When the mobile node detects that it has moved to a different 500 network, it configures a new care-of address. The mobile node then 501 sends to its home agent a Binding Update message (3). The Binding 502 Update message informs the home agent about the mobile node's new 503 care-of address. It is authenticated by means of an IPsec security 504 association between the mobile node and the home agent. 506 Having sent the Binding Update message to its home agent, the mobile 507 node produces an Early Binding Management Key, which is a one-way 508 hash on the Home Keygen Token from the most recently received Home 509 Test message. The mobile node then generates an Early Binding Update 510 message (4) to be sent to the correspondent node and to be 511 authenticated with the Early Binding Management Key. The Early 512 Binding Management Key does not incorporate a Care-of Keygen Token as 513 the Binding Management Key used for a standard binding update does. 514 However, since the Care-of Keygen Token is irrelevant for 515 "authentication" purposes, but proves that some node can be reached 516 given its care-of address, it stands to reason that the Early Binding 517 Management Key is sufficient for authenticating the Early Binding 518 Update message. The mobile node will provide proof of its 519 reachability at the new care-of address at a later stage, when it 520 sends to the correspondent node a standard Binding Update message. 521 The mobile node will then need to generate an additional, standard 522 Binding Management Key on the basis of both the Home Keygen Token and 523 the Care-of Keygen Token. Note that [1] uses a key equivalent to the 524 Early Binding Management Key when deleting an existing binding-cache 525 entry. See section 5.2.5 of [1] for details on this. 527 The Early Binding Update message contains a message-authentication 528 code and the Home Nonce Index copied from the most recently received 529 Home Test message. There are two differences between the Early 530 Binding Update message and the Binding Update message used during a 531 standard binding update. First, the message-authentication code in 532 the Early Binding Update message is produced with the Early Binding 533 Management Key, which does not incorporate a Care-of Keygen Token. 534 Second, the Early Binding Update message does not contain a Care-of 535 Nonce Index. Note that [1] uses a message similar to the Early 536 Binding Update message when deleting an existing binding-cache entry. 537 See sections 6.1.7 and 6.2.6 of [1] for details on this. The mobile 538 node may request the correspondent node to return an Early Binding 539 Acknowledgement message by raising the A-flag in the Early Binding 540 Update message. A conservative mobile node would wait for the Early 541 Binding Acknowledgement message before using its new care-of address. 542 An optimistic mobile node would start using its new care-of address 543 as soon as having dispatched the Early Binding Update message. 544 Assuming that no packet reordering occurs on the path between the 545 mobile node and the correspondent node, the Early Binding Update 546 message will come in at the correspondent node ahead of all data 547 packets which the mobile node has sent from its new care-of address. 548 Whether conservative or optimistic, with Early Binding Updates, the 549 mobile node can use its new care-of address about one round-trip time 550 sooner than with standard binding updates. See Section 5 for an 551 efficiency analysis. 553 The mobile node sends to the correspondent node a Care-of Test Init 554 message (5) in parallel with sending the Early Binding Update 555 message. The Care-of Test Init message used for an Early Binding 556 Update is the same as the one used for a standard binding update. 558 When the home agent receives the Binding Update message, it registers 559 the mobile node's new care-of address. If the home agent maintains an 560 IPsec tunnel to the mobile node, it also updates the corresponding 561 security association to the new care-of address [2]. The home agent 562 sends back to the mobile node a Binding Acknowledgement message (6) 563 to indicate successful care-of-address registration. The Binding 564 Acknowledgement message is authenticated by means of an IPsec 565 security association between the mobile node and the home agent. 567 When the correspondent node receives the Early Binding Update 568 message, it can reproduce the Home Keygen Token with the help of the 569 Home Nonce Index. The token, in turn, allows the correspondent node 570 to reproduce the Early Binding Management Key. The correspondent node 571 can then compute what the message-authentication code in the Early 572 Binding Update message should look like. If the result matches the 573 message-authentication code in the Early Binding Update message, the 574 mobile node must have received the Home Keygen Token in order to 575 construct the Early Binding Management Key with which the 576 message-authentication code was produced. Therefore, the 577 correspondent node can assume that the mobile node is the legitimate 578 owner of the home address, since the Home Keygen Token was sent, as 579 part of the Home Test message, to the mobile node's home address. 580 Beyond this, the message-authentication code validates the Early 581 Binding Update message's integrity. 583 Provided that the message-authentication code coming along with the 584 Early Binding Update message is correct, the correspondent node 585 creates a tentative binding-cache entry with the mobile node's new 586 care-of address. The correspondent node uses the mobile node's new 587 care-of address as soon as the binding-cache entry is in place. Thus, 588 with Early Binding Updates, the correspondent node can use the mobile 589 node's new care-of address about one round-trip time sooner than with 590 standard binding updates. See Section 5 for an efficiency analysis. 592 Since a care-of-address test still has to be performed for the mobile 593 node's new care-of address, the lifetime of the new binding-cache 594 entry is limited to TENTATIVE_BINDING_LIFETIME. The lifetime will be 595 extended when the correspondent node receives a standard Binding 596 Update message from the mobile node. See Section 4.2 for details on 597 the concurrent care-of-address test. In case the A-flag in the Early 598 Binding Update message is set, the correspondent node sends back to 599 the mobile node an Early Binding Acknowledgement message (7) to 600 indicate tentative care-of-address registration. 602 When the correspondent node receives the Care-of Test Init message, 603 it sends to the mobile node a Care-of Test message (8). The Care-of 604 Test message used for an Early Binding Update is the same as the one 605 used for a standard binding update. 607 The Care-of Test message delivers to the mobile node a Care-of Keygen 608 Token. The mobile node uses this Care-of Keygen Token together with 609 the Home Keygen Token from the most recently received Home Test 610 message to produce a standard Binding Management Key. This Binding 611 Management Key is a one-way hash on the concatenation of the Home 612 Keygen Token and the Care-of Keygen Token. It is equivalent to the 613 Binding Management Key used for a standard binding update. 615 The mobile node then generates a standard Binding Update message (9) 616 to be sent to the correspondent node. This Binding Update message 617 contains a message-authentication code produced with the Binding 618 Management Key. It is equivalent to the Binding Update message used 619 for a standard binding update. The mobile node may request the 620 correspondent node to return a Binding Acknowledgement message by 621 raising the A-flag in the Binding Update message. 623 When the correspondent node receives the Binding Update message, it 624 checks the message's authenticity as described in Section 3. Provided 625 that the Binding Update message is properly authenticated, the 626 correspondent node extends the lifetime of the mobile node's 627 tentative binding-cache entry to the regular lifetime proposed in 628 [1]. In case the A-flag in the Binding Update message is set, the 629 correspondent node sends back to the mobile node a standard Binding 630 Acknowledgement message (10) to indicate successful care-of-address 631 registration. This Binding Acknowledgement message is equivalent to 632 the one used for a standard binding update. 634 4.2 Concurrent Care-of Address Tests 636 In this section, we elaborate on the concurrent care-of-address test. 637 A concurrent care-of-address test is performed after a mobile node 638 has signaled to the correspondent node a new care-of address. It runs 639 in parallel with sending data to and from the new care-of address. 640 The concurrent care-of-address test facilitates data transfer while 641 testing a mobile node's reachability. It requires the correspondent 642 node to create a tentative binding-cache entry with the mobile node's 643 new care-of address before a care-of-address test has been 644 accomplished. 646 Data transfer to and from a yet-unverified care-of address is limited 647 to a tentative binding-cache entry's lifetime, 648 TENTATIVE_BINDING_LIFETIME. On one hand, this lifetime is thought to 649 be long enough to outlast the care-of-address test to be performed 650 during that time. On the other hand, the lifetime is thought to be 651 short enough to discourage the exploitation of concurrent 652 care-of-address tests for flooding attacks. 654 When the correspondent node receives a properly authenticated Binding 655 Update message from the mobile node, it extends the lifetime of the 656 tentative binding-cache entry to the regular lifetime proposed in 657 [1]. If the Binding Update message arrives before the binding-cache 658 entry expires, data transfer can continue without disruption. If the 659 Binding Update message fails to arrive before the binding-cache entry 660 expires, the correspondent node must stop sending further data 661 packets to the mobile node's new care-of address. Subsequent data 662 packets will then be sent to the mobile node's home address. See 663 Section 6.2 for a discussion on why this is a feasible modus 664 operandi. 666 4.3 Initial Care-of Address Registration 668 In Section 4.1, a mobile node is expected to have acquired a valid 669 Home Keygen Token prior to changing its point of network attachment. 670 There are scenarios, however, in which this is not a feasible 671 assumption. For example, the mobile may be connected to its home link 672 before changing its point of network attachment. At home, the mobile 673 node does not use Mobile IPv6. It hence does not run a home-address 674 test, and it does not acquire a Home Keygen Token, before it moves to 675 a foreign link. Also, when the mobile node powers on at a foreign 676 link, it does not have a valid Home Keygen Token either. The mobile 677 node may even be offline for a while and unable to run the 678 home-address test. Any previously obtained Home Keygen Token is 679 likely to be expired when the mobile node reconnects to a foreign 680 link. 682 One may consider letting the mobile node perform a home-address test 683 even while being at home. This could accelerate handovers from the 684 home link to a foreign link. The Home Test Init and Home Test 685 messages would continue to obey to the rules defined in sections 9.4 686 and 11.6 of [1], except that they would not have to be tunneled 687 between the mobile node and its home agent. Nonetheless, performing a 688 home-address test from the home network does not help when a mobile 689 node reconnects to a foreign network after an offline period or after 690 booting up. Obviously, the mobile node must have a chance to register 691 a care-of address with its correspondent node without having acquired 692 a Home Keygen Token beforehand. 694 These observations lead to the following exception: When a mobile 695 node wants to register a new care-of address with a correspondent 696 node, and the mobile node does not yet know a valid Home Keygen 697 Token, the mobile node runs a standard binding update instead of an 698 Early Binding Update. When the standard binding update is complete, 699 the mobile node can communicate through its new care-of address. The 700 mobile node will henceforth trigger a home-address test whenever a 701 handover is imminent. If handovers cannot be anticipated, the mobile 702 node may periodically repeat the home-address test. Either way, the 703 mobile node will have available a fresh Home Keygen Token when it 704 changes its point of network attachment the next time so as to apply 705 an Early Binding Update then. 707 5. Efficiency Considerations 709 In this section, we consider the impact on efficiency that a binding 710 update may have. We examine standard binding updates in Section 5.1, 711 and we analyze Early Binding Updates in Section 5.2. 713 5.1 Standard Binding Updates 715 When the mobile node detects that it has moved to a different 716 network, it configures a new care-of address. [1] defines that a 717 mobile node must do the following steps before it can use the new 718 care-of address: First, the mobile node must register the new care-of 719 address with its home agent. Second, the home-address test and, 720 third, the care-of-address test must be executed. Fourth, the mobile 721 node must register the new care-of address with its correspondent 722 node. 724 Registering the new care-of address with the home agent is a two-way 725 message exchange between the mobile node and the mobile node's home 726 agent. It consists of a Binding Update message and a Binding 727 Acknowledgement message. Let RTT_HA be the round-trip time for the 728 Binding Update and Binding Acknowledgement messages. Here, HA means 729 "home agent". 731 The home-address test is a two-way message exchange between the 732 mobile node and the correspondent node. It consists of a Home Test 733 Init message and a Home Test message, both of which are tunneled 734 between the mobile node and the mobile node's home agent. Let the 735 round-trip time for the Home Test Init and Home Test messages be 736 RTT_BT. Here, BT means "bidirectional tunneling". 738 The care-of-address test is a two-way message exchange between the 739 mobile node and the correspondent node. It consists of a Care-of Test 740 Init message and a Care-of Test message, both of which are relayed on 741 the direct path between the mobile node and the correspondent node. 742 They do not pass the mobile node's home agent. Let the round-trip 743 time for the Care-of Test Init and Care-of Test messages be RTT_RO. 744 Here, RO means "route optimization". 746 The mobile node may dispatch the Home Test Init and Care-of Test Init 747 messages at any time after having sent the Binding Update message to 748 the home agent. The mobile node may thus send out all three messages 749 virtually in parallel. It takes approximately RTT_HA time until the 750 mobile node receives the Binding Acknowledgement message from its 751 home agent. The time until the mobile node receives the Home Test 752 message from the correspondent node is approximately RTT_BT. Finally, 753 it takes approximately RTT_RO time until the Care-of Test message 754 arrives at the mobile node. The mobile node must wait for all three 755 messages before it can register its new care-of address with the 756 correspondent node. 758 Registering the new care-of address with the correspondent node is a 759 one-way or two-way message exchange between the mobile node and the 760 correspondent node. It consists of a Binding Update message and an 761 optional Binding Acknowledgement message. The mobile node may request 762 the correspondent node to return a Binding Acknowledgement message by 763 raising a flag in the Binding Update message. A conservative mobile 764 node would wait for the Binding Acknowledgement message before using 765 its new care-of address. An optimistic mobile node would start using 766 its new care-of address as soon as having dispatched the Binding 767 Update message. 769 All things considered, a standard binding update's total latency with 770 respect to sending data from a new care-of address can be 771 approximated by 773 STD_LATENCY_SEND_CONSERV = Max (RTT_HA, RTT_BT, RTT_RO) + RTT_RO 774 STD_LATENCY_SEND_OPTIMST = Max (RTT_HA, RTT_BT, RTT_RO) 776 Here, STD_LATENCY_SEND_CONSERV pertains to a conservative mobile 777 node, which waits for the returning Binding Acknowledgement message 778 before it uses its new care-of address. STD_LATENCY_SEND_OPTIMST 779 pertains to an optimistic mobile node, which uses its new care-of 780 address as soon as having dispatched the Binding Update message. 782 Whether or not the mobile node waits for the returning Binding 783 Acknowledgement message, the correspondent node starts using the 784 mobile node's new care-of address upon receiving the mobile node's 785 Binding Update message. When the correspondent node switches to the 786 new care-of address, it takes another 0.5 RTT_RO time until the first 787 data packets arrive at the mobile node's new care-of address. Thus, a 788 standard binding update's total latency with respect to receiving 789 data at a new care-of address can be approximated by 791 STD_LATENCY_RECV = Max (RTT_HA, RTT_BT, RTT_RO) + RTT_RO 793 If the mobile node has already recently changed its point of network 794 attachment, it may reuse its previously acquired Home Keygen Token 795 without running another home-address test. In this situation, RTT_BT 796 reduces to zero, and Max (RTT_HA, RTT_BT, RTT_RO) = Max (RTT_HA, 797 RTT_RO). 799 5.2 Early Binding Updates 801 Moving from one point of network attachment to another involves a 802 handover and a binding update. During the handover, the mobile node 803 attaches to a new access point, re-authenticates itself, discovers a 804 new default router, and configures a new care-of address. During the 805 binding update, the mobile node signals to its correspondent node and 806 its home agent the new care-of address. More specifically, the mobile 807 node runs a home-address test and a care-of-address test, and it 808 sends a Binding Update message to both its correspondent node and its 809 home agent. 811 One might consider three candidate periods during which to execute 812 the home-address test and the care-of address test. These candidate 813 periods are as follows. 815 (1) Before handover 816 (2) After handover, but before binding update 817 (3) After binding update 819 The home-address test is intended to authenticate a node's home 820 address. For this reason, the home-address test must be performed at 821 either (1) or (2), but cannot be performed at (3). In [1], the 822 home-address test is preferably done at (2), but it may also take 823 place at (1). Technically, there is nothing that prevents a mobile 824 node from initiating the home-address test at (1). The mobile node 825 just needs to make sure that the Home Keygen Token from the 826 home-address test is still valid at the time the binding update is 827 done. 829 The care-of-address test is intended to prove that the mobile node is 830 reachable at its new care-of address. Therefore, the care-of-address 831 test obviously cannot be done at (1). In [1], the care-of-address 832 test is done at (2), i.e., it runs in parallel with the home-address 833 test. We claim that testing the mobile node's reachability at its new 834 care-of address may also be done at (3). Data transmission to and 835 from the new care-of address may wait or, as with Early Binding 836 Updates, start with appropriate restrictions until the mobile node 837 has provided proof to the correspondent node that it is reachable at 838 its new care-of address. 840 With Early Binding Updates, the home-address test is moved to (1), 841 and the care-of-address test is moved to (3). The home-address test 842 does no longer delay the binding update, because it runs while the 843 mobile node still uses a functioning, fully registered care-of 844 address. The care-of-address test does no longer delay the binding 845 update either, because it runs while the mobile node uses a new, 846 tentatively registered care-of address. There are two things that 847 remain to be done after a handover: First, the mobile node must 848 register the new care-of address with its home agent. Second, the 849 mobile node must tentatively register the new care-of address with 850 the correspondent node. 852 Registering the new care-of address with the home agent is a two-way 853 message exchange between the mobile node and the mobile node's home 854 agent. It consists of a Binding Update message and a Binding 855 Acknowledgement message. Let RTT_HA be the round-trip time for the 856 Binding Update and Binding Acknowledgement messages. Here, HA means 857 "home agent". 859 Tentatively registering the new care-of address with the 860 correspondent node is a one-way or two-way message exchange between 861 the mobile node and the correspondent node. It consists of an Early 862 Binding Update message and an optional Early Binding Acknowledgement 863 message. The mobile node may request the correspondent node to return 864 an Early Binding Acknowledgement message by raising a flag in the 865 Early Binding Update message. Let the round-trip time for the Early 866 Binding Update and Early Binding Acknowledgement messages be RTT_RO. 867 Here, RO means "route optimization". 869 A conservative mobile node would wait for both the Binding 870 Acknowledgement message from its home agent and the Early Binding 871 Acknowledgement from its correspondent node before using its new 872 care-of address. An optimistic mobile node would start using its new 873 care-of address as soon as having dispatched the Binding Update and 874 Early Binding Update messages. 876 All things considered, an Early Binding Update's total latency with 877 respect to sending data from a new care-of address can be 878 approximated by 880 NEW_LATENCY_SEND_CONSERV = Max (RTT_HA, RTT_RO) 881 NEW_LATENCY_SEND_OPTIMST = 0 883 Here, NEW_LATENCY_SEND_CONSERV pertains to a conservative mobile 884 node, which waits for both the Binding Acknowledgement message 885 returning from its home agent and the Early Binding Acknowledgement 886 returning from its correspondent node before it uses its new care-of 887 address. NEW_LATENCY_SEND_OPTIMST pertains to an optimistic mobile 888 node, which uses its new care-of address as soon as having dispatched 889 the Binding Update and Early Binding Update messages. 891 Whether or not the mobile node waits for the returning Binding 892 Acknowledgement and Early Binding Acknowledgement messages, the 893 correspondent node starts using the mobile node's new care-of address 894 upon receiving the mobile node's Early Binding Update message. When 895 the correspondent node switches to the new care-of address, it takes 896 another 0.5 RTT_RO time until the first data packets arrive at the 897 mobile node's new care-of address. Thus, an Early Binding Update's 898 total latency with respect to receiving data can be approximated by 900 NEW_LATENCY_RECV = RTT_RO 902 This evaluation shows that an Early Binding Update is about a 903 round-trip time faster than a standard binding update. This is true 904 even if the mobile node is able to reuse a previously acquired Home 905 Keygen Token without running another home-address test. The new 906 responsiveness to mobility will be of true benefit for 907 delay-sensitive applications. 909 Section 4.3 discusses the initial care-of-address registration, 910 during which the mobile node does not yet know a valid Home Keygen 911 Token. In this situation, the mobile node must perform a standard 912 binding update, and there is no efficiency improvement. However, we 913 point out that having to resort to a standard binding update is 914 limited to only very few scenarios and will rather be an exception. 916 6. Security Considerations 918 In this section, we elaborate on security implications that come 919 along with using Early Binding Updates instead of standard binding 920 updates. There are two conceptual differences between an Early 921 Binding Update and a standard binding update. First, with the Early 922 Binding Update, the home-address test is decoupled from the 923 care-of-address test, and the Early Binding Management Key used to 924 authenticate an Early Binding Update message is produced with the 925 Home Keygen Token only. In contrast, the Binding Management Key used 926 for a standard binding update is produced with both the Home Keygen 927 Token and the Care-of Keygen Token. We discuss this matter in Section 928 6.1. Second, we propose to execute the care-of-address test in 929 parallel with sending data to and from the new care-of address. A 930 malicious - yet properly authenticated - node can so wage a flooding 931 attack for a limited time. We analyze this issue in Section 6.2. We 932 also propose precautions against a flooding attack. 934 For a comprehensive taxonomy of mobility-related attacks, we refer to 935 the Mobile IPv6 Route Optimization Security Design Background [3]. 936 The document provides a thorough understanding of what has guided the 937 design of the standard binding-update procedure. 939 6.1 Decoupled Address Tests 941 During a standard binding update, a mobile node must accomplish both 942 the home-address test and the care-of-address test before it can 943 signal to its correspondent node a new care-of address. During an 944 Early Binding Update, the home-address test is sufficient to let the 945 correspondent node tentatively register a new care-of address. The 946 tentative registration becomes a regular one once the mobile node has 947 provided proof to the correspondent node that it is reachable at its 948 new care-of address. 950 Temporally decoupling the home-address test from the care-of-address 951 test means separating an authenticity check from a validity check. 952 The authenticity check indicates that the mobile node is the 953 legitimate owner of the IP address which the mobile node claims to 954 own as its home address. The validity check indicates that the mobile 955 node is reachable through the IP address which the mobile node wishes 956 to register as its care-of address. 958 The consequence is this: During the standard binding update, when a 959 mobile node's Binding Update message arrives at a correspondent node, 960 the correspondent node knows that the message is authentic and that 961 the mobile node is reachable through its new care-of address. During 962 the Early Binding Update, when a mobile node's Early Binding Update 963 message arrives at a correspondent node, the correspondent node can 964 trust in the message's authenticity, but it must wait until 965 completion of the care-of-address test before it can assume that the 966 mobile node is reachable through its new care-of address. The maximum 967 time of uncertainty can be configured by the 968 TENTATIVE_BINDING_LIFETIME protocol-configuration variable. 970 The question is whether separating the two address tests makes 971 authentication of binding updates less secure or not. Recall that an 972 Early Binding Update message requires only a Home Keygen Token to be 973 authenticated, whereas a Binding Update message requires both a Home 974 Keygen Token and a Care-of Keygen Token. The Home Keygen Token and 975 the Care-of Keygen Token are likely to arrive at the mobile node via 976 disjoint paths: The former passes through the mobile node's home 977 agent, the latter does not. An attacker will thus have a hard time to 978 capture both tokens. One might wonder whether the simpler 979 authentication of an Early Binding Update message makes Early Binding 980 Updates open to eavesdropping and man-in-the-middle attacks. Next, we 981 argue that this is not the case. 983 Consider an attacker who intends to exploit Early Binding Updates. 984 The attacker may want to impersonate the mobile node or the 985 correspondent node, sending messages on behalf of one or both of 986 them. The attacker may also want to eavesdrop on signaling messages 987 in order to gather the information it needs for a later strike. In 988 either case, the attacker will have to get active on the home-address 989 test, because the home-address test is decisive for the mobile node's 990 authenticity. For this, the mobile node needs to be located on the 991 path between the mobile node's home agent and the correspondent node, 992 because data on the path between the mobile node and its home agent 993 is protected by IPsec. The attacker thus has to be somewhere within 994 the fixed Internet. Having to tamper with static infrastructure, 995 however, is assumed to be an obstacle significant enough to prevent 996 many such attacks [3]. 998 Suppose that, in spite of hurdles, there is an attacker which has 999 access to the path between the mobile node's home agent and the 1000 correspondent node. This attacker is in a position to listen to or 1001 intercept the Home Test Init and Home Test messages as well as to 1002 spoof these and other Mobile IPv6 messages. The likely purpose behind 1003 such an attack is to impersonate the mobile node, to install a false 1004 binding on behalf of the mobile node, and to divert the mobile node's 1005 data to an arbitrary location. The point is that, due to the 1006 attacker's position, such an attack can be accomplished even with the 1007 standard binding-update procedure. For this, the attacker listens to 1008 the Home Test message on its way from the correspondent node to the 1009 mobile node's home agent. It may also send to the correspondent node 1010 a spoofed Home Test Init message and intercept the returning Home 1011 Test message. The attacker then sends to the correspondent node a 1012 spoofed Care-of Test Init message. The attacker will probably use a 1013 care-of address through which it is reachable, for instance, its own 1014 current care-of address or its home address. This way, the attacker 1015 makes sure that it receives the returning Care-of Test message. The 1016 Care-of Test Init message can be sent from anywhere in the Internet 1017 unless prevented by ingress filtering. Since ingress filtering is not 1018 universally employed, sending the spoofed Care-of Test Init message 1019 is not difficult. Having the Home Test message and the Care-of Test 1020 message, the attacker can authenticate a fraud Binding Update 1021 message. 1023 This discussion shows that eavesdropping and impersonation is not 1024 prevented by taking the disjoint-paths approach of the standard 1025 binding-update procedure. Instead, access to a particular path within 1026 the fixed Internet is already enough. We hence believe that an Early 1027 Binding Update is equally secure than a standard binding update with 1028 respect to these attacks. 1030 6.2 Concurrent Care-of Address Tests 1032 A successful care-of-address test provides reasonable assurance to 1033 the correspondent node that the mobile node is reachable through the 1034 IP address which the mobile node wishes to register as its care-of 1035 address. This assurance is a necessary precaution against flooding 1036 attacks. If no care-of-address test was performed, a malicious mobile 1037 node could start downloading large volumes of data from multiple 1038 correspondent nodes and direct these data flows to an arbitrary IP 1039 address. 1041 Early Binding Updates allow a mobile node to use a new care-of 1042 address while the care-of-address test is in progress. This strategy 1043 reduces the latency associated with a binding update. Concerning 1044 security against flooding attacks, Early Binding Updates are at a 1045 minor disadvantage with standard binding updates, because a malicious 1046 node may exploit the time window during which a correspondent node 1047 sends data to a yet-unverified care-of address. We propose two ways 1048 to mitigate this threat. 1050 One way is to properly configure the lifetime of a tentative 1051 binding-cache entry. We propose the value, 1052 TENTATIVE_BINDING_LIFETIME, given in Section 8. In scenarios where 1053 flooding attacks cannot be ruled out, one should appropriately reduce 1054 TENTATIVE_BINDING_LIFETIME. 1056 Another way to mitigate the threat of flooding attacks is to grant 1057 Early Binding Updates to trusted nodes only. Recall that the 1058 correspondent node can authenticate a mobile node at the time it 1059 receives an Early Binding Update message from the mobile node. In 1060 other words, the correspondent node can assume that the mobile node 1061 is the legitimate owner of the IP address which the mobile node uses 1062 as its home address. This, in turn, allows the correspondent node to 1063 use the mobile node's home address as a criterion for deciding 1064 whether or not to install a tentative binding-cache entry with the 1065 mobile node's new care-of address. For instance, the correspondent 1066 node may be a corporate server which grants Early Binding Updates to 1067 mobile nodes from the corporate network only. 1069 Due to the ability to configure, and selectively apply, Early Binding 1070 Updates, we believe that the optimization's disadvantage concerning 1071 security against flooding attacks is negligible in most practical 1072 scenarios. 1074 7. Conclusion 1076 Mobile IPv6 defines two address tests that must be performed before a 1077 mobile node can register a new care-of address with its correspondent 1078 node: a home-address test and a care-of-address test. The long 1079 latency associated with the address tests makes it difficult for 1080 delay-sensitive applications to hold up service quality during a 1081 binding update. 1083 We propose a strategy, Early Binding Updates, to move both address 1084 test out of the critical period during which a new care-of address 1085 cannot yet be used. We perform the home-address test before the 1086 mobile node changes its point of network attachment. We execute the 1087 care-of-address test in parallel with sending data to and from the 1088 new care-of address. 1090 We evaluate Early Binding Updates with respect to the standard 1091 binding-update procedure. We find that an Early Binding Update can be 1092 accomplished in half, or less, of the time that a standard binding 1093 update takes. Moreover, we show that an Early Binding Update is 1094 nearly equivalent to a standard binding update with respect to 1095 security, and that it marginally increases the resources required at 1096 the correspondent node. 1098 Early Binding Updates are realized as an optional, and fully 1099 backward-compatible, extension to Mobile IPv6. Early Binding Updates 1100 use two new messages, both of which have no effect if either 1101 communication end-point does not support them. 1103 8. Protocol Configuration Variables 1105 TENTATIVE_BINDING_LIFETIME 3 seconds (default) 1107 References 1109 [1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 1110 IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), June 1111 2003. 1113 [2] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to 1114 Protect Mobile IPv6 Signaling between Mobile Nodes and Home 1115 Agents", draft-ietf-mobileip-mipv6-ha-ipsec-06 (work in 1116 progress), July 2003. 1118 [3] Nikander, P., "Mobile IP version 6 Route Optimization Security 1119 Design Background", draft-nikander-mobileip-v6-ro-sec-02 (work 1120 in progress), December 2003. 1122 Authors' Addresses 1124 Christian Vogt (Editor and Contact Person) 1125 Institute of Telematics 1126 University of Karlsruhe (TH) 1127 P.O. Box 6980 1128 76128 Karlsruhe 1129 Germany 1131 Phone: +49-721-608-8282 1132 Fax: +49-721-388-097 1133 EMail: chvogt@tm.uka.de 1134 URI: http://www.tm.uka.de/~chvogt/ 1136 Roland Bless 1137 Institute of Telematics 1138 University of Karlsruhe (TH) 1139 P.O. Box 6980 1140 76128 Karlsruhe 1141 Germany 1143 Phone: +49-721-608-6413 1144 Fax: +49-721-388-097 1145 EMail: bless@tm.uka.de 1146 URI: http://www.tm.uka.de/~bless/ 1147 Mark Doll 1148 Institute of Telematics 1149 University of Karlsruhe (TH) 1150 P.O. Box 6980 1151 76128 Karlsruhe 1152 Germany 1154 Phone: +49-721-608-6403 1155 Fax: +49-721-388-097 1156 EMail: doll@tm.uka.de 1157 URI: http://www.tm.uka.de/~doll/ 1159 Tobias K�fner 1160 Institute of Telematics 1161 University of Karlsruhe (TH) 1162 P.O. Box 6980 1163 76128 Karlsruhe 1164 Germany 1166 Phone: +49-721-608-8282 1167 Fax: +49-721-388-097 1168 EMail: kuefner@tm.uka.de 1169 URI: http://www.tm.uka.de/~kuefner/ 1171 Intellectual Property Statement 1173 The IETF takes no position regarding the validity or scope of any 1174 intellectual property or other rights that might be claimed to 1175 pertain to the implementation or use of the technology described in 1176 this document or the extent to which any license under such rights 1177 might or might not be available; neither does it represent that it 1178 has made any effort to identify any such rights. Information on the 1179 IETF's procedures with respect to rights in standards-track and 1180 standards-related documentation can be found in BCP-11. Copies of 1181 claims of rights made available for publication and any assurances of 1182 licenses to be made available, or the result of an attempt made to 1183 obtain a general license or permission for the use of such 1184 proprietary rights by implementors or users of this specification can 1185 be obtained from the IETF Secretariat. 1187 The IETF invites any interested party to bring to its attention any 1188 copyrights, patents or patent applications, or other proprietary 1189 rights which may cover technology that may be required to practice 1190 this standard. Please address the information to the IETF Executive 1191 Director. 1193 Full Copyright Statement 1195 Copyright (C) The Internet Society (2004). All Rights Reserved. 1197 This document and translations of it may be copied and furnished to 1198 others, and derivative works that comment on or otherwise explain it 1199 or assist in its implementation may be prepared, copied, published 1200 and distributed, in whole or in part, without restriction of any 1201 kind, provided that the above copyright notice and this paragraph are 1202 included on all such copies and derivative works. However, this 1203 document itself may not be modified in any way, such as by removing 1204 the copyright notice or references to the Internet Society or other 1205 Internet organizations, except as needed for the purpose of 1206 developing Internet standards in which case the procedures for 1207 copyrights defined in the Internet Standards process must be 1208 followed, or as required to translate it into languages other than 1209 English. 1211 The limited permissions granted above are perpetual and will not be 1212 revoked by the Internet Society or its successors or assignees. 1214 This document and the information contained herein is provided on an 1215 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1216 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1217 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1218 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1219 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1221 Acknowledgment 1223 Funding for the RFC Editor function is currently provided by the 1224 Internet Society.