idnits 2.17.1 draft-ietf-mobileip-optim-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 321: '... home agent MAY send a Binding Updat...' RFC 2119 keyword, line 335: '...is case, the receiving node MAY send a...' RFC 2119 keyword, line 367: '..., the home agent SHOULD set this lifet...' RFC 2119 keyword, line 508: '... mobile node, it MAY send a Binding Wa...' RFC 2119 keyword, line 574: '...ity binding. It MAY be sent by the mo...' (24 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 1541 (ref. '3') (Obsoleted by RFC 2131) ** Obsolete normative reference: RFC 1750 (ref. '4') (Obsoleted by RFC 4086) ** Downref: Normative reference to an Informational RFC: RFC 1701 (ref. '5') == Outdated reference: A later version (-17) exists of draft-ietf-mobileip-protocol-10 Summary: 12 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group David B. Johnson 2 INTERNET DRAFT Carnegie Mellon University 3 7 July 1995 Charles Perkins 4 IBM Corporation 6 Route Optimization in Mobile IP 8 draft-ietf-mobileip-optim-02.txt 10 Status of This Memo 12 This document is a product of the Mobile IP Working Group of the 13 Internet Engineering Task Force (IETF). Comments should be submitted 14 to working group mailing list at mobile-ip@tadpole.com. 16 Distribution of this document is unlimited. 18 This document is an Internet-Draft. 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 To learn the current status of any Internet-Draft, please check 29 the "1id-abstracts.txt" listing contained in the Internet- Drafts 30 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 31 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 32 ftp.isi.edu (US West Coast). 34 Abstract 36 This document defines extensions to the operation of the base 37 Mobile IP protocol to allow for optimization of datagram routing from 38 a correspondent node to a mobile node. Without Route Optimization, 39 all datagrams destined to a mobile node are routed through that 40 mobile node's home agent, which then tunnels each datagram to the 41 mobile node's current location. The protocol extensions described 42 here provide a means for correspondent nodes that implement them 43 to cache the binding of a mobile node and to then tunnel their own 44 datagrams for the mobile node directly to that location, bypassing 45 the possibly lengthy route for each datagram to and from the mobile 46 node's home agent. Extensions are also provided to allow datagrams 47 in flight when a mobile node moves, and datagrams sent based on an 48 out-of-date cached binding, to be forwarded directly to the mobile 49 node's new binding. 51 Contents 53 Status of This Memo i 55 Abstract ii 57 1. Introduction 1 59 2. Route Optimization Overview 3 60 2.1. Binding Caching . . . . . . . . . . . . . . . . . . . . . 3 61 2.2. Foreign Agent Handoff . . . . . . . . . . . . . . . . . . 3 62 2.3. Binding Cache Updates . . . . . . . . . . . . . . . . . . 5 63 2.4. Registration Key Establishment Using the Home Agent . . . 7 64 2.5. Registration Key Establishment Using Diffie-Hellman . . . 7 66 3. Route Optimization Message Formats 10 67 3.1. Binding Warning Message . . . . . . . . . . . . . . . . . 11 68 3.2. Binding Request Message . . . . . . . . . . . . . . . . . 12 69 3.3. Binding Update Message . . . . . . . . . . . . . . . . . 13 70 3.4. Binding Acknowledge Message . . . . . . . . . . . . . . . 15 72 4. Route Optimization Extension Formats 16 73 4.1. Previous Foreign Agent Notification Extension . . . . . . 17 74 4.2. Route Optimization Authentication Extension . . . . . . . 19 75 4.3. Home Agent Registration Key Request Extension . . . . . . 20 76 4.4. Mobile Node Registration Key Reply Extension . . . . . . 21 77 4.5. Foreign Agent Registration Key Reply Extension . . . . . 22 78 4.6. Diffie-Hellman Registration Key Request Extension . . . . 23 79 4.7. Diffie-Hellman Registration Key Reply Extension . . . . . 24 81 5. Mobility Security Association Management 25 83 6. Binding Cache Considerations 27 84 6.1. Cache Management . . . . . . . . . . . . . . . . . . . . 27 85 6.2. Receiving Binding Warning Messages . . . . . . . . . . . 27 86 6.3. Receiving Binding Update Messages . . . . . . . . . . . . 28 87 6.4. Using Special Tunnels . . . . . . . . . . . . . . . . . . 28 89 7. Home Agent Considerations 30 90 7.1. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . 30 91 7.2. Receiving Binding Request Messages . . . . . . . . . . . 30 92 7.3. Receiving Registration Key Requests . . . . . . . . . . . 31 93 7.4. Receiving Special Tunnels . . . . . . . . . . . . . . . . 31 95 8. Foreign Agent Considerations 32 96 8.1. Establishing a Registration Key . . . . . . . . . . . . . 32 97 8.2. Previous Foreign Agent Notification . . . . . . . . . . . 32 98 8.3. Receiving Tunneled Datagrams . . . . . . . . . . . . . . 33 99 8.4. Sending Special Tunnels . . . . . . . . . . . . . . . . . 34 101 9. Mobile Node Considerations 35 102 9.1. Requesting a Registration Key . . . . . . . . . . . . . . 35 103 9.2. Notifying Previous Foreign Agents . . . . . . . . . . . . 35 105 References 37 107 Appendix A. Using a Master Key at the Home Agent 38 109 Chairs' Addresses 39 111 Authors' Addresses 40 112 1. Introduction 114 The base Mobile IP protocol [6] allows any mobile node to move about, 115 changing its point of attachment to the Internet, while continuing 116 to be addressed by its home IP address. Correspondent nodes sending 117 IP datagrams to a mobile node address them to the mobile node's home 118 address in the same way as to any destination. 120 While the mobile node is connected to the Internet away from its 121 home network, it is served by a "home agent" on its home network 122 and is associated with a "care-of address" indicating its current 123 location. The association between a mobile node's home address and 124 its care-of address is known as a "mobility binding". The care-of 125 address is generally the address of a "foreign agent" on the network 126 being visited by the mobile node, which forwards arriving datagrams 127 locally to the mobile node. Alternatively, the care-of address may 128 be temporarily assigned to the mobile node using DHCP [3] or other 129 means. All IP datagrams addressed to the mobile node are routed by 130 the normal IP routing mechanisms to the mobile node's home network, 131 where they are intercepted by the mobile node's home agent, which 132 then tunnels each datagram to the mobile node's current care-of 133 address. Datagrams sent by a mobile node use the foreign agent as a 134 default router but require no other special handling or routing. 136 This scheme allows transparent interoperation with mobile nodes, 137 but forces all datagrams for a mobile node to be routed through 138 its home agent; packets to the mobile node are often routed along 139 paths that are significantly longer than optimal. For example, if a 140 mobile node, say MN1, is visiting some subnet, even datagrams from 141 a correspondent node on this same subnet must be routed through the 142 Internet to MN1's home agent on MN1's home network, only to then 143 be tunneled back to the original subnet to MN1's foreign agent for 144 delivery to MN1. This indirect routing can significantly delay the 145 delivery of the datagram to MN1 and places an unnecessary burden on 146 the networks and routers along this path through the Internet. If 147 the correspondent node in this example is actually another mobile 148 node, say MN2, then datagrams from MN1 to MN2 must likewise be routed 149 through MN2's home agent on MN2's home network and back to the 150 original subnet for delivery to MN1. 152 This document defines extensions to the base Mobile IP protocol to 153 allow for the optimization of datagram routing from a correspondent 154 node to a mobile node. These extensions provide a means for nodes 155 that implement them to cache the binding of a mobile node and to then 156 tunnel their own datagrams directly to the care-of address indicated 157 in that binding, bypassing the possibly lengthy route to and from 158 that mobile node's home agent. Extensions are also provided to allow 159 datagrams in flight when a mobile node moves, and datagrams sent 160 based on an out-of-date cached binding, to be forwarded directly 161 to the mobile node's new care-of address. These extensions are 162 collectively referred to as Route Optimization in this document. 164 All operation of Route Optimization that changes the routing of IP 165 datagrams to the mobile node is authenticated using the same type of 166 authentication mechanism used in the base Mobile IP protocol. This 167 authentication generally relies on a "mobility security association" 168 established in advance between the node sending a message and the 169 node receiving the message that must authenticate it. When the 170 required mobility security association has not been established, a 171 Mobile IP implementation using Route Optimization operates in the 172 same way as the base Mobile IP protocol. 174 Section 2 of this document provides an overview of the operation of 175 Route Optimization. Section 3 defines the message types used by 176 Route Optimization, and Section 4 defines the message extensions 177 used. Section 5 discusses the problem of managing the mobility 178 security associations needed to provide authentication of all 179 messages that affect the routing of datagrams to a mobile node. 180 The final four sections of this document define in detail the 181 operation of Route Optimization from the point of view of each of the 182 entities involved: considerations for nodes maintaining a binding 183 cache are presented in Section 6, mobile node considerations in 184 Section 9, foreign agent considerations in Section 8, and home agent 185 considerations in Section 7. 187 2. Route Optimization Overview 189 2.1. Binding Caching 191 Route Optimization provides a means for any node that wishes to 192 optimize its own communication with mobile nodes to maintain a 193 "binding cache" containing the mobility binding of one or more mobile 194 nodes. When sending an IP datagram to a mobile node, if the sender 195 has a binding cache entry for the destination mobile node, it may 196 tunnel the datagram directly to the care-of address indicated in the 197 cached mobility binding. 199 In the absence of any binding cache entry, datagrams destined for 200 a mobile node will be routed to the mobile node's home network in 201 the same way as any other IP datagram, and are then tunneled to the 202 mobile node's current care-of address by the mobile node's home 203 agent. This is the only routing mechanism supported by the base 204 Mobile IP protocol. With Route Optimization, as a side effect of 205 this indirect routing of a datagram to a mobile node, the original 206 sender of the datagram may be informed of the mobile node's current 207 mobility binding, giving the sender an opportunity to cache the 208 binding. 210 A node may create a binding cache entry for a mobile node only when 211 it has received and authenticated the mobile node's mobility binding. 212 Likewise, a node may update an existing binding cache entry for a 213 mobile node, such as after the mobile node has moved to a new foreign 214 agent, only when it has received and authenticated the mobile node's 215 new mobility binding. 217 A binding cache will, by necessity, have a finite size. Any node 218 implementing a binding cache may manage the space in its cache 219 using any local cache replacement policy. If a datagram is sent 220 to a destination for which the cache entry has been dropped from 221 the cache, the datagram will be routed normally through the mobile 222 node's home network and will be tunneled to the mobile node's care-of 223 address by its home agent. This indirect routing to the mobile node 224 will result in the original sender of the datagram being informed of 225 the mobile node's current mobility binding, allowing it to add this 226 entry again to its binding cache. 228 2.2. Foreign Agent Handoff 230 When a mobile node moves and registers with a new foreign agent, the 231 base Mobile IP protocol does not notify the mobile node's previous 232 foreign agent. IP datagrams intercepted by the home agent after 233 the new registration are tunneled to the mobile node's new care-of 234 address, but datagrams in flight that had already been intercepted 235 by the home agent and tunneled to the old care-of address when the 236 mobile node moved are lost and are assumed to be retransmitted by 237 higher-level protocols if neeeded. The old foreign agent eventually 238 deletes the mobile node's registration after the expiration of the 239 lifetime period established when the mobile node registered there. 241 Route Optimization provides a means for the mobile node's previous 242 foreign agent to be reliably notified of the mobile node's new 243 mobility binding, allowing datagrams in flight to the mobile 244 node's previous foreign agent to be forwarded to its new care-of 245 address. This notification also allows any datagrams tunneled to the 246 mobile node's previous foreign agent from correspondent nodes with 247 out-of-date binding cache entries for the mobile node (that have not 248 yet learned that the mobile node has moved), to be forwarded to its 249 new care-of address. Finally, this notification allows any resources 250 consumed by the mobile node's binding at the previous foreign agent 251 (such as radio channel reservations) to be released immediately, 252 rather than waiting for the mobile node's registration to expire. 254 Optionally, during registration with a new foreign agent, the mobile 255 node and the foreign agent may establish a new shared secret key 256 as a "registration key". When the mobile node later registers 257 with a new foreign agent, if it established a registration key 258 during registration with its previous foreign agent, it may use 259 this key to notify the previous foreign agent that it has moved. 260 This notification may also optionally include the mobile node's new 261 care-of address, allowing the previous foreign agent to create a 262 binding cache entry for the mobile node to serve as a "forwarding 263 pointer" to its new location. Any tunneled datagrams for the mobile 264 node that arrive at this previous foreign agent after this binding 265 cache entry has been created will then be re-tunneled by this 266 foreign agent to the mobile node's new location using the mobility 267 binding in this binding cache entry. The registration key is used 268 to authenticate the notification sent to the previous foreign agent. 269 Other uses of the registration key are possible, such as for use as 270 an encryption key for providing privacy over a wireless link between 271 the mobile node and its foreign agent, but such uses are beyond the 272 scope of this document. Once established, the registration key for a 273 mobile node can be stored by the foreign agent with the mobile node's 274 visitor list entry. 276 As part of the registration procedure, the mobile node may 277 request that its new foreign agent attempt to notify its previous 278 foreign agent on its behalf, by including a Previous Foreign Agent 279 Notification extension in its Registration Request message sent to 280 the new foreign agent. The new foreign agent then builds a Binding 281 Update message and transmits it to the mobile node's previous foreign 282 agent as part of registration, requesting an acknowledgement from 283 the previous foreign agent. The Previous Foreign Agent Notification 284 extension includes only those values needed to construct the Binding 285 Update message that are not already contained in the Registration 286 Request message. The authenticator for the Binding Update message is 287 computed by the mobile node based on its registration key shared with 288 its previous foreign agent. 290 The mobile node is responsible for occasionally retransmitting a 291 Binding Update message to its previous foreign agent until the 292 matching Binding Acknowledge message is received, or until the mobile 293 node can be sure of the expiration of its registration with that 294 foreign agent. 296 The binding cache entry created at the mobile node's previous foreign 297 agent is treated in the same way as any other binding cache entry. 298 In particular, it is possible that this binding cache entry will be 299 deleted from the cache at any time. In this case, the foreign agent 300 will be unable to re-tunnel subsequently arriving tunneled datagrams 301 for the mobile node directly to its new location. Suppose a node 302 (for instance, such a previous foreign agent) receives a datagram 303 that has been tunneled to this node, but this node is unable to 304 deliver the datagram locally to the destination mobile node (the node 305 is not the mobile node itself, and it is not a foreign agent with a 306 visitor list entry for the mobile node). To attempt delivery of the 307 datagram in this case, the node must encapsulate the datagram as a 308 "special tunnel" datagram (Section 8.4), destined to the mobile node. 309 Otherwise, the datagram would eventually reach the mobile node's 310 home network, be intercepted by the mobile node's home agent, and be 311 tunneled to the mobile node's current care-of address. If the home 312 agent were to tunnel the datagram back to the same foreign agent, a 313 loop would be created. 315 2.3. Binding Cache Updates 317 When a mobile node's home agent intercepts a datagram from the 318 home network and tunnels it to the mobile node, the home agent may 319 deduce that the original source of the datagram has no binding 320 cache entry for the destination mobile node. In this case, the 321 home agent MAY send a Binding Update message to the original source 322 node, informing it of the mobile node's current mobility binding. 323 No acknowledgement for this Binding Update message is needed, since 324 additional future datagrams from this source node intercepted by the 325 home agent for the mobile node will cause transmission of another 326 Binding Update. In order for this Binding Update to be authenticated 327 by the original source node, the home agent and this source node must 328 have established a mobility security association. 330 Similarly, when any node receives a tunneled datagram that was 331 tunneled to this node, if it is not the current foreign agent 332 serving the destination (it has no visitor list entry for this mobile 333 node), the node receiving this tunneled datagram may deduce that 334 the tunneling node has an out-of-date binding cache entry for the 335 destination mobile node. In this case, the receiving node MAY send a 336 Binding Warning message to the tunneling node, advising it that its 337 binding cache entry for the mobile node is out-of-date. As in the 338 case of a Binding Update sent by the mobile node's home agent, no 339 acknowledgement of this Binding Warning is needed, since additional 340 future datagrams for the mobile node tunneled by the same node will 341 cause the transmission of another Binding Warning. 343 However, unlike the Binding Update message, no authentication of the 344 Binding Warning message is necessary, since it does not directly 345 affect the routing of IP datagrams to the mobile node. Instead, when 346 a node receives a Binding Warning message, that node sends a Binding 347 Request message to the indicated mobile node's home agent, requesting 348 the mobile node's current mobility binding. The home agent then 349 answers this Binding Request message with a Binding Update message; 350 when the Binding Update message is received, the node may then create 351 a binding cache entry for the mobile node. In order for this node 352 and the home agent to exchange these Binding Request and Binding 353 Update messages, they must have established a mobility security 354 association. 356 DISCUSSION: An alternative design would be to send a Binding 357 Warning-like message directly to the home agent, which would 358 then send a Binding Update to the correspondent node. This 359 accomplishes the same thing in 2 messages instead of 3 360 (Binding Warning, Binding Request, Binding Update), but the 361 authentication of the binding may be more difficult without 362 a request-update exchange between the correspondent node and 363 the home agent. 365 Each Binding Update message indicates the maximum lifetime of any 366 binding cache entry created from the Binding Update. When sending 367 the Binding Update message, the home agent SHOULD set this lifetime 368 to the remaining service lifetime associated with the mobile node's 369 current registration. Any binding cache entry established or updated 370 in response to this Binding Update message must be marked to be 371 deleted after the expiration of this period. A node wanting to 372 provide continued service with a particular binding cache entry may 373 attempt to reconfirm that mobility binding before the expiration of 374 this lifetime period. Such reconfirmation of a binding cache entry 375 may be appropriate when the node has indications (such as an open 376 transport-level connection to the mobile node) that the binding 377 cache entry is still needed. This reconfirmation is performed by 378 the node sending a Binding Request message to the mobile node's home 379 agent, requesting it to reply with the mobile node's current mobility 380 binding in a new Binding Update message. 382 2.4. Registration Key Establishment Using the Home Agent 384 One method of establishing a registration key is for the mobile node 385 to request its home agent to generate one during registration, and 386 for the home agent to send a copy of this key to both the mobile 387 node and its new foreign agent. The home agent in this case acts 388 as a "key distribution center" (KDC) for the mobile node and the 389 foreign agent. The mobile node requests this by including a Home 390 Agent Registration Key Request extension in its Registration Request 391 message. The home agent sends the generated key to the mobile node 392 and to its foreign agent by including a Mobile Node Registration Key 393 Reply extension and a Foreign Agent Registration Key Reply extension 394 its Registration Reply message. The Mobile Node Registration Key 395 Reply extension contains a copy of the chosen key encrypted under a 396 key and algorithm shared between the home agent and the mobile node, 397 and a Foreign Agent Registration Key Reply extension contains a copy 398 of the same key encrypted under a key and algorithm shared between 399 the home agent and the foreign agent. 401 In order for the registration key to be established using this 402 method, the foreign agent must have a mobility security association 403 with the home agent. For example, if mobile nodes from some home 404 network often visit this foreign agent, it may in general be worth 405 the effort of creating such a mobility security association between 406 this foreign agent and the home agent serving that home network. If 407 no mobility security association exists, a mobile node may instead be 408 able to establish a registration key with its home agent using the 409 alternative method described in the next section. 411 2.5. Registration Key Establishment Using Diffie-Hellman 413 An alternate method defined in this document for establishing a 414 registration key is for the mobile node and its foreign agent to 415 execute the Diffie-Hellman key exchange algorithm [2] as part of the 416 mobile node's registration. The Diffie-Hellman algorithm is a public 417 key cryptosystem that allows two parties to establish a shared secret 418 key, such that the shared secret key cannot be determined by other 419 parties overhearing the messages exchanged during the algorithm. It 420 is used, for example, in other protocols that require a key exchange, 421 such as in the Cellular Digital Packet Data (CDPD) system [1]. 422 Briefly, the Diffie-Hellman algorithm involves the use of two large 423 public numbers, which must be known by both parties involved in the 424 algorithm, but need not be kept secret; the two public numbers may be 425 different for each execution of the algorithm and are not used once 426 the algorithm completes. Each party chooses a private random number, 427 computes a function of this number and the two public numbers, and 428 sends the result of this function in a message to the other party. 429 Each party then computes the (same) shared secret key using its own 430 private random number, the value received from the other party, and 431 the two public numbers. 433 To use this algorithm during registration with a foreign agent, 434 the mobile node includes a Diffie-Hellman Registration Key Request 435 extension in its Registration Request message, containing its 436 values for the two public numbers and the function of its own 437 private random number. When it receives the Registration Request 438 message, the foreign agent chooses its own private random number and 439 computes shared secret key value. The foreign agent also includes a 440 Diffie-Hellman Registration Key Reply extension in its Registration 441 Reply message to the mobile node, including the function of its own 442 private random number. The mobile node then also computes the shared 443 secret key value. 445 The Diffie-Hellman algorithm allows the mobile node and its foreign 446 agent to establish a registration key without any pre-existing 447 mobility security associations, but the Diffie-Hellman algorithm 448 itself is covered by a patent. The method of establishing a 449 registration key using Diffie-Hellman thus may not be usable by those 450 who have not licensed the patent. 452 Also, establishing a registration key using Diffie-Hellman is 453 computationally more expensive than the method described in 454 Section 2.4. The use of Diffie-Hellman described here, though, is 455 designed to allow the Diffie-Hellman computations to be overlapped 456 with other activities. The mobile node may choose the two public 457 numbers at any time, or may use the same two public numbers for 458 all registrations; for example, a mobile node may be configured by 459 the administrator of its home network with the two public numbers, 460 which the mobile node may continue to use until reconfigured by 461 its home network administrator. The mobile node may also choose 462 its private random number and compute its function of this and the 463 two public numbers at any time. For example, after completing one 464 registration, the mobile node may choose the random number for its 465 next registration and begin the computation on this random number, 466 such that it has completed this computation before it is needed in 467 its next registration; in its simplest form, the mobile node may 468 use the same random number and computed value for any number of 469 registrations, or even for all registrations. The foreign agent 470 may choose its random number and begin computation its based on 471 this number as soon as it receives the mobile node's Registration 472 Request message, and need only complete this computation before it 473 sends the matching Registration Reply message for the mobile node's 474 registration. 476 DISCUSSION: We could add a bit in the Agent Advertisement 477 message, indicating that this foreign agent supports the 478 Diffie-Hellman extension. This would save the mobile node 479 the effort of attempting Diffie-Hellman with a foreign agent 480 that did not support it. 482 DISCUSSION: This could be extended to support other similar 483 key exchange algorithms, either by adding a new Request 484 and Reply extension for each, or by adding a field in the 485 extensions to indicate which algorithm is to be used. 486 Diffie-Hellman seems the only obvious choice, though, 487 currently. 489 3. Route Optimization Message Formats 491 Route Optimization defines four message types used for management 492 of binding cache entries. Each of these messages begins with a 493 one-octet field indicating the type of the message. 495 The following Type codes are defined in this document: 497 16 = Binding Warning message 498 17 = Binding Request message 499 18 = Binding Update message 500 19 = Binding Acknowledge message 502 3.1. Binding Warning Message 504 A Binding Warning message is used to advise a node that it appears 505 to have either no binding cache entry or an out-of-date binding 506 cache entry for some mobile node. When any node receives a datagram 507 tunneled to itself, if it is not the current foreign agent for the 508 destination mobile node, it MAY send a Binding Warning message to the 509 node that originated the tunneled datagram. 511 0 1 2 3 512 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 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Type | Reserved | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | Mobile Node Home Address | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 Type 521 16 523 Reserved 525 Sent as 0; ignored on reception. 527 Mobile Node Home Address 529 The home address of the mobile node to which the Binding 530 Warning message refers. 532 3.2. Binding Request Message 534 A Binding Request message is used by a node to request a mobile 535 node's current mobility binding from the mobile node's home agent. 536 It is sent by a node upon receiving a Binding Warning message, or by 537 a node desiring to update the mobility binding in a binding cache 538 entry that it holds for the mobile node. 540 0 1 2 3 541 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 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | Type | Reserved | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | Mobile Node Home Address | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | | 548 + Identification + 549 | | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 Type 554 17 556 Reserved 558 Sent as 0; ignored on reception. 560 Mobile Node Home Address 562 The home address of the mobile node to which the Binding 563 Request refers. 565 Identification 567 A 64-bit sequence number, assigned by the node sending the 568 Binding Request message, used to assist in matching requests 569 with replies, and in protecting against replay attacks. 571 3.3. Binding Update Message 573 The Binding Update message is used to notify another node of a mobile 574 node's current mobility binding. It MAY be sent by the mobile node's 575 home agent in response to a Binding Request message. It MAY also 576 be sent by a mobile node, or by the foreign agent with which the 577 mobile node is registering, when notifying the mobile node's previous 578 foreign agent that the mobile node has moved. 580 0 1 2 3 581 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 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | Type |A|I|M|G| Rsvd | Lifetime | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | Lifetime | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | Mobile Node Home Address | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | Care-of Address | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | | 592 + Identification + 593 | | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Extensions ... 596 +-+-+-+-+-+-+-+- 598 Type 600 18 602 Acknowledge (A) 604 The Acknowledge (A) bit is set by the node sending the Binding 605 Update message to request a Binding Acknowledge message be 606 returned acknowledging its receipt. 608 Identification Present (I) 610 The Identification Present (I) bit is set by the node sending 611 the Binding Update message to indicate whether or not the 612 Identification field is present. 614 Minimal Encapsulation (M) 616 If the Minimal Encapsulation (M) bit is set, datagrams may be 617 tunneled to the mobile node using the minimal encapsulation 618 protocol used in the base Mobile IP protocol. 620 GRE Encapsulation (G) 622 If the GRE Encapsulation (G) bit is set, datagrams may be 623 tunneled to the mobile node using the GRE encapsulation 624 protocol [5]. 626 Rsvd 628 Sent as 0; ignored on reception. 630 Lifetime 632 The number of seconds remaining before the binding cache entry 633 must be considered expired. A value of all ones indicates 634 infinity. A value of zero indicates that no binding cache 635 entry for the mobile node should be created, and any existing 636 binding cache entry (and visitor list entry, in the case of 637 a mobile node's previous foreign agent) for the mobile node 638 should be deleted. The lifetime is typically equal to the 639 remaining lifetime of the mobile node's registration. 641 Mobile Node Home Address 643 The home address of the mobile node to which the Binding Update 644 message refers. 646 Care-of Address 648 The current care-of address of the mobile node. When set equal 649 to the home address of the mobile node, the Binding Update 650 message instead indicates that no binding cache entry for the 651 mobile node should be created, and any existing binding cache 652 entry (and visitor list entry, in the case of a mobile node's 653 previous foreign agent) for the mobile node should be deleted. 655 Identification 657 If present, a 64-bit number, assigned by the node sending the 658 Binding Request message, used to assist in matching requests 659 with replies, and in protecting against replay attacks. 661 The Route Optimization Authentication extension (Section 4.2) is 662 required. 664 3.4. Binding Acknowledge Message 666 A Binding Acknowledge message is used to acknowledge receipt of a 667 Binding Update message. It is sent by a node receiving the Binding 668 Update message, if the Acknowledge (A) bit is set in the Binding 669 Update message. 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 |N| Reserved | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 | Mobile Node Home Address | 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | | 679 + Identification + 680 | | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 Type 685 19 687 N 689 This bit is set if the acknowledgement is negative. For 690 instance, if the binding update was not accepted, but the 691 incoming datagram has the Acknowledge flag set, then the N bit 692 is set in this Binding Acknowledge message. 694 DISCUSSION: Alternatively, we could replace this bit with 695 a status code, as in the Registration Reply message. The 696 mobile node could log the error, but currently has no 697 real way to recover from it. 699 Reserved 701 Sent as 0; ignored on reception. 703 Mobile Node Home Address 705 Copied from the Binding Update message being acknowledged. 707 Identification 709 Copied from the Binding Update message being acknowledged, if 710 present there. 712 4. Route Optimization Extension Formats 714 Route Optimization defines the following Mobile IP message 715 extensions: 717 96 = Previous Foreign Agent Notification Extension 718 97 = Route Optimization Authentication Extension 719 98 = Home Agent Registration Key Request Extension 720 99 = Mobile Node Registration Key Reply Extension 721 100 = Foreign Agent Registration Key Reply Extension 722 101 = Diffie-Hellman Registration Key Request Extension 723 102 = Diffie-Hellman Registration Key Reply Extension 725 4.1. Previous Foreign Agent Notification Extension 727 The Previous Foreign Agent Notification extension may be included 728 in a Registration Request message sent to a foreign agent. It 729 requests the new foreign agent to send a Binding Update message on 730 behalf of the mobile node, to the mobile node's previous foreign 731 agent, to notify it that the mobile node has moved. The previous 732 foreign agent deletes the mobile node's visitor list entry, and also 733 creates a binding cache entry for the mobile node pointing to its new 734 care-of address if a new care-of address is included in the Binding 735 Update message. The Previous Foreign Agent Notification extension 736 contains only those values not otherwise already contained in the 737 Registration Request message, that are needed for the new foreign 738 agent to construct the Binding Update message. 740 0 1 2 3 741 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 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 | Type | Length | Cache Lifetime | 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | Previous Foreign Agent Address | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | New Care-of Address Address | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | Authenticator ... 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 Type 754 96 756 Length 758 10 plus the length of the Authenticator 760 Cache Lifetime 762 The number of seconds remaining before the binding cache entry 763 created by the previous foreign agent must be considered 764 expired. A value of all ones indicates infinity. A value 765 of zero indicates that the previous foreign agent should not 766 create a binding cache entry for the mobile node once it has 767 deleted the mobile node's visitor list entry. The Cache 768 Lifetime value is copied into the Lifetime field of the Binding 769 Update message. 771 Previous Foreign Agent Address 773 The IP address of the mobile node's previous foreign agent 774 to which the new foreign agent should send a Binding Update 775 message on behalf of the mobile node. 777 New Care-of Address 779 The new care-of address for the new foreign agent to send in 780 the Binding Update message to the previous foreign agent. This 781 SHOULD be either the care-of address being registered in this 782 new registration (i.e., to cause IP datagrams from the previous 783 foreign agent to be tunneled to the new foreign agent) or the 784 mobile node's home address (i.e., to cause the previous foreign 785 agent to only delete its visitor list entry for the mobile 786 node). 788 Authenticator 790 The authenticator value to be used in the Route Optimization 791 Authentication extension in the Binding Update message sent by 792 the new foreign agent to the mobile node's previous foreign 793 agent. This authenticator is calculated only over the Binding 794 Update message body. 796 4.2. Route Optimization Authentication Extension 798 The Route Optimization Authentication extension is used to 799 authenticate certain Route Optimization management messages. 801 0 1 2 3 802 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 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 | Type | Length | Authenticator ... 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 Type 809 97 811 Length 813 The length of the Authenticator 815 Authenticator 817 (variable length) A hash value taken over a stream of bytes 818 including the shared secret, all prior extensions in their 819 entirety, the the Route Optimization management data, and 820 the type and length of this extension, but not including the 821 Authenticator field itself. 823 4.3. Home Agent Registration Key Request Extension 825 The Home Agent Registration Key Request extension may be used in 826 Registration Request messages to request a registration key from 827 the mobile node's home agent. The extension is authenticated along 828 with the rest of the Registration Request message, and thus no 829 additional authenticator is included in the extension. In response 830 to a Home Agent Registration Key Request extension, the home agent 831 MAY include a Mobile Node Registration Key extension and a Foreign 832 Agent Registration Key extension in its Registration Reply message, 833 containing encrypted copies of the registration key for the mobile 834 node the foreign agent, respectively. 836 0 1 837 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | Type | Length | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 Type 844 98 846 Length 848 0 850 The mobility security association assumed to exist between the home 851 agent and the mobile node will be used to encrypt the key sent in 852 the Mobile Node Registration Key Reply extension, unless a Key 853 Identification extension is also included with the Registration 854 Request message. 856 4.4. Mobile Node Registration Key Reply Extension 858 The Mobile Node Registration Key Reply extension may be used in 859 Registration Reply messages to send a registration key from the 860 mobile node's home agent to the mobile node. When used, the home 861 agent MUST also include a Foreign Agent Registration Key Reply 862 extension in the Registration Reply message, giving a copy of the 863 same key to the mobile node's new foreign agent. The Mobile Node 864 Registration Key Reply extension is authenticated along with the 865 rest of the Registration Reply message, and thus no additional 866 authenticator is included in the extension. 868 0 1 2 3 869 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 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 | Type | Length | Mobile Node Encrypted Key ... 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 Type 876 99 878 Length 880 The length of the Mobile Node Encrypted Key 882 Mobile Node Encrypted Key 884 (variable length) The registration key, chosen by the home 885 agent, encrypted based on the mobility security association 886 between the home agent and the mobile node. The same key must 887 be sent, encrypted for the foreign agent in a Foreign Agent 888 Registration Key extension in this Registration Reply message. 890 4.5. Foreign Agent Registration Key Reply Extension 892 The Foreign Agent Registration Key Reply extension may be used 893 in Registration Reply messages to send a registration key from 894 the mobile node's home agent to the mobile node's new foreign 895 agent. When used, the home agent MUST also include a Mobile Node 896 Registration Key Reply extension in the Registration Reply message, 897 giving a copy of the same key to the mobile node. The Foreign Agent 898 Registration Key Reply extension is authenticated by including an 899 authenticator in the extension, computed based on the mobility 900 security association shared between the home agent and the foreign 901 agent. 903 0 1 2 3 904 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 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 | Type | Length | Foreign Agent Encrypted Key ... 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 | Authenticator ... 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 Type 913 100 915 Length 917 The length of the Foreign Agent Encrypted Key plus the length 918 of the Authenticator 920 Foreign Agent Encrypted Key 922 (variable length) The registration key, chosen by the home 923 agent, encrypted based on the mobility security association 924 between the home agent and the foreign agent. The same key 925 must be sent, encrypted for the mobile node in a Mobile Node 926 Registration Key extension in this Registration Reply message. 928 Authenticator 930 (variable length) A hash value taken over a stream of bytes 931 including the shared secret and the fields in this extension 932 other than the Authenticator field itself. 934 4.6. Diffie-Hellman Registration Key Request Extension 936 The Diffie-Hellman Registration Key Request extension may be included 937 in a Registration Request message sent to a foreign agent. It begins 938 the Diffie-Hellman key exchange algorithm [2] between the mobile node 939 and its new foreign agent, as described in Section 2.5. The foreign 940 agent SHOULD then include a Diffie-Hellman Registration Key Reply 941 extension in its Registration Reply message sent to the mobile node 942 in order to complete the key exchange. 944 0 1 2 3 945 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 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 | Type | Length | 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 | p ... 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 | g ... 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 | g**x mod p ... 954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 Type 958 101 960 Length 962 2 plus 3 times the length of each of p, g, and g**x mod p. The 963 values p, g, and g**x mod p must all be the same length, which 964 must be a multiple of 8 bits. 966 p 968 One of the two public numbers involved in the Diffie-Hellman 969 key exchange algorithm. The value p should be a large prime 970 number. 972 g 974 One of the two public numbers involved in the Diffie-Hellman 975 key exchange algorithm. The value g should be less than p, and 976 should be a primitive root of p. 978 g**x mod p 980 The mobile node chooses a large random number, x, and includes 981 the computed value g**x mod p in the extension. 983 4.7. Diffie-Hellman Registration Key Reply Extension 985 The Diffie-Hellman Registration Key Reply extension SHOULD be 986 included in a Registration Reply message sent by a foreign agent to 987 a mobile node that include a Diffie-Hellman Registration Key Request 988 extension in its Registration Request message to the foreign agent. 990 0 1 2 3 991 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 992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 993 | Type | Length | 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 | g**y mod p ... 996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 998 Type 1000 101 1002 Length 1004 2 plus the length of g**y mod p. The length of g**y mod p must 1005 be a multiple of 8 bits. 1007 g**x mod p 1009 The foreign agent chooses a large random number, y, and 1010 includes the computed value g**y mod p in the extension. 1011 The values of g and p are taken from the Diffie-Hellman 1012 Registration Key Request extension from the mobile node's 1013 Registration Request message. 1015 5. Mobility Security Association Management 1017 One of the most difficult aspects of Route Optimization for Mobile IP 1018 in the Internet today is that of providing authentication for all 1019 messages that affect the routing of datagrams to a mobile node. 1020 In the base Mobile IP protocol, all routing of datagrams to the 1021 mobile node while away from its home network is controlled by the 1022 home agent, since only the home agent is aware of the mobile node's 1023 mobility binding and only the home agent tunnels datagrams to 1024 the mobile node. Authentication is achieved based on a manually 1025 established mobility security association between the home agent and 1026 the mobile node. Since the home agent and the mobile node are both 1027 owned by the same organization (both are assigned IP addresses within 1028 the same IP subnet), this manual configuration is manageable, and 1029 (for example) can be performed while the mobile node is at home. 1031 However, with Route Optimization, authentication is more difficult 1032 to manage, since a Binding Update may in general need to any node in 1033 the Internet. Since no general authentication or key distribution 1034 protocol is available in the Internet today, the Route Optimization 1035 procedures defined in this document make use of the same type of 1036 manually configured mobility security associations used in the base 1037 Mobile IP protocol. For use with Route Optimization, a mobility 1038 security association held by a correspondent node or a foreign agent 1039 must in general include the same parameters as required by the base 1040 Mobile IP protocol specification [6]. 1042 For a correspondent node to be able to create a binding cache entry 1043 for a mobile node so that it can tunnel its own IP datagrams directly 1044 to the mobile node at its current location, the correspondent node 1045 and the mobile node's home agent must have established a mobility 1046 security association. This mobility security association, though, 1047 may be used in creating and updating binding cache entries at this 1048 correspondent node for all mobile nodes served by this home agent. 1049 This places the correspondent node in a fairly natural relationship 1050 with respect to the mobile nodes served by this home agent. For 1051 example, these mobile nodes may represent different people affiliated 1052 with the organization owning the home agent and these mobile nodes, 1053 with which the user of this correspondent node often collaborates. 1054 In this case, the effort of establishing the necessary mobility 1055 security association with this home agent may be justified. It is 1056 similarly possible for a home agent to have a manually established 1057 mobility security association with the foreign agents often used by 1058 its mobile nodes, or for a particular mobile node to have a manually 1059 established mobility security association with the foreign agents 1060 serving the foreign networks that it often visits. 1062 In general, if the movement and communication patterns of a mobile 1063 node or the group of mobile nodes served by the same home agent are 1064 sufficient to justify establishing a mobility security association 1065 with the mobile node's home agent, users or network administrators 1066 are likely to do so. Without establishing a mobility security 1067 association, nodes will not currently be able to use the Route 1068 Optimization extensions but can use the base Mobile IP protocol; in 1069 this case, though, datagrams destined for a mobile node have to be 1070 routed through the mobile node's home agent, to be tunneled to the 1071 mobile node's current location. 1073 6. Binding Cache Considerations 1075 Any node may maintain a binding cache in order to optimize its own 1076 communication with mobile nodes. When sending an IP datagram, if the 1077 sending node has a binding cache entry for the destination node, it 1078 MAY tunnel the datagram to the mobile node's care-of address using 1079 the encapsulation techniques described for home agents in the base 1080 Mobile IP protocol specification [6]. Any optional encapsulation 1081 methods supported are indicated by flag bits in the Binding Update 1082 message. 1084 When a mobile node's home agent intercepts a datagram on the home 1085 network and tunnels it to the mobile node, the originating node 1086 generally has no binding cache entry for the destination mobile node. 1087 In such cases, the home agent MAY send a Binding Update message to 1088 the originator. 1090 Similarly, when a node other than the foreign agent currently 1091 serving a mobile node receives a datagram for a mobile node, and 1092 this datagram has been tunneled to that node, the node tunneling 1093 the datagram generally has an out-of-date binding for the mobile 1094 node in its binding cache. In such cases, the node receiving the 1095 tunneled datagram MAY send a Binding Warning message to the tunneling 1096 node, which SHOULD then request a new binding for the mobile node by 1097 sending a Binding Request message to the mobile node's home agent. 1099 6.1. Cache Management 1101 A node maintaining a binding cache may use any reasonable strategy 1102 for managing the space within the cache. When a new entry needs to 1103 be added to the binding cache, the node MAY choose to drop any entry 1104 already in the cache, if needed, to make space for the new entry. 1105 For example, a "least-recently used" (LRU) strategy for cache entry 1106 replacement is likely to work well. 1108 Each binding in the binding cache also has an associated lifetime, 1109 specified by in the Binding Update message in which the node obtained 1110 the binding. After the expiration of this time period, the binding 1111 MUST be deleted from the cache. 1113 6.2. Receiving Binding Warning Messages 1115 A node maintaining and using a binding cache will receive a Binding 1116 Warning message if its binding cache entry for a datagram it has 1117 tunneled is out-of-date, as determined by the node which receives the 1118 tunneled datagram. When a node receives a Binding Warning message, 1119 it SHOULD request an updated binding for this mobile node from the 1120 mobile node's home agent, using a Binding Request message. Included 1121 in the Binding Request message is a 64-bit identification field, in 1122 the same format described in the base Mobile IP protocol document, 1123 for matching the request with the returned Binding Update message. 1124 The node SHOULD silently discard any Binding Update messages that 1125 do not correspond with its latest Binding Request message for this 1126 mobile node. 1128 6.3. Receiving Binding Update Messages 1130 When a node receives a Binding Update message, it MUST verify 1131 the authentication in the message, using the mobility security 1132 association it shares with the mobile node's home agent. The 1133 authentication data is found in the Route Optimization Authentication 1134 extension (Section 4.2). If the authentication succeeds, then a 1135 binding cache entry SHOULD be updated for use in future transmissions 1136 of data to the mobile node. Otherwise, an authentication exception 1137 SHOULD be raised. 1139 6.4. Using Special Tunnels 1141 Whenever any node receives a tunneled datagram for for which it has 1142 no binding cache entry or visitor list entry for the datagram's 1143 destination, the node may deduce then it has received the tunneled 1144 datagram in error. In this case, the node should forward the 1145 datagram to the destination mobile node's home agent. This tunneling 1146 should be done using a special form of tunneling called a "special 1147 tunnel", in which the tunneled datagram's destination address is 1148 set equal to the destination address in the tunneled datagram. 1149 Thus, both the "inner" and "outer" destination addresses are set to 1150 the home address of the mobile node. The tunneled datagram will 1151 thus be routed to the mobile node's home network, where it will be 1152 intercepted by the mobile node's home agent in the same way as other 1153 datagrams addressed to the mobile node. 1155 The home agent should then tunnel the datagram to the current care-of 1156 address for the mobile node. However, the home agent MUST NOT tunnel 1157 the datagram to the current care-of address if the special tunnel 1158 of the datagram originated at that care-of address. The use of the 1159 special tunnel format allows the home agent to identify the node 1160 that tunneled the datagram to it (as well as the original sender of 1161 the datagram). If the home agent believes that the current care-of 1162 address for the mobile node is the same as the source of the special 1163 tunnel, then the home agent SHOULD discard the datagram; in this 1164 case, the foreign agent serving the mobile node appears to have lost 1165 its entry for the mobile node in its visitor list, for example, if 1166 the foreign agent has crashed and rebooted. 1168 After tunneling the datagram to the current care-of address for the 1169 mobile node, the home agent MAY notify the source of the special 1170 tunnel of the mobile node's current binding, by sending it a Binding 1171 Update message. 1173 7. Home Agent Considerations 1175 The home agent will be the frequent source of Binding Update messages 1176 sent to correspondent nodes that are communicating with its mobile 1177 nodes. Any correspondent node that has no binding cache entry for a 1178 mobile node, will send normal, untunneled datagrams through the home 1179 agent by the normal routing in the Internet. When the home agent 1180 first receives a datagram for a mobile node, it SHOULD also send a 1181 Binding Update message to the originator of the datagram in hopes 1182 that the originator will be able to create a binding cache entry for 1183 that mobile node. Then, future datagrams sent by this node to the 1184 mobile node should not need the involvement of the home agent. 1186 As the Route Optimization extensions to the base Mobile IP protocol 1187 become widely implemented and deployed, more and more Internet nodes 1188 will be able to maintain a binding cache, and it is hoped that home 1189 agents will need to be involved only rarely with routing datagrams to 1190 mobile nodes. The home agent might usually need to be involved only 1191 when a correspondent node first begins sending datagrams to a mobile 1192 node to which it has not sent previous datagrams within some long 1193 period of time. 1195 7.1. Rate Limiting 1197 A home agent must provide some mechanism to limit the rate at which 1198 it sends Binding Update messages to to the same node about any given 1199 mobility binding, after tunneling a datagram intercepted on the home 1200 network. This is especially important because it is expected that, 1201 within the short term, many Internet nodes will not be equipped with 1202 a binding cache. In this case, continual transmissions of Binding 1203 Warning messages to such a correspondent node will only exacerbate 1204 the problem of the traffic bottleneck at the home agent, and will 1205 unnecessarily waste Internet resources between the home agent and the 1206 correspondent node. 1208 7.2. Receiving Binding Request Messages 1210 When the home agent receives a Binding Request message, it consults 1211 its home list and determines the correct binding information to be 1212 sent to the requesting node. Before satisfying the request, the 1213 home agent must check whether or not the mobile node has allowed the 1214 information to be disseminated. If the mobile node specified the 'P' 1215 bit in its Registration Request message, then the home agent must not 1216 satisfy any Binding Requests. In this case, the home agent SHOULD 1217 return Binding Update in which both the care-of address and the 1218 lifetime are set to zero. Such a Binding Update message indicates 1219 that the binding cache entry for the specified mobile node should 1220 be deleted. This situation can never arise by the action of any 1221 correctly operating node maintaining a binding cache, but it is still 1222 possible that an intelligent correspondent node might try to obtain 1223 bindings for mobile nodes. 1225 7.3. Receiving Registration Key Requests 1227 When the home agent receives a Registration Request message, a Home 1228 Agent Registration Key Request extension (Section 4.3) may be present 1229 in the message, requesting the home agent to provide a registration 1230 key to the mobile node and its foreign agent, as described in 1231 Section 2.2. In that event, the home agent employs a good algorithm 1232 for producing random keys [4] and encrypts the result separately for 1233 use by the foreign agent and by the mobile node. The chosen key is 1234 encrypted under a key and algorithm shared between the home agent and 1235 the mobile node, and the encrypted key is placed in a Mobile Node 1236 Registration Key Reply extension (Section 4.4) in the Registration 1237 Reply message. The same key also is encrypted under a key and 1238 algorithm shared between the home agent and the foreign agent, and 1239 the encrypted key is placed in a Foreign Agent Registration Key Reply 1240 extension (Section 4.5) in the Registration Reply message. 1242 7.4. Receiving Special Tunnels 1244 The home agent may also receive tunneled datagrams destined for the 1245 mobile node. If the tunnel source is the same as the foreign agent 1246 shown in the home list entry for the mobile node, then the home 1247 agent MUST NOT send the datagram back to that same foreign agent. 1248 Otherwise, the home agent can tunnel the tunneled datagram to the 1249 current foreign agent, encapsulating the incoming tunneled datagram 1250 in its entirety. 1252 The home agent also, in this case, takes responsibility for sending 1253 information to the originator of the datagram (whose source address 1254 will be in the inner datagram header inside the encapsulation), to 1255 allow that originator to update its binding cache entry for the 1256 target mobile node. If the home agent has a mobility security 1257 association with the correspondent node which originated the 1258 datagram, an authenticated Binding Update message can be sent 1259 directly. 1261 8. Foreign Agent Considerations 1263 In addition to managing the resources needed to handle registrations 1264 in the base Mobile IP protocol, the foreign agent assisting with 1265 Route Optimization assumes two additional responsibilities. The 1266 first is the maintenance of a binding cache for forwarding datagrams 1267 to mobile nodes as they switch connections to new foreign agents. 1268 The second is a small modification to the registration procedure, to 1269 allow for timely notification possible for previous foreign agents. 1271 8.1. Establishing a Registration Key 1273 As part of the registration procedure, a mobile node and its new 1274 foreign agent can establish a registration key. This registration 1275 key is, as described in Section 7.3, computed by the mobile node's 1276 home agent and transmitted back to the foreign agent (and to 1277 the mobile node) in the Registration Reply message. Within this 1278 document, the registration key is used only for authentication of a 1279 single Binding Update message; other uses for the registration key 1280 are possible, but are outside the scope of this discussion. For 1281 instance, the foreign agent and mobile node may negotiate to use 1282 the registration key to provide privacy along the wireless link 1283 connecting them. 1285 The actual request for the registration key is made by the mobile 1286 node (Section 2.2). When the foreign agent receives the Registration 1287 Reply containing a Foreign Agent Registration Key Reply extension 1288 and a Mobile Node Registration Key Reply extension, the foreign 1289 agent removes the extension containing its own registration key, 1290 and forwards the rest of the Registration Reply message to the 1291 mobile node. The Foreign Agent Registration Key Reply extension 1292 is covered by its own authentication, not by the authentication 1293 covering the Registration Reply message itself, and thus removing the 1294 Foreign Agent Registration Key Reply extension does not interfere 1295 with the mobile node's ability to verify the authentication on the 1296 Registration Reply message. 1298 8.2. Previous Foreign Agent Notification 1300 When a mobile node registers with a new foreign agent, it may request 1301 that the new foreign agent send a Binding Update message to its 1302 previous foreign agent. This Binding Update must be authenticated, 1303 using the Route Optimization Authentication extension (Section 4.2), 1304 as must all Binding Updates. The Acknowledge bit in this Binding 1305 Update message must be set. 1307 When the previous foreign agent receives the Binding Update, it will 1308 use the mobility security association set up with the mobile node 1309 during its previous registration to authenticate the message. If 1310 the message authentication is correct, the old visitor list entry 1311 will be deleted and a Binding Acknowledge message returned to the 1312 sender. In addition, if a new care-of address was included with the 1313 new binding, a binding cache entry will be created for it, and the 1314 previous foreign agent can tunnel datagrams to the mobile node's 1315 current care-of address using that binding cache, just as any node 1316 maintaining a binding cache. 1318 In particular, the previous foreign agent can tunnel the Binding 1319 Acknowledge message back to the new care-of address specified in 1320 the received binding. This creates an interesting problem for the 1321 new foreign agent when it receives the acknowledgment before the 1322 registration reply from the home agent. It is suggested that the new 1323 foreign agent deliver the acknowledgment to the mobile node anyway, 1324 even though the mobile node is technically unregistered. If there 1325 is concern that this provides a loophole for unauthorized traffic 1326 to the mobile node, the new foreign agent could limit the number of 1327 datagrams delivered to the unregistered mobile node to this single 1328 instance. Alternatively, a new extension to the Registration Reply 1329 message can be defined to carry along the acknowledgement from the 1330 previous foreign agent. This latter approach would have the benefit 1331 that fewer datagrams would be transmitted over bandwidth-constrained 1332 wireless media during registrations. 1334 The lifetime associated with the binding cache, in this situation, 1335 can be substantially shorter than other binding caches for several 1336 reasons. First, the home agent is presumably tunneling datagrams to 1337 the new foreign agent; second, any active correspondent node will 1338 probably get a new binding cache entry for the mobile node after 1339 receiving the Binding Warning message from the previous foreign 1340 agent. Lastly, even if the binding cache entry expires prematurely, 1341 the previous foreign agent can special tunnel any straggling 1342 datagrams back to the home agent for further delivery. 1344 8.3. Receiving Tunneled Datagrams 1346 If the mobile node's current foreign agent receives a tunneled 1347 datagram for the mobile node, it can be assumed that the tunneled 1348 datagram was originated by a node maintaining a binding cache. 1349 There may be pathological or special cases where this assumption is 1350 false, but one would almost have to intentionally run custom code 1351 to invalidate the assumption. Since the foreign agent currently 1352 serving a mobile node can assume that the sending node forwarded the 1353 datagram based on correct binding cache information, the foreign 1354 agent can also assume that the sending cache agent has already issued 1355 notification to the source of the original datagram. Thus, the 1356 current foreign agent never needs to send a Binding Warning message 1357 to the node which last tunneled the datagram. 1359 On the other hand, a foreign agent which is tunneling received 1360 datagrams on behalf of a mobile node not in its visitor list should, 1361 just as any other node implementing Route Optimization, send Binding 1362 Warning messages to the originator of these datagrams. If the 1363 datagrams it receives are not tunneled, the foreign agent should 1364 limit the rate at which it sends Binding Warning messages to the 1365 originators, since those originators may be unable to interpret such 1366 notifications. It is expected that reception of such un-tunneled 1367 datagrams by any foreign agent will be rare. 1369 8.4. Sending Special Tunnels 1371 If a foreign agent receives a tunneled datagram for a mobile node 1372 which is unknown, then the foreign agent can tunnel the datagram back 1373 to the home agent. This requires special care at the home agent. 1374 The foreign agent must use the mobile node's address as the tunnel 1375 destination, and its own address as the tunnel source. The home 1376 agent will then capture the special tunneled datagram and re-tunnel 1377 it to the mobile node via its current foreign agent. The foreign 1378 agent sending the special tunnel should not notify the originator of 1379 the datagram about its out-of-date binding, as this will be done by 1380 the home agent which receives the special tunnel datagram. 1382 9. Mobile Node Considerations 1384 9.1. Requesting a Registration Key 1386 When a mobile node sends a Registration Request message, it can 1387 also request a registration key to be established between itself 1388 and the prospective foreign agent. The key will be used later to 1389 authenticate the Binding Update sent to this foreign agent to notify 1390 it that the mobile node has moved to a new care-of address. The 1391 mobile node allows the home agent to pick the registration key, 1392 because it is expected that the mobile node is less likely to have 1393 good means for producing pseudo-random numbers [4]. The registration 1394 key will be returned to the mobile node in a Mobile Node Registration 1395 Key Reply extension to the Registration Reply message from the home 1396 agent. A separate copy of the registration key is also returned to 1397 the foreign agent in a Foreign Agent Registration Key Reply extension 1398 to the Registration Reply message. 1400 9.2. Notifying Previous Foreign Agents 1402 If the mobile node wishes to instruct its prospective foreign agent 1403 to send a Binding Update message to the mobile node's previous 1404 foreign agent, it includes a Previous Foreign Agent Notification 1405 extension (Section 4.1) in its Registration Request message. This 1406 notification usually results in quicker establishment of a binding 1407 cache entry at the previous foreign agent, because the previous 1408 foreign agent is likely to be much closer to the new foreign agent 1409 than the home agent is. 1411 Since the prospective new foreign agent does not have access to 1412 the registration key which was established between the mobile node 1413 and its previous foreign agent, the mobile node must compute the 1414 appropriate authentication value for use by the prospective foreign 1415 agent. This authentication is computed over the fields of the 1416 expected Binding Update message. 1418 When the Binding Acknowledgment message from the previous foreign 1419 agent is received by the new foreign agent, it detunnels it and 1420 sends it to the mobile node. In this way, the mobile node can 1421 still discover that its previous foreign agent has updated its 1422 visitor list and binding cache. This is important, because otherwise 1423 the previous foreign agent would often become a "black hole" for 1424 datagrams destined for the mobile node. The new foreign agent has no 1425 further responsibility for helping to update the binding cache at the 1426 previous foreign agent. 1428 The mobile node expects to eventually receive a Binding 1429 Acknowledgement from its previous foreign agent, signifying that the 1430 mobile node's entry has been erased from its visitor list. If the 1431 acknowledgement has not been received after sufficient time, the 1432 mobile node is responsible for retransmitting another Binding Update 1433 message to its previous foreign agent. Although the previous foreign 1434 agent may have already deleted the registration key from its records, 1435 the mobile node should continue to retransmit its Binding Update 1436 message until the previous foreign agent responds with a Binding 1437 Acknowledgement. 1439 Since the mobile node is responsible for handling the Binding 1440 Acknowledgement from its previous foreign agent, there is no need 1441 to add any status code or bit to the Registration Reply from its 1442 prospective new foreign agent 1444 References 1446 [1] CDPD Forum. Cellular Digital Packet Data system specification. 1447 Release 1.0, July 1993. 1449 [2] W. Diffie and M. E. Hellman. New directions in cryptography. 1450 IEEE Transactions on Information Theory, IT-22(6):644--654, 1451 November 1976. 1453 [3] Ralph Droms. Dynamic Host Configuration Protocol. RFC 1541, 1454 October 1993. 1456 [4] Donald E. Eastlake 3rd, Stephen D. Crocker, and Jeffrey I. 1457 Schiller. Randomness recommendations for security. RFC 1750, 1458 December 1994. 1460 [5] Stan Hanks, Tony Li, Dino Farinacci, and Paul Traina. Generic 1461 Routing Encapsulation (GRE). RFC 1701, October 1994. 1463 [6] Charles Perkins, editor. IP mobility support. Internet Draft, 1464 draft-ietf-mobileip-protocol-10.txt, May 1995. Work in progress. 1466 Appendix A. Using a Master Key at the Home Agent 1468 Rather than storing each mobility security association that it has 1469 established with many different correspondent nodes and foreign 1470 agents, a home agent may manage its mobility security associations so 1471 that each of them can be generated from a single "master" key. With 1472 the master key, the home agent could build a key for any given other 1473 node by computing the node-specific key as 1475 MD5(node-address || master-key || node-address) 1477 where node-address is the IP address of the particular node for which 1478 the home agent is building a key, and master-key is the single master 1479 key held by the home agent for all mobility security associations it 1480 has established with correspondent nodes. The node-specific key is 1481 built by computing an MD5 hash over a string consisting of the master 1482 key with the node-address concatenated as a prefix and as a suffix. 1484 Using this scheme, when establishing each mobility security 1485 association, the network administrator managing the home agent 1486 computes the node-specific key and communicates this key to the 1487 network administrator of the other node through some "secure" 1488 channel, such as over the telephone. The mobility security 1489 association is configured at this other node in the same way as any 1490 mobility security association. At the home agent, though, no record 1491 need be kept that this key has been given out. The home agent need 1492 only be configured to know that this scheme is in use for all of its 1493 mobility security associations. 1495 When the home agent then needs a mobility security association as 1496 part of the Route Optimization protocol, it builds the node-specific 1497 key based on the master key and the IP address of the other node with 1498 which it is attempting to authenticate. If the other node knows 1499 the correct node-specific key, the authentication will succeed; 1500 otherwise, it will fail as it should. 1502 Chairs' Addresses 1504 The working group can be contacted via the current chairs: 1506 Tony Li 1507 cisco Systems 1508 170 W. Tasman Drive 1509 San Jose, CA 95134 1511 Phone: +1-408-526-8186 1512 E-mail: tli@cisco.com 1514 Jim Solomon 1515 Motorola, Inc. 1516 1301 E. Algonquin Road 1517 Schaumburg, IL 60196 1519 Phone: +1-708-576-2753 1520 E-mail: solomon@comm.mot.com 1522 Authors' Addresses 1524 Questions about this document can also be directed to the authors: 1526 David B. Johnson 1527 Computer Science Department 1528 Carnegie Mellon University 1529 5000 Forbes Avenue 1530 Pittsburgh, PA 15213-3891 1532 Phone: +1-412-268-7399 1533 Fax: +1-412-268-5576 1534 E-mail: dbj@cs.cmu.edu 1536 Charles Perkins 1537 Room J1-A25 1538 T. J. Watson Research Center 1539 IBM Corporation 1540 30 Saw Mill River Rd. 1541 Hawthorne, NY 10532 1543 Phone: +1-914-784-7350 1544 Fax: +1-914-784-7007 1545 E-mail: perk@watson.ibm.com