idnits 2.17.1 draft-ietf-mobileip-optim-09.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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 26 pages 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 177: '...ed words such as MUST, SHOULD, etc., t...' RFC 2119 keyword, line 197: '...or the destination mobile node, it MAY...' RFC 2119 keyword, line 218: '... In addition, a node cache MAY use any...' RFC 2119 keyword, line 220: '...ded to the binding cache, the node MAY...' RFC 2119 keyword, line 228: '...node. The home agent SHOULD then send...' (46 more instances...) 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) -- 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' == Outdated reference: A later version (-13) exists of draft-ietf-mobileip-challenge-08 ** Downref: Normative reference to an Informational RFC: RFC 1701 (ref. '4') ** Downref: Normative reference to an Informational RFC: RFC 1702 (ref. '5') -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '7') ** Obsolete normative reference: RFC 2408 (ref. '8') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2344 (ref. '9') (Obsoleted by RFC 3024) ** Obsolete normative reference: RFC 2002 (ref. '11') (Obsoleted by RFC 3220) -- Possible downref: Non-RFC (?) normative reference: ref. '13' ** Obsolete normative reference: RFC 1700 (ref. '14') (Obsoleted by RFC 3232) Summary: 13 errors (**), 0 flaws (~~), 3 warnings (==), 6 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 15 February 2000 David B. Johnson 4 Carnegie Mellon University 6 Route Optimization in Mobile IP 7 draft-ietf-mobileip-optim-09.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 . . . . . . . . . . . . . . . 11 68 5. Route Optimization Authentication Extension 12 70 6. Smooth Handoff Authentication Extension 12 71 6.1. Modified Registration Request Message . . . . . . . . . . 13 73 7. Format of Smooth Handoff Extensions 13 74 7.1. Previous Foreign Agent Notification Extension . . . . . . 14 75 7.2. Modified Mobility Agent Advertisement Extension . . . . . 15 76 7.3. Binding Warning Extension . . . . . . . . . . . . . . . . 16 78 8. Miscellaneous Home Agent Operations 17 79 8.1. Home Agent Rate Limiting . . . . . . . . . . . . . . . . 17 80 8.2. Managing Binding Updates for Correspondent Nodes . . . . 17 82 9. Miscellaneous Foreign Agent Operations 18 83 9.1. Previous Foreign Agent Notification . . . . . . . . . . . 18 84 9.2. Maintaining Binding Caches . . . . . . . . . . . . . . . 19 85 9.3. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . 19 87 10. Security Considerations 20 89 11. Acknowledgement 20 91 A. Mobility Security Association Management 22 93 B. Using a Master Key at the Home Agent 23 95 Addresses 24 96 1. Introduction 98 The base Mobile IP protocol [11], allows any mobile node to move 99 about, changing its point of attachment to the Internet, while 100 continuing to be identified by its home IP address. Correspondent 101 nodes send IP datagrams to a mobile node at its home address 102 in the same way as with any other destination. This scheme 103 allows transparent interoperation between mobile nodes and their 104 correspondent nodes, but forces all datagrams for a mobile node to 105 be routed through its home agent. Thus, datagrams to the mobile 106 node are often routed along paths that are significantly longer than 107 optimal. For example, if a mobile node is visiting some subnet, 108 even datagrams from a correspondent node on the same subnet must be 109 routed through the Internet to the mobile node's home agent (on its 110 home network), only then to be tunneled back to the original subnet 111 for final delivery. This indirect routing delays the delivery of the 112 datagrams to mobile nodes, and places an unnecessary burden on the 113 networks and routers along their paths through the Internet. 115 In this document, we will define extensions to the operation of 116 the base Mobile IP protocol to allow for better routing, so that 117 datagrams can be routed from a correspondent node to a mobile node 118 without going to the home agent first. We refer collectively to 119 these extensions as Route Optimization. 121 Route Optimization extensions provide a means for nodes to cache 122 the binding of a mobile node and to then tunnel their own datagrams 123 directly to the care-of address indicated in that binding, bypassing 124 the mobile node's home agent. Extensions are also provided to allow 125 datagrams in flight when a mobile node moves, and datagrams sent 126 based on an out-of-date cached binding, to be forwarded directly to 127 the mobile node's new care-of address. 129 All operation of Route Optimization that changes the routing of 130 IP datagrams to the mobile node is authenticated using the same 131 type of mechanisms defined in the base Mobile IP protocol. This 132 authentication generally relies on a mobility security association 133 established in advance between the sender and receiver of such 134 messages. The association can be created using ISAKMP [8], SKIP [1], 135 or any of the registration key establishment methods specified 136 in [13]. 138 After Section 2 gives some extra terminology, Section 3 provides 139 an overview of the basic protocol operations associated with Route 140 Optimization. Section 4 defines the message types used to update 141 binding caches. Subsequent sections show the formats for the 142 messages, explaining the function of fields within each message. 143 Home agent considerations are given in Section 8, and foreign agent 144 considerations in Section 9. 146 2. Terminology 148 This document introduces the following terminology, in addition to 149 that used to describe the base Mobile IP protocol: 151 Binding cache 153 A cache of mobility bindings of mobile nodes, maintained by a 154 node for use in tunneling datagrams to those mobile nodes. 156 Binding update 158 A message indicating a mobile node's current mobility binding, 159 and in particular its care-of address. 161 Registration Lifetime 163 The registration lifetime is the time duration for which a 164 binding is valid. The term remaining registration lifetime 165 means the amount of time remaining for which a registration 166 lifetime is still valid, at some time after the registration 167 was approved by the home agent. 169 Triangle Routing 171 A situation in which a Correspondent Host's packets to a Mobile 172 Host follow a path which is longer than the optimal path 173 because the packets must be forwarded to the Mobile Host via a 174 Home Agent. 176 This protocol specification uses conventional meanings [2] for 177 capitalized words such as MUST, SHOULD, etc., to indicate requirement 178 levels for various protocol features. 180 3. Route Optimization Overview 182 This section provides an overview of the protocols and operations of 183 Route Optimization. These can be divided into two main parts: 185 1. Updating binding caches 187 2. Managing smooth handoffs between foreign agents 189 The first part of the document goes into detail about binding cache 190 maintenance, and then smooth handoff is considered. 192 3.1. Binding Caches 194 Route Optimization provides a means for any node to maintain a 195 binding cache containing the care-of address of one or more mobile 196 nodes. When sending an IP datagram to a mobile node, if the sender 197 has a binding cache entry for the destination mobile node, it MAY 198 tunnel the datagram directly to the care-of address indicated in the 199 cached mobility binding. 201 In the absence of any binding cache entry, datagrams destined for a 202 mobile node will be routed to the mobile node's home network in the 203 same way as any other IP datagram, and then tunneled to the mobile 204 node's current care-of address by the mobile node's home agent. 205 This is the only routing mechanism supported by the base Mobile IP 206 protocol. With Route Optimization, as a side effect of this indirect 207 routing of a datagram to a mobile node, the original sender of the 208 datagram may be informed of the mobile node's current mobility 209 binding, giving the sender an opportunity to cache the binding. 211 Any node may maintain a binding cache to optimize its own 212 communication with mobile nodes. A node may create or update a 213 binding cache entry for a mobile node only when it has received 214 and authenticated the mobile node's mobility binding. As before, 215 each binding in the binding cache also has an associated lifetime, 216 specified in the Binding Update message in which the node obtained 217 the binding. After the expiration of this time period, the binding 218 is deleted from the cache. In addition, a node cache MAY use any 219 reasonable strategy for managing the space within the binding cache. 220 When a new entry needs to be added to the binding cache, the node MAY 221 choose to drop any entry already in the cache, if needed, to make 222 space for the new entry. For example, a least-recently used (LRU) 223 strategy for cache entry replacement is likely to work well. 225 When a mobile node's home agent intercepts a datagram from the home 226 network and tunnels it to the mobile node, the home agent may deduce 227 that the original source of the datagram has no binding cache entry 228 for the destination mobile node. The home agent SHOULD then send 229 a Binding Update message to the original source node, informing it 230 of the mobile node's current mobility binding. No acknowledgment 231 for such a Binding Update message is needed, since additional future 232 datagrams from this source node intercepted by the home agent for the 233 mobile node will cause transmission of another Binding Update. For 234 a Binding Update to be authenticated by the original source node, 235 the source node and the home agent must have established a mobility 236 security association. 238 Similarly, when any node (e.g., a foreign agent) receives a tunneled 239 datagram, if it has a binding cache entry for the destination mobile 240 node (and thus has no visitor list entry for this mobile node), the 241 node receiving this tunneled datagram may deduce that the tunneling 242 node has an out-of-date binding cache entry for this mobile node. 243 In this case, the receiving node SHOULD send a Binding Warning 244 message to the mobile node's home agent, advising it to send a 245 Binding Update message to the node that tunneled this datagram. The 246 mobile node's home agent can be determined from the binding cache 247 entry, because the home agent address is learned from the Binding 248 Update that established this cache entry. The address of the node 249 that tunneled this datagram can be determined from the datagram's 250 header, since the address of the node tunneling this datagram is 251 the outer source address of the encapsulated datagram. As in the 252 case of a Binding Update sent by the mobile node's home agent, no 253 acknowledgment of this Binding Warning is needed, since additional 254 future datagrams for the mobile node tunneled by the same node will 255 cause the transmission of another Binding Warning. However, unlike 256 the Binding Update message, no authentication of the Binding Warning 257 message is necessary, since it does not directly affect the routing 258 of IP datagrams to the mobile node. 260 When sending an IP datagram, if the sending node has a binding cache 261 entry for the destination node, it SHOULD tunnel the datagram to the 262 mobile node's care-of address using the encapsulation techniques used 263 by home agents, and described in [10, 12, 4, 5]. 265 3.2. Foreign Agent Smooth Handoff 267 When a mobile node moves and registers with a new foreign agent, the 268 base Mobile IP protocol does not notify the mobile node's previous 269 foreign agent. IP datagrams intercepted by the home agent after 270 the new registration are tunneled to the mobile node's new care-of 271 address, but datagrams in flight that had already been intercepted 272 by the home agent and tunneled to the old care-of address when 273 the mobile node moved are likely to be lost and are assumed to be 274 retransmitted by higher-level protocols if needed. The old foreign 275 agent eventually deletes its visitor list entry for the mobile node 276 after the expiration of the registration lifetime. 278 Route Optimization provides a means for the mobile node's previous 279 foreign agent to be reliably notified of the mobile node's new 280 mobility binding, allowing datagrams in flight to the mobile 281 node's previous foreign agent to be forwarded to its new care-of 282 address. This notification also allows any datagrams tunneled to 283 the mobile node's previous foreign agent, from correspondent nodes 284 with out-of-date binding cache entries for the mobile node, to be 285 forwarded to its new care-of address. Finally, this notification 286 allows any resources consumed by the mobile node at the previous 287 foreign agent (such as radio channel reservations) to be released 288 immediately, rather than waiting for its registration lifetime to 289 expire. 291 As part of the registration procedure, the mobile node MAY 292 request that its new foreign agent attempt to notify its previous 293 foreign agent on its behalf, by including a Previous Foreign Agent 294 Notification extension in its Registration Request message sent to 295 the new foreign agent. The new foreign agent then builds a Binding 296 Update message and transmits it to the mobile node's previous foreign 297 agent as part of registration, requesting an acknowledgment from the 298 previous foreign agent. The extension includes only those values 299 needed to construct the Binding Update message that are not already 300 contained in the Registration Request message. The authenticator for 301 the Binding Update message is computed by the mobile node using the 302 security association shared with its previous foreign agent. This 303 notification will typically include the mobile node's new care-of 304 address, allowing the previous foreign agent to create a binding 305 cache entry for the mobile node to serve as a forwarding pointer [6] 306 to its new location. Any tunneled datagrams for the mobile node that 307 arrive at its previous foreign agent after the forwarding pointer has 308 been created can then be re-tunneled to the mobile node's new care-of 309 address. 311 For this smooth handoff to be secure during registration with a new 312 foreign agent, the mobile node and the previous foreign agent must 313 have a security association. The security association is used to 314 authenticate the notification sent to the previous foreign agent. 316 The Mobility Agent Advertisement extension of the agent advertisement 317 message is revised under Route Optimization to include a bit 318 indicating that the foreign agent sending the advertisement supports 319 smooth handoffs. 321 The mobile node is responsible for occasionally retransmitting a 322 Binding Update message to its previous foreign agent until the 323 matching Binding Acknowledge message is received, or until the 324 mobile node can be sure that foreign agent has expired its binding. 325 The mobile node is likely to select a small timeout value for the 326 lifetime available to such bindings sent to previous foreign agents. 328 4. Route Optimization Message Formats 330 Route Optimization defines four message types used for management 331 of binding cache entries. These message types fit in the numbering 332 space defined in the base Mobile IP specification for messages sent 333 to UDP port 434. Each of these messages begins with a one-octet 334 field indicating the type of the message. The binding cache 335 management messages in this section are carried by way of UDP, sent 336 to port 434. 338 The following type codes are defined in this document: 340 16 Binding Warning message 341 17 Binding Request message 342 18 Binding Update message 343 19 Binding Acknowledge message 345 Route Optimization also requires one minor change to existing 346 Mobile IP messages: a new flag bit must be added to the Registration 347 Request message, replacing a previously unused, reserved bit in the 348 message. 350 This section describes each of the new Route Optimization messages 351 and the change to Registration Request message. 353 4.1. Binding Warning Message 355 A Binding Warning message is used to transmit advice that a Binding 356 Update should be sent to one or more correspondent nodes or foreign 357 agents. This happens when the suggested recipients are likely to 358 have either no binding cache entry or an out-of-date binding cache 359 entry for some mobile node. When any node detunnels a datagram 360 destined for the mobile node, if it is not the current foreign agent 361 for the destination mobile node, it SHOULD send a Binding Warning 362 message to the mobile node's home agent. 364 0 1 2 3 365 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 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Type | Reserved | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Mobile Node Home Address | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Target Node Addresses ... 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 The format of the Binding Warning message is illustrated above, and 375 contains the following fields: 377 Type 16 379 Reserved Sent as 0; ignored on reception. 381 Mobile Node Home Address 382 The home address of the mobile node to which the 383 Binding Warning message refers. 385 Target Node Addresses 386 One or more addresses of nodes. Each address 387 identifies a node that should be the target of a 388 Binding Update message sent by the home agent. 390 A home agent will receive a Binding Warning message if a node 391 maintaining a binding cache entry for one of the home agent's mobile 392 nodes uses an out-of-date entry. When a home agent receives a 393 Binding Warning message, it SHOULD send a Binding Update message to 394 each target node address identified in the Binding Warning, giving it 395 the current binding for the mobile node identified in the mobile node 396 home address field of the Binding Warning. 398 When a mobile node receives a new Care-of Address, it MAY send a 399 Binding Warning message to its Home Agent, requesting that the home 400 agent send Binding Update messages to one or more correspondent 401 nodes. This feature MAY be used by the mobile node when it returns 402 to its home network, so that the Home Agent will send out Binding 403 Updates with zero lifetimes to all the mobile node's correspondent 404 nodes. It is important for the correspondent nodes to delete their 405 binding cache entries for the mobile node when the mobile node no 406 longer has a Care-of Address. 408 4.2. Binding Request Message 410 A Binding Request message is used by a node to request a mobile 411 node's current mobility binding from the mobile node's home agent. 413 0 1 2 3 414 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 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Type | Reserved | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Mobile Node Home Address | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | | 421 + Identification + 422 | | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 The format of the Binding Request message is illustrated above, and 426 contains the following fields: 428 Type 17 429 Reserved Sent as 0; ignored on reception. 431 Mobile Node Home Address 432 The home address of the mobile node to which the 433 Binding Request refers. 435 Identification 436 A 64-bit sequence number, assigned by the node sending 437 the Binding Request message, used to assist in matching 438 requests with replies, and in protecting against replay 439 attacks. 441 When the home agent receives a Binding Request message, it consults 442 its home list and determines the correct binding information to be 443 sent to the requesting node. Before satisfying the request, the home 444 agent is required to check whether or not the mobile node has allowed 445 the information to be disseminated. If the mobile node specified 446 the private (P) bit in its Registration Request message, then the 447 home agent must make no further attempt to satisfy Binding Requests 448 on behalf of that mobile node. In this case, the home agent SHOULD 449 return a Binding Update in which both the care-of address is set 450 equal to the mobile node's home address and the lifetime is set to 451 zero. Such a Binding Update message indicates that the binding cache 452 entry for the specified mobile node should be deleted. 454 4.3. Binding Update Message 456 The Binding Update message is used for notification of a mobile 457 node's current mobility binding. It SHOULD be sent by the mobile 458 node's home agent in response to a Binding Request message, a Binding 459 Warning message, or the reception of a Binding Warning extension to 460 a Registration Request. It SHOULD also be sent by a mobile node, or 461 by the foreign agent with which the mobile node is registering, when 462 notifying the mobile node's previous foreign agent that the mobile 463 node has moved. 465 0 1 2 3 466 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 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | Type |A|I|M|G| Rsvd | Lifetime | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Mobile Node Home Address | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Care-of Address | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | | 475 + Identification + 476 | | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Extensions ... 479 +-+-+-+-+-+-+-+- 481 The format of the Binding Update message is illustrated above, and 482 contains the following fields: 484 Type 18 486 A The 'A' (acknowledge) bit is set by the node sending the 487 Binding Update message to request a Binding Acknowledge 488 message be returned. 490 I The 'I' (identification present) bit is set by the node 491 sending the Binding Update message if the identification 492 field is present in the message. 494 M If the 'M' (minimal encapsulation) bit is set, datagrams 495 MAY be tunneled to the mobile node using the minimal 496 encapsulation protocol [12]. 498 G If the 'G' (Generic Record Encapsulation, or GRE) bit is 499 set, datagrams MAY be tunneled to the mobile node using 500 GRE [4]. 502 Rsvd Reserved. Sent as 0; ignored on reception. 504 Lifetime The number of seconds remaining before the binding cache 505 entry must be considered expired. A value of all ones 506 indicates infinity. A value of zero indicates that no 507 binding cache entry for the mobile node should be created 508 and that any existing binding cache entry (and visitor 509 list entry, in the case of a mobile node's previous 510 foreign agent) for the mobile node should be deleted. 511 The lifetime is typically equal to the remaining lifetime 512 of the mobile node's registration. 514 Mobile Node Home Address 515 The home address of the mobile node to which the Binding 516 Update message refers. 518 Care-of Address 519 The current care-of address of the mobile node. When set 520 equal to the home address of the mobile node, the Binding 521 Update message instead indicates that no binding cache 522 entry for the mobile node should be created, and any 523 existing binding cache entry (and visitor list entry, in 524 the case of a mobile node's previous foreign agent) for 525 the mobile node should be deleted. 527 Identification 528 If present, a 64-bit number, assigned by the node sending 529 the Binding Request message, used to assist in matching 530 requests with replies, and in protecting against replay 531 attacks. 533 Each Binding Update message indicates the binding's maximum lifetime. 534 When sending the Binding Update message, the home agent SHOULD set 535 this lifetime to the remaining registration lifetime. A node wanting 536 to provide continued service with a particular binding cache entry 537 MAY attempt to reconfirm that mobility binding before the expiration 538 of the registration lifetime. Such reconfirmation of a binding cache 539 entry may be appropriate when the node has indications (such as an 540 open transport-level connection to the mobile node) that the binding 541 cache entry is still needed. This reconfirmation is performed by 542 the node sending a Binding Request message to the mobile node's 543 home agent, requesting it to reply with the mobile node's current 544 mobility binding in a new Binding Update message. Note that the node 545 maintaining the binding SHOULD also keep track of the home agent's 546 address, to be able to fill in the destination IP address of future 547 Binding Requests. 549 When a correspondent node receives a Binding Update message, it is 550 required to verify the authentication in the message, using the 551 mobility security association it shares with the mobile node's home 552 agent. In such cases, the authentication data is found in the Route 553 Optimization or Smooth Handoff authentication extension (Section 5), 554 which is required. If the authentication succeeds, then a binding 555 cache entry SHOULD be updated for use in future transmissions of data 556 to the mobile node. Otherwise, an authentication exception SHOULD be 557 raised. 559 Under all circumstances, the sending of Binding Update messages is 560 subject to the rate limiting restriction described in Section 8.1. 562 When using nonces for replay protection, the identification field in 563 the Binding Update message is used differently, to still allow replay 564 protection even though the Binding Update is not being sent in reply 565 to a request directly from the target node. In this case, the home 566 agent is required to set the high-order 32 bits of the identification 567 field to the value of the nonce that will be used by the home agent 568 in the next Binding Update message sent to this node. The low-order 569 32 bits of the identification field are required to be set to the 570 value of the nonce being used for this message. 572 Thus, on each Binding Update message, the home agent communicates to 573 the target node, the value of the nonce that will be used next time. 574 If no Binding Updates are lost in the network, the home agent and the 575 target node can remain synchronized with respect to the nonces being 576 used. If, however, the target node receives a Binding Update with 577 what it believes to be an incorrect nonce, it MAY resynchronize with 578 the home agent by using a Binding Request message. 580 4.4. Binding Acknowledge Message 582 A Binding Acknowledge message is used to acknowledge receipt of a 583 Binding Update message. It SHOULD be sent by a node receiving a 584 Binding Update message if the acknowledge (A) bit is set in the 585 Binding Update message. 587 0 1 2 3 588 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 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | Type | Reserved | Status | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | Mobile Node Home Address | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | | 595 + Identification + 596 | | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 The format of the Binding Acknowledge message is illustrated above, 600 and contains the following fields: 602 Type 19 604 Status If the Status is nonzero, this acknowledgment is 605 negative. For instance, if the Binding Update was 606 not accepted, but the incoming datagram has the 607 Acknowledge flag set, then the status code should be 608 set appropriately in the Binding Acknowledge message. 610 Reserved Sent as 0; ignored on reception. 612 Mobile Node Home Address 613 Copied from the Binding Update message being 614 acknowledged. 616 Identification 617 Copied from the Binding Update message being 618 acknowledged, if present there. 620 Allowable values for the Status include: 622 128 reason unspecified 623 129 administratively prohibited 624 130 insufficient resources 625 131 sending node failed authentication 626 133 identification mismatch 627 134 poorly formed Binding Update 629 Up-to-date values of the Code field are specified in the most recent 630 "Assigned Numbers" [14]. 632 5. Route Optimization Authentication Extension 634 The Route Optimization Authentication extension is used to 635 authenticate Route Optimization management messages sent with 636 an SPI corresponding to the source IP address of the message. 637 This extension is subtype TBD of the Generalized Authentication 638 Extension [3]. The authenticator value is computed, as before, from 639 the stream of bytes including the shared secret, the UDP payload 640 (that is, the Route Optimization management message), all prior 641 extensions in their entirety, and the type, subtype, length, and SPI 642 of this extension, but not including the authenticator field itself 643 nor the UDP header. This extension is required to be used in any 644 Binding Update message sent by the Home Agent or the Mobile Node. 646 6. Smooth Handoff Authentication Extension 648 The Smooth Handoff Authentication extension is used to authenticate a 649 Binding Update message sent with an SPI corresponding to the Mobile 650 Node's IP address, as given in the foregoing extension data of the 651 binding cache management message. This extension is subtype TBD of 652 the Generalized Authentication Extension [3]. The authenticator 653 value is computed, as before, from the stream of bytes including 654 the shared secret, the UDP payload (that is, the Binding Update 655 message), all prior extensions in their entirety, and the type, 656 subtype, length, and SPI of this extension, but not including the 657 authenticator field itself nor the UDP header. This extension is 658 required to be used in any Binding Update message sent during a 659 smooth handoff to a previous Foreign Agent by a new Foreign Agent 660 upon receipt of the Previous Foreign Agent Notification Extension 661 (see section 7.1) from the mobile node. 663 6.1. Modified Registration Request Message 665 One bit is added to the flag bits in the Registration Request message 666 to indicate that the mobile node would like its home agent to keep 667 its mobility binding private. Normally, the home agent sends Binding 668 Update messages to correspondent nodes as needed to allow them to 669 cache the mobile node's binding. If the mobile node sets the private 670 ('P') bit in the Registration Request message, the home agent MUST 671 NOT send the mobile node's binding in any Binding Update message. 672 Instead, each Binding Update message SHOULD give the mobile node's 673 care-of address equal to its home address, and SHOULD give a lifetime 674 value of 0. 676 Thus, the Registration Request message under Route Optimization 677 begins as shown below: 679 0 1 2 3 680 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 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 | Type |S|B|D|M|G|V|T|P| Lifetime | 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | (Unchanged ...) 685 +-+-+-+-+-+-+-+-+-+-+-+-+ 687 P The private ('P') bit is set by the node sending the 688 Binding Update message to indicate that the home agent 689 MUST keep its mobility binding private. In any Binding 690 Update message sent by the mobile node's home agent, the 691 care-of address SHOULD be set equal to the mobile node's 692 home address, and the lifetime SHOULD be set equal to 0. 694 The other flag bits are as defined in the base Mobile IP 695 specification [11] and for Reverse Tunneling [9]. 697 7. Format of Smooth Handoff Extensions 699 This section specifies the format for messages which are used 700 to enable smooth handoff from a mobile node's previous foreign 701 agent to its new foreign agent when a mobile node initiates a new 702 registration. 704 7.1. Previous Foreign Agent Notification Extension 706 The Previous Foreign Agent Notification extension MAY be included in 707 a Registration Request message sent to a foreign agent. It requests 708 the new foreign agent to send a Binding Update message to the mobile 709 node's previous foreign agent on behalf of the mobile node, to notify 710 it that the mobile node has moved. The previous foreign agent SHOULD 711 then delete the mobile node's visitor list entry and, if a new 712 care-of address is included in the Binding Update message, create a 713 binding cache entry for the mobile node with its new care-of address. 714 The Previous Foreign Agent Notification extension contains only those 715 values not otherwise already contained in the Registration Request 716 message that are needed for the new foreign agent to construct the 717 Binding Update message. 719 0 1 2 3 720 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 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | Type | Length | Cache Lifetime | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 | Previous Foreign Agent Address | 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 | New Care-of Address | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | SPI | 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | Authenticator ... 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 Type 96 735 Length 14 plus the length of the authenticator 737 Cache Lifetime 738 The number of seconds remaining before the binding 739 cache entry created by the previous foreign agent must 740 be considered expired. A value of all ones indicates 741 infinity. A value of zero indicates that the previous 742 foreign agent MUST NOT create a binding cache entry for 743 the mobile node once it has deleted the mobile node's 744 visitor list entry. The cache lifetime value is copied 745 into the lifetime field of the Binding Update message. 747 Previous Foreign Agent Address 748 The IP address of the mobile node's previous foreign 749 agent to which the new foreign agent should send a 750 Binding Update message on behalf of the mobile node. 752 New Care-of Address 753 The new care-of address for the new foreign agent to send 754 in the Binding Update message to the previous foreign 755 agent. 757 SPI Security Parameters Index (4 bytes). An opaque 758 identifier. The SPI is copied over into the Smooth 759 Handoff authentication extension by the new foreign 760 agent. 762 Authenticator 763 The authenticator value to be used in the Smooth Handoff 764 Authentication extension in the Binding Update message 765 sent by the new foreign agent to the mobile node's 766 previous foreign agent. This authenticator is calculated 767 only over the Binding Update message body. 769 The binding cache entry created at the mobile node's previous 770 foreign agent is treated in the same way as any other binding cache 771 entry [11]. The New Care-of Address in the extension SHOULD be 772 either the care-of address being registered in the new registration 773 (to cause IP datagrams from the previous foreign agent to be tunneled 774 to the new foreign agent) or the mobile node's home address (to cause 775 the previous foreign agent to delete its visitor list entry only for 776 the mobile node, but not forward datagrams for it). 778 The Binding Update sent by the new foreign agent to the previous 779 foreign agent MUST have the IP address of the foreign agent as the 780 source address in the IP header. Therefore, the Route Optimization 781 authentication extension cannot be used; if it were, the SPI would no 782 longer correspond to a security association belonging to the sender 783 of the IP packet. The Smooth Handoff authentication extension allows 784 the Binding Update to be secured by a security association belonging 785 to the mobile node, with an SPI belonging to the mobile node, and not 786 belonging to the foreign agent sending the Binding Update. 788 7.2. Modified Mobility Agent Advertisement Extension 790 Performing smooth handoffs requires one minor change to the existing 791 Mobile IP Mobility Agent Advertisement extension [11]. A new flag 792 bit, the 'S' bit, replaces a previously unused reserved bit in 793 the extension, to indicate that the foreign agent supports smooth 794 handoffs. By default, every foreign agent that supports smooth 795 handoffs SHOULD support at least the establishment of a registration 796 key by using elliptic curve key exchange [13]. 798 0 1 2 3 799 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 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 | Type | Length | Sequence Number | 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 | Lifetime |R|B|H|F|M|G|V|T|S| reserved | 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 | ... zero or more Care-of Addresses 806 +-+-+- 808 Thus, the proposed modification to the Mobility Agent Advertisement 809 extension, illustrated above, keeps the advertisement almost the 810 same as in the base Mobile IP specification, except for adding the 811 following bit: 813 S The 'S' smooth handoff bit is set by the foreign agent 814 sending the agent advertisement message to indicate 815 that it supports the smooth handoffs, and thus the 816 Registration Key Request extension [13]. 818 More detailed information about the handling of this extension by 819 foreign agents is deferred until Section 9.1. 821 7.3. Binding Warning Extension 823 A mobile node MAY append a Binding Warning Extension to a 824 Registration request. The Binding Warning extension is used to 825 advise a mobile node's home agent that one or more correspondent 826 nodes are likely to have either no binding cache entry or an 827 out-of-date binding cache entry for the mobile node sending the 828 Registration Request. 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 | Reserved | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | Mobile Node Home Address | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | Target Node Addresses ... 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 The format of the Binding Warning extension is illustrated above, and 841 contains the following fields: 843 Type 16 844 Reserved Sent as 0; ignored on reception. 846 Mobile Node Home Address 847 The home address of the mobile node to which the 848 Binding Warning message refers. 850 Target Node Addresses 851 One or more addresses of the correspondent nodes that 852 need to receive Binding Update messages. Each node 853 should be the target of a Binding Update message sent 854 by the home agent. 856 When a home agent receives a Binding Warning extension as part of a 857 valid Registration Request, it SHOULD send a Binding Update message 858 to each target node address identified in the Binding Warning, giving 859 it the current binding for the mobile node identified in the mobile 860 node home address field of the Binding Warning. 862 When a mobile node returns to its home network, it SHOULD append 863 a Binding Warning extension to the Registration Request message 864 sent to its Home Agent, requesting that the home agent send Binding 865 Update messages (naturally, with zero lifetimes) to one or more 866 correspondent nodes. It is important for the correspondent nodes 867 to delete their binding cache entries for the mobile node when the 868 mobile node no longer has a Care-of Address. 870 8. Miscellaneous Home Agent Operations 872 8.1. Home Agent Rate Limiting 874 A home agent is required to provide some mechanism to limit the 875 rate at which it sends Binding Update messages to to the same node 876 about any given mobility binding. This rate limiting is especially 877 important because it is expected that, within the short term, most 878 Internet nodes will not support maintenance of a binding cache. In 879 this case, continual transmissions of Binding Update messages will 880 only waste processing resources at the home agent and correspondent 881 node, and along the Internet path between these nodes. 883 8.2. Managing Binding Updates for Correspondent Nodes 885 The home agent MAY keep a list of correspondent nodes from which it 886 has received Binding Acknowledgements for Binding Updates for active 887 registrations (i.e., registrations which have not yet timed out). In 888 this case, when the home agent receives a valid Registration Request, 889 it MAY transmit new Binding Updates to each correspondent node that 890 is on its list for the particular mobile node. In order to know 891 which correspondent nodes correctly received the Binding Updates, the 892 home agent MUST set the `A' bit in the Binding Update, requesting an 893 acknowledgement. 895 Rate-limiting MUST be employed by a Home Agent offering this service, 896 as specified in section 8.1. 898 9. Miscellaneous Foreign Agent Operations 900 This section details various operational considerations important 901 for foreign agents wishing to support smooth handoff. This includes 902 processing Previous Foreign Agent Notification extensions, and the 903 maintenance of up-to-date binding cache entries. 905 9.1. Previous Foreign Agent Notification 907 When a foreign agent receives a Previous Foreign Agent Notification 908 extension, it creates a Binding Update for the previous foreign 909 agent, using the specified SPI and precomputed authenticator sent to 910 it by the mobile node. The Binding Update message is also required 911 to set the 'A' bit, so that the previous foreign agent will know to 912 send a Binding Acknowledge message back to the mobile node. 914 When the previous foreign agent receives the Binding Update, it will 915 authenticate the message using the mobility security association and 916 SPI specified in the Binding Update. If the message authentication 917 is correct, the visitor list entry for this mobile node at the 918 previous foreign agent will be deleted and a Binding Acknowledge 919 message returned to the sender. In addition, if a new care-of 920 address was included in the Binding Update message, the previous 921 foreign agent will create a binding cache entry for the mobile node; 922 the previous foreign agent can then tunnel datagrams to the mobile 923 node's new care-of address using that binding cache, just as any node 924 maintaining a binding cache. The previous foreign agent is also 925 expected to return a Binding Acknowledge message to the mobile node. 927 Note that this Binding Acknowledge is addressed to the mobile node, 928 and SHOULD be tunneled using the new binding cache entry. The 929 tunneled acknowledgment then SHOULD be delivered directly to the 930 new foreign agent, without having to go to the home network. This 931 creates an interesting problem for the new foreign agent when it 932 receives the acknowledgment before the Registration Reply from the 933 home agent. It is suggested that the new foreign agent deliver the 934 acknowledgment to the mobile node anyway, even though the mobile 935 node is technically unregistered. If there is concern that this 936 provides a loophole for unauthorized traffic to the mobile node, the 937 new foreign agent could limit the number of datagrams delivered to 938 the unregistered mobile node to this single instance. Alternatively, 939 a new extension to the Registration Reply message can be defined to 940 carry along the acknowledgment from the previous foreign agent. This 941 latter approach would have the benefit that fewer datagrams would 942 be transmitted over bandwidth-constrained wireless media during 943 registration. 945 When the Binding Acknowledge message from the previous foreign agent 946 is received by the new foreign agent, it detunnels it and sends 947 it to the mobile node. In this way, the mobile node can discover 948 that its previous foreign agent has received the Binding Update 949 message. The mobile node has to be certain that its previous foreign 950 agent has been notified about its new care-of address, because 951 otherwise the previous foreign agent could become a "black hole" 952 for datagrams destined for the mobile node based on out-of-date 953 binding cache entries at other nodes. The new foreign agent has no 954 further responsibility for helping to update the binding cache at the 955 previous foreign agent, and does not retransmit the message even if 956 no acknowledgment is received. 958 If the acknowledgment has not been received after sufficient time, 959 the mobile node is responsible for retransmitting another Binding 960 Update message to its previous foreign agent. Although the previous 961 foreign agent may have already received and processed the Binding 962 Update message (the Binding Acknowledge message may have been lost in 963 transit to the new foreign agent), the mobile node SHOULD continue 964 to retransmit its Binding Update message until the previous foreign 965 agent responds with a Binding Acknowledge. 967 9.2. Maintaining Binding Caches 969 It is possible that the binding cache entry taken by the previous 970 foreign agent from the information in the Previous Foreign Agent 971 Notification extension 7.1 will be deleted from its cache at any 972 time. In this case, the previous foreign agent will be unable to 973 find a current care-of address for subsequently arriving tunneled 974 datagrams for the mobile node. Mobile nodes SHOULD assign small 975 lifetimes to such bindings so that they will not take up space in the 976 foreign agent's binding cache for very long. 978 9.3. Rate Limiting 980 A foreign agent MUST provide some mechanism to limit the rate at 981 which it sends Binding Warning messages to the same node about any 982 given mobility binding. This rate limiting is especially important 983 because it is expected that, within the short term, many Internet 984 nodes will not support maintenance of a binding cache. In this case, 985 continual transmissions of Binding Warning messages will only waste 986 processing resources at the foreign agent and correspondent node, and 987 along the Internet path between these nodes. 989 10. Security Considerations 991 The calculation of the authentication data supplied with the 992 Route Optimization and Smooth Handoff authentication extensions 993 in section 5 is specified to be the same as in the base Mobile IP 994 document for ease of implementation. There is a better method 995 available (HMAC), specified in RFC 2104 [7]. If the base Mobile IP 996 specification is updated to use HMAC, then this route optimization 997 specification SHOULD also be updated similarly. 999 11. Acknowledgement 1001 Expanding the Binding Warning to allow a mobile node to send a list 1002 of correspondent nodes to the Home Agent was suggested by Mohamad 1003 Khalil, Emad Qaddoura, Haseeb Akhtar, and Liem Le of Nortel Networks. 1005 References 1007 [1] A. Aziz, T. Markson, and H. Prafullchandra. Simple 1008 Key-Management For Internet Protocols (SKIP). 1009 draft-ietf-ipsec-skip-07.txt, August 1996. (work in progress). 1011 [2] S. Bradner. Key words for use in RFCs to Indicate Requirement 1012 Levels. Request for Comments (Best Current Practice) 2119, 1013 Internet Engineering Task Force, March 1997. 1015 [3] P. Calhoun and C. E. Perkins. Mobile IP Foreign Agent 1016 Challenge/Response Extension. 1017 draft-ietf-mobileip-challenge-08.txt, January 2000. (work in 1018 progress). 1020 [4] S. Hanks, T. Li, D. Farinacci, and P. Traina. Generic Routing 1021 Encapsulation (GRE). Request for Comments (Informational) 1701, 1022 Internet Engineering Task Force, October 1994. 1024 [5] S. Hanks, T. Li, D. Farinacci, and P. Traina. Generic Routing 1025 Encapsulation over IPv4 networks. Request for Comments 1026 (Informational) 1702, Internet Engineering Task Force, October 1027 1994. 1029 [6] David B. Johnson. Scalable and Robust Internetwork Routing 1030 for Mobile Hosts. In Proceedings of the 14th International 1031 Conference on Distributed Computing Systems, pages 2--11, June 1032 1994. 1034 [7] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing 1035 for Message Authentication. Request for Comments 1036 (Informational) 2104, Internet Engineering Task Force, 1037 February 1997. 1039 [8] D. Maughan, M. Schertler, M. Schneider, and J. Turner. Internet 1040 Security Association and Key Management Protocol (ISAKMP). 1041 Request for Comments (Proposed Standard) 2408, Internet 1042 Engineering Task Force, November 1998. 1044 [9] G. Montenegro. Reverse Tunneling for Mobile IP. Request for 1045 Comments (Proposed Standard) 2344, Internet Engineering Task 1046 Force, May 1998. 1048 [10] C. Perkins. IP Encapsulation within IP. Request for Comments 1049 (Proposed Standard) 2003, Internet Engineering Task Force, 1050 October 1996. 1052 [11] C. Perkins. IP Mobility Support. Request for Comments 1053 (Proposed Standard) 2002, Internet Engineering Task Force, 1054 October 1996. 1056 [12] C. Perkins. Minimal Encapsulation within IP. Request for 1057 Comments (Proposed Standard) 2004, Internet Engineering Task 1058 Force, October 1996. 1060 [13] C. Perkins and D. Johnson. Registration Keys for Route 1061 Optimization. Internet Draft, Internet Engineering Task Force, 1062 December 1997. Work in progress. 1064 [14] J. Reynolds and J. Postel. Assigned Numbers. Request for 1065 Comments (Standard) 1700, Internet Engineering Task Force, 1066 October 1994. 1068 A. Mobility Security Association Management 1070 One of the most difficult aspects of Route Optimization for Mobile IP 1071 in the Internet today is that of providing authentication for all 1072 messages that affect the routing of datagrams to a mobile node. 1073 In the base Mobile IP protocol, only the home agent is aware of 1074 the mobile node's mobility binding and only the home agent tunnels 1075 datagrams to the mobile node. Thus, all routing of datagrams to the 1076 mobile node while away from its home network is controlled by the 1077 home agent. Authentication is currently achieved based on a manually 1078 established mobility security association between the home agent and 1079 the mobile node. Since the home agent and the mobile node are both 1080 owned by the same organization (both are assigned IP addresses within 1081 the same IP subnet), this manual configuration is manageable, and 1082 (for example) can be performed while the mobile node is at home. 1084 However, with Route Optimization, authentication is more difficult 1085 to manage, since a Binding Update may in general need to be sent to 1086 almost any node in the Internet. Since no authentication or key 1087 distribution protocol is generally available in the Internet today, 1088 the Route Optimization procedures defined in this document MAY make 1089 use of the same type of manual key distribution discussed in the base 1090 Mobile IP protocol. For use with Route Optimization, a mobility 1091 security association held by a correspondent node or a foreign agent 1092 must include the same parameters as required by base Mobile IP [11]. 1094 For a correspondent node to be able to create a binding cache entry 1095 for a mobile node, the correspondent node and the mobile node's 1096 home agent are required to have established a mobility security 1097 association. This mobility security association, though, could 1098 conceivably be used in creating and updating binding cache entries 1099 at this correspondent node for all mobile nodes served by this home 1100 agent. Doing so places the correspondent node in a fairly natural 1101 relationship with respect to the mobile nodes served by this home 1102 agent. For example, the mobile nodes may represent different people 1103 affiliated with the same organization owning the home agent, with 1104 which the user of the correspondent node often collaborates. The 1105 effort of establishing such a mobility security association with 1106 the relevant home agent may be more easily justified (appendix B) 1107 than the effort of doing so with each mobile node. It is similarly 1108 possible for a home agent to have a manually established mobility 1109 security association with the foreign agents often used by its mobile 1110 nodes, or for a particular mobile node to have a manually established 1111 mobility security association with the foreign agents serving the 1112 foreign networks that it often visits. 1114 In general, if the movement and communication patterns of a mobile 1115 node or the group of mobile nodes served by the same home agent are 1116 sufficient to justify establishing a mobility security association 1117 with the mobile node's home agent, users or network administrators 1118 are likely to do so. Without establishing a mobility security 1119 association, nodes will not currently be able to authenticate the 1120 values transmitted in Route Optimization extensions. 1122 B. Using a Master Key at the Home Agent 1124 Rather than storing each mobility security association that it has 1125 established with many different correspondent nodes and foreign 1126 agents, a home agent MAY manage its mobility security associations so 1127 that each of them can be generated from a single master key. With 1128 the master key, the home agent could build a key for any given other 1129 node, for example by computing the node-specific key as 1131 MD5(node-address | master-key | node-address) 1133 where node-address is the IP address of the particular node for which 1134 the home agent is building a key, and master-key is the single master 1135 key held by the home agent for all mobility security associations it 1136 has established with correspondent nodes. The node-specific key is 1137 built by computing an MD5 hash over a string consisting of the master 1138 key with the node-address concatenated as a prefix and as a suffix. 1140 Using this scheme, when establishing each mobility security 1141 association, the network administrator managing the home agent 1142 computes the node-specific key and communicates this key to the 1143 network administrator of the other node through some secure channel, 1144 such as over the telephone. The mobility security association 1145 is configured at this other node in the same way as any mobility 1146 security association. At the home agent, though, no record need be 1147 kept that this key has been given out. The home agent need only be 1148 configured to know that this scheme is in use for all of its mobility 1149 security associations (perhaps only for specific set of its mobile 1150 nodes). 1152 When the home agent needs a mobility security association as part 1153 of Route Optimization, it builds the node-specific key based on the 1154 master key and the IP address of the other node with which it is 1155 attempting to authenticate. If the other node knows the correct 1156 node-specific key, the authentication will succeed; otherwise, it 1157 will fail as it should. 1159 Addresses 1161 The working group can be contacted via the current chairs: 1163 Basavaraj Patil Phil Roberts 1164 Nokia Corporation Motorola 1165 6000 Connection Drive 1501 West Shure Drive 1166 M/S M8-540 1167 Irving, TX 75039 Arlington Heights, IL 60004 1168 USA USA 1169 Phone: +1 972-894-6709 Phone: +1 847-632-3148 1170 Fax : +1 972-894-5349 1171 EMail: Raj.Patil@nokia.com EMail: QA3445@email.mot.com 1173 Questions about this memo can also be directed to the authors: 1175 Charles E. Perkins David B. Johnson 1176 Communications Systems Lab Computer Science Department 1177 Nokia Research Center 5000 Forbes Avenue 1178 313 Fairchild Drive Pittsburgh, PA 15213-3891 1179 Mountain View, California 94043 Carnegie Mellon University 1180 USA USA 1181 Phone: +1-650 625-2986 Phone: +1-412-268-7399 1182 EMail: charliep@iprg.nokia.com Fax: +1-412-268-5576 1183 Fax: +1 650 625-2502 E-mail: dbj@cs.cmu.edu