idnits 2.17.1 draft-ietf-mobileip-optim-05.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-18) 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 226: '...ally created and MAY be deleted by the...' RFC 2119 keyword, line 233: '...All Binding Update messages MUST carry...' RFC 2119 keyword, line 241: '... that MAY optionally be establ...' RFC 2119 keyword, line 243: '...elsewhere, the mobile node MAY use the...' RFC 2119 keyword, line 253: '...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 (-24) exists of draft-ietf-mobileip-ipv6-02 ** Obsolete normative reference: RFC 2002 (ref. '7') (Obsoleted by RFC 3220) -- Possible downref: Non-RFC (?) normative reference: ref. '8' Summary: 13 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 26 November 1996 Charles Perkins 4 IBM Corporation 6 Route Optimization in Mobile IP 8 draft-ietf-mobileip-optim-05.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@SmallWorks.COM. 16 The Route Optimization protocol extensions for Mobile IP for IPv4 17 are actively being worked on within the Mobile IP Working Group, 18 although recent emphasis has been on the design and specification of 19 Mobile IP for IPv6. This document represents the current state of 20 the Mobile IPv4 Route Optimization extensions, although the design 21 of Route Optimization is currently being revised to more closely 22 follow the design of Mobile IPv6 that has evolved. This document 23 will be revised and resubmitted once those revisions are more further 24 developed. 26 Distribution of this document is unlimited. 28 This document is an Internet-Draft. Internet-Drafts are working 29 documents of the Internet Engineering Task Force (IETF), its areas, 30 and its working groups. Note that other groups may also distribute 31 working documents as Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at 35 any time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 To learn the current status of any Internet-Draft, please check 39 the "1id-abstracts.txt" listing contained in the Internet-Drafts 40 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 41 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 42 ftp.isi.edu (US West Coast). 44 Abstract 46 This document defines extensions to the operation of the base 47 Mobile IP protocol to allow for optimization of datagram routing from 48 a correspondent node to a mobile node. Without Route Optimization, 49 all datagrams destined to a mobile node are routed through that 50 mobile node's home agent, which then tunnels each datagram to the 51 mobile node's current location. The protocol extensions described 52 here provide a means for correspondent nodes that implement them 53 to cache the binding of a mobile node and to then tunnel their own 54 datagrams for the mobile node directly to that location, bypassing 55 the possibly lengthy route for each datagram to and from the mobile 56 node's home agent. Extensions are also provided to allow datagrams 57 in flight when a mobile node moves, and datagrams sent based on an 58 out-of-date cached binding, to be forwarded directly to the mobile 59 node's new binding. 61 Contents 63 Status of This Memo i 65 Abstract ii 67 1. Introduction 1 69 2. Terminology 3 71 3. Route Optimization Overview 4 72 3.1. Binding Caching . . . . . . . . . . . . . . . . . . . . . 4 73 3.2. Foreign Agent Handoff . . . . . . . . . . . . . . . . . . 4 74 3.3. Binding Cache Updates . . . . . . . . . . . . . . . . . . 7 76 4. Route Optimization Message Formats 9 77 4.1. Binding Warning Message . . . . . . . . . . . . . . . . . 10 78 4.2. Binding Request Message . . . . . . . . . . . . . . . . . 11 79 4.3. Binding Update Message . . . . . . . . . . . . . . . . . 12 80 4.4. Binding Acknowledge Message . . . . . . . . . . . . . . . 14 81 4.5. Registration Request Message . . . . . . . . . . . . . . 16 83 5. Route Optimization Extension Formats 17 84 5.1. Previous Foreign Agent Notification Extension . . . . . . 18 85 5.2. Route Optimization Authentication Extension . . . . . . . 20 86 5.3. Registration Key Request Extension . . . . . . . . . . . 21 87 5.4. Home-Mobile Registration Key Reply Extension . . . . . . 22 88 5.5. Home-Foreign Registration Key Reply Extension . . . . . . 23 89 5.6. Diffie-Hellman Registration Key Request Extension . . . . 24 90 5.7. Diffie-Hellman Registration Key Reply Extension . . . . . 26 91 5.8. Mobile Service Extension . . . . . . . . . . . . . . . . 27 93 6. Mobility Security Association Management 28 95 7. Methods of Establishing a Registration Key 30 96 7.1. Using the Home Agent as a Key Distribution Center . . . . 30 97 7.2. Using Diffie-Hellman with the Foreign Agent . . . . . . . 30 98 7.3. Using a Mobile Node Public Key . . . . . . . . . . . . . 32 99 7.4. Using a Foreign Agent Public Key . . . . . . . . . . . . 32 101 8. Binding Cache Considerations 34 102 8.1. Cache Management . . . . . . . . . . . . . . . . . . . . 34 103 8.2. Receiving Binding Update Messages . . . . . . . . . . . . 34 104 8.3. Using Special Tunnels . . . . . . . . . . . . . . . . . . 35 106 9. Home Agent Considerations 36 107 9.1. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . 36 108 9.2. Receiving Binding Warning Messages . . . . . . . . . . . 36 109 9.3. Receiving Binding Request Messages . . . . . . . . . . . 37 110 9.4. Receiving Registration Key Requests . . . . . . . . . . . 37 111 9.5. Receiving Special Tunnels . . . . . . . . . . . . . . . . 38 113 10. Foreign Agent Considerations 39 114 10.1. Establishing a Registration Key . . . . . . . . . . . . . 39 115 10.2. Previous Foreign Agent Notification . . . . . . . . . . . 40 116 10.3. Receiving Tunneled Datagrams . . . . . . . . . . . . . . 41 117 10.4. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . 42 118 10.5. Sending Special Tunnels . . . . . . . . . . . . . . . . . 42 120 11. Mobile Node Considerations 43 121 11.1. Establishing a Registration Key . . . . . . . . . . . . . 43 122 11.2. Notifying Previous Foreign Agents . . . . . . . . . . . . 43 124 References 45 126 Appendix A. Using a Master Key at the Home Agent 46 128 Chairs' Addresses 47 130 Authors' Addresses 48 131 1. Introduction 133 The base Mobile IP protocol [7] allows any mobile node to move about, 134 changing its point of attachment to the Internet, while continuing 135 to be addressed by its home IP address. Correspondent nodes sending 136 IP datagrams to a mobile node address them to the mobile node's home 137 address in the same way as to any destination. 139 While the mobile node is connected to the Internet away from its 140 home network, it is served by a "home agent" on its home network 141 and is associated with a "care-of address" indicating its current 142 location. The association between a mobile node's home address and 143 its care-of address is known as a "mobility binding". The care-of 144 address is generally the address of a "foreign agent" on the network 145 being visited by the mobile node, which forwards arriving datagrams 146 locally to the mobile node. Alternatively, the care-of address may 147 be temporarily assigned to the mobile node using DHCP [3] or other 148 means. All IP datagrams addressed to the mobile node are routed by 149 the normal IP routing mechanisms to the mobile node's home network, 150 where they are intercepted by the mobile node's home agent, which 151 then tunnels each datagram to the mobile node's current care-of 152 address. Datagrams sent by a mobile node use the foreign agent as a 153 default router but require no other special handling or routing. 155 This scheme allows transparent interoperation with mobile nodes, 156 but forces all datagrams for a mobile node to be routed through its 157 home agent; datagrams to the mobile node are often routed along 158 paths that are significantly longer than optimal. For example, if a 159 mobile node, say MN1, is visiting some subnet, even datagrams from 160 a correspondent node on this same subnet must be routed through the 161 Internet to MN1's home agent on MN1's home network, only to then 162 be tunneled back to the original subnet to MN1's foreign agent for 163 delivery to MN1. This indirect routing can significantly delay the 164 delivery of the datagram to MN1 and places an unnecessary burden on 165 the networks and routers along this path through the Internet. If 166 the correspondent node in this example is actually another mobile 167 node, say MN2, then datagrams from MN1 to MN2 must likewise be routed 168 through MN2's home agent on MN2's home network and back to the 169 original subnet for delivery to MN1. 171 This document defines extensions to the base Mobile IP protocol to 172 allow for the optimization of datagram routing from a correspondent 173 node to a mobile node. These extensions provide a means for nodes 174 that implement them to cache the binding of a mobile node and to then 175 tunnel their own datagrams directly to the care-of address indicated 176 in that binding, bypassing the possibly lengthy route to and from 177 that mobile node's home agent. Extensions are also provided to allow 178 datagrams in flight when a mobile node moves, and datagrams sent 179 based on an out-of-date cached binding, to be forwarded directly 180 to the mobile node's new care-of address. These extensions are 181 collectively referred to as Route Optimization in this document. 183 All operation of Route Optimization that changes the routing of IP 184 datagrams to the mobile node is authenticated using the same type of 185 authentication mechanism used in the base Mobile IP protocol. This 186 authentication generally relies on a "mobility security association" 187 established in advance between the node sending a message and the 188 node receiving the message that must authenticate it. When the 189 required mobility security association has not been established, a 190 Mobile IP implementation using Route Optimization operates in the 191 same way as the base Mobile IP protocol. 193 Section 3 of this document provides an overview of the operation of 194 Route Optimization. Section 4 defines the message types used by 195 Route Optimization, and Section 5 defines the message extensions 196 used. Section 6 discusses the problem of managing the mobility 197 security associations needed to provide authentication of all 198 messages that affect the routing of datagrams to a mobile node. 199 The final four sections of this document define in detail the 200 operation of Route Optimization from the point of view of each of the 201 entities involved: considerations for nodes maintaining a binding 202 cache are presented in Section 8, mobile node considerations in 203 Section 11, foreign agent considerations in Section 10, and home 204 agent considerations in Section 9. 206 Note that this document represents the current state of the Mobile IP 207 Route Optimization extensions for IPv4, although the design of Route 208 Optimization is currently being revised. Recent emphasis within the 209 Mobile IP Working Group has been on the design and specification 210 of Mobile IP for IPv6, and the design of Route Optimization for 211 Mobile IPv4 is being revised to more closely follow the design of 212 Mobile IPv6 that has evolved [6]. This document will be revised and 213 resubmitted once those revisions are more further developed. 215 2. Terminology 217 This document introduces the following terminology, in addition to 218 that used in the base Mobile IP protocol: 220 Binding cache 222 A cache of mobility bindings of mobile nodes, maintained by 223 a node for use in tunneling datagrams to those mobile nodes. 224 Presence of a binding cache entry is not required for correct 225 operation of the Mobile IP protocol. Entries in the binding 226 cache are dynamically created and MAY be deleted by the node at 227 any time, such as to reclaim space in the cache. 229 Binding update 231 A notification to some node of a mobile node's current 232 mobility binding. A binding update is sent using a Binding 233 Update message. All Binding Update messages MUST carry 234 an authentication extension, similar to the authentication 235 required in all registration messages in the base Mobile IP 236 protocol. 238 Registration key 240 A secret key shared between a mobile node and a foreign agent, 241 that MAY optionally be established during registration with 242 that foreign agent. When later moving and registering a 243 new care-of address elsewhere, the mobile node MAY use the 244 registration key it shares with its previous foreign agent, to 245 send an authenticated binding update to this foreign agent. 247 Special tunnel 249 A method of tunneling a datagram in which the "outer" 250 destination address when encapsulating the datagram is 251 set equal to the "inner" destination address (the original 252 destination address of the datagram). Any router forwarding 253 such a tunneled datagram MUST NOT re-tunnel the datagram even 254 if it has a binding cache entry for the destination address. A 255 special tunnel is used in Route Optimization for delivering a 256 datagram, addressed to a mobile node, to the mobile node's home 257 agent while the mobile node is away from home, without knowing 258 the home agent's address. The "outer" source address allows 259 the home agent to know the tunneling node's address when it 260 intercepts the datagram on the home network. 262 3. Route Optimization Overview 264 3.1. Binding Caching 266 Route Optimization provides a means for any node that wishes to 267 optimize its own communication with mobile nodes to maintain a 268 "binding cache" containing the mobility binding of one or more mobile 269 nodes. When sending an IP datagram to a mobile node, if the sender 270 has a binding cache entry for the destination mobile node, it may 271 tunnel the datagram directly to the care-of address indicated in the 272 cached mobility binding. 274 In the absence of any binding cache entry, datagrams destined for 275 a mobile node will be routed to the mobile node's home network in 276 the same way as any other IP datagram, and are then tunneled to the 277 mobile node's current care-of address by the mobile node's home 278 agent. This is the only routing mechanism supported by the base 279 Mobile IP protocol. With Route Optimization, as a side effect of 280 this indirect routing of a datagram to a mobile node, the original 281 sender of the datagram may be informed of the mobile node's current 282 mobility binding, giving the sender an opportunity to cache the 283 binding. 285 A node may create a binding cache entry for a mobile node only when 286 it has received and authenticated the mobile node's mobility binding. 287 Likewise, a node may update an existing binding cache entry for a 288 mobile node, such as after the mobile node has moved to a new foreign 289 agent, only when it has received and authenticated the mobile node's 290 new mobility binding. 292 A binding cache will, by necessity, have a finite size. Any node 293 implementing a binding cache may manage the space in its cache using 294 any local cache replacement policy. If a datagram is sent by a 295 node to a destination for which it has dropped the cache entry from 296 its binding cache, the datagram will be routed normally, leading to 297 the mobile node's home network, where it will be intercepted by the 298 mobile node's home agent and tunneled to the mobile node's care-of 299 address. As when a binding cache entry is initially created, this 300 indirect routing to the mobile node will result in the original 301 sender of the datagram being informed of the mobile node's current 302 mobility binding, allowing it to add this entry again to its binding 303 cache. 305 3.2. Foreign Agent Handoff 307 When a mobile node moves and registers with a new foreign agent, the 308 base Mobile IP protocol does not notify the mobile node's previous 309 foreign agent. IP datagrams intercepted by the home agent after 310 the new registration are tunneled to the mobile node's new care-of 311 address, but datagrams in flight that had already been intercepted 312 by the home agent and tunneled to the old care-of address when the 313 mobile node moved are lost and are assumed to be retransmitted by 314 higher-level protocols if needed. The old foreign agent eventually 315 deletes the mobile node's registration after the expiration of the 316 lifetime period established when the mobile node registered there. 318 Route Optimization provides a means for the mobile node's previous 319 foreign agent to be reliably notified of the mobile node's new 320 mobility binding, allowing datagrams in flight to the mobile 321 node's previous foreign agent to be forwarded to its new care-of 322 address. This notification also allows any datagrams tunneled to the 323 mobile node's previous foreign agent from correspondent nodes with 324 out-of-date binding cache entries for the mobile node (that have not 325 yet learned that the mobile node has moved), to be forwarded to its 326 new care-of address. Finally, this notification allows any resources 327 consumed by the mobile node's binding at the previous foreign agent 328 (such as radio channel reservations) to be released immediately, 329 rather than waiting for the mobile node's registration to expire. 331 Optionally, during registration with a new foreign agent, the mobile 332 node and the foreign agent may establish a new shared secret key 333 as a "registration key". When the mobile node later registers 334 with a new foreign agent, if it established a registration key 335 during registration with its previous foreign agent, it may use 336 this key to notify the previous foreign agent that it has moved. 337 This notification may also optionally include the mobile node's new 338 care-of address, allowing the previous foreign agent to create a 339 binding cache entry for the mobile node to serve as a "forwarding 340 pointer" to its new location. Any tunneled datagrams for the mobile 341 node that arrive at this previous foreign agent after this binding 342 cache entry has been created will then be re-tunneled by this 343 foreign agent to the mobile node's new location using the mobility 344 binding in this binding cache entry. The registration key is used 345 to authenticate the notification sent to the previous foreign agent. 346 Other uses of the registration key are possible, such as for use as 347 an encryption key for providing privacy over a wireless link between 348 the mobile node and its foreign agent, but such uses are beyond the 349 scope of this document. Once established, the registration key for a 350 mobile node can be stored by the foreign agent with the mobile node's 351 visitor list entry. 353 In this document, we suggest four methods that a mobile node could 354 use for dynamically establishing a registration key with a foreign 355 agent when it registers with that foreign agent: 357 - The home agent chooses the new registration key, and returns a 358 separate encrypted copy of the key to the foreign agent and to 359 the mobile node in its Registration Reply message. For this 360 method, the home agent must share a mobility security association 361 with the foreign agent in addition to its required mobility 362 security association with the mobile node. 364 - The mobile node and its foreign agent execute a Diffie-Hellman 365 key exchange protocol [2] as part of the registration protocol. 367 - The mobile node includes its public key (such as RSA) in its 368 Registration Request to the foreign agent, and the foreign 369 agent chooses the new registration key and returns a copy of it 370 encrypted with the mobile node's public key. 372 - The foreign agent includes an MD5 digest of its public key (such 373 as RSA) in its Agent Advertisement messages. The mobile node 374 includes a copy of this digest in its Registration Request, and 375 the foreign agent adds its full public key to the Registration 376 Request when relaying it to the home agent. The home agent then 377 chooses the new registration key and returns a separate encrypted 378 copy of the key to the foreign agent (using this public key) and 379 to the mobile node (using its mobility security association with 380 the mobile node) in its Registration Reply message. 382 Section 7 discusses these methods of establishing a registration key 383 in detail. 385 As part of the registration procedure, the mobile node may 386 request that its new foreign agent attempt to notify its previous 387 foreign agent on its behalf, by including a Previous Foreign Agent 388 Notification extension in its Registration Request message sent to 389 the new foreign agent. The new foreign agent then builds a Binding 390 Update message and transmits it to the mobile node's previous foreign 391 agent as part of registration, requesting an acknowledgement from 392 the previous foreign agent. The Previous Foreign Agent Notification 393 extension includes only those values needed to construct the Binding 394 Update message that are not already contained in the Registration 395 Request message. The authenticator for the Binding Update message is 396 computed by the mobile node based on its registration key shared with 397 its previous foreign agent. 399 The mobile node is responsible for occasionally retransmitting a 400 Binding Update message to its previous foreign agent until the 401 matching Binding Acknowledge message is received, or until the mobile 402 node can be sure of the expiration of its registration with that 403 foreign agent. 405 The binding cache entry created at the mobile node's previous foreign 406 agent is treated in the same way as any other binding cache entry. 407 In particular, it is possible that this binding cache entry will be 408 deleted from the cache at any time. In this case, the foreign agent 409 will be unable to re-tunnel subsequently arriving tunneled datagrams 410 for the mobile node, directly to the mobile node's new location. 412 3.3. Binding Cache Updates 414 When a mobile node's home agent intercepts a datagram from the 415 home network and tunnels it to the mobile node, the home agent may 416 deduce that the original source of the datagram has no binding 417 cache entry for the destination mobile node. In this case, the 418 home agent MAY send a Binding Update message to the original source 419 node, informing it of the mobile node's current mobility binding. 420 No acknowledgement for this Binding Update message is needed, since 421 additional future datagrams from this source node intercepted by the 422 home agent for the mobile node will cause transmission of another 423 Binding Update. In order for this Binding Update to be authenticated 424 by the original source node, the home agent and this source node must 425 have established a mobility security association. 427 Similarly, when any node receives a tunneled datagram that was 428 tunneled to this node, if it has a binding cache entry for the 429 destination mobile node (and thus has no visitor list entry for 430 this mobile node), the node receiving this tunneled datagram may 431 deduce that the tunneling node has an out-of-date binding cache entry 432 for this mobile node. In this case, the receiving node MAY send a 433 Binding Warning message to the mobile node's home agent, advising 434 it to send a Binding Update message to the node that tunneled this 435 datagram. The mobile node's home agent can be determined from the 436 binding cache entry (the home agent address is learned from the 437 Binding Update that established this cache entry), and the address 438 of the node that tunneled this datagram can be determined from the 439 datagram's header (the address of the node tunneling this datagram 440 is the "outer" source address of the encapsulated datagram). As in 441 the case of a Binding Update sent by the mobile node's home agent, no 442 acknowledgement of this Binding Warning is needed, since additional 443 future datagrams for the mobile node tunneled by the same node will 444 cause the transmission of another Binding Warning. However, unlike 445 the Binding Update message, no authentication of the Binding Warning 446 message is necessary, since it does not directly affect the routing 447 of IP datagrams to the mobile node. 449 Finally, suppose a node receives a datagram that has been tunneled to 450 this node, but this node is unable to deliver the datagram locally 451 to the destination mobile node (the node is not the mobile node 452 itself, and it is not a foreign agent with a visitor list entry for 453 the mobile node), and this node has no binding cache entry for the 454 destination mobile node. To attempt delivery of the datagram in this 455 case, the node must encapsulate the datagram as a "special tunnel" 456 datagram (Section 10.5), destined to the mobile node. This use of a 457 "special tunnel" avoids a possible routing loop in the case in which 458 the case-of address registered at the home agent is the address of 459 this node, but this node has forgotten that it is serving as the 460 mobile node's foreign agent, perhaps because the node has crashed and 461 lost its visitor list state. The "special tunnel" allows the home 462 agent to see the address of the node that tunneled the datagram, and 463 to avoid tunneling the datagram back to the same node. 465 Each Binding Update message indicates the maximum lifetime of any 466 binding cache entry created from the Binding Update. When sending 467 the Binding Update message, the home agent SHOULD set this lifetime 468 to the remaining service lifetime associated with the mobile node's 469 current registration. Any binding cache entry established or updated 470 in response to this Binding Update message must be marked to be 471 deleted after the expiration of this period. A node wanting to 472 provide continued service with a particular binding cache entry may 473 attempt to reconfirm that mobility binding before the expiration of 474 this lifetime period. Such reconfirmation of a binding cache entry 475 may be appropriate when the node has indications (such as an open 476 transport-level connection to the mobile node) that the binding 477 cache entry is still needed. This reconfirmation is performed by 478 the node sending a Binding Request message to the mobile node's home 479 agent, requesting it to reply with the mobile node's current mobility 480 binding in a new Binding Update message. 482 4. Route Optimization Message Formats 484 Route Optimization defines four message types used for management 485 of binding cache entries. Each of these messages begins with a 486 one-octet field indicating the type of the message. 488 The following Type codes are defined in this document: 490 16 = Binding Warning message 491 17 = Binding Request message 492 18 = Binding Update message 493 19 = Binding Acknowledge message 495 Route Optimization also requires one minor change to existing 496 Mobile IP messages: a new flag bit must be added to the Registration 497 Request message, replacing a previously unused, reserved bit in the 498 message. 500 This section describes each of the new Route Optimization messages 501 and the change to Registration Request message. 503 4.1. Binding Warning Message 505 A Binding Warning message is used to advise a mobile node's home 506 agent that another node appears to have either no binding cache entry 507 or an out-of-date binding cache entry for some mobile node. When any 508 node receives a datagram tunneled to itself, if it is not the current 509 foreign agent for the destination mobile node, it MAY send a Binding 510 Warning message to the mobile node's home agent. 512 0 1 2 3 513 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 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | Type | Reserved | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | Mobile Node Home Address | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | Target Node Address | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 Type 524 16 526 Reserved 528 Sent as 0; ignored on reception. 530 Mobile Node Home Address 532 The home address of the mobile node to which the Binding 533 Warning message refers. 535 Target Node Address 537 The address of the node tunneling the datagram that caused the 538 Binding Warning message. This node should be the target of the 539 Binding Update message sent by the home agent. 541 4.2. Binding Request Message 543 A Binding Request message is used by a node to request a mobile 544 node's current mobility binding from the mobile node's home agent. 546 0 1 2 3 547 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 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | Type | Reserved | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | Mobile Node Home Address | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | | 554 + Identification + 555 | | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 Type 560 17 562 Reserved 564 Sent as 0; ignored on reception. 566 Mobile Node Home Address 568 The home address of the mobile node to which the Binding 569 Request refers. 571 Identification 573 A 64-bit sequence number, assigned by the node sending the 574 Binding Request message, used to assist in matching requests 575 with replies, and in protecting against replay attacks. 577 4.3. Binding Update Message 579 The Binding Update message is used to notify another node of a mobile 580 node's current mobility binding. It MAY be sent by the mobile 581 node's home agent in response to a Binding Request message or a 582 Binding Warning message. It MAY also be sent by a mobile node, or 583 by the foreign agent with which the mobile node is registering, when 584 notifying the mobile node's previous foreign agent that the mobile 585 node has moved. 587 0 1 2 3 588 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | Type |A|I|M|G| Rsvd | Lifetime | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | Mobile Node Home Address | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | Care-of Address | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | | 597 + Identification + 598 | | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | Extensions ... 601 +-+-+-+-+-+-+-+- 603 Type 605 18 607 Acknowledge (A) 609 The Acknowledge (A) bit is set by the node sending the Binding 610 Update message to request a Binding Acknowledge message be 611 returned acknowledging its receipt. 613 Identification Present (I) 615 The Identification Present (I) bit is set by the node sending 616 the Binding Update message to indicate that the Identification 617 field is present in the message. 619 Minimal Encapsulation (M) 621 If the Minimal Encapsulation (M) bit is set, datagrams may be 622 tunneled to the mobile node using the minimal encapsulation 623 protocol used in the base Mobile IP protocol. 625 GRE Encapsulation (G) 627 If the GRE Encapsulation (G) bit is set, datagrams may be 628 tunneled to the mobile node using the GRE encapsulation 629 protocol [5]. 631 Reserved (Rsvd) 633 Sent as 0; ignored on reception. 635 Lifetime 637 The number of seconds remaining before the binding cache entry 638 must be considered expired. A value of all ones indicates 639 infinity. A value of zero indicates that no binding cache 640 entry for the mobile node should be created and that any 641 existing binding cache entry (and visitor list entry, in the 642 case of a mobile node's previous foreign agent) for the mobile 643 node should be deleted. The lifetime is typically equal to the 644 remaining lifetime of the mobile node's registration. 646 Mobile Node Home Address 648 The home address of the mobile node to which the Binding Update 649 message refers. 651 Care-of Address 653 The current care-of address of the mobile node. When set equal 654 to the home address of the mobile node, the Binding Update 655 message instead indicates that no binding cache entry for the 656 mobile node should be created, and any existing binding cache 657 entry (and visitor list entry, in the case of a mobile node's 658 previous foreign agent) for the mobile node should be deleted. 660 Identification 662 If present, a 64-bit number, assigned by the node sending the 663 Binding Request message, used to assist in matching requests 664 with replies, and in protecting against replay attacks. 666 The Route Optimization Authentication extension (Section 5.2) is 667 required. 669 4.4. Binding Acknowledge Message 671 A Binding Acknowledge message is used to acknowledge receipt of a 672 Binding Update message. It SHOULD be sent by a node receiving the 673 Binding Update message if the Acknowledge (A) bit is set in the 674 Binding Update message. 676 0 1 2 3 677 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 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | Type |N| Reserved | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | Mobile Node Home Address | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | | 684 + Identification + 685 | | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 Type 690 19 692 Negative Acknowledge (N) 694 If the Negative Acknowledge (N) bit is set, this 695 acknowledgement is negative. For instance, if the 696 binding update was not accepted, but the incoming datagram has 697 the Acknowledge flag set, then the Negative Acknowledge (N) bit 698 SHOULD be set in this Binding Acknowledge message. 700 DISCUSSION: Alternatively, we could replace this bit with 701 a status code, as in the Registration Reply message. The 702 mobile node could log the error, but currently has no 703 real way to recover from it, so perhaps the exact reason 704 for the error isn't that useful. 706 Reserved 708 Sent as 0; ignored on reception. 710 Mobile Node Home Address 712 Copied from the Binding Update message being acknowledged. 714 Identification 716 Copied from the Binding Update message being acknowledged, if 717 present there. 719 4.5. Registration Request Message 721 One bit is added to the flag bits in the Registration Request message 722 to indicate that the mobile node would like its home agent to keep 723 its mobility binding "private". Normally, the home agent sends 724 Binding Update messages to correspondent nodes as needed to allow 725 them to cache the mobile node's binding. If the mobile node sets the 726 Private (P) bit in the Registration Request message, the home agent 727 MUST not send the mobile node's binding in Binding Update messages. 728 Instead, each Binding Update message should give the mobile node's 729 care-of address equal to its home address, and should give a Lifetime 730 value of 0. 732 Thus, the Registration Request message under Route Optimization 733 begins as follows: 735 0 1 2 3 736 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 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | Type |S|B|D|M|G|P|rvd| Lifetime | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | (unchanged...) 741 +-+-+- 743 Private (P) 745 The Private (P) bit is set by the node sending the Binding 746 Update message to indicate that the home agent should keep its 747 mobility binding private. In any Binding Update message sent 748 by the mobile node's home agent, the care-of address should be 749 set equal to the mobile node's home address, and the Lifetime 750 should be set equal to 0. 752 5. Route Optimization Extension Formats 754 Route Optimization defines the following Mobile IP message 755 extensions: 757 96 = Previous Foreign Agent Notification Extension 758 97 = Route Optimization Authentication Extension 759 98 = Registration Key Request Extension 760 99 = Home-Mobile Registration Key Reply Extension 761 100 = Home-Foreign Registration Key Reply Extension 762 101 = Diffie-Hellman Registration Key Request Extension 763 102 = Diffie-Hellman Registration Key Reply Extension 764 103 = Foreign Agent Public Key Digest Advertisement Extension 765 104 = Registration Key Request Public Key Digest Extension 766 105 = Foreign Agent Public Key Extension 767 106 = Mobile Node Public Key Extension 768 107 = Foreign-Mobile Registration Key Reply Extension 770 Route Optimization also requires one minor change to existing 771 Mobile IP message extensions: a new flag bit must be added to the 772 Mobile Service extension, replacing a previously unused, reserved bit 773 in the extension. 775 This section describes each of the new Route Optimization message 776 extensions and the change to Mobile Service extension. 778 5.1. Previous Foreign Agent Notification Extension 780 The Previous Foreign Agent Notification extension may be included 781 in a Registration Request message sent to a foreign agent. It 782 requests the new foreign agent to send a Binding Update message to 783 the mobile node's previous foreign agent on behalf of the mobile 784 node, to notify it that the mobile node has moved. The previous 785 foreign agent deletes the mobile node's visitor list entry and, if a 786 new care-of address is included in the Binding Update message, also 787 creates a binding cache entry for the mobile node pointing to its new 788 care-of address. The Previous Foreign Agent Notification extension 789 contains only those values not otherwise already contained in the 790 Registration Request message that are needed for the new foreign 791 agent to construct the Binding Update message. 793 0 1 2 3 794 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 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | Type | Length | Cache Lifetime | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | Previous Foreign Agent Address | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | New Care-of Address Address | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | Authenticator ... 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 Type 807 96 809 Length 811 10 plus the length of the Authenticator 813 Cache Lifetime 815 The number of seconds remaining before the binding cache entry 816 created by the previous foreign agent must be considered 817 expired. A value of all ones indicates infinity. A value 818 of zero indicates that the previous foreign agent should not 819 create a binding cache entry for the mobile node once it has 820 deleted the mobile node's visitor list entry. The Cache 821 Lifetime value is copied into the Lifetime field of the Binding 822 Update message. 824 Previous Foreign Agent Address 826 The IP address of the mobile node's previous foreign agent 827 to which the new foreign agent should send a Binding Update 828 message on behalf of the mobile node. 830 New Care-of Address 832 The new care-of address for the new foreign agent to send in 833 the Binding Update message to the previous foreign agent. This 834 SHOULD be either the care-of address being registered in this 835 new registration (i.e., to cause IP datagrams from the previous 836 foreign agent to be tunneled to the new foreign agent) or the 837 mobile node's home address (i.e., to cause the previous foreign 838 agent to only delete its visitor list entry for the mobile 839 node). 841 Authenticator 843 The authenticator value to be used in the Route Optimization 844 Authentication extension in the Binding Update message sent by 845 the new foreign agent to the mobile node's previous foreign 846 agent. This authenticator is calculated only over the Binding 847 Update message body. 849 5.2. Route Optimization Authentication Extension 851 The Route Optimization Authentication extension is used to 852 authenticate certain Route Optimization management messages. 854 0 1 2 3 855 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 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 | Type | Length | Authenticator ... 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 Type 862 97 864 Length 866 The length of the Authenticator 868 Authenticator 870 (variable length) A value computed from a stream of bytes 871 including the shared secret, the UDP payload (that is, the 872 Route Optimization management message), all prior extensions 873 in their entirety, and the type and length of this extension, 874 but not including the Authenticator field itself nor the UDP 875 header. 877 5.3. Registration Key Request Extension 879 The Registration Key Request extension may be used in Registration 880 Request messages to request a registration key from the mobile 881 node's home agent. The extension is included in the Registration 882 Request message by the mobile node. It is authenticated along 883 with the rest of the Registration Request message, and thus no 884 additional authenticator is included in the extension. In response 885 to a Registration Key Request extension, the home agent MAY include 886 a Home-Mobile Registration Key Reply extension and a Home-Foreign 887 Registration Key Reply extension in its Registration Reply message, 888 containing encrypted copies of the (same) new registration key for 889 the mobile node and the foreign agent, respectively. 891 0 1 892 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 | Type | Length | 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 Type 899 98 901 Length 903 0 905 The mobility security association assumed to exist between the home 906 agent and the mobile node will be used to encrypt the key sent in 907 the Home-Mobile Registration Key Reply extension, unless a Key 908 Identification extension is also included with the Registration 909 Request message. 911 The home agent must also share a mobility security association with 912 the foreign agent in order to return the requested registration key, 913 and the home agent will use this security association to encrypt the 914 key sent in the Home-Foreign Registration Key Reply extension. 916 5.4. Home-Mobile Registration Key Reply Extension 918 The Home-Mobile Registration Key Reply extension may be used in 919 Registration Reply messages to send a registration key from the 920 mobile node's home agent to the mobile node. When used, the home 921 agent MUST also include a Home-Foreign Registration Key Reply 922 extension in the Registration Reply message, giving a copy of the 923 same key to the mobile node's new foreign agent. The Home-Mobile 924 Registration Key Reply extension is authenticated along with the 925 rest of the Registration Reply message, and thus no additional 926 authenticator is included in the extension. 928 0 1 2 3 929 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 930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 | Type | Length | Mobile Node Encrypted Key ... 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 Type 936 99 938 Length 940 The length of the Mobile Node Encrypted Key 942 Mobile Node Encrypted Key 944 (variable length) The registration key, chosen by the home 945 agent, encrypted under the mobility security association 946 between the home agent and the mobile node. The same key must 947 be sent, encrypted for the foreign agent in a Foreign Agent 948 Registration Key extension in this Registration Reply message. 950 5.5. Home-Foreign Registration Key Reply Extension 952 The Home-Foreign Registration Key Reply extension may be used 953 in Registration Reply messages to send a registration key from 954 the mobile node's home agent to the mobile node's new foreign 955 agent. When used, the home agent MUST also include a Home-Mobile 956 Registration Key Reply extension in the Registration Reply message, 957 giving a copy of the same key to the mobile node. The Home-Foreign 958 Registration Key Reply extension is authenticated by including an 959 authenticator in the extension, computed based on the mobility 960 security association shared between the home agent and the foreign 961 agent. In order for this extension to be used, the home agent MUST 962 share a mobility security association with the foreign agent. 964 0 1 2 3 965 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 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 | Type | Length | Foreign Agent Encrypted Key ... 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 | Authenticator ... 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 Type 974 100 976 Length 978 The length of the Foreign Agent Encrypted Key plus the length 979 of the Authenticator 981 Foreign Agent Encrypted Key 983 (variable length) The registration key, chosen by the home 984 agent, encrypted under the mobility security association 985 between the home agent and the foreign agent. The same key 986 must be sent, encrypted for the mobile node in a Mobile Node 987 Registration Key extension in this Registration Reply message. 989 Authenticator 991 (variable length) A value computed from a stream of bytes 992 including the shared secret and the fields in this extension 993 other than the Authenticator field itself. 995 5.6. Diffie-Hellman Registration Key Request Extension 997 The Diffie-Hellman Registration Key Request extension may be included 998 in a Registration Request message sent to a foreign agent. It begins 999 the Diffie-Hellman key exchange algorithm [2] between the mobile node 1000 and its new foreign agent, as described in Section 7.2. The foreign 1001 agent SHOULD then include a Diffie-Hellman Registration Key Reply 1002 extension in its Registration Reply message sent to the mobile node 1003 in order to complete the key exchange. 1005 0 1 2 3 1006 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 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1008 | Type | Length | 1009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1010 | Prime ... 1011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1012 | Generator ... 1013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1014 | Computed Value ... 1015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 Type 1019 101 1021 Length 1023 3 times the length of each of Prime, Generator, and 1024 Computed Value. The values Prime, Generator, and 1025 Computed Value must all be the same length, which must be a 1026 multiple of 8 bits. 1028 Prime 1030 One of the two public numbers involved in the Diffie-Hellman 1031 key exchange algorithm. The value Prime should be a large 1032 prime number. 1034 Generator 1036 One of the two public numbers involved in the Diffie-Hellman 1037 key exchange algorithm. If p is the value of the Prime used 1038 for this Diffie-Hellman exchange, the value Generator should be 1039 less than p, and should be a primitive root of p. 1041 Computed Value 1043 The public computed value from the mobile node for this 1044 Diffie-Hellman exchange. The mobile node chooses a large 1045 random number, x. If g is the value of the Generator and p is 1046 the value of the Prime, the Computed Value in the extension is 1047 (g**x) mod p. 1049 5.7. Diffie-Hellman Registration Key Reply Extension 1051 The Diffie-Hellman Registration Key Reply extension SHOULD be 1052 included in a Registration Reply message sent by a foreign agent to a 1053 mobile node that included a Diffie-Hellman Registration Key Request 1054 extension in its Registration Request message to the foreign agent. 1056 0 1 2 3 1057 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 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 | Type | Length | 1060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1061 | Computed Value ... 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 Type 1066 101 1068 Length 1070 The length of the Computed Value. The length of the Computed 1071 Value must be a multiple of 8 bits. 1073 Computed Value 1075 The foreign agent chooses a large random number, y. If g is 1076 the value of the Generator and p is the value of the Prime, the 1077 Computed Value in the extension is (g**y) mod p. The values 1078 of the Generator and Prime are taken from the Diffie-Hellman 1079 Registration Key Request extension from the mobile node's 1080 Registration Request message. 1082 5.8. Mobile Service Extension 1084 One bit is added to the flag bits in the Mobile Service extension 1085 (forming an Agent Advertisement message), when sent by a foreign 1086 agent, to indicate that the foreign agent supports registration 1087 key establishment using the Diffie-Hellman key exchange algorithm. 1088 When this bit is set in the Agent Advertisement, the mobile node 1089 MAY request a registration key be established by including a 1090 Diffie-Hellman Registration Key Request extension in its Registration 1091 Request message. The foreign agent replies with the Diffie-Hellman 1092 Registration Key Reply extension in its Registration Reply to the 1093 mobile node. 1095 Thus, the Mobile Service extension under Route Optimization begins as 1096 follows: 1098 0 1 2 3 1099 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 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 | Type | Length | Sequence Number | 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 | Lifetime |R|B|H|F|M|G|D| reserved | 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 | (unchanged...) 1106 +-+-+- 1108 Diffie-Hellman (D) 1110 The Diffie-Hellman (D) bit is set by the foreign agent 1111 sending the Agent Advertisement message to indicate that it 1112 supports the registration key establishment protocol using the 1113 Diffie-Hellman Registration Key Request and Diffie-Hellman 1114 Registration Key Reply extensions. 1116 6. Mobility Security Association Management 1118 One of the most difficult aspects of Route Optimization for Mobile IP 1119 in the Internet today is that of providing authentication for all 1120 messages that affect the routing of datagrams to a mobile node. 1121 In the base Mobile IP protocol, all routing of datagrams to the 1122 mobile node while away from its home network is controlled by the 1123 home agent, since only the home agent is aware of the mobile node's 1124 mobility binding and only the home agent tunnels datagrams to 1125 the mobile node. Authentication is currently achieved based on a 1126 manually established mobility security association between the home 1127 agent and the mobile node. Since the home agent and the mobile 1128 node are both owned by the same organization (both are assigned IP 1129 addresses within the same IP subnet), this manual configuration is 1130 manageable, and (for example) can be performed while the mobile node 1131 is at home. 1133 However, with Route Optimization, authentication is more difficult 1134 to manage, since a Binding Update may in general need to be sent to 1135 any node in the Internet. Since no general authentication or key 1136 distribution protocol is available in the Internet today, the Route 1137 Optimization procedures defined in this document make use of the 1138 same type of manually configured mobility security associations used 1139 in the base Mobile IP protocol. For use with Route Optimization, 1140 a mobility security association held by a correspondent node or a 1141 foreign agent must in general include the same parameters as required 1142 by the base Mobile IP protocol specification [7]. 1144 For a correspondent node to be able to create a binding cache entry 1145 for a mobile node, the correspondent node and the mobile node's 1146 home agent MUST have established a mobility security association. 1147 This mobility security association, though, may be used in creating 1148 and updating binding cache entries at this correspondent node 1149 for all mobile nodes served by this home agent. This places the 1150 correspondent node in a fairly natural relationship with respect 1151 to the mobile nodes served by this home agent. For example, these 1152 mobile nodes may represent different people affiliated with the 1153 organization owning the home agent and these mobile nodes, with which 1154 the user of this correspondent node often collaborates. In this 1155 case, the effort of establishing the necessary mobility security 1156 association with this home agent may be justified. It is similarly 1157 possible for a home agent to have a manually established mobility 1158 security association with the foreign agents often used by its mobile 1159 nodes, or for a particular mobile node to have a manually established 1160 mobility security association with the foreign agents serving the 1161 foreign networks that it often visits. 1163 In general, if the movement and communication patterns of a mobile 1164 node or the group of mobile nodes served by the same home agent are 1165 sufficient to justify establishing a mobility security association 1166 with the mobile node's home agent, users or network administrators 1167 are likely to do so. Without establishing a mobility security 1168 association, nodes will not currently be able to use the Route 1169 Optimization extensions but can use the base Mobile IP protocol. 1171 7. Methods of Establishing a Registration Key 1173 This document suggests four different methods that a mobile node 1174 could use for dynamically establishing a registration key with a 1175 foreign agent when it registers with that foreign agent. 1177 7.1. Using the Home Agent as a Key Distribution Center 1179 One method of establishing a registration key is for the mobile node 1180 to request its home agent to generate one during registration, and 1181 for the home agent to send a copy of this key to both the mobile node 1182 and its new foreign agent. The home agent in this case acts as a 1183 "key distribution center" (KDC) for the mobile node and the foreign 1184 agent. The mobile node requests this by including a Registration 1185 Key Request extension in its Registration Request message. The home 1186 agent sends the generated key to the mobile node and to its foreign 1187 agent by including a Home-Mobile Registration Key Reply extension 1188 and a Home-Foreign Registration Key Reply extension its Registration 1189 Reply message. The Home-Mobile Registration Key Reply extension 1190 contains a copy of the chosen key encrypted under a key and algorithm 1191 shared between the home agent and the mobile node, and a Home-Foreign 1192 Registration Key Reply extension contains a copy of the same key 1193 encrypted under a key and algorithm shared between the home agent and 1194 the foreign agent. 1196 In order for the registration key to be established using this 1197 method, the foreign agent must have a mobility security association 1198 with the home agent. For example, if mobile nodes from some home 1199 network often visit this foreign agent, it may in general be worth 1200 the effort of creating such a mobility security association between 1201 this foreign agent and the home agent serving that home network. If 1202 no mobility security association exists, a mobile node may instead be 1203 able to establish a registration key with its home agent using the 1204 alternative method described in the next section. 1206 7.2. Using Diffie-Hellman with the Foreign Agent 1208 An alternate method defined in this document for establishing a 1209 registration key is for the mobile node and its foreign agent to 1210 execute the Diffie-Hellman key exchange algorithm [2] as part of the 1211 mobile node's registration. The Diffie-Hellman algorithm is a public 1212 key cryptosystem that allows two parties to establish a shared secret 1213 key, such that the shared secret key cannot be determined by other 1214 parties overhearing the messages exchanged during the algorithm. It 1215 is used, for example, in other protocols that require a key exchange, 1216 such as in the Cellular Digital Packet Data (CDPD) system [1]. 1218 Briefly, the Diffie-Hellman algorithm involves the use of two large 1219 public numbers, a Prime number (p) and a Generator (g). The Prime 1220 number and the Generator must be known by both parties involved in 1221 the algorithm, but need not be kept secret; these values may be 1222 different for each execution of the algorithm and are not used once 1223 the algorithm completes. Each party chooses a private random number, 1224 produces a Computed Value based on this random number and the Prime 1225 and the Generator, and sends the Computed Value in a message to the 1226 other party. Each party then computes the (same) shared secret key 1227 using its own private random number, the Computed Value received from 1228 the other party, and the Prime and Generator values. 1230 To use this algorithm during registration with a foreign agent, 1231 the mobile node includes a Diffie-Hellman Registration Key Request 1232 extension in its Registration Request message, containing its values 1233 for the Prime and Generator, along with the Computed Value from its 1234 own private random number. The foreign agent then chooses its own 1235 private random number and includes a Diffie-Hellman Registration Key 1236 Reply extension in its Registration Reply message to the mobile node; 1237 the extension includes the foreign agent's own Computed Value based 1238 on its chosen random number and the supplied Prime and Generator 1239 values from the mobile node. The mobile node and foreign agent each 1240 independently form the (same) shared secret key from their own chosen 1241 random number, the Computed Value supplied by the other party, and 1242 the Prime and Generator values. 1244 The Diffie-Hellman algorithm allows the mobile node and its foreign 1245 agent to establish a registration key without any pre-existing 1246 mobility security associations, but the Diffie-Hellman algorithm 1247 itself is covered by a patent in the United States. The method of 1248 establishing a registration key using Diffie-Hellman thus may not be 1249 usable by those who have not licensed the patent. An implementation 1250 of the Diffie-Hellman key exchange algorithm is available, though, in 1251 the free RSAREF toolkit from RSA Laboratories [8]. 1253 Also, establishing a registration key using Diffie-Hellman is 1254 computationally more expensive than the method described in 1255 Section 7.1. The use of Diffie-Hellman described here, though, is 1256 designed to allow the Diffie-Hellman computations to be overlapped 1257 with other activities. The mobile node may choose (or be manually 1258 configured with) the Prime and Generator values at any time, or 1259 may use the same two values for a number of registrations. The 1260 mobile node may also choose its private random number and compute 1261 its Computed Value at any time. For example, after completing 1262 one registration, the mobile node may choose the private random 1263 number for its next registration and begin the computation of 1264 its new Computed Value based on this random number, such that it 1265 has completed this computation before it is needed in its next 1266 registration; in its simplest form, the mobile node may use the 1267 same private random number and Computed Value for any number of 1268 registrations. The foreign agent may choose its private random 1269 number and begin computation of its Computed Value based on this 1270 number as soon as it receives the mobile node's Registration Request 1271 message, and need only complete this computation before it sends 1272 the matching Registration Reply message for the mobile node's 1273 registration. 1275 The Agent Advertisement message (Mobile Service extension) is revised 1276 under Route Optimization to include a bit to indicate that the 1277 foreign agent sending the advertisement supports this method of 1278 registration key establishment using the Diffie-Hellman algorithm. 1279 If this bit is not set in the Agent Advertisement from the foreign 1280 agent, the mobile node MUST NOT send a Diffie-Hellman Registration 1281 Key Request extension to the foreign agent in its Registration 1282 Request message. 1284 DISCUSSION: This could be extended to support other similar 1285 key exchange algorithms, either by adding a new Request 1286 and Reply extension for each, or by adding a field in the 1287 extensions to indicate which algorithm is to be used. 1288 Diffie-Hellman seems the only obvious choice, though, 1289 currently. 1291 7.3. Using a Mobile Node Public Key 1293 The mobile node includes its public key (such as RSA) in its 1294 Registration Request to the foreign agent, using a Mobile Node Public 1295 Key extension. The foreign agent chooses the new registration key 1296 and returns a copy of it encrypted with the mobile node's public key, 1297 using a Foreign-Mobile Registration Key Reply extension. 1299 7.4. Using a Foreign Agent Public Key 1301 The foreign agent includes an MD5 digest of its public key (such 1302 as RSA) in its Agent Advertisement messages, using a Foreign 1303 Agent Public Key Digest Advertisement extension. The mobile node 1304 includes a copy of this digest in its Registration Request, using 1305 a Registration Key Request Public Key Digest extension, and the 1306 foreign agent adds its full public key to the Registration Request 1307 when relaying it to the home agent, using a Foreign Agent Public Key 1308 extension. The home agent then chooses the new registration key and 1309 returns a separate encrypted copy of the key to the foreign agent 1310 (using this public key) and to the mobile node (using its mobility 1311 security association with the mobile node) in its Registration 1312 Reply message. The copy sent to the foreign agent is included in a 1313 Home-Foreign Registration Key Reply extension, and the copy sent to 1314 the mobile node is included in a Home-Mobile Registration Key Reply 1315 extension. 1317 8. Binding Cache Considerations 1319 Any node may maintain a binding cache in order to optimize its own 1320 communication with mobile nodes. When sending an IP datagram, if the 1321 sending node has a binding cache entry for the destination node, it 1322 MAY tunnel the datagram to the mobile node's care-of address using 1323 the encapsulation techniques described for home agents in the base 1324 Mobile IP protocol specification [7]. Any optional encapsulation 1325 methods supported are indicated by flag bits in the Binding Update 1326 message. 1328 When a mobile node's home agent intercepts a datagram on the home 1329 network and tunnels it to the mobile node, the originating node 1330 generally has no binding cache entry for the destination mobile node. 1331 In such cases, the home agent MAY send a Binding Update message to 1332 the originator. 1334 Similarly, when a node other than the foreign agent currently 1335 serving a mobile node receives a datagram for a mobile node, and 1336 this datagram has been tunneled to that node, the node tunneling the 1337 datagram generally has an out-of-date binding for the mobile node in 1338 its binding cache. In such cases, the node receiving the tunneled 1339 datagram MAY send a Binding Warning message to the mobile node's home 1340 agent, advising it to send a Binding Update message to the tunneling 1341 node. 1343 8.1. Cache Management 1345 A node maintaining a binding cache may use any reasonable strategy 1346 for managing the space within the cache. When a new entry needs to 1347 be added to the binding cache, the node MAY choose to drop any entry 1348 already in the cache, if needed, to make space for the new entry. 1349 For example, a "least-recently used" (LRU) strategy for cache entry 1350 replacement is likely to work well. 1352 Each binding in the binding cache also has an associated lifetime, 1353 specified by in the Binding Update message in which the node obtained 1354 the binding. After the expiration of this time period, the binding 1355 MUST be deleted from the cache. 1357 8.2. Receiving Binding Update Messages 1359 When a node receives a Binding Update message, it MUST verify 1360 the authentication in the message, using the mobility security 1361 association it shares with the mobile node's home agent. The 1362 authentication data is found in the Route Optimization Authentication 1363 extension (Section 5.2). If the authentication succeeds, then a 1364 binding cache entry SHOULD be updated for use in future transmissions 1365 of data to the mobile node. Otherwise, an authentication exception 1366 SHOULD be raised. 1368 8.3. Using Special Tunnels 1370 Whenever any node receives a tunneled datagram for for which it has 1371 no visitor list entry for the datagram's destination, the node may 1372 deduce that the tunneling node has an out-of-date binding cache entry 1373 for the destination mobile node. If the node receiving the tunneled 1374 datagram has a binding cache entry for the destination, it SHOULD 1375 re-tunnel the datagram to the care-of address indicated in this 1376 binding cache entry. 1378 However, if the node receiving the tunneled datagram has no binding 1379 cache entry for the destination, it cannot re-tunnel the node to 1380 its destination. Instead, the node SHOULD forward the datagram 1381 to the destination mobile node's home agent, using a special form 1382 of tunneling called a "special tunnel". To tunnel the datagram 1383 using a special tunnel, the tunneled datagram's destination address 1384 is set equal to the destination address in the tunneled datagram. 1385 Thus, both the "inner" and "outer" destination addresses are set to 1386 the home address of the mobile node. The tunneled datagram will 1387 thus be routed to the mobile node's home network, where it will be 1388 intercepted by the mobile node's home agent in the same way as other 1389 datagrams addressed to the mobile node. 1391 The home agent SHOULD then tunnel the datagram to the current care-of 1392 address for the mobile node. However, the home agent MUST NOT tunnel 1393 the datagram to the current care-of address if the special tunnel of 1394 the datagram originated at that care-of address, as indicated by the 1395 "outer" source address of the special tunnel datagram. The use of 1396 the special tunnel format allows the home agent to identify the node 1397 that tunneled the datagram to it (as well as the original sender of 1398 the datagram). If the home agent believes that the current care-of 1399 address for the mobile node is the same as the source of the special 1400 tunnel, then the home agent SHOULD discard the datagram; in this 1401 case, the foreign agent serving the mobile node appears to have lost 1402 its entry for the mobile node in its visitor list, for example, if 1403 the foreign agent has crashed and rebooted. 1405 After tunneling the datagram to the current care-of address for the 1406 mobile node, the home agent MAY notify the source of the special 1407 tunnel of the mobile node's current binding, by sending it a Binding 1408 Update message. 1410 9. Home Agent Considerations 1412 The home agent will be the frequent source of Binding Update messages 1413 sent to correspondent nodes that are communicating with its mobile 1414 nodes. Any correspondent node that has no binding cache entry for a 1415 mobile node, will send normal, untunneled datagrams through the home 1416 agent by the normal routing in the Internet. When the home agent 1417 first receives a datagram for a mobile node, it SHOULD also send a 1418 Binding Update message to the originator of the datagram in hopes 1419 that the originator will be able to create a binding cache entry for 1420 that mobile node. Then, future datagrams sent by this node to the 1421 mobile node should not need the involvement of the home agent. 1423 9.1. Rate Limiting 1425 A home agent MUST provide some mechanism to limit the rate at which 1426 it sends Binding Update messages to to the same node about any given 1427 mobility binding. This rate limiting is especially important because 1428 it is expected that, within the short term, many Internet nodes will 1429 not support maintenance of a binding cache. In this case, continual 1430 transmissions of Binding Update messages to such a correspondent 1431 node will only add unnecessary overhead to at the home agent and 1432 correspondent node, and along the Internet path between these nodes. 1434 9.2. Receiving Binding Warning Messages 1436 A home agent will receive a Binding Warning message if a node 1437 maintaining a binding cache entry for one of the home agent's mobile 1438 nodes uses the entry after it becomes out-of-date. When a home agent 1439 receives a Binding Warning message, it SHOULD send a Binding Update 1440 message to the Target Node Address identified in the Binding Warning, 1441 giving it the current binding for the mobile node identified in the 1442 Mobile Node Home Address field of the Binding Warning. 1444 If using nonces for replay protection, the use of the Identification 1445 field in the Binding Update message is different in this case, in 1446 order to still allow replay protection even though the Binding Update 1447 is not being sent in reply to a request directly from the target 1448 node. In this case, the high-order 32 bits of the Identification 1449 field MUST be set by the home agent to the value of the nonce that 1450 will be used by the home agent in the next Binding Update message 1451 sent to this node. The low-order 32 bits of the Identification field 1452 MUST be set to the value of the nonce being used for this message. 1453 Thus, on each Binding Update message, the home agent communicates to 1454 the target node, the value of the nonce that will be used next time, 1455 and if no Binding Updates are lost in the network, the home agent and 1456 the target node can remain synchronized with respect to the nonces 1457 being used. If, however, the target node receives a Binding Update 1458 with what it believes to be an incorrect nonce, it may resynchronize 1459 with the home agent by requesting the mobile node's binding using a 1460 Binding Request message. 1462 9.3. Receiving Binding Request Messages 1464 When the home agent receives a Binding Request message, it consults 1465 its home list and determines the correct binding information to be 1466 sent to the requesting node. Before satisfying the request, the 1467 home agent MUST check whether or not the mobile node has allowed 1468 the information to be disseminated. If the mobile node specified 1469 the Private (P) bit in its Registration Request message, then the 1470 home agent MUST not satisfy any Binding Requests. In this case, 1471 the home agent SHOULD return a Binding Update in which both the 1472 Care-of Address is set equal to the mobile node's home address and 1473 the Lifetime is set to zero. Such a Binding Update message indicates 1474 that the binding cache entry for the specified mobile node should be 1475 deleted. 1477 9.4. Receiving Registration Key Requests 1479 When the home agent receives a Registration Request message, a 1480 Registration Key Request extension (Section 5.3) may be present in 1481 the message, requesting the home agent to provide a registration 1482 key to the mobile node and its foreign agent, as described in 1483 Section 3.2. In that event, the home agent employs a good algorithm 1484 for producing random keys [4] and encrypts the result separately for 1485 use by the foreign agent and by the mobile node. The chosen key is 1486 encrypted under the mobility security association shared between the 1487 home agent and the mobile node, and the encrypted key is placed in 1488 a Home-Mobile Registration Key Reply extension (Section 5.4) in the 1489 Registration Reply message. The same key also is encrypted under 1490 the mobility security association shared between the home agent and 1491 the foreign agent, and the encrypted key is placed in a Home-Foreign 1492 Registration Key Reply extension (Section 5.5) in the Registration 1493 Reply message. 1495 If the home agent receives a Registration Key Request extension in 1496 a Registration Request message, but it does not have an established 1497 mobility security association with the foreign agent with which 1498 the mobile node is registering, the home agent MUST reject the 1499 registration attempt. In this case, the home agent returns a 1500 Registration Reply message indicating that the foreign agent failed 1501 authentication. 1503 9.5. Receiving Special Tunnels 1505 The home agent may also receive datagrams tunneled to the mobile 1506 node using a special tunnel (Section 8.3), which it has intercepted 1507 for the mobile node in the same way as any datagram destined to the 1508 mobile node while the mobile node is away from home. The home agent 1509 MUST examine the tunnel source address (the "outer" address of the 1510 tunneled datagram). If the tunnel source address differs from the 1511 care-of address shown in the home list entry for the mobile node, 1512 the home agent SHOULD decapsulate the inner datagram from the tunnel 1513 and re-tunnel it to the mobile node's care-of address. However, if 1514 the tunnel source address is the same as the mobile node's care-of 1515 address, the home agent MUST NOT tunnel the datagram back to that 1516 same node; the home agent SHOULD instead discard the datagram. 1518 In either case, the home agent SHOULD also send a Binding Update 1519 message to the sender of the original datagram (the "inner" source 1520 address of the tunneled datagram), if it shares a mobility security 1521 association with this node. The sending of this Binding Update 1522 message, though, is subject to the rate limiting restriction 1523 described in Section 9.1. 1525 10. Foreign Agent Considerations 1527 In addition to managing the resources needed to handle registrations 1528 in the base Mobile IP protocol, a foreign agent participating in 1529 Route Optimization assumes two additional responsibilities. It 1530 SHOULD maintain a binding cache for forwarding datagrams to mobile 1531 nodes once they have moved to new care-of addresses, and it SHOULD 1532 support the use of a Binding Update message for notifying a mobile 1533 node's previous foreign agent that it has moved. 1535 10.1. Establishing a Registration Key 1537 As part of the registration procedure, a mobile node and its 1538 new foreign agent can establish a registration key (Sections 7.1 1539 and 7.2). Within this document, the registration key is used only 1540 for authentication of a single Binding Update message. Other uses 1541 for the registration key are possible, such as the use of this key to 1542 provide privacy along the wireless link connecting between the mobile 1543 node and its foreign agent; such additional uses of the registration 1544 key are outside the scope of this discussion. 1546 This document specifies two alternative methods for establishing 1547 a registration key as part of a mobile node's registration with a 1548 foreign agent. 1550 The foreign agent may receive a Registration Key Request extension 1551 in the mobile node's Registration Request message (Section 7.1). 1552 The foreign agent need not process the Registration Key Request 1553 extension. When the Registration Reply is received by the 1554 foreign agent from the home agent, it MAY contain a Home-Foreign 1555 Registration Key Reply extension and a Home-Mobile Registration 1556 Key Reply extension. In this case, the foreign agent removes the 1557 Home-Foreign Registration Key Reply extension, and forwards the 1558 rest of the Registration Reply message to the mobile node. The 1559 Home-Foreign Registration Key Reply extension is covered by its own 1560 authentication, not by the authentication covering the Registration 1561 Reply message itself, and thus removing the Home-Foreign Registration 1562 Key Reply extension does not interfere with the mobile node's ability 1563 to verify the authentication on the Registration Reply message. 1564 The foreign agent decrypts the supplied registration key using the 1565 mobility security association it shares with the home agent, and 1566 stores the key as part of the visitor list entry created for the 1567 mobile node for this registration. 1569 Alternatively, the foreign agent may receive a Diffie-Hellman 1570 Registration Key Request extension in the mobile node's Registration 1571 Request message (Section 7.2). The extension contains the Prime 1572 and Generator values, chosen by the mobile node, to be used for 1573 this execution of the Diffie-Hellman algorithm. The foreign agent 1574 chooses its own private random number and returns the Diffie-Hellman 1575 Computed Value when it sends the Registration Reply message sent to 1576 the mobile node. The foreign agent uses Prime and Generator values 1577 and the Computed Value from the mobile node that it received in the 1578 Diffie-Hellman Registration Key Request extension, together with its 1579 own chosen private random number, to form the registration key. The 1580 foreign agent stores this registration key as part of the visitor 1581 list entry created for the mobile node for this registration. 1583 Establishing the registration key in effect establishes a mobility 1584 security association between the mobile node and the foreign agent. 1585 After the mobile node moves to a new care-of address, this mobility 1586 security association is used for authenticating the Binding Update 1587 message from the mobile node notifying this foreign agent of its 1588 movement. 1590 10.2. Previous Foreign Agent Notification 1592 When a mobile node registers with a new foreign agent, the mobile 1593 node MAY request its new foreign agent to notify its previous foreign 1594 agent that it has moved. The mobile node includes a Previous Foreign 1595 Agent Notification extension in its Registration Request message to 1596 the foreign agent, requesting that the foreign agent send a Binding 1597 Update message to its previous foreign agent. As with all Binding 1598 Update messages, this Binding Update must be authenticated using the 1599 Route Optimization Authentication extension (Section 5.2). 1601 The foreign agent assembles the Binding Update message using 1602 the fields in the Registration Request message (including the 1603 Authenticator supplied in the Previous Foreign Agent Notification 1604 extension) and sends it to the previous foreign agent identified in 1605 the extension. The Acknowledge (A) bit MUST be set in this Binding 1606 Update message. 1608 When the previous foreign agent receives the Binding Update, it will 1609 authenticate the message using the mobility security association 1610 set up with the registration key established with the mobile node 1611 during its registration with this mobile node. If the message 1612 authentication is correct, the visitor list entry for this mobile 1613 node at the previous foreign agent will be deleted and a Binding 1614 Acknowledge message returned to the sender. In addition, if a new 1615 care-of address was included in the Binding Update message, the 1616 previous foreign agent will create a binding cache entry for the 1617 mobile node; the previous foreign agent can then tunnel datagrams to 1618 the mobile node's new care-of address using that binding cache, just 1619 as any node maintaining a binding cache. 1621 In particular, the previous foreign agent can tunnel the Binding 1622 Acknowledge message back to the new care-of address specified in 1623 the received binding. This creates an interesting problem for the 1624 new foreign agent when it receives the acknowledgment before the 1625 registration reply from the home agent. It is suggested that the new 1626 foreign agent deliver the acknowledgment to the mobile node anyway, 1627 even though the mobile node is technically unregistered. If there 1628 is concern that this provides a loophole for unauthorized traffic 1629 to the mobile node, the new foreign agent could limit the number of 1630 datagrams delivered to the unregistered mobile node to this single 1631 instance. Alternatively, a new extension to the Registration Reply 1632 message can be defined to carry along the acknowledgement from the 1633 previous foreign agent. This latter approach would have the benefit 1634 that fewer datagrams would be transmitted over bandwidth-constrained 1635 wireless media during registrations. 1637 The registration key established with this previous foreign agent is 1638 destroyed as a part of the processing of this Binding Update message. 1639 Since the previous foreign agent deletes the visitor list entry for 1640 the mobile node, it also deletes its record of the registration key. 1641 A registration key is thus useful only for the notification to the 1642 previous foreign agent after moving to a new care-of address. No 1643 subsequent use of this registration key is possible, and thus no 1644 reply protection is necessary for the Binding Update message used for 1645 this notification. 1647 10.3. Receiving Tunneled Datagrams 1649 When a foreign agent receives a datagram tunneled to itself, it 1650 examines its visitor list for an entry for the destination mobile 1651 node, as in the base Mobile IP protocol. If a visitor list entry is 1652 found, the foreign agent delivers the datagram to the mobile node. 1654 However, if no visitor list entry is found, the foreign agent 1655 examines its binding cache for a cache entry for the destination 1656 mobile node. If one is found, the foreign agent re-tunnels the new 1657 care-of address indicated in the binding cache entry. In this case, 1658 the foreign agent also may deduce that the sender of the datagram has 1659 an out-of-date binding cache entry for this mobile node, since it 1660 otherwise would have tunneled the datagram directly to the correct 1661 new care-of address itself. The foreign agent SHOULD then send a 1662 Binding Warning message to the mobile node's home agent, which it 1663 learned in the Binding Update message from which this binding cache 1664 entry was created. 1666 10.4. Rate Limiting 1668 A foreign agent MUST provide some mechanism to limit the rate at 1669 which it sends Binding Warning messages to to the same node about any 1670 given mobility binding. This rate limiting is especially important 1671 because it is expected that, within the short term, many Internet 1672 nodes will not support maintenance of a binding cache. In this 1673 case, continual transmissions of Binding Warning messages to such 1674 a correspondent node will only add unnecessary overhead to at the 1675 foreign agent and correspondent node, and along the Internet path 1676 between these nodes. 1678 10.5. Sending Special Tunnels 1680 If a foreign agent receives a tunneled datagram for a mobile node 1681 for which it has no visitor list entry or binding cache entry, the 1682 foreign agent MAY forward the datagram to the mobile node's home 1683 agent by sending it as a special tunnel (Section 3.2). The home 1684 agent will intercept the special tunnel datagram addressed to the 1685 mobile node in the same way as any datagram for the mobile node while 1686 it is away from home. 1688 11. Mobile Node Considerations 1690 11.1. Establishing a Registration Key 1692 When a mobile node sends a Registration Request message, it can also 1693 request a registration key to be established between itself and the 1694 new foreign agent. The key may be used later to authenticate the 1695 Binding Update sent to this foreign agent to notify it that the 1696 mobile node has moved to a new care-of address. 1698 The mobile node may include a Registration Key Request extension in 1699 its Registration Request message to request its home agent to act as 1700 a "key distribution center" (KDC) for establishing a registration key 1701 with its new foreign agent (Section 7.1). The home agent chooses a 1702 new key and returns encrypted copies of it for the foreign agent and 1703 the mobile node. The mobile node receives its copy of the new key in 1704 the Home-Mobile Registration Key Reply extension in the Registration 1705 Reply extension. The mobile node decrypts the key using the mobility 1706 security association it shares with its home agent, and stores the 1707 key for later use in notifying this foreign agent that it has moved 1708 to a new care-of address. 1710 Alternatively, the mobile node may include a Diffie-Hellman 1711 Registration Key Request extension in its Registration Request 1712 message to request its new foreign agent to participate in the 1713 Diffie-Hellman key exchange algorithm with it. The mobile node 1714 chooses a private random number and includes the Prime and Generator 1715 values to be used in this execution of the Diffie-Hellman algorithm, 1716 together with the Computed Value based on its chosen private random 1717 number, in the Diffie-Hellman Registration Request extension. The 1718 foreign agent chooses its own private random number, and returns the 1719 Computed Value based on this number in a Diffie-Hellman Registration 1720 Key Reply extension in the Registration Reply that it returns to the 1721 mobile node. The mobile node forms the registration key according to 1722 the Diffie-Hellman algorithm and stores it for later use in notifying 1723 this foreign agent that it has moved to a new care-of address. 1725 11.2. Notifying Previous Foreign Agents 1727 During registration with a new foreign agent, a mobile node may 1728 request its new foreign agent to notify its previous foreign agent 1729 that it has moved. The new foreign agent sends a Binding Update 1730 message to the previous foreign agent on behalf of the mobile node. 1732 To novity its previous foreign agent as part of the new registration, 1733 the mobile node includes a Previous Foreign Agent Notification 1734 extension (Section 5.1) in its Registration Request message. The 1735 extension contains only those values needed by the new foreign 1736 agent to construct the Binding Update message that are not already 1737 included in the Registration Request message. In particular, the 1738 new foreign agent only sends the Binding Update message on behalf of 1739 the mobile node. The mobile node computes the correct Authenticator 1740 value for the Binding Update message, based on the registration key 1741 it established with its previous foreign agent, and includes this 1742 Authenticator value in the extension for inclusion in the Binding 1743 Update message by the new foreign agent. The new foreign agent does 1744 not learn the previous foreign agent registration key during the new 1745 registration or notification. 1747 When the Binding Acknowledgment message from the previous foreign 1748 agent is received by the new foreign agent, it detunnels it and sends 1749 it to the mobile node. In this way, the mobile node can discover 1750 that its previous foreign agent has received the Binding Update 1751 message. This is important, because otherwise the previous foreign 1752 agent would often become a "black hole" for datagrams destined for 1753 the mobile node based on out-of-date binding cache entries at other 1754 nodes. The new foreign agent has no further responsibility for 1755 helping to update the binding cache at the previous foreign agent. 1757 The mobile node expects to eventually receive a Binding 1758 Acknowledgement message from its previous foreign agent, signifying 1759 that the Binding Update message was received. If the acknowledgement 1760 has not been received after sufficient time, the mobile node is 1761 responsible for retransmitting another Binding Update message to its 1762 previous foreign agent. Although the previous foreign agent may 1763 have already received and processed the Binding Update message (the 1764 Binding Acknowledge message may have been lost in transit to the new 1765 foreign agent), the mobile node should continue to retransmit its 1766 Binding Update message until the previous foreign agent responds with 1767 a Binding Acknowledgement. 1769 References 1771 [1] CDPD Consortium. Cellular Digital Packet Data system 1772 specification. Release 1.0, July 1993. 1774 [2] W. Diffie and M. E. Hellman. New directions in cryptography. 1775 IEEE Transactions on Information Theory, IT-22(6):644--654, 1776 November 1976. 1778 [3] Ralph Droms. Dynamic Host Configuration Protocol. RFC 1541, 1779 October 1993. 1781 [4] Donald E. Eastlake 3rd, Stephen D. Crocker, and Jeffrey I. 1782 Schiller. Randomness recommendations for security. RFC 1750, 1783 December 1994. 1785 [5] Stan Hanks, Tony Li, Dino Farinacci, and Paul Traina. Generic 1786 Routing Encapsulation (GRE). RFC 1701, October 1994. 1788 [6] David B. Johnson and Charles Perkins, editors. Mobility support 1789 in IPv6. Internet Draft, draft-ietf-mobileip-ipv6-02.txt, 1790 November 1996. Work in progress. 1792 [7] Charles Perkins, editor. IP mobility support. RFC 2002, October 1793 1996. 1795 [8] RSA Laboratories. RSAREF(TM) 2.0: A free cryptographic toolkit, 1796 April 1994. 1798 Appendix A. Using a Master Key at the Home Agent 1800 Rather than storing each mobility security association that it has 1801 established with many different correspondent nodes and foreign 1802 agents, a home agent may manage its mobility security associations so 1803 that each of them can be generated from a single "master" key. With 1804 the master key, the home agent could build a key for any given other 1805 node by computing the node-specific key as 1807 MD5(node-address || master-key || node-address) 1809 where node-address is the IP address of the particular node for which 1810 the home agent is building a key, and master-key is the single master 1811 key held by the home agent for all mobility security associations it 1812 has established with correspondent nodes. The node-specific key is 1813 built by computing an MD5 hash over a string consisting of the master 1814 key with the node-address concatenated as a prefix and as a suffix. 1816 Using this scheme, when establishing each mobility security 1817 association, the network administrator managing the home agent 1818 computes the node-specific key and communicates this key to the 1819 network administrator of the other node through some "secure" 1820 channel, such as over the telephone. The mobility security 1821 association is configured at this other node in the same way as any 1822 mobility security association. At the home agent, though, no record 1823 need be kept that this key has been given out. The home agent need 1824 only be configured to know that this scheme is in use for all of its 1825 mobility security associations (perhaps only for specific set of its 1826 mobile nodes). 1828 When the home agent then needs a mobility security association as 1829 part of Route Optimization, it builds the node-specific key based on 1830 the master key and the IP address of the other node with which it 1831 is attempting to authenticate. If the other node knows the correct 1832 node-specific key, the authentication will succeed; otherwise, it 1833 will fail as it should. 1835 Chairs' Addresses 1837 The working group can be contacted via the current chairs: 1839 Jim Solomon 1840 Motorola, Inc. 1841 1301 E. Algonquin Rd. 1842 Schaumburg, IL 60196 1843 USA 1845 Phone: +1 847 576-2753 1846 E-mail: solomon@comm.mot.com 1848 Erik Nordmark 1849 Sun Microsystems, Inc. 1850 2550 Garcia Avenue 1851 Mt. View, CA 94041 1852 USA 1854 Phone: +1 415 786-5166 1855 Fax: +1 415 786-5896 1856 E-mail: nordmark@sun.com 1858 Authors' Addresses 1860 Questions about this document can also be directed to the authors: 1862 David B. Johnson 1863 Carnegie Mellon University 1864 Computer Science Department 1865 5000 Forbes Avenue 1866 Pittsburgh, PA 15213-3891 1867 USA 1869 Phone: +1 412 268-7399 1870 Fax: +1 412 268-5576 1871 E-mail: dbj@cs.cmu.edu 1873 Charles Perkins 1874 IBM Corporation 1875 T. J. Watson Research Center 1876 Room H3-D34 1877 30 Saw Mill River Rd. 1878 Hawthorne, NY 10532 1879 USA 1881 Phone: +1 914 789-7350 1882 Fax: +1 914 784-6205 1883 E-mail: perk@watson.ibm.com