idnits 2.17.1 draft-ietf-mobileip-optim-11.txt: 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == 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 an Authors' Addresses Section. ** 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 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Downref: Normative reference to an Informational RFC: RFC 1701 (ref. '3') ** Downref: Normative reference to an Informational RFC: RFC 1702 (ref. '4') -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '6') ** Obsolete normative reference: RFC 2408 (ref. '7') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2344 (ref. '8') (Obsoleted by RFC 3024) -- Possible downref: Non-RFC (?) normative reference: ref. '11' == Outdated reference: A later version (-08) exists of draft-ietf-mobileip-rfc2002-bis-03 ** Obsolete normative reference: RFC 1700 (ref. '13') (Obsoleted by RFC 3232) Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobile IP Working Group Charles Perkins 2 INTERNET DRAFT Nokia Research Center 3 6 September 2001 David B. Johnson 4 Carnegie Mellon University 6 Route Optimization in Mobile IP 7 draft-ietf-mobileip-optim-11.txt 9 Status of This Memo 11 This document is a submission by the mobile-ip Working Group of the 12 Internet Engineering Task Force (IETF). Comments should be submitted 13 to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list. 15 Distribution of this memo is unlimited. 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at 25 any time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at: 29 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at: 31 http://www.ietf.org/shadow.html. 33 Abstract 35 Using the base Mobile IP protocol, all datagrams destined to a mobile 36 node are routed through that mobile node's home agent, which then 37 tunnels each datagram to the mobile node's current location. This 38 document defines Route Optimization messages and extensions to the 39 base protocol to optimize datagram routing to a mobile node. Using 40 these protocol extensions, correspondent nodes may cache the binding 41 of a mobile node, and then tunnel their datagrams for the mobile node 42 directly to the care-of address, bypassing the mobile node's home 43 agent. Extensions are also provided to allow datagrams in flight 44 when a mobile node moves, and datagrams sent based on an out-of-date 45 cached binding, to be forwarded directly to the mobile node's new 46 binding. 48 Contents 50 Status of This Memo i 52 Abstract i 54 1. Introduction 1 56 2. Terminology 2 58 3. Route Optimization Overview 2 59 3.1. Binding Caches . . . . . . . . . . . . . . . . . . . . . 3 60 3.2. Foreign Agent Smooth Handoff . . . . . . . . . . . . . . 4 62 4. Route Optimization Message Formats 5 63 4.1. Binding Warning Message . . . . . . . . . . . . . . . . . 6 64 4.2. Binding Request Message . . . . . . . . . . . . . . . . . 7 65 4.3. Binding Update Message . . . . . . . . . . . . . . . . . 8 66 4.4. Binding Acknowledge Message . . . . . . . . . . . . . . . 12 68 5. Route Optimization Authentication Extension 13 69 5.1. Modified Registration Request Message . . . . . . . . . . 13 71 6. Format of Smooth Handoff Extensions 14 72 6.1. Previous Foreign Agent Notification Extension . . . . . . 14 73 6.2. Modified Mobility Agent Advertisement Extension . . . . . 16 74 6.3. Binding Warning Extension . . . . . . . . . . . . . . . . 17 76 7. Miscellaneous Home Agent Operations 18 77 7.1. Home Agent Rate Limiting . . . . . . . . . . . . . . . . 18 78 7.2. Managing Binding Updates for Correspondent Nodes . . . . 18 80 8. Miscellaneous Foreign Agent Operations 18 81 8.1. Previous Foreign Agent Notification . . . . . . . . . . . 19 82 8.2. Maintaining Binding Caches . . . . . . . . . . . . . . . 20 83 8.3. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . 20 85 9. Security Considerations 20 87 10. Acknowledgement 21 89 A. Mobility Security Association Management 23 91 B. Using a Master Key at the Home Agent 24 93 Addresses 25 94 1. Introduction 96 The base Mobile IP protocol [12], allows any mobile node to move 97 about, changing its point of attachment to the Internet, while 98 continuing to be identified by its home IP address. Correspondent 99 nodes send IP datagrams to a mobile node at its home address 100 in the same way as with any other destination. This scheme 101 allows transparent interoperation between mobile nodes and their 102 correspondent nodes, but forces all datagrams for a mobile node to 103 be routed through its home agent. Thus, datagrams to the mobile 104 node are often routed along paths that are significantly longer than 105 optimal. For example, if a mobile node is visiting some subnet, 106 even datagrams from a correspondent node on the same subnet must be 107 routed through the Internet to the mobile node's home agent (on its 108 home network), only then to be tunneled back to the original subnet 109 for final delivery. This indirect routing delays the delivery of the 110 datagrams to mobile nodes, and places an unnecessary burden on the 111 networks and routers along their paths through the Internet. 113 In this document, we will define extensions to the operation of 114 the base Mobile IP protocol to allow for better routing, so that 115 datagrams can be routed from a correspondent node to a mobile node 116 without going to the home agent first. We refer collectively to 117 these extensions as Route Optimization. 119 Route Optimization extensions provide a means for nodes to cache 120 the binding of a mobile node and to then tunnel their own datagrams 121 directly to the care-of address indicated in that binding, bypassing 122 the mobile node's home agent. Extensions are also provided to allow 123 datagrams in flight when a mobile node moves, and datagrams sent 124 based on an out-of-date cached binding, to be forwarded directly to 125 the mobile node's new care-of address. 127 All operation of Route Optimization that changes the routing of 128 IP datagrams to the mobile node is authenticated using the same 129 type of mechanisms defined in the base Mobile IP protocol. This 130 authentication generally relies on a mobility security association 131 established in advance between the sender and receiver of such 132 messages. The association can be created using ISAKMP [7], or any of 133 the registration key establishment methods specified in [11]. 135 After Section 2 gives some extra terminology, Section 3 provides 136 an overview of the basic protocol operations associated with Route 137 Optimization. Section 4 defines the message types used to update 138 binding caches. Subsequent sections show the formats for the 139 messages, explaining the function of fields within each message. 140 Home agent considerations are given in Section 7, and foreign agent 141 considerations in Section 8. 143 2. Terminology 145 This document introduces the following terminology, in addition to 146 that used to describe the base Mobile IP protocol: 148 Binding cache 150 A cache of mobility bindings of mobile nodes, maintained by a 151 node for use in tunneling datagrams to those mobile nodes. 153 Binding update 155 A message indicating a mobile node's current mobility binding, 156 and in particular its care-of address. 158 Registration Lifetime 160 The registration lifetime is the time duration for which a 161 binding is valid. The term remaining registration lifetime 162 means the amount of time remaining for which a registration 163 lifetime is still valid, at some time after the registration 164 was approved by the home agent. 166 Security Parameters Index (SPI) 168 An index identifying a security context between a pair of 169 nodes among the contexts available in the Mobility Security 170 Association. SPI values 0 through 255 are reserved [2]. 172 Triangle Routing 174 A situation in which a Correspondent Host's packets to a Mobile 175 Host follow a path which is longer than the optimal path 176 because the packets must be forwarded to the Mobile Host via a 177 Home Agent. 179 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 180 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 181 document are to be interpreted as described in RFC 2119 [1]. 183 3. Route Optimization Overview 185 This section provides an overview of the protocols and operations of 186 Route Optimization. These can be divided into two main parts: 188 1. Updating binding caches 190 2. Managing smooth handoffs between foreign agents 192 The first part of the document goes into detail about binding cache 193 maintenance, and then smooth handoff is considered. 195 3.1. Binding Caches 197 Route Optimization provides a means for any node to maintain a 198 binding cache containing the care-of address of one or more mobile 199 nodes. When sending an IP datagram to a mobile node, if the sender 200 has a binding cache entry for the destination mobile node, it MAY 201 tunnel the datagram directly to the care-of address indicated in the 202 cached mobility binding. 204 In the absence of any binding cache entry, datagrams destined for a 205 mobile node will be routed to the mobile node's home network in the 206 same way as any other IP datagram, and then tunneled to the mobile 207 node's current care-of address by the mobile node's home agent. 208 This is the only routing mechanism supported by the base Mobile IP 209 protocol. With Route Optimization, as a side effect of this indirect 210 routing of a datagram to a mobile node, the original sender of the 211 datagram may be informed of the mobile node's current mobility 212 binding, giving the sender an opportunity to cache the binding. 214 Any node may maintain a binding cache to optimize its own 215 communication with mobile nodes. A node may create or update a 216 binding cache entry for a mobile node only when it has received 217 and authenticated the mobile node's mobility binding. As before, 218 each binding in the binding cache also has an associated lifetime, 219 specified in the Binding Update message in which the node obtained 220 the binding. After the expiration of this time period, the binding 221 is deleted from the cache. In addition, a node cache MAY use any 222 reasonable strategy for managing the space within the binding cache. 223 When a new entry needs to be added to the binding cache, the node MAY 224 choose to drop any entry already in the cache, if needed, to make 225 space for the new entry. For example, a least-recently used (LRU) 226 strategy for cache entry replacement is likely to work well. 228 When a mobile node's home agent intercepts a datagram from the home 229 network and tunnels it to the mobile node, the home agent may deduce 230 that the original source of the datagram has no binding cache entry 231 for the destination mobile node. The home agent SHOULD then send 232 a Binding Update message to the original source node, informing it 233 of the mobile node's current mobility binding. No acknowledgment 234 for such a Binding Update message is needed, since additional future 235 datagrams from this source node intercepted by the home agent for the 236 mobile node will cause transmission of another Binding Update. For 237 a Binding Update to be authenticated by the original source node, 238 the source node and the home agent must have established a mobility 239 security association. 241 Similarly, when any node (e.g., a foreign agent) receives a tunneled 242 datagram, if it has a binding cache entry for the destination mobile 243 node (and thus has no visitor list entry for this mobile node), the 244 node receiving this tunneled datagram may deduce that the tunneling 245 node has an out-of-date binding cache entry for this mobile node. In 246 this case, the receiving node SHOULD send a Binding Warning message 247 to the mobile node's home agent, advising it to send a Binding Update 248 message to the node that tunneled this datagram. A correspondent 249 node can determine the mobile node's home agent from the binding 250 cache entry, because the home agent address is learned from the 251 Binding Update that established this cache entry. The address of 252 the node that tunneled this datagram can be determined from the 253 datagram's header, since the address of the node tunneling this 254 datagram is the outer source address of the encapsulated datagram. 255 As in the case of a Binding Update sent by the mobile node's home 256 agent, no acknowledgment of this Binding Warning is needed, since 257 additional future datagrams for the mobile node tunneled by the 258 same node will cause the transmission of another Binding Warning. 259 However, unlike the Binding Update message, no authentication of the 260 Binding Warning message is necessary, since it does not directly 261 affect the routing of IP datagrams to the mobile node. 263 When sending an IP datagram, if the sending node has a binding cache 264 entry for the destination node, it SHOULD tunnel the datagram to the 265 mobile node's care-of address using the encapsulation techniques used 266 by home agents, and described in [9, 10, 3, 4]. 268 3.2. Foreign Agent Smooth Handoff 270 When a mobile node moves and registers with a new foreign agent, the 271 base Mobile IP protocol does not notify the mobile node's previous 272 foreign agent. IP datagrams intercepted by the home agent after 273 the new registration are tunneled to the mobile node's new care-of 274 address, but datagrams in flight that had already been intercepted 275 by the home agent and tunneled to the old care-of address when 276 the mobile node moved are likely to be lost and are assumed to be 277 retransmitted by higher-level protocols if needed. The old foreign 278 agent eventually deletes its visitor list entry for the mobile node 279 after the expiration of the registration lifetime. 281 Route Optimization provides a means for the mobile node's previous 282 foreign agent to be reliably notified of the mobile node's new 283 mobility binding, allowing datagrams in flight to the mobile 284 node's previous foreign agent to be forwarded to its new care-of 285 address. This notification also allows any datagrams tunneled to 286 the mobile node's previous foreign agent, from correspondent nodes 287 with out-of-date binding cache entries for the mobile node, to be 288 forwarded to its new care-of address. Finally, this notification 289 allows any resources consumed by the mobile node at the previous 290 foreign agent (such as radio channel reservations) to be released 291 immediately, rather than waiting for its registration lifetime to 292 expire. 294 As part of the registration procedure, the mobile node MAY 295 request that its new foreign agent attempt to notify its previous 296 foreign agent on its behalf, by including a Previous Foreign Agent 297 Notification extension in its Registration Request message sent to 298 the new foreign agent. The new foreign agent then builds a Binding 299 Update message and transmits it to the mobile node's previous foreign 300 agent as part of registration, requesting an acknowledgment from the 301 previous foreign agent. The extension includes only those values 302 needed to construct the Binding Update message that are not already 303 contained in the Registration Request message. The authenticator for 304 the Binding Update message is computed by the mobile node using the 305 security association shared with its previous foreign agent. This 306 notification will typically include the mobile node's new care-of 307 address, allowing the previous foreign agent to create a binding 308 cache entry for the mobile node to serve as a forwarding pointer [5] 309 to its new location. Any tunneled datagrams for the mobile node that 310 arrive at its previous foreign agent after the forwarding pointer has 311 been created can then be re-tunneled to the mobile node's new care-of 312 address. 314 For this smooth handoff to be secure during registration with a new 315 foreign agent, the mobile node and the previous foreign agent must 316 have a security association. The security association is used to 317 authenticate the notification sent to the previous foreign agent. 319 The Mobility Agent Advertisement extension of the agent advertisement 320 message is revised under Route Optimization to include a bit 321 indicating that the foreign agent supports smooth handoffs. 323 The mobile node is responsible for occasionally retransmitting a 324 Binding Update message to its previous foreign agent until the 325 matching Binding Acknowledge message is received, or until the 326 mobile node can be sure that foreign agent has expired its binding. 327 The mobile node is likely to select a small timeout value for the 328 lifetime available to such bindings sent to previous foreign agents. 330 4. Route Optimization Message Formats 332 Route Optimization defines four message types used for management 333 of binding cache entries. These message types fit in the numbering 334 space defined in the base Mobile IP specification for messages sent 335 to UDP port 434. Each of these messages begins with a one-octet 336 field indicating the type of the message. The binding cache 337 management messages in this section are carried by way of UDP, sent 338 to port 434. 340 The following type codes are defined in this document: 342 16 Binding Warning message 343 17 Binding Request message 344 18 Binding Update message 345 19 Binding Acknowledge message 347 Route Optimization also requires one minor change to existing 348 Mobile IP messages: a new flag bit must be added to the Registration 349 Request message, replacing a previously unused, reserved bit in the 350 message. 352 This section describes each of the new Route Optimization messages 353 and the change to Registration Request message. 355 4.1. Binding Warning Message 357 A Binding Warning message is used to transmit advice that a Binding 358 Update is needed by one or more correspondent nodes or foreign 359 agents. This happens when the suggested recipients are likely to 360 have either no binding cache entry or an out-of-date binding cache 361 entry for some mobile node. When any node detunnels a datagram 362 destined for the mobile node, if it is not the current foreign agent 363 for the destination mobile node, that foreign agent SHOULD send a 364 Binding Warning message to the mobile node's home agent. If the 365 foreign agent does not have any information about the mobile node's 366 home agent, the foreign agent SHOULD send a Binding Warning message 367 to the sender of the datagram (i.e., the correspondent node). 369 0 1 2 3 370 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Type | Reserved | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Mobile Node Home Address | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Target Node Addresses ... 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 The format of the Binding Warning message is illustrated above, and 380 contains the following fields: 382 Type 16 384 Reserved Sent as 0; ignored on reception. 386 Mobile Node Home Address 387 The home address of the mobile node to which the 388 Binding Warning message refers. 390 Target Node Addresses 391 Zero or more addresses of nodes. Each address 392 identifies a node that should be the target of a 393 Binding Update message sent by the home agent. If no 394 addresses are present, the recipient of the message is 395 the intended target for the message. 397 A home agent will receive a Binding Warning message if a node 398 maintaining a binding cache entry for one of the home agent's mobile 399 nodes uses an out-of-date entry. When a home agent receives a 400 Binding Warning message, it SHOULD send a Binding Update message to 401 each target node address identified in the Binding Warning, giving it 402 the current binding for the mobile node identified in the mobile node 403 home address field of the Binding Warning. 405 When a mobile node receives a new Care-of Address, it MAY send a 406 Binding Warning message to its Home Agent, requesting that the home 407 agent send Binding Update messages to one or more correspondent 408 nodes. This feature MAY be used by the mobile node when it returns 409 to its home network, so that the Home Agent will send out Binding 410 Updates with zero lifetimes to all the mobile node's correspondent 411 nodes. It is important for the correspondent nodes to delete their 412 binding cache entries for the mobile node when the mobile node no 413 longer has a Care-of Address. 415 If a foreign agent receives a packet for a mobile node for 416 which there isn't any visitor list or binding cache information 417 available, the foreign agent SHOULD send the Binding Warning to the 418 correspondent node that transmitted the undeliverable message. 420 4.2. Binding Request Message 422 A Binding Request message is used by a node to request a mobile 423 node's current mobility binding from a mobile node or the mobile 424 node's home agent. 426 0 1 2 3 427 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Type | Reserved | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Mobile Node Home Address | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | | 434 + Identification + 435 | | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 The format of the Binding Request message is illustrated above, and 439 contains the following fields: 441 Type 17 443 Reserved Sent as 0; ignored on reception. 445 Mobile Node Home Address 446 The home address of the mobile node to which the 447 Binding Request refers. 449 Identification 450 A 64-bit sequence number, assigned by the node sending 451 the Binding Request message, used to assist in matching 452 requests with replies, and in protecting against replay 453 attacks. 455 When the home agent receives a Binding Request message, it consults 456 its home list and determines the correct binding information to be 457 sent to the requesting node. Before satisfying the request, the home 458 agent is required to check whether or not the mobile node has allowed 459 the information to be disseminated. If the mobile node specified 460 the private (P) bit in its Registration Request message, then the 461 home agent must make no further attempt to satisfy Binding Requests 462 on behalf of that mobile node. In this case, the home agent SHOULD 463 return a Binding Update in which both the care-of address is set 464 equal to the mobile node's home address and the lifetime is set to 465 zero. Such a Binding Update message indicates that the binding cache 466 entry for the specified mobile node should be deleted. 468 4.3. Binding Update Message 470 The Binding Update message is used for notification of a mobile 471 node's current mobility binding. Subject to rate-limiting 472 provisions, it SHOULD be sent by the mobile node's home agent in the 473 following situations: 475 - in response to a Binding Request message, 477 - in response to a Binding Warning message, 479 - in response to the reception of a Binding Warning extension to a 480 Registration Request, 482 - in response to the reception of a packet destined for a mobile 483 node. 485 A Binding Update SHOULD also be sent by a mobile node, or by the 486 foreign agent with which the mobile node is registering, when 487 notifying the mobile node's previous foreign agent that the mobile 488 node has moved. 490 0 1 2 3 491 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Type |A|I|M|G| Rsv | Lifetime | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | Mobile Node Home Address | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | Care-of Address | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | | 500 + Identification + 501 | | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | Extensions ... 504 +-+-+-+-+-+-+-+- 506 The format of the Binding Update message is illustrated above, and 507 contains the following fields: 509 Type 18 511 A The 'A' (acknowledge) bit is set by the node sending 512 the Binding Update message to request a Binding 513 Acknowledge message be returned. 515 I The 'I' (identification present) bit is set by the 516 node sending the Binding Update message if the 517 identification field is present in the message. 519 M If the 'M' (minimal encapsulation) bit is set, 520 datagrams MAY be tunneled to the mobile node using 521 the minimal encapsulation protocol [10]. 523 G If the 'G' (Generic Record Encapsulation, or GRE) bit 524 is set, datagrams MAY be tunneled to the mobile node 525 using GRE [3]. 527 Rsv Reserved. Sent as 0; ignored on reception. 529 Lifetime The number of seconds remaining before the binding 530 cache entry must be considered expired. A value 531 of all ones indicates infinity. A value of zero 532 indicates that no binding cache entry for the mobile 533 node should be created and that any existing binding 534 cache entry (and visitor list entry, in the case of a 535 mobile node's previous foreign agent) for the mobile 536 node should be deleted. The lifetime is typically 537 equal to the remaining lifetime of the mobile node's 538 registration. 540 Mobile Node Home Address 541 The home address of the mobile node to which the 542 Binding Update message refers. 544 Care-of Address 545 The current care-of address of the mobile node. When 546 set equal to the home address of the mobile node, 547 the Binding Update message instead indicates that no 548 binding cache entry for the mobile node should be 549 created, and any existing binding cache entry (and 550 visitor list entry, in the case of a mobile node's 551 previous foreign agent) for the mobile node should be 552 deleted. 554 Identification 555 If present, a 64-bit number, assigned by the node 556 sending the Binding Request message, used to assist 557 in matching requests with replies, and in protecting 558 against replay attacks. 560 Each Binding Update message indicates the binding's maximum lifetime. 561 When sending the Binding Update message, the home agent SHOULD set 562 this lifetime to the remaining registration lifetime. A node wanting 563 to provide continued service with a particular binding cache entry 564 MAY attempt to reconfirm that mobility binding before the expiration 565 of the registration lifetime. Such reconfirmation of a binding cache 566 entry may be appropriate when the node has indications (such as an 567 open transport-level connection to the mobile node) that the binding 568 cache entry is still needed. This reconfirmation is performed by 569 the node sending a Binding Request message to the mobile node's 570 home agent, requesting it to reply with the mobile node's current 571 mobility binding in a new Binding Update message. Note that the node 572 maintaining the binding SHOULD also keep track of the home agent's 573 address, to be able to fill in the destination IP address of future 574 Binding Requests. 576 As stated in Section 4.2, if the home agent chooses to respond to 577 a Binding Request for a mobile node that set the `P' bit in its 578 registration, or which has returned home, it MUST send a Binding 579 Update with the care-of address set to the mobile node's home address 580 and with the lifetime set to zero. The home agent may also send 581 such zero-lifetime Binding Updates to correspondent nodes named in 582 a Binding Warning extension to a registration request that has the 583 `P' bit set or which is effecting de-registration of the mobile node. 584 Finally, the home agent MAY also send such zero-lifetime Binding 585 Updates to foreign agents from which the mobile node was previously 586 registered but which are no longer serving the mobile node. This 587 would allow such foreign agents to immediately reclaim any state 588 information that pertained to the mobile node without waiting for the 589 requisite lifetime to expire. 591 When a node receives a Binding Update message, it is required to 592 verify the authentication in the message, using the mobility security 593 association it shares with the sender's home agent. In such cases, 594 the authentication data is found in the Route Optimization or Smooth 595 Handoff authentication extension (Section 5), which is required. If 596 the authentication succeeds, then a binding cache entry SHOULD be 597 updated for use in future transmissions of data to the mobile node. 598 Otherwise, an authentication exception SHOULD be raised. 600 Under all circumstances, the sending of Binding Update messages is 601 subject to the rate limiting restriction described in Section 7.1. 603 When using nonces for replay protection, the identification field in 604 the Binding Update message is used differently, to still allow replay 605 protection even though the Binding Update is not being sent in reply 606 to a request directly from the target node. In this case, the home 607 agent is required to set the high-order 32 bits of the identification 608 field to the value of the nonce that will be used by the home agent 609 in the next Binding Update message sent to this node. The low-order 610 32 bits of the identification field are required to be set to the 611 value of the nonce being used for this message. 613 Thus, on each Binding Update message, the home agent communicates to 614 the target node, the value of the nonce that will be used next time. 615 If no Binding Updates are lost in the network, the home agent and the 616 target node can remain synchronized with respect to the nonces being 617 used. If, however, the target node receives a Binding Update with 618 what it believes to be an incorrect nonce, it MAY resynchronize with 619 the home agent by using a Binding Request message. 621 4.4. Binding Acknowledge Message 623 A Binding Acknowledge message is used to acknowledge receipt of a 624 Binding Update message. It SHOULD be sent by a node receiving a 625 Binding Update message in which the acknowledge (A) bit is set; if in 626 addition that message also contains a valid authentication extension 627 and Identification, the Binding Acknowledge MUST be sent. 629 0 1 2 3 630 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | Type | Reserved | Status | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | Mobile Node Home Address | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | | 637 + Identification + 638 | | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 The format of the Binding Acknowledge message is illustrated above, 642 and contains the following fields: 644 Type 19 646 Status If the Status is nonzero, this acknowledgment is 647 negative. For instance, if the Binding Update was 648 not accepted, but the incoming datagram has the 649 Acknowledge flag set, then the status code should be 650 set appropriately in the Binding Acknowledge message. 652 Reserved Sent as 0; ignored on reception. 654 Mobile Node Home Address 655 Copied from the Binding Update message being 656 acknowledged. 658 Identification 659 Copied from the Binding Update message being 660 acknowledged, if present there. 662 Allowable values for the Status include: 664 128 reason unspecified 665 129 administratively prohibited 666 130 insufficient resources 667 131 sending node failed authentication 668 133 identification mismatch 669 134 poorly formed Binding Update 671 Up-to-date values of the Code field are specified in the most recent 672 "Assigned Numbers" [13]. 674 5. Route Optimization Authentication Extension 676 The Route Optimization Authentication extension is used to 677 authenticate Route Optimization management messages sent with 678 an SPI corresponding to the source IP address of the message. 679 This extension is subtype TBD of the Generalized Authentication 680 Extension [2]. The authenticator value is computed, as before, from 681 the stream of bytes including the shared secret, the UDP payload 682 (that is, the Route Optimization management message), all prior 683 extensions in their entirety, and the type, subtype, length, and SPI 684 of this extension, but not including the authenticator field itself 685 nor the UDP header. This extension is required to be used in any 686 Binding Update message sent by the Home Agent or the Mobile Node. 688 5.1. Modified Registration Request Message 690 One bit is added to the flag bits in the Registration Request message 691 to indicate that the mobile node would like its home agent to keep 692 its mobility binding private. Normally, the home agent sends Binding 693 Update messages to correspondent nodes as needed to allow them to 694 cache the mobile node's binding. If the mobile node sets the private 695 (`P') bit in the Registration Request message, the home agent MUST 696 NOT send the mobile node's binding in any Binding Update message. 697 Instead, each Binding Update message SHOULD give the mobile node's 698 care-of address equal to its home address, and SHOULD give a lifetime 699 value of 0. 701 Thus, the Registration Request message under Route Optimization 702 begins as shown below: 704 0 1 2 3 705 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | Type |S|B|D|M|G|x|T|P| Lifetime | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | (Unchanged ...) 710 +-+-+-+-+-+-+-+-+-+-+-+-+ 712 P The private (`P') bit is set by the node sending the 713 Binding Update message to indicate that the home agent 714 MUST keep its mobility binding private. In any Binding 715 Update message sent by the mobile node's home agent, the 716 care-of address SHOULD be set equal to the mobile node's 717 home address, and the lifetime SHOULD be set equal to 0. 719 The other flag bits are as defined in the base Mobile IP 720 specification [12] and for Reverse Tunneling [8]. 722 6. Format of Smooth Handoff Extensions 724 This section specifies the format for messages which are used 725 to enable smooth handoff from a mobile node's previous foreign 726 agent to its new foreign agent when a mobile node initiates a new 727 registration. 729 6.1. Previous Foreign Agent Notification Extension 731 The Previous Foreign Agent Notification extension MAY be included 732 in a Registration Request message sent to a mobility agent (either 733 a foreign agent or the mobile node's home agent). It instructs the 734 mobility agent to send a Binding Update message to the mobile node's 735 previous foreign agent on behalf of the mobile node, to notify it 736 that the mobile node has moved. The previous foreign agent SHOULD 737 then delete the mobile node's visitor list entry and, if a new 738 care-of address is included in the Binding Update message, create a 739 binding cache entry for the mobile node with its new care-of address. 740 The Previous Foreign Agent Notification extension contains only those 741 values not otherwise already contained in the Registration Request 742 message that are needed for the new foreign agent to construct the 743 Binding Update message. 745 0 1 2 3 746 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | Type | Length | Cache Lifetime | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | Previous Foreign Agent Address | 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 | New Care-of Address | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | SPI | 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | Authenticator ... 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 Type 96 761 Length 14 plus the length of the authenticator 763 Cache Lifetime 764 The number of seconds remaining before the binding 765 cache entry created by the previous foreign agent must 766 be considered expired. A value of all ones indicates 767 infinity. A value of zero indicates that the previous 768 foreign agent MUST NOT create a binding cache entry for 769 the mobile node once it has deleted the mobile node's 770 visitor list entry. The cache lifetime value is copied 771 into the lifetime field of the Binding Update message. 773 Previous Foreign Agent Address 774 The IP address of the mobile node's previous foreign 775 agent to which the new foreign agent should send a 776 Binding Update message on behalf of the mobile node. 778 New Care-of Address 779 The address for the new mobility agent to send in the 780 Binding Update message to the previous foreign agent. 782 SPI Security Parameters Index (4 bytes). An opaque 783 identifier. The SPI is copied over into the Smooth 784 Handoff authentication extension by the new foreign 785 agent. 787 Authenticator 788 The authenticator value to be used in the Route 789 Optimization Authentication extension in the Binding 790 Update message sent by the new foreign agent to the 791 mobile node's previous foreign agent. This authenticator 792 is calculated only over the Binding Update message body. 794 If a binding cache entry is created at the mobile node's previous 795 foreign agent, it is treated in the same way as any other binding 796 cache entry. The New Care-of Address in the extension SHOULD be 797 either the care-of address being registered in the new registration 798 (to cause IP datagrams from the previous foreign agent to be tunneled 799 to the new foreign agent) or the mobile node's home address (to cause 800 the previous foreign agent to delete its visitor list entry only for 801 the mobile node, but not forward datagrams for it). This latter 802 feature is especially valuable when a mobile node returns to its home 803 network. 805 Mobile nodes SHOULD assign a small value to the Cache Lifetime, so 806 that the binding created at the previous foreign agent will not take 807 up space in the foreign agent's binding cache for very long. 809 The Binding Update sent by the mobility agent to the previous 810 foreign agent MUST have the IP address of the foreign agent as the 811 source address in the IP header. Conceptually, the mobility agent 812 is ``forwarding'' a Binding Update to the previous foreign agent, 813 albeit in a way that is specialized to the needs of the mobile 814 node to reestablish connectivity with the fewest number of packet 815 transmissions over its own link. The mobility agent MUST set the `A' 816 bit in the Binding Update message, so that the previous foreign agent 817 will know to send a Binding Acknowledge message back to the mobile 818 node. 820 6.2. Modified Mobility Agent Advertisement Extension 822 Performing smooth handoffs requires one minor change to the existing 823 Mobile IP Mobility Agent Advertisement extension [12]. A new flag 824 bit, the 'S' bit, replaces a previously unused reserved bit in 825 the extension, to indicate that the foreign agent supports smooth 826 handoffs. By default, every foreign agent that supports smooth 827 handoffs SHOULD support at least the establishment of a registration 828 key by using elliptic curve key exchange [11]. 830 0 1 2 3 831 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | Type | Length | Sequence Number | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | Lifetime |R|B|H|F|M|G|x|T|S| reserved | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | ... zero or more Care-of Addresses 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - 840 Thus, the proposed modification to the Mobility Agent Advertisement 841 extension, illustrated above, keeps the advertisement almost the 842 same as in the base Mobile IP specification, except for adding the 843 following bit: 845 S The 'S' smooth handoff bit is set by the foreign agent 846 sending the agent advertisement message to indicate 847 that it supports the smooth handoffs, and thus the 848 Registration Key Request extension [11]. 850 More detailed information about the handling of this extension by 851 foreign agents is deferred until Section 8.1. 853 6.3. Binding Warning Extension 855 A mobile node MAY append a Binding Warning Extension to a 856 Registration Request. The Binding Warning extension is used to 857 advise a mobile node's home agent that one or more correspondent 858 nodes are likely to have either no binding cache entry or an 859 out-of-date binding cache entry for the mobile node sending the 860 Registration Request. 862 0 1 2 3 863 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 | Type | Length | Reserved | 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 | Mobile Node Home Address | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 | Target Node Addresses ... 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 The format of the Binding Warning extension is illustrated above, and 873 contains the following fields: 875 Type 16 877 Reserved Sent as 0; ignored on reception. 879 Mobile Node Home Address 880 The home address of the mobile node to which the 881 Binding Warning message refers. 883 Target Node Addresses 884 One or more addresses of the correspondent nodes that 885 need to receive Binding Update messages. Each node 886 should be the target of a Binding Update message sent 887 by the home agent. 889 When a home agent receives a Binding Warning extension as part of a 890 valid Registration Request, it SHOULD send a Binding Update message 891 to each target node address identified in the Binding Warning, giving 892 it the current binding for the mobile node identified in the mobile 893 node home address field of the Binding Warning. 895 When a mobile node returns to its home network, it SHOULD append 896 a Binding Warning extension to the Registration Request message 897 sent to its Home Agent, instructing its home agent to send Binding 898 Update messages (naturally, with zero lifetimes) to one or more 899 correspondent nodes. It is important for the correspondent nodes 900 to delete their binding cache entries for the mobile node when the 901 mobile node no longer has a Care-of Address. 903 7. Miscellaneous Home Agent Operations 905 7.1. Home Agent Rate Limiting 907 A home agent is required to provide some mechanism to limit the 908 rate at which it sends Binding Update messages to to the same node 909 about any given mobility binding. This rate limiting is especially 910 important because it is expected that, within the short term, most 911 Internet nodes will not support maintenance of a binding cache. In 912 this case, continual transmissions of Binding Update messages will 913 only waste processing resources at the home agent and correspondent 914 node, and along the Internet path between these nodes. 916 7.2. Managing Binding Updates for Correspondent Nodes 918 The home agent MAY keep a list of correspondent nodes from which it 919 has received Binding Acknowledgements for Binding Updates for active 920 registrations (i.e., registrations which have not yet timed out). In 921 this case, when the home agent receives a valid Registration Request, 922 it MAY transmit new Binding Updates to each correspondent node that 923 is on its list for the particular mobile node. In order to know 924 which correspondent nodes correctly received the Binding Updates, the 925 home agent SHOULD set the `A' bit in the Binding Update, requesting 926 an acknowledgement. 928 Rate-limiting MUST be employed by a Home Agent offering this service, 929 as specified in section 7.1. 931 8. Miscellaneous Foreign Agent Operations 933 This section details various operational considerations important 934 for foreign agents wishing to support smooth handoff. This includes 935 processing Previous Foreign Agent Notification extensions, and the 936 maintenance of up-to-date binding cache entries. 938 8.1. Previous Foreign Agent Notification 940 When a foreign agent receives a Previous Foreign Agent Notification 941 extension, it creates a Binding Update for the previous foreign 942 agent, using the specified SPI and precomputed authenticator sent to 943 it by the mobile node. 945 When the previous foreign agent receives the Binding Update, it will 946 authenticate the message using the mobility security association and 947 SPI specified in the Binding Update. If the message authentication 948 is correct, the visitor list entry for this mobile node at the 949 previous foreign agent will be deleted and a Binding Acknowledge 950 message returned to the sender. In addition, if a new care-of 951 address was included in the Binding Update message, the previous 952 foreign agent will create a binding cache entry for the mobile node; 953 the previous foreign agent can then tunnel datagrams to the mobile 954 node's new care-of address using that binding cache, just as any node 955 maintaining a binding cache. The previous foreign agent is also 956 expected to return a Binding Acknowledge message to the mobile node. 958 Note that this Binding Acknowledge is addressed to the mobile node, 959 and SHOULD be tunneled using the new binding cache entry. The 960 tunneled acknowledgment then SHOULD be delivered directly to the 961 new foreign agent, without having to go to the home network. This 962 creates an interesting problem for the new foreign agent when it 963 receives the acknowledgment before the Registration Reply from the 964 home agent. It is suggested that the new foreign agent deliver the 965 acknowledgment to the mobile node anyway, even though the mobile 966 node is technically unregistered. If there is concern that this 967 provides a loophole for unauthorized traffic to the mobile node, the 968 new foreign agent could limit the number of datagrams delivered to 969 the unregistered mobile node to this single instance. Alternatively, 970 a new extension to the Registration Reply message can be defined to 971 carry along the acknowledgment from the previous foreign agent. This 972 latter approach would have the benefit that fewer datagrams would 973 be transmitted over bandwidth-constrained wireless media during 974 registration. 976 When the Binding Acknowledge message from the previous foreign agent 977 is received by the new foreign agent, it detunnels it and sends 978 it to the mobile node. In this way, the mobile node can discover 979 that its previous foreign agent has received the Binding Update 980 message. The mobile node has to be certain that its previous foreign 981 agent has been notified about its new care-of address, because 982 otherwise the previous foreign agent could become a "black hole" 983 for datagrams destined for the mobile node based on out-of-date 984 binding cache entries at other nodes. The new foreign agent has no 985 further responsibility for helping to update the binding cache at the 986 previous foreign agent, and does not retransmit the message even if 987 no acknowledgment is received. 989 If the acknowledgment has not been received after sufficient time, 990 the mobile node is responsible for retransmitting another Binding 991 Update message to its previous foreign agent. Although the previous 992 foreign agent may have already received and processed the Binding 993 Update message (the Binding Acknowledge message may have been lost in 994 transit to the new foreign agent), the mobile node SHOULD continue 995 to retransmit its Binding Update message until the previous foreign 996 agent responds with a Binding Acknowledge. 998 8.2. Maintaining Binding Caches 1000 The binding cache entry built by the previous foreign agent from the 1001 information in the Previous Foreign Agent Notification extension 1002 MAY be deleted from its Binding Cache at any time, and these 1003 cache entries are expected to be created with short lifetimes (see 1004 section 6.1). In this case, the previous foreign agent will be 1005 unable to find a current care-of address for subsequently arriving 1006 tunneled datagrams for the mobile node. 1008 8.3. Rate Limiting 1010 A foreign agent MUST provide some mechanism to limit the rate at 1011 which it sends Binding Warning messages to the same node about any 1012 given mobility binding. This rate limiting is especially important 1013 because it is expected that, within the short term, many Internet 1014 nodes will not support maintenance of a binding cache. In this case, 1015 continual transmissions of Binding Warning messages will only waste 1016 processing resources at the foreign agent and correspondent node, and 1017 along the Internet path between these nodes. 1019 9. Security Considerations 1021 The calculation of the authentication data supplied with the 1022 Route Optimization and Smooth Handoff authentication extensions 1023 in section 5 is specified to be the same as in the base Mobile IP 1024 document for ease of implementation. There is a better method 1025 available (HMAC), specified in RFC 2104 [6]. If the base Mobile IP 1026 specification is updated to use HMAC, then this route optimization 1027 specification SHOULD also be updated similarly. 1029 10. Acknowledgement 1031 Expanding the Binding Warning to allow a mobile node to send a list 1032 of correspondent nodes to the Home Agent was suggested by Mohamad 1033 Khalil, Emad Qaddoura, Haseeb Akhtar, and Liem Le of Nortel Networks. 1034 Pete McCann of Lucent also contributed text specifying additional 1035 considerations under which the home agent could send zero-lifetime 1036 Binding Updates in section 4.3. 1038 References 1040 [1] S. Bradner. Key words for use in RFCs to Indicate Requirement 1041 Levels. Request for Comments (Best Current Practice) 2119, 1042 Internet Engineering Task Force, March 1997. 1044 [2] P. Calhoun and C. E. Perkins. Mobile IP Foreign Agent 1045 Challenge/Response Extension, December 2000. 1047 [3] S. Hanks, T. Li, D. Farinacci, and P. Traina. Generic Routing 1048 Encapsulation (GRE). Request for Comments (Informational) 1701, 1049 Internet Engineering Task Force, October 1994. 1051 [4] S. Hanks, T. Li, D. Farinacci, and P. Traina. Generic Routing 1052 Encapsulation over IPv4 networks. Request for Comments 1053 (Informational) 1702, Internet Engineering Task Force, October 1054 1994. 1056 [5] David B. Johnson. Scalable and Robust Internetwork Routing 1057 for Mobile Hosts. In Proceedings of the 14th International 1058 Conference on Distributed Computing Systems, pages 2--11, June 1059 1994. 1061 [6] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing 1062 for Message Authentication. Request for Comments 1063 (Informational) 2104, Internet Engineering Task Force, 1064 February 1997. 1066 [7] D. Maughan, M. Schertler, M. Schneider, and J. Turner. Internet 1067 Security Association and Key Management Protocol (ISAKMP). 1068 Request for Comments (Proposed Standard) 2408, Internet 1069 Engineering Task Force, November 1998. 1071 [8] G. Montenegro. Reverse Tunneling for Mobile IP. Request for 1072 Comments (Proposed Standard) 2344, Internet Engineering Task 1073 Force, May 1998. 1075 [9] C. Perkins. IP Encapsulation within IP. Request for Comments 1076 (Proposed Standard) 2003, Internet Engineering Task Force, 1077 October 1996. 1079 [10] C. Perkins. Minimal Encapsulation within IP. Request for 1080 Comments (Proposed Standard) 2004, Internet Engineering Task 1081 Force, October 1996. 1083 [11] C. Perkins and D. Johnson. Registration Keys for Route 1084 Optimization (work in progress). Internet Draft, Internet 1085 Engineering Task Force, December 1997. 1087 [12] C. Perkins, Editor. IP Mobility Support version 2 (work in 1088 progress). 1089 draft-ietf-mobileip-rfc2002-bis-03.txt, September 2000. 1091 [13] J. Reynolds and J. Postel. Assigned Numbers. Request for 1092 Comments (Standard) 1700, Internet Engineering Task Force, 1093 October 1994. 1095 A. Mobility Security Association Management 1097 One of the most difficult aspects of Route Optimization for Mobile IP 1098 in the Internet today is that of providing authentication for all 1099 messages that affect the routing of datagrams to a mobile node. 1100 In the base Mobile IP protocol, only the home agent is aware of 1101 the mobile node's mobility binding and only the home agent tunnels 1102 datagrams to the mobile node. Thus, all routing of datagrams to the 1103 mobile node while away from its home network is controlled by the 1104 home agent. Authentication is currently achieved based on a manually 1105 established mobility security association between the home agent and 1106 the mobile node. Since the home agent and the mobile node are both 1107 owned by the same organization (both are assigned IP addresses within 1108 the same IP subnet), this manual configuration is manageable, and 1109 (for example) can be performed while the mobile node is at home. 1111 However, with Route Optimization, authentication is more difficult 1112 to manage, since a Binding Update may in general need to be sent to 1113 almost any node in the Internet. Since no authentication or key 1114 distribution protocol is generally available in the Internet today, 1115 the Route Optimization procedures defined in this document MAY make 1116 use of the same type of manual key distribution discussed in the base 1117 Mobile IP protocol. For use with Route Optimization, a mobility 1118 security association held by a correspondent node or a foreign agent 1119 must include the same parameters as required by base Mobile IP [12]. 1121 For a correspondent node to be able to create a binding cache entry 1122 for a mobile node, the correspondent node needs a mobility security 1123 association with either the mobile node or its home agent. This 1124 mobility security association, though, could be used in creating 1125 and updating binding cache entries at this correspondent node for 1126 all mobile nodes served by this home agent. Doing so places the 1127 correspondent node in a fairly natural relationship with respect 1128 to the mobile nodes served by this home agent. For example, the 1129 mobile nodes may represent different people affiliated with the 1130 same organization owning the home agent, with which the user of the 1131 correspondent node often collaborates. The effort of establishing 1132 such a mobility security association with the relevant home agent may 1133 be more manageable (appendix B) than the effort of doing so with each 1134 mobile node. It is similarly possible for a home agent to have a 1135 manually established mobility security association with the foreign 1136 agents often used by its mobile nodes, or for a particular mobile 1137 node to have a manually established mobility security association 1138 with the foreign agents serving the foreign networks that it often 1139 visits. 1141 In general, if the movement and communication patterns of a mobile 1142 node or the group of mobile nodes served by the same home agent are 1143 sufficient to justify establishing a mobility security association 1144 with the mobile node's home agent, users or network administrators 1145 are likely to do so. Without establishing a mobility security 1146 association, nodes will not currently be able to authenticate the 1147 values transmitted in Route Optimization extensions. 1149 B. Using a Master Key at the Home Agent 1151 Rather than storing each mobility security association that it has 1152 established with many different correspondent nodes and foreign 1153 agents, a home agent MAY manage its mobility security associations so 1154 that each of them can be generated from a single master key. With 1155 the master key, the home agent could build a key for any given other 1156 node, for example by computing the node-specific key as 1158 MD5(node-address | master-key | node-address) 1160 where node-address is the IP address of the particular node for which 1161 the home agent is building a key, and master-key is the single master 1162 key held by the home agent for all mobility security associations it 1163 has established with correspondent nodes. The node-specific key is 1164 built by computing an MD5 hash over a string consisting of the master 1165 key with the node-address concatenated as a prefix and as a suffix. 1167 Using this scheme, when establishing each mobility security 1168 association, the network administrator managing the home agent 1169 computes the node-specific key and communicates this key to the 1170 network administrator of the other node through some secure channel, 1171 such as over the telephone. The mobility security association 1172 is configured at this other node in the same way as any mobility 1173 security association. At the home agent, though, no record need be 1174 kept that this key has been given out. The home agent need only be 1175 configured to know that this scheme is in use for all of its mobility 1176 security associations (perhaps only for specific set of its mobile 1177 nodes). 1179 When the home agent needs a mobility security association as part 1180 of Route Optimization, it builds the node-specific key based on the 1181 master key and the IP address of the other node with which it is 1182 attempting to authenticate. If the other node knows the correct 1183 node-specific key, the authentication will succeed; otherwise, it 1184 will fail as it should. 1186 Addresses 1188 The working group can be contacted via the current chairs: 1190 Basavaraj Patil Phil Roberts 1191 Nokia Corporation Megisto Corp. 1192 6000 Connection Drive Suite 120 1193 M/S M8-540 20251 Century Blvd 1194 Irving, TX 75039 Germantown MD 20874 1195 USA USA 1196 Phone: +1 972-894-6709 Phone: +1 847-202-9314 1197 Fax : +1 972-894-5349 1198 EMail: Raj.Patil@nokia.com Email: PRoberts@MEGISTO.com 1200 Questions about this memo can also be directed to the authors: 1202 Charles E. Perkins David B. Johnson 1203 Communications Systems Lab Dept. Computer Science - MS 132 1204 Nokia Research Center 6100 Main Street 1205 313 Fairchild Drive Houston, Texas 77005-1892 1206 Mountain View, California 94043 Rice University 1207 USA USA 1208 Phone: +1-650 625-2986 Phone: +1-713-348-3063 1209 Fax: +1 650 625-2502 Fax: +1-713-348-5930 1210 EMail: charliep@iprg.nokia.com E-mail: dbj@cs.rice.edu