idnits 2.17.1 draft-ietf-mobileip-optim-08.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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. ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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) -- Unexpected draft version: The latest known version of draft-ietf-ipsec-skip is -06, but you're referring to -07. -- Possible downref: Normative reference to a draft: ref. '1' ** 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') == Outdated reference: A later version (-09) exists of draft-ietf-ipsec-isakmp-08 ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-isakmp (ref. '7') == Outdated reference: A later version (-03) exists of draft-ietf-mobileip-regkey-00 -- Possible downref: Normative reference to a draft: ref. '10' -- Possible downref: Normative reference to a draft: ref. '11' ** Obsolete normative reference: RFC 2002 (ref. '12') (Obsoleted by RFC 3220) -- Possible downref: Non-RFC (?) normative reference: ref. '13' Summary: 14 errors (**), 0 flaws (~~), 4 warnings (==), 8 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 Sun Microsystems 3 25 Feburary 1999 David B. Johnson 4 Carnegie Mellon University 6 Route Optimization in Mobile IP 8 draft-ietf-mobileip-optim-08.txt 10 Status of This Memo 12 This document is a submission by the Mobile IP Working Group of the 13 Internet Engineering Task Force (IETF). Comments should be submitted 14 to the mobile-ip@SmallWorks.COM mailing list. 16 Distribution of this memo is unlimited. 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at 26 any time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at: 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at: 35 http://www.ietf.org/shadow.html. 37 Abstract 39 This document defines extensions to the base Mobile IP protocol to 40 allow for optimization of datagram routing from a correspondent 41 node to a mobile node. Without Route Optimization, all datagrams 42 destined to a mobile node are routed through that mobile node's home 43 agent, which then tunnels each datagram to the mobile node's current 44 location. The protocol extensions described here provide a means 45 for correspondent nodes to cache the binding of a mobile node and to 46 then tunnel their own datagrams for the mobile node directly to that 47 location, bypassing the route for each datagram through the mobile 48 node's home agent. Extensions are also provided to allow datagrams 49 in flight when a mobile node moves, and datagrams sent based on an 50 out-of-date cached binding, to be forwarded directly to the mobile 51 node's new binding. 53 Contents 55 Status of This Memo i 57 Abstract i 59 1. Introduction 1 61 2. Terminology 2 63 3. Route Optimization Overview 2 64 3.1. Binding Caches . . . . . . . . . . . . . . . . . . . . . 3 65 3.2. Foreign Agent Smooth Handoff . . . . . . . . . . . . . . 4 67 4. Route Optimization Message Formats 6 68 4.1. Binding Warning Message . . . . . . . . . . . . . . . . . 6 69 4.2. Binding Request Message . . . . . . . . . . . . . . . . . 7 70 4.3. Binding Update Message . . . . . . . . . . . . . . . . . 8 71 4.4. Binding Acknowledge Message . . . . . . . . . . . . . . . 11 72 4.5. Route Optimization Authentication Extension . . . . . . . 12 73 4.6. Modified Registration Request Message . . . . . . . . . . 12 75 5. Format of Smooth Handoff Extensions 13 76 5.1. Previous Foreign Agent Notification Extension . . . . . . 13 77 5.2. Modified Mobility Agent Advertisement Extension . . . . . 15 79 6. Binding Warning Extension 16 81 7. Miscellaneous Home Agent Operations 17 82 7.1. Home Agent Rate Limiting . . . . . . . . . . . . . . . . 17 83 7.2. Mobility Security Association Management . . . . . . . . 17 84 7.3. Managing Binding Updates for Correspondent Nodes . . . . 18 86 8. Miscellaneous Foreign Agent Operations 18 87 8.1. Previous Foreign Agent Notification . . . . . . . . . . . 18 88 8.2. Maintaining Binding Caches . . . . . . . . . . . . . . . 20 89 8.3. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . 20 91 9. Security Considerations 20 93 10. Summary 20 95 11. Acknowledgement 21 97 A. Using a Master Key at the Home Agent 21 99 References 23 101 Chairs' Addresses 24 102 1. Introduction 104 The base Mobile IP protocol [12], allows any mobile node to move 105 about, changing its point of attachment to the Internet, while 106 continuing to be identified by its home IP address. Correspondent 107 nodes sending IP datagrams to a mobile node at its home address 108 in the same way as with any other destination. This scheme 109 allows transparent interoperation between mobile nodes and their 110 correspondent nodes, but forces all datagrams for a mobile node to 111 be routed through its home agent. Thus, datagrams to the mobile 112 node are often routed along paths that are significantly longer than 113 optimal. For example, if a mobile node is visiting some subnet, 114 even datagrams from a correspondent node on the same subnet must be 115 routed through the Internet to the mobile node's home agent (on its 116 home network), only then to be tunneled back to the original subnet 117 for final delivery. This indirect routing delays the delivery of the 118 datagrams to mobile nodes, and places an unnecessary burden on the 119 networks and routers along their paths through the Internet. 121 In this document, we will define extensions to the operation of 122 the base Mobile IP protocol to allow for better routing, so that 123 datagrams can be routed from a correspondent node to a mobile node 124 without going to the home agent first. We refer collectively to 125 these extensions as Route Optimization. 127 Route Optimization extensions provide a means for nodes to cache 128 the binding of a mobile node and to then tunnel their own datagrams 129 directly to the care-of address indicated in that binding, bypassing 130 the mobile node's home agent. Extensions are also provided to allow 131 datagrams in flight when a mobile node moves, and datagrams sent 132 based on an out-of-date cached binding, to be forwarded directly to 133 the mobile node's new care-of address. 135 All operation of Route Optimization that changes the routing of IP 136 datagrams to the mobile node is authenticated using the same type of 137 mechanisms used in the base Mobile IP protocol. This authentication 138 generally relies on a mobility security association established 139 in advance between the sender and receiver of such messages. The 140 association can be created using ISAKMP [7], SKIP [1], or any of the 141 registration key establishment methods specified in [10]. 143 After Section 2 gives some extra terminology, Section 3 provides 144 an overview of the basic protocol operations associated with 145 Route Optimization. Section 4 defines the message types used 146 to update binding caches. Subsequent sections show the formats 147 for the messages, explaining the function of fields within each 148 message. Home agent considerations in Section 7, and foreign agent 149 considerations in Section 8. 151 2. Terminology 153 This document introduces the following terminology, in addition to 154 that used to describe the base Mobile IP protocol: 156 Binding cache 158 A cache of mobility bindings of mobile nodes, maintained by a 159 node for use in tunneling datagrams to those mobile nodes. 161 Binding update 163 A message indicating a mobile node's current mobility binding, 164 and in particular its care-of address. 166 Registration Lifetime 168 The registration lifetime is the time duration for which a 169 binding is valid. The term remaining registration lifetime 170 means the amount of time remaining for which a registration 171 lifetime is still valid, at some time after the registration 172 was approved by the home agent. 174 Security Parameters Index (SPI) 176 An index identifying a security context between a pair of 177 nodes among the contexts available in the Mobility Security 178 Association. SPI values 0 through 255 are reserved and MUST 179 NOT be used in any Mobility Security Association. 181 Triangle Routing 183 A situation in which a Correspondent Host's packets to a Mobile 184 Host follow a path which is longer than the optimal path 185 because the packets must be forwarded to the Mobile Host via a 186 Home Agent. 188 This protocol specification uses conventional meanings [2] for 189 capitalized words such as MUST, SHOULD, etc., to indicate requirement 190 levels for various protocol features. 192 3. Route Optimization Overview 194 This section provides an overview of the protocols and operations of 195 Route Optimization. These can be divided into two main parts: 197 1. Updating binding caches 198 2. Managing smooth handoffs between foreign agents 200 The first part of the document goes into detail about binding cache 201 maintenance, and then smooth handoff is considered. 203 3.1. Binding Caches 205 Route Optimization provides a means for any node to maintain a 206 binding cache containing the care-of address of one or more mobile 207 nodes. When sending an IP datagram to a mobile node, if the sender 208 has a binding cache entry for the destination mobile node, it may 209 tunnel the datagram directly to the care-of address indicated in the 210 cached mobility binding. 212 In the absence of any binding cache entry, datagrams destined for a 213 mobile node will be routed to the mobile node's home network in the 214 same way as any other IP datagram, and then tunneled to the mobile 215 node's current care-of address by the mobile node's home agent. 216 This is the only routing mechanism supported by the base Mobile IP 217 protocol. With Route Optimization, as a side effect of this indirect 218 routing of a datagram to a mobile node, the original sender of the 219 datagram may be informed of the mobile node's current mobility 220 binding, giving the sender an opportunity to cache the binding. 222 Any node may maintain a binding cache to optimize its own 223 communication with mobile nodes. A node may create or update a 224 binding cache entry for a mobile node only when it has received 225 and authenticated the mobile node's mobility binding. As before, 226 each binding in the binding cache also has an associated lifetime, 227 specified in the Binding Update message in which the node obtained 228 the binding. After the expiration of this time period, the binding 229 is deleted from the cache. In addition, a node cache may use any 230 reasonable strategy for managing the space within the binding cache. 231 When a new entry needs to be added to the binding cache, the node may 232 choose to drop any entry already in the cache, if needed, to make 233 space for the new entry. For example, a least-recently used (LRU) 234 strategy for cache entry replacement is likely to work well. 236 When a mobile node's home agent intercepts a datagram from the home 237 network and tunnels it to the mobile node, the home agent may deduce 238 that the original source of the datagram has no binding cache entry 239 for the destination mobile node. The home agent should then send 240 a Binding Update message to the original source node, informing it 241 of the mobile node's current mobility binding. No acknowledgment 242 for such a Binding Update message is needed, since additional future 243 datagrams from this source node intercepted by the home agent for the 244 mobile node will cause transmission of another Binding Update. For 245 a Binding Update to be authenticated by the original source node, 246 the source node and the home agent must have established a mobility 247 security association. 249 Similarly, when any node (e.g., a foreign agent) receives a tunneled 250 datagram, if it has a binding cache entry for the destination mobile 251 node (and thus has no visitor list entry for this mobile node), the 252 node receiving this tunneled datagram may deduce that the tunneling 253 node has an out-of-date binding cache entry for this mobile node. 254 In this case, the receiving node should send a Binding Warning 255 message to the mobile node's home agent, advising it to send a 256 Binding Update message to the node that tunneled this datagram. The 257 mobile node's home agent can be determined from the binding cache 258 entry, because the home agent address is learned from the Binding 259 Update that established this cache entry. The address of the node 260 that tunneled this datagram can be determined from the datagram's 261 header, since the address of the node tunneling this datagram is 262 the outer source address of the encapsulated datagram. As in the 263 case of a Binding Update sent by the mobile node's home agent, no 264 acknowledgment of this Binding Warning is needed, since additional 265 future datagrams for the mobile node tunneled by the same node will 266 cause the transmission of another Binding Warning. However, unlike 267 the Binding Update message, no authentication of the Binding Warning 268 message is necessary, since it does not directly affect the routing 269 of IP datagrams to the mobile node. 271 When sending an IP datagram, if the sending node has a binding cache 272 entry for the destination node, it should tunnel the datagram to the 273 mobile node's care-of address using the encapsulation techniques used 274 by home agents, and described in [8, 9, 3, 4]. 276 3.2. Foreign Agent Smooth Handoff 278 When a mobile node moves and registers with a new foreign agent, the 279 base Mobile IP protocol does not notify the mobile node's previous 280 foreign agent. IP datagrams intercepted by the home agent after 281 the new registration are tunneled to the mobile node's new care-of 282 address, but datagrams in flight that had already been intercepted 283 by the home agent and tunneled to the old care-of address when 284 the mobile node moved are likely to be lost and are assumed to be 285 retransmitted by higher-level protocols if needed. The old foreign 286 agent eventually deletes its visitor list entry for the mobile node 287 after the expiration of the registration lifetime. 289 Route Optimization provides a means for the mobile node's previous 290 foreign agent to be reliably notified of the mobile node's new 291 mobility binding, allowing datagrams in flight to the mobile 292 node's previous foreign agent to be forwarded to its new care-of 293 address. This notification also allows any datagrams tunneled to 294 the mobile node's previous foreign agent, from correspondent nodes 295 with out-of-date binding cache entries for the mobile node, to be 296 forwarded to its new care-of address. Finally, this notification 297 allows any resources consumed by the mobile node at the previous 298 foreign agent (such as radio channel reservations) to be released 299 immediately, rather than waiting for its registration lifetime to 300 expire. 302 As part of the registration procedure, the mobile node may 303 request that its new foreign agent attempt to notify its previous 304 foreign agent on its behalf, by including a Previous Foreign Agent 305 Notification extension in its Registration Request message sent to 306 the new foreign agent. The new foreign agent then builds a Binding 307 Update message and transmits it to the mobile node's previous foreign 308 agent as part of registration, requesting an acknowledgment from the 309 previous foreign agent. The extension includes only those values 310 needed to construct the Binding Update message that are not already 311 contained in the Registration Request message. The authenticator for 312 the Binding Update message is computed by the mobile node using the 313 security association shared with its previous foreign agent. This 314 notification will typically include the mobile node's new care-of 315 address, allowing the previous foreign agent to create a binding 316 cache entry for the mobile node to serve as a forwarding pointer [5] 317 to its new location. Any tunneled datagrams for the mobile node that 318 arrive at its previous foreign agent after the forwarding pointer has 319 been created can then be re-tunneled to the mobile node's new care-of 320 address. 322 For this smooth handoff to be secure, during registration with a 323 new foreign agent, the mobile node and the foreign agent have to 324 have a security association. The security association is used to 325 authenticate the notification sent to the previous foreign agent. 327 The Mobility Agent Advertisement extension of the agent advertisement 328 message is revised under Route Optimization to include a bit 329 indicating that the foreign agent sending the advertisement supports 330 smooth handoffs. 332 The mobile node is responsible for occasionally retransmitting a 333 Binding Update message to its previous foreign agent until the 334 matching Binding Acknowledge message is received, or until the 335 mobile node can be sure that foreign agent has expired its binding. 336 The mobile node is likely to select a small timeout value for the 337 lifetime available to such bindings sent to previous foreign agents. 339 4. Route Optimization Message Formats 341 Route Optimization defines four message types used for management 342 of binding cache entries. These message types fit in the numbering 343 space defined in the base Mobile IP specification for messages sent 344 to UDP port 434. Each of these messages begins with a one-octet 345 field indicating the type of the message. The binding cache 346 management messages in this section are carried by way of UDP, sent 347 to port 434. 349 The following type codes are defined in this document: 351 16 Binding Warning message 352 17 Binding Request message 353 18 Binding Update message 354 19 Binding Acknowledge message 356 Route Optimization also requires one minor change to existing 357 Mobile IP messages: a new flag bit must be added to the Registration 358 Request message, replacing a previously unused, reserved bit in the 359 message. 361 This section describes each of the new Route Optimization messages 362 and the change to Registration Request message. 364 4.1. Binding Warning Message 366 A Binding Warning message is used to transmit advice that one or 367 more correspondent nodes or foreign agents are likely to have either 368 no binding cache entry or an out-of-date binding cache entry for 369 some mobile node. When any node detunnels a datagram destined for 370 the mobile node, if it is not the current foreign agent for the 371 destination mobile node, it SHOULD send a Binding Warning message to 372 the mobile node's home agent. 374 0 1 2 3 375 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 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Type | Reserved | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Mobile Node Home Address | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Target Node Addresses ... 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 The format of the Binding Warning message is illustrated above, and 385 contains the following fields: 387 Type 16 389 Reserved Sent as 0; ignored on reception. 391 Mobile Node Home Address 392 The home address of the mobile node to which the Binding 393 Warning message refers. 395 Target Node Addresses 396 One or more addresses of nodes that need to receive 397 Binding Update messages. Each node should be the target 398 of a Binding Update message sent by the home agent. 400 A home agent will receive a Binding Warning message if a node 401 maintaining a binding cache entry for one of the home agent's mobile 402 nodes uses an out-of-date entry. When a home agent receives a 403 Binding Warning message, it should send a Binding Update message to 404 each target node address identified in the Binding Warning, giving it 405 the current binding for the mobile node identified in the mobile node 406 home address field of the Binding Warning. 408 When a mobile node receives a new Care-of Address, it MAY send a 409 Binding Warning message to its Home Agent, requesting that the home 410 agent send Binding Update messages to one or more correspondent 411 nodes. This feature MAY be used by the mobile node when it returns 412 to its home network, so that the Home Agent will send out Binding 413 Updates with zero lifetimes to all the mobile node's correspondent 414 nodes. It is important for the correspondent nodes to delete their 415 binding cache entries for the mobile node when the mobile node no 416 longer has a Care-of Address. 418 4.2. Binding Request Message 420 A Binding Request message is used by a node to request a mobile 421 node's current mobility binding from the mobile node's home agent. 423 0 1 2 3 424 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 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Type | Reserved | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Mobile Node Home Address | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | | 431 + Identification + 432 | | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 The format of the Binding Request message is illustrated above, and 435 contains the following fields: 437 Type 17 439 Reserved Sent as 0; ignored on reception. 441 Mobile Node Home Address 442 The home address of the mobile node to which the Binding 443 Request refers. 445 Identification 446 A 64-bit sequence number, assigned by the node sending 447 the Binding Request message, used to assist in matching 448 requests with replies, and in protecting against replay 449 attacks. 451 When the home agent receives a Binding Request message, it consults 452 its home list and determines the correct binding information to be 453 sent to the requesting node. Before satisfying the request, the home 454 agent is required to check whether or not the mobile node has allowed 455 the information to be disseminated. If the mobile node specified 456 the private (P) bit in its Registration Request message, then the 457 home agent must make no further attempt to satisfy Binding Requests 458 on behalf of that mobile node. In this case, the home agent should 459 return a Binding Update in which both the care-of address is set 460 equal to the mobile node's home address and the lifetime is set to 461 zero. Such a Binding Update message indicates that the binding cache 462 entry for the specified mobile node should be deleted. 464 4.3. Binding Update Message 466 The Binding Update message is used for notification of a mobile 467 node's current mobility binding. It should be sent by the mobile 468 node's home agent in response to a Binding Request message, a Binding 469 Warning message, or the reception of a Binding Warning extension to 470 a Registration Request. It should also be sent by a mobile node, or 471 by the foreign agent with which the mobile node is registering, when 472 notifying the mobile node's previous foreign agent that the mobile 473 node has moved. 475 0 1 2 3 476 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 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Type |A|I|M|G| Rsvd | Lifetime | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Mobile Node Home Address | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | Care-of Address | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | | 485 + Identification + 486 | | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Extensions ... 489 +-+-+-+-+-+-+-+- 491 The format of the Binding Update message is illustrated above, and 492 contains the following fields: 494 Type 18 496 A The 'A' (acknowledge) bit is set by the node sending the 497 Binding Update message to request a Binding Acknowledge 498 message be returned. 500 I The 'I' (identification present) bit is set by the node 501 sending the Binding Update message if the identification 502 field is present in the message. 504 M If the 'M' (minimal encapsulation) bit is set, datagrams 505 may be tunneled to the mobile node using the minimal 506 encapsulation protocol [9]. 508 G If the 'G' (Generic Record Encapsulation, or GRE) bit is 509 set, datagrams may be tunneled to the mobile node using 510 GRE [3]. 512 Rsvd Reserved. Sent as 0; ignored on reception. 514 Lifetime The number of seconds remaining before the binding cache 515 entry must be considered expired. A value of all ones 516 indicates infinity. A value of zero indicates that no 517 binding cache entry for the mobile node should be created 518 and that any existing binding cache entry (and visitor 519 list entry, in the case of a mobile node's previous 520 foreign agent) for the mobile node should be deleted. 521 The lifetime is typically equal to the remaining lifetime 522 of the mobile node's registration. 524 Mobile Node Home Address 525 The home address of the mobile node to which the Binding 526 Update message refers. 528 Care-of Address 529 The current care-of address of the mobile node. When set 530 equal to the home address of the mobile node, the Binding 531 Update message instead indicates that no binding cache 532 entry for the mobile node should be created, and any 533 existing binding cache entry (and visitor list entry, in 534 the case of a mobile node's previous foreign agent) for 535 the mobile node should be deleted. 537 Identification 538 If present, a 64-bit number, assigned by the node sending 539 the Binding Request message, used to assist in matching 540 requests with replies, and in protecting against replay 541 attacks. 543 Each Binding Update message indicates the binding's maximum lifetime. 544 When sending the Binding Update message, the home agent should set 545 this lifetime to the remaining registration lifetime. A node wanting 546 to provide continued service with a particular binding cache entry 547 may attempt to reconfirm that mobility binding before the expiration 548 of the registration lifetime. Such reconfirmation of a binding cache 549 entry may be appropriate when the node has indications (such as an 550 open transport-level connection to the mobile node) that the binding 551 cache entry is still needed. This reconfirmation is performed by 552 the node sending a Binding Request message to the mobile node's 553 home agent, requesting it to reply with the mobile node's current 554 mobility binding in a new Binding Update message. Note that the node 555 maintaining the binding should also keep track of the home agent's 556 address, to be able to fill in the destination IP address of future 557 Binding Requests. 559 When a node receives a Binding Update message, it is required to 560 verify the authentication in the message, using the mobility security 561 association it shares with the mobile node's home agent. The 562 authentication data is found in the Route Optimization Authentication 563 extension (Section 4.5), which is required. If the authentication 564 succeeds, then a binding cache entry should be updated for use in 565 future transmissions of data to the mobile node. Otherwise, an 566 authentication exception should be raised. 568 Under all circumstances, the sending of Binding Update messages is 569 subject to the rate limiting restriction described in Section 7.1. 571 When using nonces for replay protection, the identification field in 572 the Binding Update message is used differently in this case, to still 573 allow replay protection even though the Binding Update is not being 574 sent in reply to a request directly from the target node. In this 575 case, the home agent is required to set the high-order 32 bits of the 576 identification field to the value of the nonce that will be used by 577 the home agent in the next Binding Update message sent to this node. 578 The low-order 32 bits of the identification field are required to be 579 set to the value of the nonce being used for this message. 581 Thus, on each Binding Update message, the home agent communicates to 582 the target node, the value of the nonce that will be used next time, 583 and if no Binding Updates are lost in the network, the home agent and 584 the target node can remain synchronized with respect to the nonces 585 being used. If, however, the target node receives a Binding Update 586 with what it believes to be an incorrect nonce, it may resynchronize 587 with the home agent by using a Binding Request message. 589 4.4. Binding Acknowledge Message 591 A Binding Acknowledge message is used to acknowledge receipt of a 592 Binding Update message. It should be sent by a node receiving a 593 Binding Update message if the acknowledge (A) bit is set in the 594 Binding Update message. 596 0 1 2 3 597 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 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | Type | Reserved | Status | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Mobile Node Home Address | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | | 604 + Identification + 605 | | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 The format of the Binding Acknowledge message is illustrated above, 609 and contains the following fields: 611 Type 19 613 Status If the Status is nonzero, this acknowledgment is 614 negative. For instance, if the Binding Update was 615 not accepted, but the incoming datagram has the 616 Acknowledge flag set, then the status code should be set 617 appropriately in the Binding Acknowledge message. 619 Reserved Sent as 0; ignored on reception. 621 Mobile Node Home Address 622 Copied from the Binding Update message being 623 acknowledged. 625 Identification 626 Copied from the Binding Update message being 627 acknowledged, if present there. 629 Allowable values for the Status include: 631 128 reason unspecified 632 129 administratively prohibited 633 130 insufficient resources 634 131 sending node failed authentication 635 133 identification mismatch 636 134 poorly formed Binding Update 638 Up-to-date values of the Code field are specified in the most recent 639 "Assigned Numbers" [13]. 641 4.5. Route Optimization Authentication Extension 643 The Route Optimization Authentication extension is used to 644 authenticate certain Route Optimization management messages. It has 645 the same format and default algorithm support requirements as the 646 three authentication extensions defined for base Mobile IP [12], but 647 is distinguished by its type, which is 35. The authenticator value 648 is computed, as before, from the stream of bytes including the shared 649 secret, the UDP payload (that is, the Route Optimization management 650 message), all prior extensions in their entirety, and the type and 651 length of this extension, but not including the authenticator field 652 itself nor the UDP header. This extension is required to be used in 653 any Binding Update message. 655 4.6. Modified Registration Request Message 657 One bit is added to the flag bits in the Registration Request message 658 to indicate that the mobile node would like its home agent to keep 659 its mobility binding private. Normally, the home agent sends Binding 660 Update messages to correspondent nodes as needed to allow them to 661 cache the mobile node's binding. If the mobile node sets the private 662 ('P') bit in the Registration Request message, the home agent MUST 663 NOT send the mobile node's binding in any Binding Update message. 664 Instead, each Binding Update message should give the mobile node's 665 care-of address equal to its home address, and should give a lifetime 666 value of 0. 668 Thus, the Registration Request message under Route Optimization 669 begins as shown below: 671 0 1 2 3 672 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 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | Type |S|B|D|M|G|V|P|r| Lifetime | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 | (Unchanged ...) 677 +-+-+-+-+-+-+-+-+-+-+-+-+ 679 P The private ('P') bit is set by the node sending the 680 Binding Update message to indicate that the home agent 681 should keep its mobility binding private. In any Binding 682 Update message sent by the mobile node's home agent, the 683 care-of address should be set equal to the mobile node's 684 home address, and the lifetime should be set equal to 0. 686 r reserved 688 5. Format of Smooth Handoff Extensions 690 This section specifies the format for messages which are used 691 to enable smooth handoff from a mobile node's previous foreign 692 agent to its new foreign agent when a mobile node initiates a new 693 registration. 695 5.1. Previous Foreign Agent Notification Extension 697 The Previous Foreign Agent Notification extension may be included in 698 a Registration Request message sent to a foreign agent. It requests 699 the new foreign agent to send a Binding Update message to the mobile 700 node's previous foreign agent on behalf of the mobile node, to notify 701 it that the mobile node has moved. The previous foreign agent may 702 then delete the mobile node's visitor list entry and, if a new 703 care-of address is included in the Binding Update message, create a 704 binding cache entry for the mobile node with its new care-of address. 705 The Previous Foreign Agent Notification extension contains only those 706 values not otherwise already contained in the Registration Request 707 message that are needed for the new foreign agent to construct the 708 Binding Update message. 710 0 1 2 3 711 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 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 | Type | Length | Cache Lifetime | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | Previous Foreign Agent Address | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | New Care-of Address Address | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | SPI | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | Authenticator ... 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 Type 96 726 Length 14 plus the length of the authenticator 728 Cache Lifetime 729 The number of seconds remaining before the binding 730 cache entry created by the previous foreign agent must 731 be considered expired. A value of all ones indicates 732 infinity. A value of zero indicates that the previous 733 foreign agent should not create a binding cache entry for 734 the mobile node once it has deleted the mobile node's 735 visitor list entry. The cache lifetime value is copied 736 into the lifetime field of the Binding Update message. 738 Previous Foreign Agent Address 739 The IP address of the mobile node's previous foreign 740 agent to which the new foreign agent should send a 741 Binding Update message on behalf of the mobile node. 743 New Care-of Address 744 The new care-of address for the new foreign agent to send 745 in the Binding Update message to the previous foreign 746 agent. This should be either the care-of address being 747 registered in this new registration (i.e., to cause IP 748 datagrams from the previous foreign agent to be tunneled 749 to the new foreign agent) or the mobile node's home 750 address (i.e., to cause the previous foreign agent to 751 delete its visitor list entry only for the mobile node, 752 but not forward datagrams for it). 754 SPI Security Parameters Index (4 bytes). An opaque 755 identifier. The SPI is copied over into the Route 756 Optimization Authentication extension by the new foreign 757 agent. 759 Authenticator 760 The authenticator value to be used in the Route 761 Optimization Authentication extension in the Binding 762 Update message sent by the new foreign agent to the 763 mobile node's previous foreign agent. This authenticator 764 is calculated only over the Binding Update message body. 766 The binding cache entry created at the mobile node's previous 767 foreign agent is treated in the same way as any other binding cache 768 entry [12]. 770 5.2. Modified Mobility Agent Advertisement Extension 772 Performing smooth handoffs requires one minor change to the existing 773 Mobile IP Mobility Agent Advertisement extension [12]. A new flag 774 bit, the 'S' bit, replaces a previously unused reserved bit in 775 the extension, to indicate that the foreign agent supports smooth 776 handoffs. By default, every foreign agent that supports smooth 777 handoffs SHOULD support at least the establishment of a registration 778 key [10] by using Diffie-Hellman key exchange. 780 0 1 2 3 781 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 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 | Type | Length | Sequence Number | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | Lifetime |R|B|H|F|M|G|V|T|S| reserved | 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | ... zero or more Care-of Addresses 788 +-+-+- 790 Thus, the proposed modification to the Mobility Agent Advertisement 791 extension, illustrated above, keeps the advertisement almost the same 792 as in the base Mobile IP specification, except for adding following 793 bit: 795 S The 'S' smooth handoff bit is set by the foreign agent 796 sending the agent advertisement message to indicate 797 that it supports the smooth handoffs, and thus the 798 Registration Key Request and Diffie-Hellman Registration 799 Key Reply extensions [10]. 801 More detailed information about the handling of this extension by 802 foreign agents is deferred until Section 8.1. 804 6. Binding Warning Extension 806 A mobile node may append a Binding Warning Extension to a 807 Registration request. The Binding Warning extension is used to 808 advise a mobile node's home agent that one or more correspondent 809 nodes are likely to have either no binding cache entry or an 810 out-of-date binding cache entry for the mobile node sending the 811 Registration Request. 813 0 1 2 3 814 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 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 | Type | Length | Reserved | 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | Mobile Node Home Address | 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 | Target Node Addresses ... 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 The format of the Binding Warning extension is illustrated above, and 824 contains the following fields: 826 Type TBD 828 Reserved Sent as 0; ignored on reception. 830 Mobile Node Home Address 831 The home address of the mobile node to which the Binding 832 Warning message refers. 834 Target Node Addresses 835 One or more addresses of the correspondent nodes that 836 need to receive Binding Update messages. Each node 837 should be the target of a Binding Update message sent by 838 the home agent. 840 When a home agent receives a Binding Warning extension as part of a 841 valid Registration Request, it should send a Binding Update message 842 to each target node address identified in the Binding Warning, giving 843 it the current binding for the mobile node identified in the mobile 844 node home address field of the Binding Warning. 846 When a mobile node returns to its home network, it MAY append a 847 Binding Warning extension to the Registration Request message sent 848 to its Home Agent, requesting that the home agent send Binding 849 Update messages (naturally, with zero lifetimes) to one or more 850 correspondent nodes. It is important for the correspondent nodes 851 to delete their binding cache entries for the mobile node when the 852 mobile node no longer has a Care-of Address. 854 7. Miscellaneous Home Agent Operations 856 7.1. Home Agent Rate Limiting 858 A home agent is required to provide some mechanism to limit the 859 rate at which it sends Binding Update messages to to the same node 860 about any given mobility binding. This rate limiting is especially 861 important because it is expected that, within the short term, most 862 Internet nodes will not support maintenance of a binding cache. In 863 this case, continual transmissions of Binding Update messages will 864 only waste processing resources at the home agent and correspondent 865 node, and along the Internet path between these nodes. 867 7.2. Mobility Security Association Management 869 One of the most difficult aspects of Route Optimization for Mobile IP 870 in the Internet today is that of providing authentication for all 871 messages that affect the routing of datagrams to a mobile node. 872 In the base Mobile IP protocol, only the home agent is aware of 873 the mobile node's mobility binding and only the home agent tunnels 874 datagrams to the mobile node. Thus, all routing of datagrams to the 875 mobile node while away from its home network is controlled by the 876 home agent. Authentication is currently achieved based on a manually 877 established mobility security association between the home agent and 878 the mobile node. Since the home agent and the mobile node are both 879 owned by the same organization (both are assigned IP addresses within 880 the same IP subnet), this manual configuration is manageable, and 881 (for example) can be performed while the mobile node is at home. 883 However, with Route Optimization, authentication is more difficult 884 to manage, since a Binding Update may in general need to be sent to 885 almost any node in the Internet. Since no authentication or key 886 distribution protocol is generally available in the Internet today, 887 the Route Optimization procedures defined in this document MAY make 888 use of the same type of manual key distribution discussed in the base 889 Mobile IP protocol. For use with Route Optimization, a mobility 890 security association held by a correspondent node or a foreign agent 891 must include the same parameters as required by base Mobile IP [12]. 893 For a correspondent node to be able to create a binding cache entry 894 for a mobile node, the correspondent node and the mobile node's 895 home agent are required to have established a mobility security 896 association. This mobility security association, though, could 897 conceivably be used in creating and updating binding cache entries 898 at this correspondent node for all mobile nodes served by this home 899 agent. Doing so places the correspondent node in a fairly natural 900 relationship with respect to the mobile nodes served by this home 901 agent. For example, the mobile nodes may represent different people 902 affiliated with the same organization owning the home agent, with 903 which the user of the correspondent node often collaborates. The 904 effort of establishing such a mobility security association with 905 the relevant home agent may be more easily justified (appendix A) 906 than the effort of doing so with each mobile node. It is similarly 907 possible for a home agent to have a manually established mobility 908 security association with the foreign agents often used by its mobile 909 nodes, or for a particular mobile node to have a manually established 910 mobility security association with the foreign agents serving the 911 foreign networks that it often visits. 913 In general, if the movement and communication patterns of a mobile 914 node or the group of mobile nodes served by the same home agent are 915 sufficient to justify establishing a mobility security association 916 with the mobile node's home agent, users or network administrators 917 are likely to do so. Without establishing a mobility security 918 association, nodes will not currently be able to authenticate the 919 values transmitted in Route Optimization extensions. 921 7.3. Managing Binding Updates for Correspondent Nodes 923 The home agent MAY keep a list of correspondent nodes from which it 924 has received Binding Acknowledgements for Binding Updates for active 925 registrations (i.e., registrations which have not yet timed out). In 926 this case, when the home agent receives a valid Registration Request, 927 it MAY transmit new Binding Updates to each correspondent node that 928 is on its list for the particular mobile node. In order to know 929 which correspondent nodes correctly received the Binding Updates, the 930 home agent MUST set the `A' bit in the Binding Update, requesting an 931 acknowledgement. 933 Rate-limiting MUST be employed by a Home Agent offering this service, 934 as specified in section 7.1. 936 8. Miscellaneous Foreign Agent Operations 938 This section details various operational considerations important 939 for foreign agents wishing to support smooth handoff. This includes 940 processing Previous Foreign Agent Notification messages, and the 941 maintenance of up-to-date binding cache entries. 943 8.1. Previous Foreign Agent Notification 945 When a foreign agent receives a Previous Foreign Agent Notification 946 message, it creates a Binding Update for the previous foreign agent, 947 using the specified SPI and precomputed authenticator sent to it by 948 the mobile node. The Binding Update message is also required to set 949 the 'A' bit, so that the previous foreign agent will know to send a 950 Binding Acknowledge message back to the mobile node. 952 When the previous foreign agent receives the Binding Update, it will 953 authenticate the message using the mobility security association and 954 SPI specified in the Binding Update. If the message authentication 955 is correct, the visitor list entry for this mobile node at the 956 previous foreign agent will be deleted and a Binding Acknowledge 957 message returned to the sender. In addition, if a new care-of 958 address was included in the Binding Update message, the previous 959 foreign agent will create a binding cache entry for the mobile node; 960 the previous foreign agent can then tunnel datagrams to the mobile 961 node's new care-of address using that binding cache, just as any node 962 maintaining a binding cache. The previous foreign agent is also 963 expected to return a Binding Acknowledge message to the mobile node. 965 Note that this Binding Acknowledge is addressed to the mobile node, 966 and SHOULD be tunneled using the new binding cache entry. The 967 tunneled acknowledgment then SHOULD be delivered directly to the 968 new foreign agent, without having to go to the home network. This 969 creates an interesting problem for the new foreign agent when it 970 receives the acknowledgment before the Registration Reply from the 971 home agent. It is suggested that the new foreign agent deliver the 972 acknowledgment to the mobile node anyway, even though the mobile 973 node is technically unregistered. If there is concern that this 974 provides a loophole for unauthorized traffic to the mobile node, the 975 new foreign agent could limit the number of datagrams delivered to 976 the unregistered mobile node to this single instance. Alternatively, 977 a new extension to the Registration Reply message can be defined to 978 carry along the acknowledgment from the previous foreign agent. This 979 latter approach would have the benefit that fewer datagrams would 980 be transmitted over bandwidth-constrained wireless media during 981 registration. 983 When the Binding Acknowledge message from the previous foreign agent 984 is received by the new foreign agent, it detunnels it and sends 985 it to the mobile node. In this way, the mobile node can discover 986 that its previous foreign agent has received the Binding Update 987 message. The mobile node has to be certain that its previous foreign 988 agent has been notified about its new care-of address, because 989 otherwise the previous foreign agent could become a "black hole" 990 for datagrams destined for the mobile node based on out-of-date 991 binding cache entries at other nodes. The new foreign agent has no 992 further responsibility for helping to update the binding cache at the 993 previous foreign agent, and does not retransmit the message even if 994 no acknowledgment is received. 996 If the acknowledgment has not been received after sufficient time, 997 the mobile node is responsible for retransmitting another Binding 998 Update message to its previous foreign agent. Although the previous 999 foreign agent may have already received and processed the Binding 1000 Update message (the Binding Acknowledge message may have been lost in 1001 transit to the new foreign agent), the mobile node should continue 1002 to retransmit its Binding Update message until the previous foreign 1003 agent responds with a Binding Acknowledge. 1005 8.2. Maintaining Binding Caches 1007 It is possible that the binding cache entry taken by the previous 1008 foreign agent from the information in the Previous Foreign Agent 1009 Notification extension 5.1 will be deleted from its cache at any 1010 time. In this case, the previous foreign agent will be unable to 1011 re-tunnel subsequently arriving tunneled datagrams for the mobile 1012 node, and would resort to using a special tunnel [11]. Mobile nodes 1013 SHOULD assign small lifetimes to such bindings so that they will not 1014 take up space in the foreign agent's binding cache for very long. 1016 8.3. Rate Limiting 1018 A foreign agent MUST provide some mechanism to limit the rate at 1019 which it sends Binding Warning messages to the same node about any 1020 given mobility binding. This rate limiting is especially important 1021 because it is expected that, within the short term, many Internet 1022 nodes will not support maintenance of a binding cache. In this case, 1023 continual transmissions of Binding Warning messages will only waste 1024 processing resources at the foreign agent and correspondent node, and 1025 along the Internet path between these nodes. 1027 9. Security Considerations 1029 The calculation of the authentication data supplied with the Route 1030 Optimization Authentication extension in section 4.5 is specified 1031 to be the same as in the base Mobile IP document for ease of 1032 implementation. There is a better method available (HMAC), specified 1033 in RFC 2104 [6]. If the base Mobile IP specification is updated to 1034 use HMAC, then this route optimization specification should also be 1035 updated similarly. 1037 10. Summary 1039 In this document, we have presented the current protocol definition 1040 for Route Optimization, by which is meant the elimination of triangle 1041 routing whenever the correspondent node is able to perform the 1042 necessary protocol operations. The Route Optimization protocol 1043 definition is largely concerned with supplying a Binding Update to 1044 any correspondent node that needs one (and has some realistic chance 1045 to process it correctly). The Binding Update message is also used in 1046 conjunction with the Previous Foreign Agent Notification message to 1047 allow for smooth handoffs between foreign agents. 1049 11. Acknowledgement 1051 Expanding the Binding Warning to allow a mobile node to send a list 1052 of correspondent nodes to the Home Agent was suggested by Mohamad 1053 Khalil, Emad Qaddoura, Haseeb Akhtar, and Liem Le of Nortel Networks. 1055 A. Using a Master Key at the Home Agent 1057 Rather than storing each mobility security association that it has 1058 established with many different correspondent nodes and foreign 1059 agents, a home agent may manage its mobility security associations so 1060 that each of them can be generated from a single master key. With 1061 the master key, the home agent could build a key for any given other 1062 node, for example by computing the node-specific key as 1063 MD5(node-address | master-key | node-address) 1064 where node-address is the IP address of the particular node for which 1065 the home agent is building a key, and master-key is the single master 1066 key held by the home agent for all mobility security associations it 1067 has established with correspondent nodes. The node-specific key is 1068 built by computing an MD5 hash over a string consisting of the master 1069 key with the node-address concatenated as a prefix and as a suffix. 1071 Using this scheme, when establishing each mobility security 1072 association, the network administrator managing the home agent 1073 computes the node-specific key and communicates this key to the 1074 network administrator of the other node through some secure channel, 1075 such as over the telephone. The mobility security association 1076 is configured at this other node in the same way as any mobility 1077 security association. At the home agent, though, no record need be 1078 kept that this key has been given out. The home agent need only be 1079 configured to know that this scheme is in use for all of its mobility 1080 security associations (perhaps only for specific set of its mobile 1081 nodes). 1083 When the home agent needs a mobility security association as part 1084 of Route Optimization, it builds the node-specific key based on the 1085 master key and the IP address of the other node with which it is 1086 attempting to authenticate. If the other node knows the correct 1087 node-specific key, the authentication will succeed; otherwise, it 1088 will fail as it should. 1090 References 1092 [1] A. Aziz, T. Markson, and H. Prafullchandra. Simple 1093 Key-Management For Internet Protocols (SKIP). 1094 draft-ietf-ipsec-skip-07.txt, August 1996. (work in progress). 1096 [2] S. Bradner. Key Words for Use in RFCs to Indicate Requirement 1097 Levels. RFC 2119, March 1997. 1099 [3] Stan Hanks, Tony Li, Dino Farinacci, and Paul Traina. Generic 1100 Routing Encapsulation (GRE). RFC 1701, October 1994. 1102 [4] Stan Hanks, Tony Li, Dino Farinacci, and Paul Traina. Generic 1103 Routing Encapsulation over IPv4 networks. RFC 1702, October 1104 1994. 1106 [5] David B. Johnson. Scalable and Robust Internetwork Routing 1107 for Mobile Hosts. In Proceedings of the 14th International 1108 Conference on Distributed Computing Systems, pages 2--11, June 1109 1994. 1111 [6] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: Keyed-Hashing 1112 for Message Authentication. RFC 2104, February 1997. 1114 [7] D. Maughan, M. Schertler, M. Schneider, and J. Turner. Internet 1115 Security Association and Key Management Protocol (ISAKMP). 1116 draft-ietf-ipsec-isakmp-08.txt, July 1997. (work in progress). 1118 [8] Charles Perkins. IP Encapsulation within IP. RFC 2003, May 1119 1996. 1121 [9] Charles Perkins. Minimal Encapsulation within IP. RFC 2004, 1122 May 1996. 1124 [10] Charles E. Perkins and David B. Johnson. Registration Keys for 1125 Route Optimization. draft-ietf-mobileip-regkey-00.txt, November 1126 1997. (work in progress). 1128 [11] Charles E. Perkins and David B. Johnson. Special Tunnels for 1129 Mobile IP. draft-ietf-mobileip-spectun-00.txt, November 1997. 1130 (work in progress). 1132 [12] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 1133 1996. 1135 [13] Joyce K. Reynolds and Jon Postel. Assigned Numbers. STD 2, 1136 October 1994. 1138 Chairs' Addresses 1140 The working group can be contacted via the current chairs: 1142 Jim Solomon Erik Nordmark 1143 Redback Networks, Inc. Sun Microsystems, Inc. 1144 1301 E. Algonquin Road 17 Network Circle 1145 Schaumburg, IL 60196 Menlo Park, California 94025 1146 USA USA 1148 Phone: +1-847-576-2753 Phone: +1 650 786-5166 1149 Fax: Fax: +1 650 786-5896 1150 E-mail: solomon@redbacknetworks.com E-mail: nordmark@sun.com 1152 Questions about this document can also be directed to the authors: 1154 Charles E. Perkins David B. Johnson 1155 Sun Microsystems Laboratories Computer Science Department 1156 Mail Stop MPK15-214 1157 Room 2682 1158 Sun Microsystems, Inc. Carnegie Mellon University 1159 15 Network Circly 5000 Forbes Avenue 1160 Menlo Park, California 94025 Pittsburgh, PA 15213-3891 1161 USA USA 1162 Phone: +1-650-786-6464 Phone: +1-412-268-7399 1163 Fax: +1-650-786-6445 Fax: +1-412-268-5576 1164 E-mail: charles.perkins@Sun.COM E-mail: dbj@cs.cmu.edu