idnits 2.17.1 draft-ietf-mobileip-optim-01.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-20) 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 332: '...ode. In this case, the home agent MAY...' RFC 2119 keyword, line 346: '... case, this node MAY send a Binding Wa...' RFC 2119 keyword, line 365: '..., the home agent SHOULD set this lifet...' RFC 2119 keyword, line 399: '... mobile node, it MAY send a Binding Wa...' RFC 2119 keyword, line 465: '...ity binding. It MAY be sent by the mo...' (7 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1541 (ref. '1') (Obsoleted by RFC 2131) ** Obsolete normative reference: RFC 1750 (ref. '2') (Obsoleted by RFC 4086) == Outdated reference: A later version (-17) exists of draft-ietf-mobileip-protocol-08 Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group David B. Johnson 2 INTERNET DRAFT Carnegie Mellon University 3 15 March 1995 Charles Perkins 4 IBM Corporation 5 Andrew Myles 6 Macquarie University 8 Route Optimization in Mobile IP 10 draft-ietf-mobileip-optim-01.txt 12 Abstract 14 This document defines extensions to the operation of the basic 15 Mobile IP protocol to allow for optimization of datagram routing from 16 a correspondent node to a mobile node. Without Route Optimization, 17 all datagrams destined to a mobile node are routed through that 18 mobile node's home agent, which then tunnels each datagram to the 19 mobile node's current location. The protocol extensions described 20 here provide a means for correspondent nodes that implement them to 21 cache the location of a mobile node and to then tunnel their own 22 datagrams for the mobile node directly to that location, bypassing 23 the possibly lengthy route for each datagram to and from the mobile 24 node's home agent. Extensions are also provided to allow datagrams 25 in flight when a mobile node moves, and datagrams sent based on an 26 out-of-date cached location, to be forwarded directly to the mobile 27 node's new location. 29 Status of This Memo 31 This document is a product of the Mobile IP Working Group of the 32 Internet Engineering Task Force (IETF). Comments should be submitted 33 to working group mailing list at mobile-ip@tadpole.com. Distribution 34 of this memo is unlimited. 36 This document is an Internet-Draft. Internet-Drafts are working 37 documents of the Internet Engineering Task Force (IETF), its areas, 38 and its working groups. Note that other groups may also distribute 39 working documents as Internet-Drafts. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at 43 any time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress". 46 To learn the current status of any Internet-Draft, please check 47 the "1id-abstracts.txt" listing contained in the Internet- Drafts 48 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 49 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 50 ftp.isi.edu (US West Coast). 52 Contents 54 Abstract i 56 Status of This Memo i 58 1. Introduction 1 60 2. Route Optimization Overview 3 61 2.1. Location Caching . . . . . . . . . . . . . . . . . . . . 3 62 2.2. Foreign Agent Handoff . . . . . . . . . . . . . . . . . . 3 63 2.3. Location Cache Updates . . . . . . . . . . . . . . . . . 6 65 3. Route Optimization Message Formats 8 66 3.1. Binding Warning Message . . . . . . . . . . . . . . . . . 9 67 3.2. Binding Request Message . . . . . . . . . . . . . . . . . 10 68 3.3. Binding Update Message . . . . . . . . . . . . . . . . . 11 69 3.4. Binding Acknowledge Message . . . . . . . . . . . . . . . 13 71 4. Route Optimization Extension Formats 14 72 4.1. Previous Foreign Agent Notification Extension . . . . . . 15 73 4.2. Route Optimization Authentication Extension . . . . . . . 17 74 4.3. Registration Key Request Extension . . . . . . . . . . . 18 75 4.4. Mobile Node Registration Key Extension . . . . . . . . . 19 76 4.5. Foreign Agent Registration Key Extension . . . . . . . . 20 77 4.6. Foreign Agent Public Key Extension . . . . . . . . . . . 21 79 5. Mobility Security Association Management 22 80 5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 22 81 5.2. Mobility Security Associations . . . . . . . . . . . . . 23 83 6. Location Cache Considerations 24 84 6.1. Cache Management . . . . . . . . . . . . . . . . . . . . 24 85 6.2. Receiving Binding Warning Messages . . . . . . . . . . . 24 86 6.3. Receiving Binding Update Messages . . . . . . . . . . . . 25 87 6.4. Using Special Tunnels . . . . . . . . . . . . . . . . . . 25 89 7. Home Agent Considerations 26 90 7.1. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . 26 91 7.2. Receiving Binding Request Messages . . . . . . . . . . . 26 92 7.3. Receiving Registration Key requests . . . . . . . . . . . 27 93 7.4. Receiving Special Tunnels . . . . . . . . . . . . . . . . 27 95 8. Foreign Agent Considerations 28 96 8.1. Setting up Temporary Mobility Security Associations . . . 28 97 8.2. Previous Foreign Agent Notification . . . . . . . . . . . 29 98 8.3. Receiving Tunneled Datagrams . . . . . . . . . . . . . . 30 99 8.4. Sending Special Tunnels . . . . . . . . . . . . . . . . . 30 101 9. Mobile Node Considerations 31 102 9.1. Requesting a Registration Key . . . . . . . . . . . . . . 31 103 9.2. Notifying Previous Foreign Agents . . . . . . . . . . . . 31 105 References 33 107 Appendix A. Using a Master Key at the Home Agent 34 109 Chairs' Addresses 35 111 Authors' Addresses 36 112 1. Introduction 114 The basic Mobile IP protocol [3] allows any mobile node to move 115 about, changing its point of attachment to the Internet, while 116 continuing to be addressed by its home IP address. Correspondent 117 nodes sending IP datagrams to a mobile node address them to the 118 mobile node's home address in the same way as to any destination. 120 While the mobile node is connected to the Internet away from its 121 home network, it is served by a "home agent" on its home network 122 and is associated with a "care-of address" indicating its current 123 location. The association between a mobile node's home address and 124 its care-of address is known as a "mobility binding". The care-of 125 address is generally the address of a "foreign agent" on the network 126 being visited by the mobile node, which forwards arriving datagrams 127 locally to the mobile node. Alternatively, the care-of address may 128 be temporarily assigned to the mobile node using DHCP [1] or other 129 means. All IP datagrams addressed to the mobile node are routed by 130 the normal IP routing mechanisms to the mobile node's home network, 131 where they are intercepted by the mobile node's home agent, which 132 then tunnels each datagram to the mobile node's current care-of 133 address. Datagrams sent by a mobile node use the foreign agent as a 134 default router but require no other special handling or routing. 136 This basic scheme allows transparent interoperation with mobile 137 nodes, but forces all datagrams for a mobile node to be routed 138 through its home agent; packets to the mobile node are often routed 139 along paths that are significantly longer than optimal. For example, 140 if a mobile node, say MN1, is visiting some subnet, even datagrams 141 from a correspondent node on this same subnet must be routed through 142 the Internet to MN1's home agent on MN1's home network, only to then 143 be tunneled back to the original subnet to MN1's foreign agent for 144 delivery to MN1. This indirect routing can significantly delay the 145 delivery of the datagram to MN1 and places an unnecessary burden on 146 the networks and routers along this path through the Internet. If 147 the correspondent node in this example is actually another mobile 148 node, say MN2, then datagrams from MN1 to MN2 must likewise be routed 149 through MN2's home agent on MN2's home network and back to the 150 original subnet for delivery to MN1. 152 This document defines extensions to the basic Mobile IP protocol to 153 allow for the optimization of datagram routing from a correspondent 154 node to a mobile node. These extensions provide a means for nodes 155 that implement them to cache the care-of address of a mobile node 156 and to then tunnel their own datagrams directly there, bypassing the 157 possibly lengthy route to and from that mobile node's home agent. 158 Extensions are also provided to allow datagrams in flight when a 159 mobile node moves, and datagrams sent based on an out-of-date cached 160 care-of address, to be forwarded directly to the mobile node's new 161 care-of address. These extensions are collectively referred to as 162 Route Optimization in this document. 164 All operation of Route Optimization that changes the routing of IP 165 datagrams to the mobile node is authenticated using the same type of 166 authentication mechanism used in the basic Mobile IP protocol. This 167 authentication generally relies on a "mobility security association" 168 established in advance between the node sending a message and the 169 node receiving the message that must authenticate it. When the 170 required mobility security association has not been established, a 171 Mobile IP implementation using Route Optimization operates in the 172 same way as the basic Mobile IP protocol. 174 Section 2 of this document provides an overview of the operation of 175 Route Optimization. Section 3 defines the message types used by 176 Route Optimization, and Section 4 defines the message extensions 177 used. Section 5 discusses the problem of managing the mobility 178 security associations needed to provide authentication of all 179 messages that affect the routing of datagrams to a mobile node. 180 The final four sections of this document define in detail the 181 operation of Route Optimization from the point of view of each of the 182 entities involved: considerations for nodes maintaining a location 183 cache are presented in Section 6, mobile node considerations in 184 Section 9, foreign agent considerations in Section 8, and home agent 185 considerations in Section 7. 187 2. Route Optimization Overview 189 2.1. Location Caching 191 Route Optimization provides a means for any node that wishes to 192 optimize its own communication with mobile nodes to maintain a 193 "location cache" containing the mobility binding of one or more 194 mobile nodes. When sending an IP datagram to a mobile node, if the 195 sender has a location cache entry for the destination mobile node, it 196 may tunnel the datagram directly to the care-of address indicated in 197 the cached mobility binding. 199 In the absence of any location cache entry, datagrams destined for 200 a mobile node will be routed to the mobile node's home network in 201 the same way as any other IP datagram, and are then tunneled to the 202 mobile node's current care-of address by the mobile node's home 203 agent. This is the only routing mechanism supported by the basic 204 Mobile IP protocol. With Route Optimization, as a side effect of 205 this indirect routing of a datagram to a mobile node, the original 206 sender of the datagram may be informed of the mobile node's current 207 mobility binding, giving the sender an opportunity to cache the 208 binding. 210 A node may create a location cache entry for a mobile node only when 211 it has received and authenticated the mobile node's mobility binding. 212 Likewise, a node may update an existing location cache entry for a 213 mobile node, such as after the mobile node has moved to a new foreign 214 agent, only when it has received and authenticated the mobile node's 215 new mobility binding. 217 A location cache will, by necessity, have a finite size. Any node 218 implementing a location cache may manage the space in its cache 219 using any local cache replacement policy. If a datagram is sent 220 to a destination for which the cache entry has been dropped from 221 the cache, the datagram will be routed normally through the mobile 222 node's home network and will be tunneled to the mobile node's care-of 223 address by its home agent. This indirect routing to the mobile node 224 will result in the original sender of the datagram being informed of 225 the mobile node's current mobility binding, allowing it to add this 226 entry again to its location cache. 228 2.2. Foreign Agent Handoff 230 When a mobile node moves and registers with a new foreign agent, the 231 basic Mobile IP protocol does not notify the mobile node's previous 232 foreign agent. IP datagrams intercepted by the home agent after 233 the new registration are tunneled to the mobile node's new care-of 234 address, but datagrams in flight that had already been intercepted 235 by the home agent and tunneled to the old care-of address when the 236 mobile node moved are lost and are assumed to be retransmitted by 237 higher-level protocols if neeeded. The old foreign agent eventually 238 deletes the mobile node's registration after the expiration of the 239 lifetime period established when the mobile node registered there. 241 Route Optimization provides a means for the mobile node's previous 242 foreign agent to be reliably notified of the mobile node's new 243 mobility binding, allowing datagrams in flight to the mobile 244 node's previous foreign agent to be forwarded to its new care-of 245 address. This notification also allows any datagrams tunneled to the 246 mobile node's previous foreign agent from correspondent nodes with 247 out-of-date location cache entries for the mobile node (that have not 248 yet learned that the mobile node has moved), to be forwarded to its 249 new care-of address. Finally, this notification allows any resources 250 consumed by the mobile node's binding at the previous foreign agent 251 (such as radio channel reservations) to be released immediately, 252 rather than waiting for the mobile node's registration to expire. 254 During registration with a new foreign agent, the mobile node and the 255 new foreign agent may establish a "registration key", which acts as a 256 session key for this registration. When a Registration Key Request 257 extension is included in the Registration Request message to the 258 mobile node's home agent, the home agent may choose a registration 259 key and include it in its Registration Reply message. The home agent 260 includes a Mobile Node Registration Key extension, containing a copy 261 of the chosen key encrypted under a key and algorithm shared between 262 the home agent and the mobile node, and a Foreign Agent Registration 263 Key extension, containing a copy of the same key encrypted under 264 a key and algorithm shared between the home agent and the foreign 265 agent. In order for the registration key to be established, the 266 foreign agent must have a mobility security association with the home 267 agent. This security association may either be preestablished or may 268 be established for purposes of this registration through exchange of 269 the foreign agent's public encryption key in the Agent Advertisement 270 and Registration Request messages. The registration key for a mobile 271 node can be stored by the foreign agent with the mobile node's 272 visitor list entry. 274 When a mobile node registers with a new foreign agent, if it 275 established a registration key during registration with its previous 276 foreign agent, it may use this key to notify the previous foreign 277 agent that it has moved. This notification may also optionally 278 include the mobile node's new care-of address, allowing the previous 279 foreign agent to create a location cache entry for the mobile node to 280 serve as a "forwarding pointer" to its new location. Any tunneled 281 datagrams for the mobile node that arrive at this previous foreign 282 agent after this location cache entry has been created will then be 283 re-tunneled by this foreign agent to the mobile node's new location 284 using the mobility binding in this location cache entry. The 285 registration key is used to authenticate the notification sent to the 286 previous foreign agent. 288 As part of the registration procedure, the mobile node may 289 request that its new foreign agent attempt to notify its previous 290 foreign agent on its behalf, by including a Previous Foreign Agent 291 Notification extension in its Registration Request message sent to 292 the new foreign agent. The new foreign agent then builds a Binding 293 Update message and transmits it to the mobile node's previous foreign 294 agent as part of registration, requesting an acknowledgement from 295 the previous foreign agent. The Previous Foreign Agent Notification 296 extension includes only those values needed to construct the Binding 297 Update message that are not already contained in the Registration 298 Request message. The authenticator for the Binding Update message is 299 computed by the mobile node based on its registration key shared with 300 its previous foreign agent. 302 The mobile node is responsible for occasionally retransmitting a 303 Binding Update message to its previous foreign agent until the 304 matching Binding Acknowledge message is received, or until the mobile 305 node can be sure of the expiration of its registration with that 306 foreign agent. 308 The location cache entry created at the mobile node's previous 309 foreign agent is treated in the same way as any other location cache 310 entry. In particular, it is possible that this location cache 311 entry will be deleted from the cache at any time. In this case, 312 the foreign agent will be unable to re-tunnel subsequently arriving 313 tunneled datagrams for the mobile node directly to its new location. 314 Suppose a node (for instance, such a previous foreign agent) receives 315 a datagram that has been tunneled to this node, but this node is 316 unable to deliver the datagram locally to the destination mobile node 317 (the node is not the mobile node itself, and it is not a foreign 318 agent with a visitor list entry for the mobile node). To attempt 319 delivery of the datagram in this case, the node must encapsulate 320 the datagram as a "special tunnel" datagram (Section 8.4), destined 321 to the mobile node. Otherwise, the datagram would eventually reach 322 the mobile node's home network, be intercepted by the mobile node's 323 home agent, and be tunneled to the mobile node's current care-of 324 address. If the home agent were to tunnel the datagram back to the 325 same foreign agent, a loop would be created. 327 2.3. Location Cache Updates 329 When a mobile node's home agent intercepts a datagram from the home 330 network and tunnels it to the mobile node, the home agent may deduce 331 that the original sender of the datagram has no location cache entry 332 for the destination mobile node. In this case, the home agent MAY 333 send a Binding Update message to the sender, informing it of the 334 mobile node's current mobility binding. No acknowledgement for this 335 Binding Update message is needed, since additional future datagrams 336 from this sender intercepted by the home agent for the mobile node 337 will cause transmission of another update. In order for this Binding 338 Update to be authenticated by the sender of the datagram, the home 339 agent and the sender must have established a mobility security 340 association. 342 Similarly, when any node receives a tunneled datagram tunneled 343 to this node, if it is not the current foreign agent serving the 344 destination as a mobile node the source of the tunneled datagram 345 probably has an out-of-date location cache entry for the destination 346 mobile node. In this case, this node MAY send a Binding Warning 347 message to the originator of the tunneled datagram. As above, no 348 acknowledgement of this Binding Warning is needed. 350 Unlike the Binding Update message, though, no authentication of the 351 Binding Warning message is necessary, since it does not directly 352 affect the routing of IP datagrams to the mobile node. Instead, when 353 a node receives a Binding Warning message, that node sends a Binding 354 Request message to the indicated mobile node's home agent, requesting 355 the mobile node's current mobility binding. The home agent then 356 answers this Binding Request message with a Binding Update message, 357 and when the Binding Update message is received, the node may then 358 create a location cache entry for the mobile node. In order for this 359 node and the home agent to exchange these Binding Request and Binding 360 Update messages, they must have established a mobility security 361 association. 363 Each Binding Update message indicates the maximum lifetime of any 364 location cache entry created from the Binding Update. When sending 365 the Binding Update message, the home agent SHOULD set this lifetime 366 to the remaining service lifetime associated with the mobile node's 367 current registration. Any location cache entry established or 368 updated in response to this Binding Update message must be marked 369 to be deleted after the expiration of this period. A node wanting 370 to provide continued service with a particular location cache entry 371 may attempt to reconfirm that mobility binding before the expiration 372 of this lifetime period. Location cache entry reconfirmation 373 may be appropriate when the node has indications (such as an open 374 transport-level connection to the mobile node) that the location 375 cache entry is still needed. This reconfirmation is performed by 376 the node sending a Binding Request message to the mobile node's home 377 agent, requesting it to reply with the mobile node's current mobility 378 binding in a new Binding Update message. 380 3. Route Optimization Message Formats 382 Route Optimization defines four message types used for management 383 of location cache entries. Each of these messages begins with a 384 one-octet field indicating the type of the message. 386 The following Type codes are defined in this document: 388 16 = Binding Warning message 389 17 = Binding Request message 390 18 = Binding Update message 391 19 = Binding Acknowledge message 393 3.1. Binding Warning Message 395 A Binding Warning message is used to advise a node that it appears 396 to have either no location cache entry or an out-of-date location 397 cache entry for some mobile node. When any node receives a datagram 398 tunneled to itself, if it is not the current foreign agent for the 399 destination mobile node, it MAY send a Binding Warning message to the 400 node that originated the tunneled datagram. 402 0 1 2 3 403 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 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Type | Reserved | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Mobile Node Home Address | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 Type 412 16 414 Reserved 416 Sent as 0; ignored on reception. 418 Mobile Node Home Address 420 The home address of the mobile node to which the Binding 421 Warning message refers. 423 3.2. Binding Request Message 425 A Binding Request message is used by a node to request a mobile 426 node's current mobility binding from the mobile node's home agent. 427 It is sent by a node upon receiving a Binding Warning message, or by 428 a node desiring to update the mobility binding in a location cache 429 entry that it holds for the mobile node. 431 0 1 2 3 432 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 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Type | Reserved | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | Mobile Node Home Address | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | | 439 + Identification + 440 | | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 Type 445 17 447 Reserved 449 Sent as 0; ignored on reception. 451 Mobile Node Home Address 453 The home address of the mobile node to which the Binding 454 Request refers. 456 Identification 458 A 64-bit sequence number, assigned by the node sending the 459 Binding Request message, used to assist in matching requests 460 with replies, and in protecting against replay attacks. 462 3.3. Binding Update Message 464 The Binding Update message is used to notify another node of a mobile 465 node's current mobility binding. It MAY be sent by the mobile node's 466 home agent in response to a Binding Request message. It MAY also 467 be sent by a mobile node, or by the foreign agent with which the 468 mobile node is registering, when notifying the mobile node's previous 469 foreign agent that the mobile node has moved. 471 0 1 2 3 472 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 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 | Type |A|I| Reserved | Lifetime | 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | Lifetime | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Mobile Node Home Address | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Care-of Address | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | | 483 + Identification + 484 | | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Extensions ... 487 +-+-+-+-+-+-+-+- 489 Type 491 18 493 Acknowledge (A) 495 The Acknowledge (A) bit is set by the node sending the Binding 496 Update message to request a Binding Acknowledge message be 497 returned acknowledging its receipt. 499 Identification Present (I) 501 The (I) bit is set by the node sending the Binding Update 502 message to indicate whether or not the Identification field is 503 present. 505 Reserved 507 Sent as 0; ignored on reception. 509 Lifetime 511 The number of seconds remaining before the location cache entry 512 must be considered expired. A value of all ones indicates 513 infinity. A value of zero indicates that no location cache 514 entry for the mobile node should be created, and any existing 515 location cache entry (and visitor list entry, in the case of 516 a mobile node's previous foreign agent) for the mobile node 517 should be deleted. The lifetime is typically equal to the 518 remaining lifetime of the mobile node's registration. 520 Mobile Node Home Address 522 The home address of the mobile node to which the Binding Update 523 message refers. 525 Care-of Address 527 The current care-of address of the mobile node. When set equal 528 to the home address of the mobile node, the Binding Update 529 message instead indicates that no location cache entry for the 530 mobile node should be created, and any existing location cache 531 entry (and visitor list entry, in the case of a mobile node's 532 previous foreign agent) for the mobile node should be deleted. 534 Identification 536 If present, a 64-bit number, assigned by the node sending the 537 Binding Request message, used to assist in matching requests 538 with replies, and in protecting against replay attacks. 540 The Route Optimization Authentication extension (Section 4.2) is 541 required. 543 3.4. Binding Acknowledge Message 545 A Binding Acknowledge message is used to acknowledge receipt of a 546 Binding Update message. It is sent by a node receiving the Binding 547 Update message, if the Acknowledge (A) bit is set in the Binding 548 Update message. 550 0 1 2 3 551 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 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | Type |N| Reserved | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | Mobile Node Home Address | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | | 558 + Identification + 559 | | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 Type 564 19 566 N 568 This bit is set if the acknowledgement is negative. For 569 instance, if the binding update was not accepted, but the 570 incoming datagram has the Acknowledge flag set, then the N bit 571 is set in this Binding Acknowledge message. 573 DISCUSSION: Alternatively, we could replace this bit with a 574 status code, as in the Registration Reply message. The mobile 575 node could log the error, but currently has no real way to 576 recover from it. 578 Reserved 580 Sent as 0; ignored on reception. 582 Mobile Node Home Address 584 Copied from the Binding Update message being acknowledged. 586 Identification 588 Copied from the Binding Update message being acknowledged, if 589 present there. 591 4. Route Optimization Extension Formats 593 Route Optimization defines the following Mobile IP message 594 extensions: 596 96 = Previous Foreign Agent Notification extension 597 97 = Route Optimization Authentication extension 598 98 = Registration Key Request extension 599 99 = Mobile Node Registration Key extension 600 100 = Foreign Agent Registration Key extension 601 101 = Foreign Agent Public Key extension 603 4.1. Previous Foreign Agent Notification Extension 605 The Previous Foreign Agent Notification Extension may be included in 606 a Registration Request message sent to a foreign agent. It requests 607 the new foreign agent to send a Binding Update message on behalf of 608 the mobile node, to the mobile node's previous foreign agent, to 609 notify it that the mobile node has moved. The previous foreign agent 610 deletes the mobile node's visitor list entry and creates a location 611 cache entry for the mobile node pointing to its new care-of address. 612 The extension contains only those values not otherwise already 613 contained in the Registration Request message, which are needed for 614 the new foreign agent to construct the Binding Update message. 616 0 1 2 3 617 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 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | Type | Length | Cache Lifetime | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | Previous Foreign Agent Address | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | Authenticator ... 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 Type 628 96 630 Length 632 6 plus the length of the Authenticator 634 Cache Lifetime 636 The number of seconds remaining before the location cache 637 entry created by the previous foreign agent must be considered 638 expired. A value of all ones indicates infinity. A value 639 of zero indicates that the previous foreign agent should not 640 create a location cache entry for the mobile node once it 641 has deleted the mobile node's visitor list entry. The Cache 642 Lifetime value is copied into the Lifetime field of the Binding 643 Update message. 645 Previous Foreign Agent Address 647 The IP address of the mobile node's previous foreign agent 648 to which the new foreign agent should send a Binding Update 649 message on behalf of the mobile node. 651 Authenticator 653 The authenticator value to be used in the Route Optimization 654 Authentication extension in the Binding Update message sent by 655 the new foreign agent to the mobile node's previous foreign 656 agent. This authenticator is calculated only over the Binding 657 Update message body. 659 4.2. Route Optimization Authentication Extension 661 The Route Optimization Authentication Extension is used to 662 authenticate certain Route Optimization management messages. 664 0 1 2 3 665 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 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | Type | Length | Authenticator ... 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 Type 672 97 674 Length 676 The length of the Authenticator 678 Authenticator 680 (variable length) A hash value taken over a stream of bytes 681 including the shared secret, all prior extensions in their 682 entirety, the the Route Optimization management data, and 683 the type and length of this extension, but not including the 684 Authenticator field itself. 686 4.3. Registration Key Request Extension 688 The Registration Key Request extension may be used on Registration 689 Request messages to request a registration key from the mobile 690 node's home agent. The extension is authenticated along with the 691 rest of the Registration Request message, and thus no additional 692 authenticator is included in the extension. In response to a 693 Registration Key Request extension, the home agent MAY include 694 a Mobile Node Registration Key extension and a Foreign Agent 695 Registration Key extension in its Registration Reply message, 696 containing encrypted copies of the registration key for the mobile 697 node the foreign agent. 699 0 1 2 3 700 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 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | Type | Length | Foreign Agent Public Key ... 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 Type 707 98 709 Length 711 The length of the Foreign Agent Public Key, or 0 if no Foreign 712 Agent Public Key is present 714 Foreign Agent Public Key 716 If the mobile node received a Foreign Agent Public Key 717 extension in the foreign agent's Agent Advertisement message, 718 this field is present and contains the key advertised in that 719 message, if the mobile node chooses to use the key. 721 The mobility security association assumed to exist between the home 722 agent and the mobile node will be used to encrypt the key unless a 723 Key Identification extension is also included with the Registration 724 Request message. The key returned by the home agent will be assumed, 725 by default, to be 128 bits long. 727 4.4. Mobile Node Registration Key Extension 729 The Mobile Node Registration Key extension may be used on 730 Registration Reply messages to send a registration key from the 731 mobile node's home agent to the mobile node. When used, the home 732 agent must also include a Foreign Agent Registration Key extension in 733 the Registration Reply message, giving a copy of the same key to the 734 mobile node's new foreign agent. The Mobile Node Registration Key 735 extension is authenticated along with the rest of the Registration 736 Reply message, and thus no additional authenticator is included in 737 the extension. 739 0 1 2 3 740 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 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | Type | Length | Mobile Node Encrypted Key ... 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 Type 747 99 749 Length 751 The length of the Mobile Node Encrypted Key 753 Mobile Node Encrypted Key 755 (variable length) The registration key, chosen by the home 756 agent, encrypted based on the mobility security association 757 between the home agent and the mobile node. The same key must 758 be sent, encrypted for the foreign agent in a Foreign Agent 759 Registration Key extension in this Registration Reply message. 761 4.5. Foreign Agent Registration Key Extension 763 The Foreign Agent Registration Key extension may be used on 764 Registration Reply messages to send a registration key from 765 the mobile node's home agent to the mobile node's new foreign 766 agent. When used, the home agent must also include a Mobile Node 767 Registration Key extension in the Registration Reply message, 768 giving a copy of the same key to the mobile node. The Foreign 769 Agent Registration Key extension is authenticated by including an 770 authenticator in the extension, computed based on the mobility 771 security association shared between the home agent and the foreign 772 agent. 774 0 1 2 3 775 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | Type | Length | Foreign Agent Encrypted Key ... 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | Authenticator ... 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 Type 784 100 786 Length 788 The length of the Foreign Agent Encrypted Key plus the length 789 of the Authenticator 791 Foreign Agent Encrypted Key 793 (variable length) The registration key, chosen by the home 794 agent, encrypted based on the mobility security association 795 between the home agent and the foreign agent, if one exists, or 796 based on the foreign agent public key from the Registration Key 797 Request message. The same key must be sent, encrypted for the 798 mobile node in a Mobile Node Registration Key extension in this 799 Registration Reply message. 801 Authenticator 803 (variable length) A hash value taken over a stream of bytes 804 including the shared secret and the fields in this extension 805 other than the Authenticator field itself. 807 4.6. Foreign Agent Public Key Extension 809 The Foreign Agent Public Key Extension MAY be included by a foreign 810 agent in the Agent Advertisement messages that it sends. The 811 extension advertises the foreign agent's public encryption key, to 812 allow mobile nodes to include the key in a Registration Key Request 813 extension to their Registration Request message. 815 0 1 2 3 816 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 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | Type | Length | Foreign Agent Public Key ... 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 Type 823 101 825 Length 827 The length of the Foreign Agent Public Key 829 Foreign Agent Public Key 831 The foreign agent's public encryption key 833 5. Mobility Security Association Management 835 5.1. Motivation 837 One of the most difficult aspects of Route Optimization for Mobile IP 838 in the Internet today is that of providing authentication for all 839 messages that affect the routing of datagrams to a mobile node. 840 In the basic Mobile IP protocol, all routing of datagrams to the 841 mobile node while away from its home network is controlled by the 842 home agent, since only the home agent is aware of the mobile node's 843 mobility binding and only the home agent tunnels datagrams to 844 the mobile node. Authentication is achieved based on a manually 845 established "mobility security association" between the home agent 846 and the mobile node. Since the home agent and the mobile node are 847 both owned by the same organization (both are assigned IP addresses 848 within the same IP subnet), this manual configuration is manageable, 849 and (for example) can be performed while the mobile node is at home. 851 With Route Optimization, though, there is a need in general to 852 authenticate messages between two nodes belonging to different 853 organizations, making establishment of a mobility security 854 association more difficult. Since no general authentication or key 855 distribution protocol is available in the Internet today, the Route 856 Optimization procedures defined in this document rely partially on 857 the same type of manually configured mobility security associations 858 used in the basic Mobile IP protocol. 860 For a correspondent node to be able to create a location cache entry 861 for a mobile node so that it can tunnel its own IP datagrams directly 862 to the mobile node at its current location, the correspondent node 863 and the mobile node's home agent must have established a mobility 864 security association. This mobility security association, though, 865 may be used in creating and updating location cache entries at 866 this correspondent node for all mobile nodes served by this home 867 agent. This places the correspondent node in a fairly natural 868 relationship with respect to the mobile nodes served by this home 869 agent. For example, these mobile nodes may represent different 870 people affiliated with the organization owning the home agent and 871 these mobile nodes, with which the user of this correspondent node 872 often collaborates. In this case, the effort of establishing the 873 necessary mobility security association with this home agent may be 874 justified. It is similarly possible for a mobile node to have a 875 manually established mobility security association with the foreign 876 agents that it commonly uses; when it does, there is no need to 877 obtain a registration key from the home agent. 879 However, the possibility of obtaining a registration key, as outlined 880 in Section 8.1, allows smooth handoffs to occur even in the absence 881 of mutually assured identification between the mobile node and the 882 foreign agent. This feature depends for its operation on the fact 883 that the foreign agent has already agreed to provide service for the 884 mobile node; no additional verification of identity is required. In 885 other words, for the purposes of mobility protocols, if an agent acts 886 like a foreign agent, then it is a foreign agent. 888 In general, if the movement and communication patterns of a mobile 889 node or the group of mobile nodes served by the same home agent are 890 sufficient to justify establishing a mobility security association 891 with the mobile node's home agent, users or network administrators 892 are likely to do so. Establishing a mobility security association 893 is not a requirement to using the protocol. In that case, however, 894 the ability of correspondent nodes to use the Mobile IP protocol with 895 Route Optimization is severely restricted; datagrams destined for a 896 mobile node have to be routed through the mobile node's home agent, 897 to be tunneled to the mobile node's current location. 899 5.2. Mobility Security Associations 901 For use with Route Optimization, a mobility security association held 902 by a correspondent node or a foreign agent must in general include 903 the same parameters as required by the base Mobile IP protocol 904 specification [3]. 906 6. Location Cache Considerations 908 Any node may maintain a location cache in order to optimize its 909 own communication with mobile nodes. When sending a datagram, if 910 the node has a location cache entry for the destination node, it 911 may tunnel the datagram to the mobile node's care-of address using 912 the encapsulation techniques described for home agents in the base 913 Mobile IP protocol specification [3]. 915 When a node other than the foreign agent currently serving a mobile 916 node receives a datagram for a mobile node, and this datagram has 917 been tunneled to that node, the node tunneling the datagram generally 918 has an out-of-date binding for the mobile node in its location 919 cache. In such cases, the node receiving the tunneled datagram may 920 send a Binding Warning message to the tunneling node, which should 921 then request a new binding for the mobile node by sending a Binding 922 Request message to the mobile node's home agent. Similarly, when a 923 mobile node's home agent intercepts a datagram on the home network 924 and tunnels it to the mobile node, the originating node typically 925 has no location cache entry for the destination mobile node. In 926 such cases, the home agent may send a Binding Update message to the 927 originator. 929 6.1. Cache Management 931 A node maintaining a location cache may use any reasonable strategy 932 for managing the space within the cache. When a new entry needs to 933 be added to the location cache, the node may choose to drop any entry 934 already in the cache, if needed, to make space for the new entry. 935 For example, a "least-recently used" (LRU) strategy for cache entry 936 replacement is likely to work well. 938 Each binding in the location cache also has an associated lifetime, 939 specified by in the Binding Update message in which the node obtained 940 the binding. After the expiration of this time period, the binding 941 MUST be dropped from the cache. 943 6.2. Receiving Binding Warning Messages 945 A node maintaining and using a location cache will receive a Binding 946 Warning message if its location cache entry for a datagram it has 947 tunneled is out-of-date, as determined by the node which receives the 948 tunneled datagram. The node receiving the Binding Warning message 949 then constructs a Binding Request message to obtain a new binding 950 from the home agent serving the mobile node. Included in the Binding 951 Request message is a 64-bit identification field, in the same format 952 described in the base Mobile IP protocol document, for matching the 953 request with the returned Binding Update message. The node should 954 silently discard any Binding Update messages that do not correspond 955 with its latest Binding Request message for this mobile node. 957 6.3. Receiving Binding Update Messages 959 When a node receives a Binding Update message, it uses the 960 authentication technique indicated by the mobility security 961 association between itself and the mobile node's home agent. The 962 authentication data is found in the Route Optimization Authentication 963 Extension (Section 4.2). If the authentication succeeds, then a 964 location cache entry may be updated for use in future transmissions 965 of data to the mobile node. Otherwise, an authentication exception 966 SHOULD be raised. 968 6.4. Using Special Tunnels 970 Whenever any node receives a tunneled datagram for a mobile node, 971 for which no location cache entry or visitor list entry is known, 972 the node may determine that it has received the tunneled datagram 973 in error. In this case, the node should use a "special tunnel" to 974 make sure the datagram arrives at the home agent for the mobile node. 975 The home agent will then notify the originator of the tunnel about 976 its out-of-date location cache entry, and take steps to deliver the 977 datagram to the current care-of address of the mobile node. As part 978 of this service, the home agent must also check to make sure that the 979 datagram is not tunneled again to the node originating the special 980 tunnel. 982 7. Home Agent Considerations 984 The home agent will be the frequent source of and Binding Update 985 messages sent to correspondent nodes which are communicating with its 986 mobile nodes. Any correspondent node which has no cached bindings 987 for a mobile node, will send normal, untunneled datagrams through 988 the home agent by the normal routing in the Internet. When the home 989 agent first gets a datagram for a mobile node, it SHOULD also send 990 a Binding Update message to the originator of the datagram in hopes 991 that the originator will be able to create a location cache entry for 992 that mobile node. Then, future transmissions for the mobile node 993 will not necessarily involve the home agent. 995 As time goes on, more and more Internet nodes will be able to 996 maintain location caches, and it is hoped that home agents will need 997 to be involved only rarely with routing datagrams to mobile nodes. 998 This might usually happen only when correspondent nodes first try to 999 initiate a session from a mobile node which has not been in contact 1000 with the correspondent node for a long period of time. 1002 7.1. Rate Limiting 1004 A home agent must provide some mechanism to limit the rate at which 1005 it sends Binding Update messages to to the same node about any given 1006 mobility binding, after tunneling a datagram intercepted on the home 1007 network. This is especially true because it is expected that most 1008 Internet nodes will not be equipped with location caches for a long 1009 time, and continual transmissions of Binding Warning messages to such 1010 nodes will only exacerbate the problem of the traffic bottleneck at 1011 the home agent. 1013 7.2. Receiving Binding Request Messages 1015 When the home agent receives a Binding Request message, it consults 1016 its home list and determines the correct binding information to be 1017 sent to the requesting node. Before satisfying the request, the 1018 home agent must check whether or not the mobile node has allowed the 1019 information to be disseminated. If the mobile node specified the 'P' 1020 bit in its Registration Request, then the home agent must not satisfy 1021 any binding Requests. Nevertheless, the home agent can return an 1022 empty Binding Update, with a zero care-of address and zero lifetime, 1023 so that the correspondent node will not go to the trouble of trying 1024 to obtain a binding. This situation can never arise by the action of 1025 any correctly operating node maintaining a location cache, but it is 1026 still possible that an intelligent correspondent node might try to 1027 obtain bindings for mobile nodes. 1029 7.3. Receiving Registration Key requests 1031 When the home agent receives a Registration Request message, it may 1032 also be asked to compute registration keys for use with foreign 1033 agent handoffs (Section 2.2). In that event, the home agent employs 1034 a good algorithm for producing random keys [2] and encrypts the 1035 result separately for use by the foreign agent and by the mobile 1036 node. The chosen key is encrypted under a key and algorithm shared 1037 between the home agent and the mobile node, and the encrypted key 1038 is placed in a Mobile Node Registration Key extension (Section 4.4) 1039 in the Registration Reply message. The same key also is encrypted 1040 under a key and algorithm shared between the home agent and the 1041 foreign agent, and the encrypted key is placed in a Foreign Agent 1042 Registration Key extension (Section 4.5) in the Registration Reply 1043 message. By default, the home agent uses its mobility security 1044 association for the mobile node and for the foreign agent to encrypt 1045 the registration key. If the home agent has no preestablished 1046 mobility security association with the foreign agent and the 1047 Registration Key Request extension contained a public key from the 1048 foreign agent, the home agent may instead use this key to encrypt the 1049 registration key for the foreign agent. 1051 7.4. Receiving Special Tunnels 1053 The home agent can also receive tunneled datagrams destined for the 1054 mobile node. If the tunnel source is the same as the foreign agent 1055 shown in the home list entry for the mobile node, then the home 1056 agent MUST NOT send the datagram back to that same foreign agent. 1057 Otherwise, the home agent can tunnel the tunneled datagram to the 1058 current foreign agent, encapsulating the incoming tunneled datagram 1059 in its entirety. 1061 The home agent also, in this case, takes responsibility for sending 1062 information to the originator of the datagram (whose source address 1063 will be in the inner datagram header inside the encapsulation), 1064 to allow that originator to update its location cache entry for 1065 the target mobile node. If the home agent has a mobility security 1066 association with the correspondent node which originated the 1067 datagram, an authenticated Binding Update message can be sent 1068 directly. 1070 8. Foreign Agent Considerations 1072 In addition to managing the resources needed to handle basic 1073 Mobile IP registrations, the foreign agent assisting with Route 1074 Optimization assumes two additional responsibilities. The first 1075 is the maintenance of a location cache for forwarding datagrams to 1076 mobile nodes as they switch connections to new foreign agents. The 1077 second is a slight modification of the registration procedure, to 1078 allow for timely notification possible for previous foreign agents. 1080 8.1. Setting up Temporary Mobility Security Associations 1082 As part of the registration procedure, a mobile node and foreign 1083 agent can agree on a registration key. This registration key is, as 1084 described in Section 7.3, computed by the mobile node's home agent 1085 and transmitted back to the foreign agent along with the Registration 1086 Reply message. Within this document, the registration key is used 1087 only for authentication of a single Binding Update message; other 1088 uses for the registration key are possible, but are outside the scope 1089 of this discussion. For instance, the foreign agent and mobile node 1090 may negotiate to use the registration key to provide confidentiality 1091 along the wireless link connecting them. If a foreign agent is 1092 unable to process a registration request because the mobile node also 1093 expects a registration key, the foreign agent returns the appropriate 1094 status code immediately in a Registration Reply message. 1096 DISCUSSION: Alternatively, we could add a bit to the Agent 1097 Advertisement message. 1099 The actual request for the registration key is made by the mobile 1100 node (Section 2.2). Since the foreign agent and the home agent 1101 may have no mobility security association, the home agent cannot 1102 be assured of the identity of the foreign agent. This does not 1103 matter, however, for the production of the registration key. When 1104 the foreign agent receives the registration reply, with both foreign 1105 agent registration key extensions, it strips off the extension 1106 containing its own registration key, and relays the rest to the 1107 mobile node. 1109 This registration key can be trusted for the purposes outlined, even 1110 though the mobile node and the foreign agent cannot be expected to 1111 always authenticate each other's identity. They can, however, expect 1112 each other to follow the operational procedures comprising the Route 1113 Optimization protocols. Any further use made of the registration key 1114 must take into account the fact that the nodes involved have not yet 1115 mutually identified each other in a trustworthy fashion; they have 1116 only agreed that the foreign agent will provide certain desirable 1117 services to the mobile node. 1119 8.2. Previous Foreign Agent Notification 1121 When a mobile node registers with a new foreign agent, it may request 1122 that the new foreign agent send a Binding Update message to its 1123 previous foreign agent. This Binding Update must be authenticated, 1124 using the Route Optimization Authentication extension (Section 4.2), 1125 as must all Binding Updates. The Acknowledge bit in this Binding 1126 Update message must be set. 1128 When the previous foreign agent receives the Binding Update, it will 1129 use the mobility security association set up with the mobile node 1130 during its previous registration to authenticate the message. If 1131 the message authentication is correct, the old visitor list entry 1132 will be deleted and a Binding Acknowledge message returned to the 1133 sender. In addition, if a new care-of address was included with the 1134 new binding, a location cache entry will be created for it, and the 1135 previous foreign agent can tunnel datagrams to the mobile node's 1136 current care-of address using that location cache, just as any node 1137 maintaining a location cache. 1139 In particular, the previous foreign agent can tunnel the Binding 1140 Acknowledge message back to the new care-of address specified in 1141 the received binding. This creates an interesting problem for the 1142 new foreign agent when it receives the acknowledgment before the 1143 registration reply from the home agent. It is suggested that the new 1144 foreign agent deliver the acknowledgment to the mobile node anyway, 1145 even though the mobile node is technically unregistered. If there 1146 is concern that this provides a loophole for unauthorized traffic 1147 to the mobile node, the new foreign agent could limit the number of 1148 datagrams delivered to the unregistered mobile node to this single 1149 instance. Alternatively, a new extension to the Registration Reply 1150 message can be defined to carry along the acknowledgement from the 1151 previous foreign agent. This latter approach would have the benefit 1152 that fewer datagrams would be transmitted over bandwidth-constrained 1153 wireless media during registrations. 1155 The lifetime associated with the location cache, in this situation, 1156 can be substantially shorter than other location caches for several 1157 reasons. First, the home agent is presumably tunneling datagrams to 1158 the new foreign agent; second, any active correspondent node will 1159 probably get a new location cache entry for the mobile node after 1160 receiving the Binding Warning message from the previous foreign 1161 agent. Lastly, even if the location cache entry expires prematurely, 1162 the previous foreign agent can special tunnel any straggling 1163 datagrams back to the home agent for further delivery. 1165 8.3. Receiving Tunneled Datagrams 1167 If the mobile node's current foreign agent receives a tunneled 1168 datagram for the mobile node, it can be assumed that the tunneled 1169 datagram was originated by a node maintaining a location cache. 1170 There may be pathological or special cases where this assumption is 1171 false, but one would almost have to intentionally run custom code 1172 to invalidate the assumption. Since the foreign agent currently 1173 serving a mobile node can assume that the sending node forwarded the 1174 datagram based on correct location cache information, the foreign 1175 agent can also assume that the sending cache agent has already issued 1176 notification to the source of the original datagram. Thus, the 1177 current foreign agent never needs to send a Binding Warning message 1178 to the node which last tunneled the datagram. 1180 On the other hand, a foreign agent which is tunneling received 1181 datagrams on behalf of a mobile node not in its visitor list should, 1182 just as any other node implementing Route Optimization, send Binding 1183 Warning messages to the originator of these datagrams. If the 1184 datagrams it receives are not tunneled, the foreign agent should 1185 limit the rate at which it sends Binding Warning messages to the 1186 originators, since those originators may be unable to interpret such 1187 notifications. It is expected that reception of such un-tunneled 1188 datagrams by any foreign agent will be rare. 1190 8.4. Sending Special Tunnels 1192 If a foreign agent receives a tunneled datagram for a mobile node 1193 which is unknown, then the foreign agent can tunnel the datagram back 1194 to the home agent. This requires special care at the home agent. 1195 The foreign agent must use the mobile node's address as the tunnel 1196 destination, and its own address as the tunnel source. The home 1197 agent will then capture the special tunneled datagram and re-tunnel 1198 it to the mobile node via its current foreign agent. The foreign 1199 agent sending the special tunnel should not notify the originator of 1200 the datagram about its out-of-date binding, as this will be done by 1201 the home agent which receives the special tunnel datagram. 1203 9. Mobile Node Considerations 1205 9.1. Requesting a Registration Key 1207 When a mobile node makes a registration request, it can request a 1208 registration key to be shared between itself and the prospective 1209 foreign agent. The key will be used to authenticate a future 1210 disconnection notice from the mobile node, when the mobile node 1211 has moved to a new cell. The mobile node allows the home agent to 1212 pick the registration key, because it is expected that the mobile 1213 node is less likely to have good means for computing pseudo-random 1214 numbers [2]. The registration key will be returned in an extension 1215 to the expected registration reply, and the foreign agent can use 1216 it to compute a "mobile-foreign" authentication extension to the 1217 registration reply. If this is done, the mobile node will have 1218 complete confidence that it does in fact share a secret registration 1219 key. If not, the mobile node can still act on the supposition that 1220 the key has been correctly received by the foreign agent, but the 1221 delivery of the key to the foreign agent can be compromised by an 1222 active attack which modifies some of the bits of the extension which 1223 the home agent uses to deliver the key to the foreign agent. In the 1224 latter case, the foreign agent does not have a good way to detect the 1225 corruption. Since the problem will only show up by possibly causing 1226 some datagrams to be lost after some unpredictably distant future 1227 movement by the mobile node, it is not absolutely required to test 1228 the validity of the registration key. 1230 If the mobile node detects that the foreign agent has a corrupted 1231 registration key, it can re-register immediately. 1233 9.2. Notifying Previous Foreign Agents 1235 If the mobile node wishes to instruct its prospective foreign agent 1236 to send a Binding Update message to the mobile node's previous 1237 foreign agent, it uses the appropriate extension (see 4.1) to the 1238 Registration Request message. This usually results in quicker 1239 establishment of a location cache entry at the previous foreign 1240 agent, because the previous foreign agent is likely to be much closer 1241 to the new foreign agent than the home agent is. 1243 Since the prospective new foreign agent does not have access to 1244 the registration key which was established between the mobile node 1245 and its previous foreign agent, the mobile node has to compute 1246 the appropriate authentication value for use by the prospective 1247 foreign agent. This authentication is computed over the fields of 1248 the expected Binding Update message, with the 'I' bit set and no 1249 identification present. Reply protection is considered unnecessary 1250 since the binding update is expected to be sent only once with the 1251 registration key. 1253 When the acknowledgment arrives, the new foreign agent detunnels 1254 it and sends it to the mobile node. In this way, the mobile node 1255 can still discover that its previous foreign agent has updated 1256 its visitor list and location cache. This is important, because 1257 otherwise the previous foreign agent would often become a "black 1258 hole" for datagrams destined for the mobile node. The new foreign 1259 agent has no further responsibility for helping to update the 1260 location cache at the previous foreign agent. 1262 The mobile node expects to eventually receive an acknowledgement 1263 from its previous foreign agent, signifying that the mobile node's 1264 entry has been erased from its visitor list. If the acknowledgement 1265 has not been received after sufficient time, the mobile node is 1266 responsible for retransmitting another Binding Update message to 1267 its previous foreign agent. Although the previous foreign agent 1268 may have already deleted the registration key from its records, the 1269 mobile node should continue to retransmit its Binding Update message 1270 until the previous foreign agent responds with either a positive or 1271 negative acknowledgment. 1273 Since the mobile node is responsible for fielding the acknowledgement 1274 from its previous foreign agent, there is no need to add any status 1275 code or bit to the Registration Reply from its prospective new 1276 foreign agent 1278 References 1280 [1] Ralph Droms. Dynamic Host Configuration Protocol. RFC 1541, 1281 October 1993. 1283 [2] Donald E. Eastlake 3rd, Stephen D. Crocker, and Jeffrey I. 1284 Schiller. Randomness recommendations for security. RFC 1750, 1285 December 1994. 1287 [3] Charles Perkins, editor. IP mobility support. Internet Draft, 1288 draft-ietf-mobileip-protocol-08.txt, January 1995. Work in 1289 progress. 1291 Appendix A. Using a Master Key at the Home Agent 1293 Rather than storing each mobility security association that it has 1294 established with many different correspondent nodes and foreign 1295 agents, a home agent may manage its mobility security associations so 1296 that each of them can be generated from a single "master" key. With 1297 the master key, the home agent could build a key for any given other 1298 node by computing the node-specific key as 1300 MD5(node-address || master-key || node-address) 1302 where node-address is the IP address of the particular node for which 1303 the home agent is building a key, and master-key is the single master 1304 key held by the home agent for all mobility security associations it 1305 has established with correspondent nodes. The node-specific key is 1306 built by computing an MD5 hash over a string consisting of the master 1307 key with the node-address concatenated as a prefix and as a suffix. 1309 Using this scheme, when establishing each mobility security 1310 association, the network administrator managing the home agent 1311 computes the node-specific key and communicates this key to the 1312 network administrator of the other node through some "secure" 1313 channel, such as over the telephone. The mobility security 1314 association is configured at this other node in the same way as any 1315 mobility security association. At the home agent, though, no record 1316 need be kept that this key has been given out. The home agent need 1317 only be configured to know that this scheme is in use for all of its 1318 mobility security associations. 1320 When the home agent then needs a mobility security association as 1321 part of the Route Optimization protocol, it builds the node-specific 1322 key based on the master key and the IP address of the other node with 1323 which it is attempting to authenticate. If the other node knows 1324 the correct node-specific key, the authentication will succeed; 1325 otherwise, it will fail as it should. 1327 Chairs' Addresses 1329 The working group can be contacted via the current chairs: 1331 Tony Li 1332 cisco Systems 1333 170 W. Tasman Dr. 1334 San Jose CA 95134 1336 Phone: +1-408-526-8186 1337 E-mail: tli@cisco.com 1339 Jim Solomon 1340 Motorola, Inc. 1342 Phone: +1-708-576-2753 1343 E-mail: solomon@comm.mot.com 1345 Authors' Addresses 1347 Questions about this document can also be directed to the authors: 1349 David B. Johnson 1350 Computer Science Department 1351 Carnegie Mellon University 1352 5000 Forbes Avenue 1353 Pittsburgh, PA 15213-3891 1355 Phone: +1-412-268-7399 1356 Fax: +1-412-268-5576 1357 E-mail: dbj@cs.cmu.edu 1359 Charles Perkins 1360 Room J1-A25 1361 T. J. Watson Research Center 1362 IBM Corporation 1363 30 Saw Mill River Rd. 1364 Hawthorne, NY 10532 1366 Phone: +1-914-784-7350 1367 Fax: +1-914-784-7007 1368 E-mail: perk@watson.ibm.com 1370 Andrew Myles 1371 Electronics Department 1372 Macquarie University 2109 1373 Sydney, Australia 1375 Phone: +61-2-8059071 1376 Fax: +61-2-8059128 1377 E-mail: andrewm@mpce.mq.edu.au