idnits 2.17.1 draft-ietf-mobileip-optim-04.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-25) 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 207: '...ally created and MAY be deleted by the...' RFC 2119 keyword, line 214: '...All Binding Update messages MUST carry...' RFC 2119 keyword, line 222: '... that MAY optionally be establ...' RFC 2119 keyword, line 224: '...elsewhere, the mobile node MAY use the...' RFC 2119 keyword, line 234: '...unneled datagram MUST NOT re-tunnel th...' (55 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: One bit is added to the flag bits in the Registration Request message to indicate that the mobile node would like its home agent to keep its mobility binding "private". Normally, the home agent sends Binding Update messages to correspondent nodes as needed to allow them to cache the mobile node's binding. If the mobile node sets the Private (P) bit in the Registration Request message, the home agent MUST not send the mobile node's binding in Binding Update messages. Instead, each Binding Update message should give the mobile node's care-of address equal to its home address, and should give a Lifetime value of 0. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: When the home agent receives a Binding Request message, it consults its home list and determines the correct binding information to be sent to the requesting node. Before satisfying the request, the home agent MUST check whether or not the mobile node has allowed the information to be disseminated. If the mobile node specified the Private (P) bit in its Registration Request message, then the home agent MUST not satisfy any Binding Requests. In this case, the home agent SHOULD return a Binding Update in which both the Care-of Address is set equal to the mobile node's home address and the Lifetime is set to zero. Such a Binding Update message indicates that the binding cache entry for the specified mobile node should be deleted. -- 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-12 -- Possible downref: Non-RFC (?) normative reference: ref. '7' Summary: 12 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobile IP Working Group David B. Johnson 2 INTERNET DRAFT Carnegie Mellon University 3 22 February 1996 Charles Perkins 4 IBM Corporation 6 Route Optimization in Mobile IP 8 draft-ietf-mobileip-optim-04.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. Terminology 3 61 3. Route Optimization Overview 4 62 3.1. Binding Caching . . . . . . . . . . . . . . . . . . . . . 4 63 3.2. Foreign Agent Handoff . . . . . . . . . . . . . . . . . . 4 64 3.3. Binding Cache Updates . . . . . . . . . . . . . . . . . . 7 66 4. Route Optimization Message Formats 9 67 4.1. Binding Warning Message . . . . . . . . . . . . . . . . . 10 68 4.2. Binding Request Message . . . . . . . . . . . . . . . . . 11 69 4.3. Binding Update Message . . . . . . . . . . . . . . . . . 12 70 4.4. Binding Acknowledge Message . . . . . . . . . . . . . . . 14 71 4.5. Registration Request Message . . . . . . . . . . . . . . 16 73 5. Route Optimization Extension Formats 17 74 5.1. Previous Foreign Agent Notification Extension . . . . . . 18 75 5.2. Route Optimization Authentication Extension . . . . . . . 20 76 5.3. Registration Key Request Extension . . . . . . . . . . . 21 77 5.4. Home-Mobile Registration Key Reply Extension . . . . . . 22 78 5.5. Home-Foreign Registration Key Reply Extension . . . . . . 23 79 5.6. Diffie-Hellman Registration Key Request Extension . . . . 24 80 5.7. Diffie-Hellman Registration Key Reply Extension . . . . . 26 81 5.8. Mobile Service Extension . . . . . . . . . . . . . . . . 27 83 6. Mobility Security Association Management 28 85 7. Methods of Establishing a Registration Key 30 86 7.1. Using the Home Agent as a Key Distribution Center . . . . 30 87 7.2. Using Diffie-Hellman with the Foreign Agent . . . . . . . 30 88 7.3. Using a Mobile Node Public Key . . . . . . . . . . . . . 32 89 7.4. Using a Foreign Agent Public Key . . . . . . . . . . . . 32 91 8. Binding Cache Considerations 34 92 8.1. Cache Management . . . . . . . . . . . . . . . . . . . . 34 93 8.2. Receiving Binding Update Messages . . . . . . . . . . . . 34 94 8.3. Using Special Tunnels . . . . . . . . . . . . . . . . . . 35 96 9. Home Agent Considerations 36 97 9.1. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . 36 98 9.2. Receiving Binding Warning Messages . . . . . . . . . . . 36 99 9.3. Receiving Binding Request Messages . . . . . . . . . . . 37 100 9.4. Receiving Registration Key Requests . . . . . . . . . . . 37 101 9.5. Receiving Special Tunnels . . . . . . . . . . . . . . . . 38 103 10. Foreign Agent Considerations 39 104 10.1. Establishing a Registration Key . . . . . . . . . . . . . 39 105 10.2. Previous Foreign Agent Notification . . . . . . . . . . . 40 106 10.3. Receiving Tunneled Datagrams . . . . . . . . . . . . . . 41 107 10.4. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . 42 108 10.5. Sending Special Tunnels . . . . . . . . . . . . . . . . . 42 110 11. Mobile Node Considerations 43 111 11.1. Establishing a Registration Key . . . . . . . . . . . . . 43 112 11.2. Notifying Previous Foreign Agents . . . . . . . . . . . . 43 114 References 45 116 Appendix A. Using a Master Key at the Home Agent 46 118 Chairs' Addresses 47 120 Authors' Addresses 48 121 1. Introduction 123 The base Mobile IP protocol [6] allows any mobile node to move about, 124 changing its point of attachment to the Internet, while continuing 125 to be addressed by its home IP address. Correspondent nodes sending 126 IP datagrams to a mobile node address them to the mobile node's home 127 address in the same way as to any destination. 129 While the mobile node is connected to the Internet away from its 130 home network, it is served by a "home agent" on its home network 131 and is associated with a "care-of address" indicating its current 132 location. The association between a mobile node's home address and 133 its care-of address is known as a "mobility binding". The care-of 134 address is generally the address of a "foreign agent" on the network 135 being visited by the mobile node, which forwards arriving datagrams 136 locally to the mobile node. Alternatively, the care-of address may 137 be temporarily assigned to the mobile node using DHCP [3] or other 138 means. All IP datagrams addressed to the mobile node are routed by 139 the normal IP routing mechanisms to the mobile node's home network, 140 where they are intercepted by the mobile node's home agent, which 141 then tunnels each datagram to the mobile node's current care-of 142 address. Datagrams sent by a mobile node use the foreign agent as a 143 default router but require no other special handling or routing. 145 This scheme allows transparent interoperation with mobile nodes, 146 but forces all datagrams for a mobile node to be routed through its 147 home agent; datagrams to the mobile node are often routed along 148 paths that are significantly longer than optimal. For example, if a 149 mobile node, say MN1, is visiting some subnet, even datagrams from 150 a correspondent node on this same subnet must be routed through the 151 Internet to MN1's home agent on MN1's home network, only to then 152 be tunneled back to the original subnet to MN1's foreign agent for 153 delivery to MN1. This indirect routing can significantly delay the 154 delivery of the datagram to MN1 and places an unnecessary burden on 155 the networks and routers along this path through the Internet. If 156 the correspondent node in this example is actually another mobile 157 node, say MN2, then datagrams from MN1 to MN2 must likewise be routed 158 through MN2's home agent on MN2's home network and back to the 159 original subnet for delivery to MN1. 161 This document defines extensions to the base Mobile IP protocol to 162 allow for the optimization of datagram routing from a correspondent 163 node to a mobile node. These extensions provide a means for nodes 164 that implement them to cache the binding of a mobile node and to then 165 tunnel their own datagrams directly to the care-of address indicated 166 in that binding, bypassing the possibly lengthy route to and from 167 that mobile node's home agent. Extensions are also provided to allow 168 datagrams in flight when a mobile node moves, and datagrams sent 169 based on an out-of-date cached binding, to be forwarded directly 170 to the mobile node's new care-of address. These extensions are 171 collectively referred to as Route Optimization in this document. 173 All operation of Route Optimization that changes the routing of IP 174 datagrams to the mobile node is authenticated using the same type of 175 authentication mechanism used in the base Mobile IP protocol. This 176 authentication generally relies on a "mobility security association" 177 established in advance between the node sending a message and the 178 node receiving the message that must authenticate it. When the 179 required mobility security association has not been established, a 180 Mobile IP implementation using Route Optimization operates in the 181 same way as the base Mobile IP protocol. 183 Section 3 of this document provides an overview of the operation of 184 Route Optimization. Section 4 defines the message types used by 185 Route Optimization, and Section 5 defines the message extensions 186 used. Section 6 discusses the problem of managing the mobility 187 security associations needed to provide authentication of all 188 messages that affect the routing of datagrams to a mobile node. 189 The final four sections of this document define in detail the 190 operation of Route Optimization from the point of view of each of the 191 entities involved: considerations for nodes maintaining a binding 192 cache are presented in Section 8, mobile node considerations in 193 Section 11, foreign agent considerations in Section 10, and home 194 agent considerations in Section 9. 196 2. Terminology 198 This document introduces the following terminology, in addition to 199 that used in the base Mobile IP protocol: 201 Binding cache 203 A cache of mobility bindings of mobile nodes, maintained by 204 a node for use in tunneling datagrams to those mobile nodes. 205 Presence of a binding cache entry is not required for correct 206 operation of the Mobile IP protocol. Entries in the binding 207 cache are dynamically created and MAY be deleted by the node at 208 any time, such as to reclaim space in the cache. 210 Binding update 212 A notification to some node of a mobile node's current 213 mobility binding. A binding update is sent using a Binding 214 Update message. All Binding Update messages MUST carry 215 an authentication extension, similar to the authentication 216 required in all registration messages in the base Mobile IP 217 protocol. 219 Registration key 221 A secret key shared between a mobile node and a foreign agent, 222 that MAY optionally be established during registration with 223 that foreign agent. When later moving and registering a 224 new care-of address elsewhere, the mobile node MAY use the 225 registration key it shares with its previous foreign agent, to 226 send an authenticated binding update to this foreign agent. 228 Special tunnel 230 A method of tunneling a datagram in which the "outer" 231 destination address when encapsulating the datagram is 232 set equal to the "inner" destination address (the original 233 destination address of the datagram). Any router forwarding 234 such a tunneled datagram MUST NOT re-tunnel the datagram even 235 if it has a binding cache entry for the destination address. A 236 special tunnel is used in Route Optimization for delivering a 237 datagram, addressed to a mobile node, to the mobile node's home 238 agent while the mobile node is away from home, without knowing 239 the home agent's address. The "outer" source address allows 240 the home agent to know the tunneling node's address when it 241 intercepts the datagram on the home network. 243 3. Route Optimization Overview 245 3.1. Binding Caching 247 Route Optimization provides a means for any node that wishes to 248 optimize its own communication with mobile nodes to maintain a 249 "binding cache" containing the mobility binding of one or more mobile 250 nodes. When sending an IP datagram to a mobile node, if the sender 251 has a binding cache entry for the destination mobile node, it may 252 tunnel the datagram directly to the care-of address indicated in the 253 cached mobility binding. 255 In the absence of any binding cache entry, datagrams destined for 256 a mobile node will be routed to the mobile node's home network in 257 the same way as any other IP datagram, and are then tunneled to the 258 mobile node's current care-of address by the mobile node's home 259 agent. This is the only routing mechanism supported by the base 260 Mobile IP protocol. With Route Optimization, as a side effect of 261 this indirect routing of a datagram to a mobile node, the original 262 sender of the datagram may be informed of the mobile node's current 263 mobility binding, giving the sender an opportunity to cache the 264 binding. 266 A node may create a binding cache entry for a mobile node only when 267 it has received and authenticated the mobile node's mobility binding. 268 Likewise, a node may update an existing binding cache entry for a 269 mobile node, such as after the mobile node has moved to a new foreign 270 agent, only when it has received and authenticated the mobile node's 271 new mobility binding. 273 A binding cache will, by necessity, have a finite size. Any node 274 implementing a binding cache may manage the space in its cache using 275 any local cache replacement policy. If a datagram is sent by a 276 node to a destination for which it has dropped the cache entry from 277 its binding cache, the datagram will be routed normally, leading to 278 the mobile node's home network, where it will be intercepted by the 279 mobile node's home agent and tunneled to the mobile node's care-of 280 address. As when a binding cache entry is initially created, this 281 indirect routing to the mobile node will result in the original 282 sender of the datagram being informed of the mobile node's current 283 mobility binding, allowing it to add this entry again to its binding 284 cache. 286 3.2. Foreign Agent Handoff 288 When a mobile node moves and registers with a new foreign agent, the 289 base Mobile IP protocol does not notify the mobile node's previous 290 foreign agent. IP datagrams intercepted by the home agent after 291 the new registration are tunneled to the mobile node's new care-of 292 address, but datagrams in flight that had already been intercepted 293 by the home agent and tunneled to the old care-of address when the 294 mobile node moved are lost and are assumed to be retransmitted by 295 higher-level protocols if needed. The old foreign agent eventually 296 deletes the mobile node's registration after the expiration of the 297 lifetime period established when the mobile node registered there. 299 Route Optimization provides a means for the mobile node's previous 300 foreign agent to be reliably notified of the mobile node's new 301 mobility binding, allowing datagrams in flight to the mobile 302 node's previous foreign agent to be forwarded to its new care-of 303 address. This notification also allows any datagrams tunneled to the 304 mobile node's previous foreign agent from correspondent nodes with 305 out-of-date binding cache entries for the mobile node (that have not 306 yet learned that the mobile node has moved), to be forwarded to its 307 new care-of address. Finally, this notification allows any resources 308 consumed by the mobile node's binding at the previous foreign agent 309 (such as radio channel reservations) to be released immediately, 310 rather than waiting for the mobile node's registration to expire. 312 Optionally, during registration with a new foreign agent, the mobile 313 node and the foreign agent may establish a new shared secret key 314 as a "registration key". When the mobile node later registers 315 with a new foreign agent, if it established a registration key 316 during registration with its previous foreign agent, it may use 317 this key to notify the previous foreign agent that it has moved. 318 This notification may also optionally include the mobile node's new 319 care-of address, allowing the previous foreign agent to create a 320 binding cache entry for the mobile node to serve as a "forwarding 321 pointer" to its new location. Any tunneled datagrams for the mobile 322 node that arrive at this previous foreign agent after this binding 323 cache entry has been created will then be re-tunneled by this 324 foreign agent to the mobile node's new location using the mobility 325 binding in this binding cache entry. The registration key is used 326 to authenticate the notification sent to the previous foreign agent. 327 Other uses of the registration key are possible, such as for use as 328 an encryption key for providing privacy over a wireless link between 329 the mobile node and its foreign agent, but such uses are beyond the 330 scope of this document. Once established, the registration key for a 331 mobile node can be stored by the foreign agent with the mobile node's 332 visitor list entry. 334 In this document, we suggest four methods that a mobile node could 335 use for dynamically establishing a registration key with a foreign 336 agent when it registers with that foreign agent: 338 - The home agent chooses the new registration key, and returns a 339 separate encrypted copy of the key to the foreign agent and to 340 the mobile node in its Registration Reply message. For this 341 method, the home agent must share a mobility security association 342 with the foreign agent in addition to its required mobility 343 security association with the mobile node. 345 - The mobile node and its foreign agent execute a Diffie-Hellman 346 key exchange protocol [2] as part of the registration protocol. 348 - The mobile node includes its public key (such as RSA) in its 349 Registration Request to the foreign agent, and the foreign 350 agent chooses the new registration key and returns a copy of it 351 encrypted with the mobile node's public key. 353 - The foreign agent includes an MD5 digest of its public key (such 354 as RSA) in its Agent Advertisement messages. The mobile node 355 includes a copy of this digest in its Registration Request, and 356 the foreign agent adds its full public key to the Registration 357 Request when relaying it to the home agent. The home agent then 358 chooses the new registration key and returns a separate encrypted 359 copy of the key to the foreign agent (using this public key) and 360 to the mobile node (using its mobility security association with 361 the mobile node) in its Registration Reply message. 363 Section 7 discusses these methods of establishing a registration key 364 in detail. 366 As part of the registration procedure, the mobile node may 367 request that its new foreign agent attempt to notify its previous 368 foreign agent on its behalf, by including a Previous Foreign Agent 369 Notification extension in its Registration Request message sent to 370 the new foreign agent. The new foreign agent then builds a Binding 371 Update message and transmits it to the mobile node's previous foreign 372 agent as part of registration, requesting an acknowledgement from 373 the previous foreign agent. The Previous Foreign Agent Notification 374 extension includes only those values needed to construct the Binding 375 Update message that are not already contained in the Registration 376 Request message. The authenticator for the Binding Update message is 377 computed by the mobile node based on its registration key shared with 378 its previous foreign agent. 380 The mobile node is responsible for occasionally retransmitting a 381 Binding Update message to its previous foreign agent until the 382 matching Binding Acknowledge message is received, or until the mobile 383 node can be sure of the expiration of its registration with that 384 foreign agent. 386 The binding cache entry created at the mobile node's previous foreign 387 agent is treated in the same way as any other binding cache entry. 388 In particular, it is possible that this binding cache entry will be 389 deleted from the cache at any time. In this case, the foreign agent 390 will be unable to re-tunnel subsequently arriving tunneled datagrams 391 for the mobile node, directly to the mobile node's new location. 393 3.3. Binding Cache Updates 395 When a mobile node's home agent intercepts a datagram from the 396 home network and tunnels it to the mobile node, the home agent may 397 deduce that the original source of the datagram has no binding 398 cache entry for the destination mobile node. In this case, the 399 home agent MAY send a Binding Update message to the original source 400 node, informing it of the mobile node's current mobility binding. 401 No acknowledgement for this Binding Update message is needed, since 402 additional future datagrams from this source node intercepted by the 403 home agent for the mobile node will cause transmission of another 404 Binding Update. In order for this Binding Update to be authenticated 405 by the original source node, the home agent and this source node must 406 have established a mobility security association. 408 Similarly, when any node receives a tunneled datagram that was 409 tunneled to this node, if it has a binding cache entry for the 410 destination mobile node (and thus has no visitor list entry for 411 this mobile node), the node receiving this tunneled datagram may 412 deduce that the tunneling node has an out-of-date binding cache entry 413 for this mobile node. In this case, the receiving node MAY send a 414 Binding Warning message to the mobile node's home agent, advising 415 it to send a Binding Update message to the node that tunneled this 416 datagram. The mobile node's home agent can be determined from the 417 binding cache entry (the home agent address is learned from the 418 Binding Update that established this cache entry), and the address 419 of the node that tunneled this datagram can be determined from the 420 datagram's header (the address of the node tunneling this datagram 421 is the "outer" source address of the encapsulated datagram). As in 422 the case of a Binding Update sent by the mobile node's home agent, no 423 acknowledgement of this Binding Warning is needed, since additional 424 future datagrams for the mobile node tunneled by the same node will 425 cause the transmission of another Binding Warning. However, unlike 426 the Binding Update message, no authentication of the Binding Warning 427 message is necessary, since it does not directly affect the routing 428 of IP datagrams to the mobile node. 430 Finally, suppose a node receives a datagram that has been tunneled to 431 this node, but this node is unable to deliver the datagram locally 432 to the destination mobile node (the node is not the mobile node 433 itself, and it is not a foreign agent with a visitor list entry for 434 the mobile node), and this node has no binding cache entry for the 435 destination mobile node. To attempt delivery of the datagram in this 436 case, the node must encapsulate the datagram as a "special tunnel" 437 datagram (Section 10.5), destined to the mobile node. This use of a 438 "special tunnel" avoids a possible routing loop in the case in which 439 the case-of address registered at the home agent is the address of 440 this node, but this node has forgotten that it is serving as the 441 mobile node's foreign agent, perhaps because the node has crashed and 442 lost its visitor list state. The "special tunnel" allows the home 443 agent to see the address of the node that tunneled the datagram, and 444 to avoid tunneling the datagram back to the same node. 446 Each Binding Update message indicates the maximum lifetime of any 447 binding cache entry created from the Binding Update. When sending 448 the Binding Update message, the home agent SHOULD set this lifetime 449 to the remaining service lifetime associated with the mobile node's 450 current registration. Any binding cache entry established or updated 451 in response to this Binding Update message must be marked to be 452 deleted after the expiration of this period. A node wanting to 453 provide continued service with a particular binding cache entry may 454 attempt to reconfirm that mobility binding before the expiration of 455 this lifetime period. Such reconfirmation of a binding cache entry 456 may be appropriate when the node has indications (such as an open 457 transport-level connection to the mobile node) that the binding 458 cache entry is still needed. This reconfirmation is performed by 459 the node sending a Binding Request message to the mobile node's home 460 agent, requesting it to reply with the mobile node's current mobility 461 binding in a new Binding Update message. 463 4. Route Optimization Message Formats 465 Route Optimization defines four message types used for management 466 of binding cache entries. Each of these messages begins with a 467 one-octet field indicating the type of the message. 469 The following Type codes are defined in this document: 471 16 = Binding Warning message 472 17 = Binding Request message 473 18 = Binding Update message 474 19 = Binding Acknowledge message 476 Route Optimization also requires one minor change to existing 477 Mobile IP messages: a new flag bit must be added to the Registration 478 Request message, replacing a previously unused, reserved bit in the 479 message. 481 This section describes each of the new Route Optimization messages 482 and the change to Registration Request message. 484 4.1. Binding Warning Message 486 A Binding Warning message is used to advise a mobile node's home 487 agent that another node appears to have either no binding cache entry 488 or an out-of-date binding cache entry for some mobile node. When any 489 node receives a datagram tunneled to itself, if it is not the current 490 foreign agent for the destination mobile node, it MAY send a Binding 491 Warning message to the mobile node's home agent. 493 0 1 2 3 494 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 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Type | Reserved | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Mobile Node Home Address | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | Target Node Address | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 Type 505 16 507 Reserved 509 Sent as 0; ignored on reception. 511 Mobile Node Home Address 513 The home address of the mobile node to which the Binding 514 Warning message refers. 516 Target Node Address 518 The address of the node tunneling the datagram that caused the 519 Binding Warning message. This node should be the target of the 520 Binding Update message sent by the home agent. 522 4.2. Binding Request Message 524 A Binding Request message is used by a node to request a mobile 525 node's current mobility binding from the mobile node's home agent. 527 0 1 2 3 528 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 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Type | Reserved | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | Mobile Node Home Address | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | | 535 + Identification + 536 | | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 Type 541 17 543 Reserved 545 Sent as 0; ignored on reception. 547 Mobile Node Home Address 549 The home address of the mobile node to which the Binding 550 Request refers. 552 Identification 554 A 64-bit sequence number, assigned by the node sending the 555 Binding Request message, used to assist in matching requests 556 with replies, and in protecting against replay attacks. 558 4.3. Binding Update Message 560 The Binding Update message is used to notify another node of a mobile 561 node's current mobility binding. It MAY be sent by the mobile 562 node's home agent in response to a Binding Request message or a 563 Binding Warning message. It MAY also be sent by a mobile node, or 564 by the foreign agent with which the mobile node is registering, when 565 notifying the mobile node's previous foreign agent that the mobile 566 node has moved. 568 0 1 2 3 569 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 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Type |A|I|M|G| Rsvd | Lifetime | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Mobile Node Home Address | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | Care-of Address | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | | 578 + Identification + 579 | | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | Extensions ... 582 +-+-+-+-+-+-+-+- 584 Type 586 18 588 Acknowledge (A) 590 The Acknowledge (A) bit is set by the node sending the Binding 591 Update message to request a Binding Acknowledge message be 592 returned acknowledging its receipt. 594 Identification Present (I) 596 The Identification Present (I) bit is set by the node sending 597 the Binding Update message to indicate that the Identification 598 field is present in the message. 600 Minimal Encapsulation (M) 602 If the Minimal Encapsulation (M) bit is set, datagrams may be 603 tunneled to the mobile node using the minimal encapsulation 604 protocol used in the base Mobile IP protocol. 606 GRE Encapsulation (G) 608 If the GRE Encapsulation (G) bit is set, datagrams may be 609 tunneled to the mobile node using the GRE encapsulation 610 protocol [5]. 612 Reserved (Rsvd) 614 Sent as 0; ignored on reception. 616 Lifetime 618 The number of seconds remaining before the binding cache entry 619 must be considered expired. A value of all ones indicates 620 infinity. A value of zero indicates that no binding cache 621 entry for the mobile node should be created and that any 622 existing binding cache entry (and visitor list entry, in the 623 case of a mobile node's previous foreign agent) for the mobile 624 node should be deleted. The lifetime is typically equal to the 625 remaining lifetime of the mobile node's registration. 627 Mobile Node Home Address 629 The home address of the mobile node to which the Binding Update 630 message refers. 632 Care-of Address 634 The current care-of address of the mobile node. When set equal 635 to the home address of the mobile node, the Binding Update 636 message instead indicates that no binding cache entry for the 637 mobile node should be created, and any existing binding cache 638 entry (and visitor list entry, in the case of a mobile node's 639 previous foreign agent) for the mobile node should be deleted. 641 Identification 643 If present, a 64-bit number, assigned by the node sending the 644 Binding Request message, used to assist in matching requests 645 with replies, and in protecting against replay attacks. 647 The Route Optimization Authentication extension (Section 5.2) is 648 required. 650 4.4. Binding Acknowledge Message 652 A Binding Acknowledge message is used to acknowledge receipt of a 653 Binding Update message. It SHOULD be sent by a node receiving the 654 Binding Update message if the Acknowledge (A) bit is set in the 655 Binding Update message. 657 0 1 2 3 658 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 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 | Type |N| Reserved | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | Mobile Node Home Address | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | | 665 + Identification + 666 | | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 Type 671 19 673 Negative Acknowledge (N) 675 If the Negative Acknowledge (N) bit is set, this 676 acknowledgement is negative. For instance, if the 677 binding update was not accepted, but the incoming datagram has 678 the Acknowledge flag set, then the Negative Acknowledge (N) bit 679 SHOULD be set in this Binding Acknowledge message. 681 DISCUSSION: Alternatively, we could replace this bit with 682 a status code, as in the Registration Reply message. The 683 mobile node could log the error, but currently has no 684 real way to recover from it, so perhaps the exact reason 685 for the error isn't that useful. 687 Reserved 689 Sent as 0; ignored on reception. 691 Mobile Node Home Address 693 Copied from the Binding Update message being acknowledged. 695 Identification 697 Copied from the Binding Update message being acknowledged, if 698 present there. 700 4.5. Registration Request Message 702 One bit is added to the flag bits in the Registration Request message 703 to indicate that the mobile node would like its home agent to keep 704 its mobility binding "private". Normally, the home agent sends 705 Binding Update messages to correspondent nodes as needed to allow 706 them to cache the mobile node's binding. If the mobile node sets the 707 Private (P) bit in the Registration Request message, the home agent 708 MUST not send the mobile node's binding in Binding Update messages. 709 Instead, each Binding Update message should give the mobile node's 710 care-of address equal to its home address, and should give a Lifetime 711 value of 0. 713 Thus, the Registration Request message under Route Optimization 714 begins as follows: 716 0 1 2 3 717 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 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | Type |S|B|D|M|G|P|rvd| Lifetime | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | (unchanged...) 722 +-+-+- 724 Private (P) 726 The Private (P) bit is set by the node sending the Binding 727 Update message to indicate that the home agent should keep its 728 mobility binding private. In any Binding Update message sent 729 by the mobile node's home agent, the care-of address should be 730 set equal to the mobile node's home address, and the Lifetime 731 should be set equal to 0. 733 5. Route Optimization Extension Formats 735 Route Optimization defines the following Mobile IP message 736 extensions: 738 96 = Previous Foreign Agent Notification Extension 739 97 = Route Optimization Authentication Extension 740 98 = Registration Key Request Extension 741 99 = Home-Mobile Registration Key Reply Extension 742 100 = Home-Foreign Registration Key Reply Extension 743 101 = Diffie-Hellman Registration Key Request Extension 744 102 = Diffie-Hellman Registration Key Reply Extension 745 103 = Foreign Agent Public Key Digest Advertisement Extension 746 104 = Registration Key Request Public Key Digest Extension 747 105 = Foreign Agent Public Key Extension 748 106 = Mobile Node Public Key Extension 749 107 = Foreign-Mobile Registration Key Reply Extension 751 Route Optimization also requires one minor change to existing 752 Mobile IP message extensions: a new flag bit must be added to the 753 Mobile Service extension, replacing a previously unused, reserved bit 754 in the extension. 756 This section describes each of the new Route Optimization message 757 extensions and the change to Mobile Service extension. 759 5.1. Previous Foreign Agent Notification Extension 761 The Previous Foreign Agent Notification extension may be included 762 in a Registration Request message sent to a foreign agent. It 763 requests the new foreign agent to send a Binding Update message to 764 the mobile node's previous foreign agent on behalf of the mobile 765 node, to notify it that the mobile node has moved. The previous 766 foreign agent deletes the mobile node's visitor list entry and, if a 767 new care-of address is included in the Binding Update message, also 768 creates a binding cache entry for the mobile node pointing to its new 769 care-of address. The Previous Foreign Agent Notification extension 770 contains only those values not otherwise already contained in the 771 Registration Request message that are needed for the new foreign 772 agent to construct the Binding Update message. 774 0 1 2 3 775 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 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | Type | Length | Cache Lifetime | 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | Previous Foreign Agent Address | 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 | New Care-of Address Address | 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 | Authenticator ... 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 Type 788 96 790 Length 792 10 plus the length of the Authenticator 794 Cache Lifetime 796 The number of seconds remaining before the binding cache entry 797 created by the previous foreign agent must be considered 798 expired. A value of all ones indicates infinity. A value 799 of zero indicates that the previous foreign agent should not 800 create a binding cache entry for the mobile node once it has 801 deleted the mobile node's visitor list entry. The Cache 802 Lifetime value is copied into the Lifetime field of the Binding 803 Update message. 805 Previous Foreign Agent Address 807 The IP address of the mobile node's previous foreign agent 808 to which the new foreign agent should send a Binding Update 809 message on behalf of the mobile node. 811 New Care-of Address 813 The new care-of address for the new foreign agent to send in 814 the Binding Update message to the previous foreign agent. This 815 SHOULD be either the care-of address being registered in this 816 new registration (i.e., to cause IP datagrams from the previous 817 foreign agent to be tunneled to the new foreign agent) or the 818 mobile node's home address (i.e., to cause the previous foreign 819 agent to only delete its visitor list entry for the mobile 820 node). 822 Authenticator 824 The authenticator value to be used in the Route Optimization 825 Authentication extension in the Binding Update message sent by 826 the new foreign agent to the mobile node's previous foreign 827 agent. This authenticator is calculated only over the Binding 828 Update message body. 830 5.2. Route Optimization Authentication Extension 832 The Route Optimization Authentication extension is used to 833 authenticate certain Route Optimization management messages. 835 0 1 2 3 836 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 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 | Type | Length | Authenticator ... 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 Type 843 97 845 Length 847 The length of the Authenticator 849 Authenticator 851 (variable length) A value computed from a stream of bytes 852 including the shared secret, the UDP payload (that is, the 853 Route Optimization management message), all prior extensions 854 in their entirety, and the type and length of this extension, 855 but not including the Authenticator field itself nor the UDP 856 header. 858 5.3. Registration Key Request Extension 860 The Registration Key Request extension may be used in Registration 861 Request messages to request a registration key from the mobile 862 node's home agent. The extension is included in the Registration 863 Request message by the mobile node. It is authenticated along 864 with the rest of the Registration Request message, and thus no 865 additional authenticator is included in the extension. In response 866 to a Registration Key Request extension, the home agent MAY include 867 a Home-Mobile Registration Key Reply extension and a Home-Foreign 868 Registration Key Reply extension in its Registration Reply message, 869 containing encrypted copies of the (same) new registration key for 870 the mobile node and the foreign agent, respectively. 872 0 1 873 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | Type | Length | 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 Type 880 98 882 Length 884 0 886 The mobility security association assumed to exist between the home 887 agent and the mobile node will be used to encrypt the key sent in 888 the Home-Mobile Registration Key Reply extension, unless a Key 889 Identification extension is also included with the Registration 890 Request message. 892 The home agent must also share a mobility security association with 893 the foreign agent in order to return the requested registration key, 894 and the home agent will use this security association to encrypt the 895 key sent in the Home-Foreign Registration Key Reply extension. 897 5.4. Home-Mobile Registration Key Reply Extension 899 The Home-Mobile Registration Key Reply extension may be used in 900 Registration Reply messages to send a registration key from the 901 mobile node's home agent to the mobile node. When used, the home 902 agent MUST also include a Home-Foreign Registration Key Reply 903 extension in the Registration Reply message, giving a copy of the 904 same key to the mobile node's new foreign agent. The Home-Mobile 905 Registration Key Reply extension is authenticated along with the 906 rest of the Registration Reply message, and thus no additional 907 authenticator is included in the extension. 909 0 1 2 3 910 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 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 | Type | Length | Mobile Node Encrypted Key ... 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 Type 917 99 919 Length 921 The length of the Mobile Node Encrypted Key 923 Mobile Node Encrypted Key 925 (variable length) The registration key, chosen by the home 926 agent, encrypted under the mobility security association 927 between the home agent and the mobile node. The same key must 928 be sent, encrypted for the foreign agent in a Foreign Agent 929 Registration Key extension in this Registration Reply message. 931 5.5. Home-Foreign Registration Key Reply Extension 933 The Home-Foreign Registration Key Reply extension may be used 934 in Registration Reply messages to send a registration key from 935 the mobile node's home agent to the mobile node's new foreign 936 agent. When used, the home agent MUST also include a Home-Mobile 937 Registration Key Reply extension in the Registration Reply message, 938 giving a copy of the same key to the mobile node. The Home-Foreign 939 Registration Key Reply extension is authenticated by including an 940 authenticator in the extension, computed based on the mobility 941 security association shared between the home agent and the foreign 942 agent. In order for this extension to be used, the home agent MUST 943 share a mobility security association with the foreign agent. 945 0 1 2 3 946 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 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 | Type | Length | Foreign Agent Encrypted Key ... 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 | Authenticator ... 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 Type 955 100 957 Length 959 The length of the Foreign Agent Encrypted Key plus the length 960 of the Authenticator 962 Foreign Agent Encrypted Key 964 (variable length) The registration key, chosen by the home 965 agent, encrypted under the mobility security association 966 between the home agent and the foreign agent. The same key 967 must be sent, encrypted for the mobile node in a Mobile Node 968 Registration Key extension in this Registration Reply message. 970 Authenticator 972 (variable length) A value computed from a stream of bytes 973 including the shared secret and the fields in this extension 974 other than the Authenticator field itself. 976 5.6. Diffie-Hellman Registration Key Request Extension 978 The Diffie-Hellman Registration Key Request extension may be included 979 in a Registration Request message sent to a foreign agent. It begins 980 the Diffie-Hellman key exchange algorithm [2] between the mobile node 981 and its new foreign agent, as described in Section 7.2. The foreign 982 agent SHOULD then include a Diffie-Hellman Registration Key Reply 983 extension in its Registration Reply message sent to the mobile node 984 in order to complete the key exchange. 986 0 1 2 3 987 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 988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 | Type | Length | 990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 | Prime ... 992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 993 | Generator ... 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 | Computed Value ... 996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 998 Type 1000 101 1002 Length 1004 3 times the length of each of Prime, Generator, and 1005 Computed Value. The values Prime, Generator, and 1006 Computed Value must all be the same length, which must be a 1007 multiple of 8 bits. 1009 Prime 1011 One of the two public numbers involved in the Diffie-Hellman 1012 key exchange algorithm. The value Prime should be a large 1013 prime number. 1015 Generator 1017 One of the two public numbers involved in the Diffie-Hellman 1018 key exchange algorithm. If p is the value of the Prime used 1019 for this Diffie-Hellman exchange, the value Generator should be 1020 less than p, and should be a primitive root of p. 1022 Computed Value 1024 The public computed value from the mobile node for this 1025 Diffie-Hellman exchange. The mobile node chooses a large 1026 random number, x. If g is the value of the Generator and p is 1027 the value of the Prime, the Computed Value in the extension is 1028 (g**x) mod p. 1030 5.7. Diffie-Hellman Registration Key Reply Extension 1032 The Diffie-Hellman Registration Key Reply extension SHOULD be 1033 included in a Registration Reply message sent by a foreign agent to a 1034 mobile node that included a Diffie-Hellman Registration Key Request 1035 extension in its Registration Request message to the foreign agent. 1037 0 1 2 3 1038 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 1039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1040 | Type | Length | 1041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 | Computed Value ... 1043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1045 Type 1047 101 1049 Length 1051 The length of the Computed Value. The length of the Computed 1052 Value must be a multiple of 8 bits. 1054 Computed Value 1056 The foreign agent chooses a large random number, y. If g is 1057 the value of the Generator and p is the value of the Prime, the 1058 Computed Value in the extension is (g**y) mod p. The values 1059 of the Generator and Prime are taken from the Diffie-Hellman 1060 Registration Key Request extension from the mobile node's 1061 Registration Request message. 1063 5.8. Mobile Service Extension 1065 One bit is added to the flag bits in the Mobile Service extension 1066 (forming an Agent Advertisement message), when sent by a foreign 1067 agent, to indicate that the foreign agent supports registration 1068 key establishment using the Diffie-Hellman key exchange algorithm. 1069 When this bit is set in the Agent Advertisement, the mobile node 1070 MAY request a registration key be established by including a 1071 Diffie-Hellman Registration Key Request extension in its Registration 1072 Request message. The foreign agent replies with the Diffie-Hellman 1073 Registration Key Reply extension in its Registration Reply to the 1074 mobile node. 1076 Thus, the Mobile Service extension under Route Optimization begins as 1077 follows: 1079 0 1 2 3 1080 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 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1082 | Type | Length | Sequence Number | 1083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1084 | Lifetime |R|B|H|F|M|G|D| reserved | 1085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 | (unchanged...) 1087 +-+-+- 1089 Diffie-Hellman (D) 1091 The Diffie-Hellman (D) bit is set by the foreign agent 1092 sending the Agent Advertisement message to indicate that it 1093 supports the registration key establishment protocol using the 1094 Diffie-Hellman Registration Key Request and Diffie-Hellman 1095 Registration Key Reply extensions. 1097 6. Mobility Security Association Management 1099 One of the most difficult aspects of Route Optimization for Mobile IP 1100 in the Internet today is that of providing authentication for all 1101 messages that affect the routing of datagrams to a mobile node. 1102 In the base Mobile IP protocol, all routing of datagrams to the 1103 mobile node while away from its home network is controlled by the 1104 home agent, since only the home agent is aware of the mobile node's 1105 mobility binding and only the home agent tunnels datagrams to 1106 the mobile node. Authentication is currently achieved based on a 1107 manually established mobility security association between the home 1108 agent and the mobile node. Since the home agent and the mobile 1109 node are both owned by the same organization (both are assigned IP 1110 addresses within the same IP subnet), this manual configuration is 1111 manageable, and (for example) can be performed while the mobile node 1112 is at home. 1114 However, with Route Optimization, authentication is more difficult 1115 to manage, since a Binding Update may in general need to be sent to 1116 any node in the Internet. Since no general authentication or key 1117 distribution protocol is available in the Internet today, the Route 1118 Optimization procedures defined in this document make use of the 1119 same type of manually configured mobility security associations used 1120 in the base Mobile IP protocol. For use with Route Optimization, 1121 a mobility security association held by a correspondent node or a 1122 foreign agent must in general include the same parameters as required 1123 by the base Mobile IP protocol specification [6]. 1125 For a correspondent node to be able to create a binding cache entry 1126 for a mobile node, the correspondent node and the mobile node's 1127 home agent MUST have established a mobility security association. 1128 This mobility security association, though, may be used in creating 1129 and updating binding cache entries at this correspondent node 1130 for all mobile nodes served by this home agent. This places the 1131 correspondent node in a fairly natural relationship with respect 1132 to the mobile nodes served by this home agent. For example, these 1133 mobile nodes may represent different people affiliated with the 1134 organization owning the home agent and these mobile nodes, with which 1135 the user of this correspondent node often collaborates. In this 1136 case, the effort of establishing the necessary mobility security 1137 association with this home agent may be justified. It is similarly 1138 possible for a home agent to have a manually established mobility 1139 security association with the foreign agents often used by its mobile 1140 nodes, or for a particular mobile node to have a manually established 1141 mobility security association with the foreign agents serving the 1142 foreign networks that it often visits. 1144 In general, if the movement and communication patterns of a mobile 1145 node or the group of mobile nodes served by the same home agent are 1146 sufficient to justify establishing a mobility security association 1147 with the mobile node's home agent, users or network administrators 1148 are likely to do so. Without establishing a mobility security 1149 association, nodes will not currently be able to use the Route 1150 Optimization extensions but can use the base Mobile IP protocol. 1152 7. Methods of Establishing a Registration Key 1154 This document suggests four different methods that a mobile node 1155 could use for dynamically establishing a registration key with a 1156 foreign agent when it registers with that foreign agent. 1158 7.1. Using the Home Agent as a Key Distribution Center 1160 One method of establishing a registration key is for the mobile node 1161 to request its home agent to generate one during registration, and 1162 for the home agent to send a copy of this key to both the mobile node 1163 and its new foreign agent. The home agent in this case acts as a 1164 "key distribution center" (KDC) for the mobile node and the foreign 1165 agent. The mobile node requests this by including a Registration 1166 Key Request extension in its Registration Request message. The home 1167 agent sends the generated key to the mobile node and to its foreign 1168 agent by including a Home-Mobile Registration Key Reply extension 1169 and a Home-Foreign Registration Key Reply extension its Registration 1170 Reply message. The Home-Mobile Registration Key Reply extension 1171 contains a copy of the chosen key encrypted under a key and algorithm 1172 shared between the home agent and the mobile node, and a Home-Foreign 1173 Registration Key Reply extension contains a copy of the same key 1174 encrypted under a key and algorithm shared between the home agent and 1175 the foreign agent. 1177 In order for the registration key to be established using this 1178 method, the foreign agent must have a mobility security association 1179 with the home agent. For example, if mobile nodes from some home 1180 network often visit this foreign agent, it may in general be worth 1181 the effort of creating such a mobility security association between 1182 this foreign agent and the home agent serving that home network. If 1183 no mobility security association exists, a mobile node may instead be 1184 able to establish a registration key with its home agent using the 1185 alternative method described in the next section. 1187 7.2. Using Diffie-Hellman with the Foreign Agent 1189 An alternate method defined in this document for establishing a 1190 registration key is for the mobile node and its foreign agent to 1191 execute the Diffie-Hellman key exchange algorithm [2] as part of the 1192 mobile node's registration. The Diffie-Hellman algorithm is a public 1193 key cryptosystem that allows two parties to establish a shared secret 1194 key, such that the shared secret key cannot be determined by other 1195 parties overhearing the messages exchanged during the algorithm. It 1196 is used, for example, in other protocols that require a key exchange, 1197 such as in the Cellular Digital Packet Data (CDPD) system [1]. 1199 Briefly, the Diffie-Hellman algorithm involves the use of two large 1200 public numbers, a Prime number (p) and a Generator (g). The Prime 1201 number and the Generator must be known by both parties involved in 1202 the algorithm, but need not be kept secret; these values may be 1203 different for each execution of the algorithm and are not used once 1204 the algorithm completes. Each party chooses a private random number, 1205 produces a Computed Value based on this random number and the Prime 1206 and the Generator, and sends the Computed Value in a message to the 1207 other party. Each party then computes the (same) shared secret key 1208 using its own private random number, the Computed Value received from 1209 the other party, and the Prime and Generator values. 1211 To use this algorithm during registration with a foreign agent, 1212 the mobile node includes a Diffie-Hellman Registration Key Request 1213 extension in its Registration Request message, containing its values 1214 for the Prime and Generator, along with the Computed Value from its 1215 own private random number. The foreign agent then chooses its own 1216 private random number and includes a Diffie-Hellman Registration Key 1217 Reply extension in its Registration Reply message to the mobile node; 1218 the extension includes the foreign agent's own Computed Value based 1219 on its chosen random number and the supplied Prime and Generator 1220 values from the mobile node. The mobile node and foreign agent each 1221 independently form the (same) shared secret key from their own chosen 1222 random number, the Computed Value supplied by the other party, and 1223 the Prime and Generator values. 1225 The Diffie-Hellman algorithm allows the mobile node and its foreign 1226 agent to establish a registration key without any pre-existing 1227 mobility security associations, but the Diffie-Hellman algorithm 1228 itself is covered by a patent in the United States. The method of 1229 establishing a registration key using Diffie-Hellman thus may not be 1230 usable by those who have not licensed the patent. An implementation 1231 of the Diffie-Hellman key exchange algorithm is available, though, in 1232 the free RSAREF toolkit from RSA Laboratories [7]. 1234 Also, establishing a registration key using Diffie-Hellman is 1235 computationally more expensive than the method described in 1236 Section 7.1. The use of Diffie-Hellman described here, though, is 1237 designed to allow the Diffie-Hellman computations to be overlapped 1238 with other activities. The mobile node may choose (or be manually 1239 configured with) the Prime and Generator values at any time, or 1240 may use the same two values for a number of registrations. The 1241 mobile node may also choose its private random number and compute 1242 its Computed Value at any time. For example, after completing 1243 one registration, the mobile node may choose the private random 1244 number for its next registration and begin the computation of 1245 its new Computed Value based on this random number, such that it 1246 has completed this computation before it is needed in its next 1247 registration; in its simplest form, the mobile node may use the 1248 same private random number and Computed Value for any number of 1249 registrations. The foreign agent may choose its private random 1250 number and begin computation of its Computed Value based on this 1251 number as soon as it receives the mobile node's Registration Request 1252 message, and need only complete this computation before it sends 1253 the matching Registration Reply message for the mobile node's 1254 registration. 1256 The Agent Advertisement message (Mobile Service extension) is revised 1257 under Route Optimization to include a bit to indicate that the 1258 foreign agent sending the advertisement supports this method of 1259 registration key establishment using the Diffie-Hellman algorithm. 1260 If this bit is not set in the Agent Advertisement from the foreign 1261 agent, the mobile node MUST NOT send a Diffie-Hellman Registration 1262 Key Request extension to the foreign agent in its Registration 1263 Request message. 1265 DISCUSSION: This could be extended to support other similar 1266 key exchange algorithms, either by adding a new Request 1267 and Reply extension for each, or by adding a field in the 1268 extensions to indicate which algorithm is to be used. 1269 Diffie-Hellman seems the only obvious choice, though, 1270 currently. 1272 7.3. Using a Mobile Node Public Key 1274 The mobile node includes its public key (such as RSA) in its 1275 Registration Request to the foreign agent, using a Mobile Node Public 1276 Key extension. The foreign agent chooses the new registration key 1277 and returns a copy of it encrypted with the mobile node's public key, 1278 using a Foreign-Mobile Registration Key Reply extension. 1280 7.4. Using a Foreign Agent Public Key 1282 The foreign agent includes an MD5 digest of its public key (such 1283 as RSA) in its Agent Advertisement messages, using a Foreign 1284 Agent Public Key Digest Advertisement extension. The mobile node 1285 includes a copy of this digest in its Registration Request, using 1286 a Registration Key Request Public Key Digest extension, and the 1287 foreign agent adds its full public key to the Registration Request 1288 when relaying it to the home agent, using a Foreign Agent Public Key 1289 extension. The home agent then chooses the new registration key and 1290 returns a separate encrypted copy of the key to the foreign agent 1291 (using this public key) and to the mobile node (using its mobility 1292 security association with the mobile node) in its Registration 1293 Reply message. The copy sent to the foreign agent is included in a 1294 Home-Foreign Registration Key Reply extension, and the copy sent to 1295 the mobile node is included in a Home-Mobile Registration Key Reply 1296 extension. 1298 8. Binding Cache Considerations 1300 Any node may maintain a binding cache in order to optimize its own 1301 communication with mobile nodes. When sending an IP datagram, if the 1302 sending node has a binding cache entry for the destination node, it 1303 MAY tunnel the datagram to the mobile node's care-of address using 1304 the encapsulation techniques described for home agents in the base 1305 Mobile IP protocol specification [6]. Any optional encapsulation 1306 methods supported are indicated by flag bits in the Binding Update 1307 message. 1309 When a mobile node's home agent intercepts a datagram on the home 1310 network and tunnels it to the mobile node, the originating node 1311 generally has no binding cache entry for the destination mobile node. 1312 In such cases, the home agent MAY send a Binding Update message to 1313 the originator. 1315 Similarly, when a node other than the foreign agent currently 1316 serving a mobile node receives a datagram for a mobile node, and 1317 this datagram has been tunneled to that node, the node tunneling the 1318 datagram generally has an out-of-date binding for the mobile node in 1319 its binding cache. In such cases, the node receiving the tunneled 1320 datagram MAY send a Binding Warning message to the mobile node's home 1321 agent, advising it to send a Binding Update message to the tunneling 1322 node. 1324 8.1. Cache Management 1326 A node maintaining a binding cache may use any reasonable strategy 1327 for managing the space within the cache. When a new entry needs to 1328 be added to the binding cache, the node MAY choose to drop any entry 1329 already in the cache, if needed, to make space for the new entry. 1330 For example, a "least-recently used" (LRU) strategy for cache entry 1331 replacement is likely to work well. 1333 Each binding in the binding cache also has an associated lifetime, 1334 specified by in the Binding Update message in which the node obtained 1335 the binding. After the expiration of this time period, the binding 1336 MUST be deleted from the cache. 1338 8.2. Receiving Binding Update Messages 1340 When a node receives a Binding Update message, it MUST verify 1341 the authentication in the message, using the mobility security 1342 association it shares with the mobile node's home agent. The 1343 authentication data is found in the Route Optimization Authentication 1344 extension (Section 5.2). If the authentication succeeds, then a 1345 binding cache entry SHOULD be updated for use in future transmissions 1346 of data to the mobile node. Otherwise, an authentication exception 1347 SHOULD be raised. 1349 8.3. Using Special Tunnels 1351 Whenever any node receives a tunneled datagram for for which it has 1352 no visitor list entry for the datagram's destination, the node may 1353 deduce that the tunneling node has an out-of-date binding cache entry 1354 for the destination mobile node. If the node receiving the tunneled 1355 datagram has a binding cache entry for the destination, it SHOULD 1356 re-tunnel the datagram to the care-of address indicated in this 1357 binding cache entry. 1359 However, if the node receiving the tunneled datagram has no binding 1360 cache entry for the destination, it cannot re-tunnel the node to 1361 its destination. Instead, the node SHOULD forward the datagram 1362 to the destination mobile node's home agent, using a special form 1363 of tunneling called a "special tunnel". To tunnel the datagram 1364 using a special tunnel, the tunneled datagram's destination address 1365 is set equal to the destination address in the tunneled datagram. 1366 Thus, both the "inner" and "outer" destination addresses are set to 1367 the home address of the mobile node. The tunneled datagram will 1368 thus be routed to the mobile node's home network, where it will be 1369 intercepted by the mobile node's home agent in the same way as other 1370 datagrams addressed to the mobile node. 1372 The home agent SHOULD then tunnel the datagram to the current care-of 1373 address for the mobile node. However, the home agent MUST NOT tunnel 1374 the datagram to the current care-of address if the special tunnel of 1375 the datagram originated at that care-of address, as indicated by the 1376 "outer" source address of the special tunnel datagram. The use of 1377 the special tunnel format allows the home agent to identify the node 1378 that tunneled the datagram to it (as well as the original sender of 1379 the datagram). If the home agent believes that the current care-of 1380 address for the mobile node is the same as the source of the special 1381 tunnel, then the home agent SHOULD discard the datagram; in this 1382 case, the foreign agent serving the mobile node appears to have lost 1383 its entry for the mobile node in its visitor list, for example, if 1384 the foreign agent has crashed and rebooted. 1386 After tunneling the datagram to the current care-of address for the 1387 mobile node, the home agent MAY notify the source of the special 1388 tunnel of the mobile node's current binding, by sending it a Binding 1389 Update message. 1391 9. Home Agent Considerations 1393 The home agent will be the frequent source of Binding Update messages 1394 sent to correspondent nodes that are communicating with its mobile 1395 nodes. Any correspondent node that has no binding cache entry for a 1396 mobile node, will send normal, untunneled datagrams through the home 1397 agent by the normal routing in the Internet. When the home agent 1398 first receives a datagram for a mobile node, it SHOULD also send a 1399 Binding Update message to the originator of the datagram in hopes 1400 that the originator will be able to create a binding cache entry for 1401 that mobile node. Then, future datagrams sent by this node to the 1402 mobile node should not need the involvement of the home agent. 1404 9.1. Rate Limiting 1406 A home agent MUST provide some mechanism to limit the rate at which 1407 it sends Binding Update messages to to the same node about any given 1408 mobility binding. This rate limiting is especially important because 1409 it is expected that, within the short term, many Internet nodes will 1410 not support maintenance of a binding cache. In this case, continual 1411 transmissions of Binding Update messages to such a correspondent 1412 node will only add unnecessary overhead to at the home agent and 1413 correspondent node, and along the Internet path between these nodes. 1415 9.2. Receiving Binding Warning Messages 1417 A home agent will receive a Binding Warning message if a node 1418 maintaining a binding cache entry for one of the home agent's mobile 1419 nodes uses the entry after it becomes out-of-date. When a home agent 1420 receives a Binding Warning message, it SHOULD send a Binding Update 1421 message to the Target Node Address identified in the Binding Warning, 1422 giving it the current binding for the mobile node identified in the 1423 Mobile Node Home Address field of the Binding Warning. 1425 If using nonces for replay protection, the use of the Identification 1426 field in the Binding Update message is different in this case, in 1427 order to still allow replay protection even though the Binding Update 1428 is not being sent in reply to a request directly from the target 1429 node. In this case, the high-order 32 bits of the Identification 1430 field MUST be set by the home agent to the value of the nonce that 1431 will be used by the home agent in the next Binding Update message 1432 sent to this node. The low-order 32 bits of the Identification field 1433 MUST be set to the value of the nonce being used for this message. 1434 Thus, on each Binding Update message, the home agent communicates to 1435 the target node, the value of the nonce that will be used next time, 1436 and if no Binding Updates are lost in the network, the home agent and 1437 the target node can remain synchronized with respect to the nonces 1438 being used. If, however, the target node receives a Binding Update 1439 with what it believes to be an incorrect nonce, it may resynchronize 1440 with the home agent by requesting the mobile node's binding using a 1441 Binding Request message. 1443 9.3. Receiving Binding Request Messages 1445 When the home agent receives a Binding Request message, it consults 1446 its home list and determines the correct binding information to be 1447 sent to the requesting node. Before satisfying the request, the 1448 home agent MUST check whether or not the mobile node has allowed 1449 the information to be disseminated. If the mobile node specified 1450 the Private (P) bit in its Registration Request message, then the 1451 home agent MUST not satisfy any Binding Requests. In this case, 1452 the home agent SHOULD return a Binding Update in which both the 1453 Care-of Address is set equal to the mobile node's home address and 1454 the Lifetime is set to zero. Such a Binding Update message indicates 1455 that the binding cache entry for the specified mobile node should be 1456 deleted. 1458 9.4. Receiving Registration Key Requests 1460 When the home agent receives a Registration Request message, a 1461 Registration Key Request extension (Section 5.3) may be present in 1462 the message, requesting the home agent to provide a registration 1463 key to the mobile node and its foreign agent, as described in 1464 Section 3.2. In that event, the home agent employs a good algorithm 1465 for producing random keys [4] and encrypts the result separately for 1466 use by the foreign agent and by the mobile node. The chosen key is 1467 encrypted under the mobility security association shared between the 1468 home agent and the mobile node, and the encrypted key is placed in 1469 a Home-Mobile Registration Key Reply extension (Section 5.4) in the 1470 Registration Reply message. The same key also is encrypted under 1471 the mobility security association shared between the home agent and 1472 the foreign agent, and the encrypted key is placed in a Home-Foreign 1473 Registration Key Reply extension (Section 5.5) in the Registration 1474 Reply message. 1476 If the home agent receives a Registration Key Request extension in 1477 a Registration Request message, but it does not have an established 1478 mobility security association with the foreign agent with which 1479 the mobile node is registering, the home agent MUST reject the 1480 registration attempt. In this case, the home agent returns a 1481 Registration Reply message indicating that the foreign agent failed 1482 authentication. 1484 9.5. Receiving Special Tunnels 1486 The home agent may also receive datagrams tunneled to the mobile 1487 node using a special tunnel (Section 8.3), which it has intercepted 1488 for the mobile node in the same way as any datagram destined to the 1489 mobile node while the mobile node is away from home. The home agent 1490 MUST examine the tunnel source address (the "outer" address of the 1491 tunneled datagram). If the tunnel source address differs from the 1492 care-of address shown in the home list entry for the mobile node, 1493 the home agent SHOULD decapsulate the inner datagram from the tunnel 1494 and re-tunnel it to the mobile node's care-of address. However, if 1495 the tunnel source address is the same as the mobile node's care-of 1496 address, the home agent MUST NOT tunnel the datagram back to that 1497 same node; the home agent SHOULD instead discard the datagram. 1499 In either case, the home agent SHOULD also send a Binding Update 1500 message to the sender of the original datagram (the "inner" source 1501 address of the tunneled datagram), if it shares a mobility security 1502 association with this node. The sending of this Binding Update 1503 message, though, is subject to the rate limiting restriction 1504 described in Section 9.1. 1506 10. Foreign Agent Considerations 1508 In addition to managing the resources needed to handle registrations 1509 in the base Mobile IP protocol, a foreign agent participating in 1510 Route Optimization assumes two additional responsibilities. It 1511 SHOULD maintain a binding cache for forwarding datagrams to mobile 1512 nodes once they have moved to new care-of addresses, and it SHOULD 1513 support the use of a Binding Update message for notifying a mobile 1514 node's previous foreign agent that it has moved. 1516 10.1. Establishing a Registration Key 1518 As part of the registration procedure, a mobile node and its 1519 new foreign agent can establish a registration key (Sections 7.1 1520 and 7.2). Within this document, the registration key is used only 1521 for authentication of a single Binding Update message. Other uses 1522 for the registration key are possible, such as the use of this key to 1523 provide privacy along the wireless link connecting between the mobile 1524 node and its foreign agent; such additional uses of the registration 1525 key are outside the scope of this discussion. 1527 This document specifies two alternative methods for establishing 1528 a registration key as part of a mobile node's registration with a 1529 foreign agent. 1531 The foreign agent may receive a Registration Key Request extension 1532 in the mobile node's Registration Request message (Section 7.1). 1533 The foreign agent need not process the Registration Key Request 1534 extension. When the Registration Reply is received by the 1535 foreign agent from the home agent, it MAY contain a Home-Foreign 1536 Registration Key Reply extension and a Home-Mobile Registration 1537 Key Reply extension. In this case, the foreign agent removes the 1538 Home-Foreign Registration Key Reply extension, and forwards the 1539 rest of the Registration Reply message to the mobile node. The 1540 Home-Foreign Registration Key Reply extension is covered by its own 1541 authentication, not by the authentication covering the Registration 1542 Reply message itself, and thus removing the Home-Foreign Registration 1543 Key Reply extension does not interfere with the mobile node's ability 1544 to verify the authentication on the Registration Reply message. 1545 The foreign agent decrypts the supplied registration key using the 1546 mobility security association it shares with the home agent, and 1547 stores the key as part of the visitor list entry created for the 1548 mobile node for this registration. 1550 Alternatively, the foreign agent may receive a Diffie-Hellman 1551 Registration Key Request extension in the mobile node's Registration 1552 Request message (Section 7.2). The extension contains the Prime 1553 and Generator values, chosen by the mobile node, to be used for 1554 this execution of the Diffie-Hellman algorithm. The foreign agent 1555 chooses its own private random number and returns the Diffie-Hellman 1556 Computed Value when it sends the Registration Reply message sent to 1557 the mobile node. The foreign agent uses Prime and Generator values 1558 and the Computed Value from the mobile node that it received in the 1559 Diffie-Hellman Registration Key Request extension, together with its 1560 own chosen private random number, to form the registration key. The 1561 foreign agent stores this registration key as part of the visitor 1562 list entry created for the mobile node for this registration. 1564 Establishing the registration key in effect establishes a mobility 1565 security association between the mobile node and the foreign agent. 1566 After the mobile node moves to a new care-of address, this mobility 1567 security association is used for authenticating the Binding Update 1568 message from the mobile node notifying this foreign agent of its 1569 movement. 1571 10.2. Previous Foreign Agent Notification 1573 When a mobile node registers with a new foreign agent, the mobile 1574 node MAY request its new foreign agent to notify its previous foreign 1575 agent that it has moved. The mobile node includes a Previous Foreign 1576 Agent Notification extension in its Registration Request message to 1577 the foreign agent, requesting that the foreign agent send a Binding 1578 Update message to its previous foreign agent. As with all Binding 1579 Update messages, this Binding Update must be authenticated using the 1580 Route Optimization Authentication extension (Section 5.2). 1582 The foreign agent assembles the Binding Update message using 1583 the fields in the Registration Request message (including the 1584 Authenticator supplied in the Previous Foreign Agent Notification 1585 extension) and sends it to the previous foreign agent identified in 1586 the extension. The Acknowledge (A) bit MUST be set in this Binding 1587 Update message. 1589 When the previous foreign agent receives the Binding Update, it will 1590 authenticate the message using the mobility security association 1591 set up with the registration key established with the mobile node 1592 during its registration with this mobile node. If the message 1593 authentication is correct, the visitor list entry for this mobile 1594 node at the previous foreign agent will be deleted and a Binding 1595 Acknowledge message returned to the sender. In addition, if a new 1596 care-of address was included in the Binding Update message, the 1597 previous foreign agent will create a binding cache entry for the 1598 mobile node; the previous foreign agent can then tunnel datagrams to 1599 the mobile node's new care-of address using that binding cache, just 1600 as any node maintaining a binding cache. 1602 In particular, the previous foreign agent can tunnel the Binding 1603 Acknowledge message back to the new care-of address specified in 1604 the received binding. This creates an interesting problem for the 1605 new foreign agent when it receives the acknowledgment before the 1606 registration reply from the home agent. It is suggested that the new 1607 foreign agent deliver the acknowledgment to the mobile node anyway, 1608 even though the mobile node is technically unregistered. If there 1609 is concern that this provides a loophole for unauthorized traffic 1610 to the mobile node, the new foreign agent could limit the number of 1611 datagrams delivered to the unregistered mobile node to this single 1612 instance. Alternatively, a new extension to the Registration Reply 1613 message can be defined to carry along the acknowledgement from the 1614 previous foreign agent. This latter approach would have the benefit 1615 that fewer datagrams would be transmitted over bandwidth-constrained 1616 wireless media during registrations. 1618 The registration key established with this previous foreign agent is 1619 destroyed as a part of the processing of this Binding Update message. 1620 Since the previous foreign agent deletes the visitor list entry for 1621 the mobile node, it also deletes its record of the registration key. 1622 A registration key is thus useful only for the notification to the 1623 previous foreign agent after moving to a new care-of address. No 1624 subsequent use of this registration key is possible, and thus no 1625 reply protection is necessary for the Binding Update message used for 1626 this notification. 1628 10.3. Receiving Tunneled Datagrams 1630 When a foreign agent receives a datagram tunneled to itself, it 1631 examines its visitor list for an entry for the destination mobile 1632 node, as in the base Mobile IP protocol. If a visitor list entry is 1633 found, the foreign agent delivers the datagram to the mobile node. 1635 However, if no visitor list entry is found, the foreign agent 1636 examines its binding cache for a cache entry for the destination 1637 mobile node. If one is found, the foreign agent re-tunnels the new 1638 care-of address indicated in the binding cache entry. In this case, 1639 the foreign agent also may deduce that the sender of the datagram has 1640 an out-of-date binding cache entry for this mobile node, since it 1641 otherwise would have tunneled the datagram directly to the correct 1642 new care-of address itself. The foreign agent SHOULD then send a 1643 Binding Warning message to the mobile node's home agent, which it 1644 learned in the Binding Update message from which this binding cache 1645 entry was created. 1647 10.4. Rate Limiting 1649 A foreign agent MUST provide some mechanism to limit the rate at 1650 which it sends Binding Warning messages to to the same node about any 1651 given mobility binding. This rate limiting is especially important 1652 because it is expected that, within the short term, many Internet 1653 nodes will not support maintenance of a binding cache. In this 1654 case, continual transmissions of Binding Warning messages to such 1655 a correspondent node will only add unnecessary overhead to at the 1656 foreign agent and correspondent node, and along the Internet path 1657 between these nodes. 1659 10.5. Sending Special Tunnels 1661 If a foreign agent receives a tunneled datagram for a mobile node 1662 for which it has no visitor list entry or binding cache entry, the 1663 foreign agent MAY forward the datagram to the mobile node's home 1664 agent by sending it as a special tunnel (Section 3.2). The home 1665 agent will intercept the special tunnel datagram addressed to the 1666 mobile node in the same way as any datagram for the mobile node while 1667 it is away from home. 1669 11. Mobile Node Considerations 1671 11.1. Establishing a Registration Key 1673 When a mobile node sends a Registration Request message, it can also 1674 request a registration key to be established between itself and the 1675 new foreign agent. The key may be used later to authenticate the 1676 Binding Update sent to this foreign agent to notify it that the 1677 mobile node has moved to a new care-of address. 1679 The mobile node may include a Registration Key Request extension in 1680 its Registration Request message to request its home agent to act as 1681 a "key distribution center" (KDC) for establishing a registration key 1682 with its new foreign agent (Section 7.1). The home agent chooses a 1683 new key and returns encrypted copies of it for the foreign agent and 1684 the mobile node. The mobile node receives its copy of the new key in 1685 the Home-Mobile Registration Key Reply extension in the Registration 1686 Reply extension. The mobile node decrypts the key using the mobility 1687 security association it shares with its home agent, and stores the 1688 key for later use in notifying this foreign agent that it has moved 1689 to a new care-of address. 1691 Alternatively, the mobile node may include a Diffie-Hellman 1692 Registration Key Request extension in its Registration Request 1693 message to request its new foreign agent to participate in the 1694 Diffie-Hellman key exchange algorithm with it. The mobile node 1695 chooses a private random number and includes the Prime and Generator 1696 values to be used in this execution of the Diffie-Hellman algorithm, 1697 together with the Computed Value based on its chosen private random 1698 number, in the Diffie-Hellman Registration Request extension. The 1699 foreign agent chooses its own private random number, and returns the 1700 Computed Value based on this number in a Diffie-Hellman Registration 1701 Key Reply extension in the Registration Reply that it returns to the 1702 mobile node. The mobile node forms the registration key according to 1703 the Diffie-Hellman algorithm and stores it for later use in notifying 1704 this foreign agent that it has moved to a new care-of address. 1706 11.2. Notifying Previous Foreign Agents 1708 During registration with a new foreign agent, a mobile node may 1709 request its new foreign agent to notify its previous foreign agent 1710 that it has moved. The new foreign agent sends a Binding Update 1711 message to the previous foreign agent on behalf of the mobile node. 1713 To novity its previous foreign agent as part of the new registration, 1714 the mobile node includes a Previous Foreign Agent Notification 1715 extension (Section 5.1) in its Registration Request message. The 1716 extension contains only those values needed by the new foreign 1717 agent to construct the Binding Update message that are not already 1718 included in the Registration Request message. In particular, the 1719 new foreign agent only sends the Binding Update message on behalf of 1720 the mobile node. The mobile node computes the correct Authenticator 1721 value for the Binding Update message, based on the registration key 1722 it established with its previous foreign agent, and includes this 1723 Authenticator value in the extension for inclusion in the Binding 1724 Update message by the new foreign agent. The new foreign agent does 1725 not learn the previous foreign agent registration key during the new 1726 registration or notification. 1728 When the Binding Acknowledgment message from the previous foreign 1729 agent is received by the new foreign agent, it detunnels it and sends 1730 it to the mobile node. In this way, the mobile node can discover 1731 that its previous foreign agent has received the Binding Update 1732 message. This is important, because otherwise the previous foreign 1733 agent would often become a "black hole" for datagrams destined for 1734 the mobile node based on out-of-date binding cache entries at other 1735 nodes. The new foreign agent has no further responsibility for 1736 helping to update the binding cache at the previous foreign agent. 1738 The mobile node expects to eventually receive a Binding 1739 Acknowledgement message from its previous foreign agent, signifying 1740 that the Binding Update message was received. If the acknowledgement 1741 has not been received after sufficient time, the mobile node is 1742 responsible for retransmitting another Binding Update message to its 1743 previous foreign agent. Although the previous foreign agent may 1744 have already received and processed the Binding Update message (the 1745 Binding Acknowledge message may have been lost in transit to the new 1746 foreign agent), the mobile node should continue to retransmit its 1747 Binding Update message until the previous foreign agent responds with 1748 a Binding Acknowledgement. 1750 References 1752 [1] CDPD Forum. Cellular Digital Packet Data system specification. 1753 Release 1.0, July 1993. 1755 [2] W. Diffie and M. E. Hellman. New directions in cryptography. 1756 IEEE Transactions on Information Theory, IT-22(6):644--654, 1757 November 1976. 1759 [3] Ralph Droms. Dynamic Host Configuration Protocol. RFC 1541, 1760 October 1993. 1762 [4] Donald E. Eastlake 3rd, Stephen D. Crocker, and Jeffrey I. 1763 Schiller. Randomness recommendations for security. RFC 1750, 1764 December 1994. 1766 [5] Stan Hanks, Tony Li, Dino Farinacci, and Paul Traina. Generic 1767 Routing Encapsulation (GRE). RFC 1701, October 1994. 1769 [6] Charles Perkins, editor. IP mobility support. Internet Draft, 1770 draft-ietf-mobileip-protocol-12.txt, August 1995. Work in 1771 progress. 1773 [7] RSA Laboratories. RSAREF(TM) 2.0: A free cryptographic toolkit, 1774 April 1994. 1776 Appendix A. Using a Master Key at the Home Agent 1778 Rather than storing each mobility security association that it has 1779 established with many different correspondent nodes and foreign 1780 agents, a home agent may manage its mobility security associations so 1781 that each of them can be generated from a single "master" key. With 1782 the master key, the home agent could build a key for any given other 1783 node by computing the node-specific key as 1785 MD5(node-address || master-key || node-address) 1787 where node-address is the IP address of the particular node for which 1788 the home agent is building a key, and master-key is the single master 1789 key held by the home agent for all mobility security associations it 1790 has established with correspondent nodes. The node-specific key is 1791 built by computing an MD5 hash over a string consisting of the master 1792 key with the node-address concatenated as a prefix and as a suffix. 1794 Using this scheme, when establishing each mobility security 1795 association, the network administrator managing the home agent 1796 computes the node-specific key and communicates this key to the 1797 network administrator of the other node through some "secure" 1798 channel, such as over the telephone. The mobility security 1799 association is configured at this other node in the same way as any 1800 mobility security association. At the home agent, though, no record 1801 need be kept that this key has been given out. The home agent need 1802 only be configured to know that this scheme is in use for all of its 1803 mobility security associations (perhaps only for specific set of its 1804 mobile nodes). 1806 When the home agent then needs a mobility security association as 1807 part of Route Optimization, it builds the node-specific key based on 1808 the master key and the IP address of the other node with which it 1809 is attempting to authenticate. If the other node knows the correct 1810 node-specific key, the authentication will succeed; otherwise, it 1811 will fail as it should. 1813 Chairs' Addresses 1815 The working group can be contacted via the current chairs: 1817 Tony Li 1818 cisco Systems 1819 170 W. Tasman Drive 1820 San Jose, CA 95134 1822 Phone: +1-408-526-8186 1823 E-mail: tli@cisco.com 1825 Jim Solomon 1826 Motorola, Inc. 1827 1301 E. Algonquin Road 1828 Schaumburg, IL 60196 1830 Phone: +1-847-576-2753 1831 E-mail: solomon@comm.mot.com 1833 Authors' Addresses 1835 Questions about this document can also be directed to the authors: 1837 David B. Johnson 1838 Computer Science Department 1839 Carnegie Mellon University 1840 5000 Forbes Avenue 1841 Pittsburgh, PA 15213-3891 1843 Phone: +1-412-268-7399 1844 Fax: +1-412-268-5576 1845 E-mail: dbj@cs.cmu.edu 1847 Charles Perkins 1848 Room J1-A25 1849 T. J. Watson Research Center 1850 IBM Corporation 1851 30 Saw Mill River Rd. 1852 Hawthorne, NY 10532 1854 Phone: +1-914-784-7350 1855 Fax: +1-914-784-7007 1856 E-mail: perk@watson.ibm.com 1858 ----------------------------------------------------------------------