Network Working Group David B. Johnson INTERNET DRAFT Carnegie Mellon University 15 March 1995 Charles Perkins IBM Corporation Andrew Myles Macquarie University Route Optimization in Mobile IP draft-ietf-mobileip-optim-01.txt Abstract This document defines extensions to the operation of the basic Mobile IP protocol to allow for optimization of datagram routing from a correspondent node to a mobile node. Without Route Optimization, all datagrams destined to a mobile node are routed through that mobile node's home agent, which then tunnels each datagram to the mobile node's current location. The protocol extensions described here provide a means for correspondent nodes that implement them to cache the location of a mobile node and to then tunnel their own datagrams for the mobile node directly to that location, bypassing the possibly lengthy route for each datagram to and from the mobile node's home agent. Extensions are also provided to allow datagrams in flight when a mobile node moves, and datagrams sent based on an out-of-date cached location, to be forwarded directly to the mobile node's new location. Status of This Memo This document is a product of the Mobile IP Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to working group mailing list at mobile-ip@tadpole.com. Distribution of this memo is unlimited. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". Johnson, Perkins, Myles Expires 15 September 1995 [Page i] Internet Draft Route Optimization in Mobile IP 15 March 1995 To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Johnson, Perkins, Myles Expires 15 September 1995 [Page ii] Internet Draft Route Optimization in Mobile IP 15 March 1995 Contents Abstract i Status of This Memo i 1. Introduction 1 2. Route Optimization Overview 3 2.1. Location Caching . . . . . . . . . . . . . . . . . . . . 3 2.2. Foreign Agent Handoff . . . . . . . . . . . . . . . . . . 3 2.3. Location Cache Updates . . . . . . . . . . . . . . . . . 6 3. Route Optimization Message Formats 8 3.1. Binding Warning Message . . . . . . . . . . . . . . . . . 9 3.2. Binding Request Message . . . . . . . . . . . . . . . . . 10 3.3. Binding Update Message . . . . . . . . . . . . . . . . . 11 3.4. Binding Acknowledge Message . . . . . . . . . . . . . . . 13 4. Route Optimization Extension Formats 14 4.1. Previous Foreign Agent Notification Extension . . . . . . 15 4.2. Route Optimization Authentication Extension . . . . . . . 17 4.3. Registration Key Request Extension . . . . . . . . . . . 18 4.4. Mobile Node Registration Key Extension . . . . . . . . . 19 4.5. Foreign Agent Registration Key Extension . . . . . . . . 20 4.6. Foreign Agent Public Key Extension . . . . . . . . . . . 21 5. Mobility Security Association Management 22 5.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 22 5.2. Mobility Security Associations . . . . . . . . . . . . . 23 6. Location Cache Considerations 24 6.1. Cache Management . . . . . . . . . . . . . . . . . . . . 24 6.2. Receiving Binding Warning Messages . . . . . . . . . . . 24 6.3. Receiving Binding Update Messages . . . . . . . . . . . . 25 6.4. Using Special Tunnels . . . . . . . . . . . . . . . . . . 25 7. Home Agent Considerations 26 7.1. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . 26 7.2. Receiving Binding Request Messages . . . . . . . . . . . 26 7.3. Receiving Registration Key requests . . . . . . . . . . . 27 7.4. Receiving Special Tunnels . . . . . . . . . . . . . . . . 27 Johnson, Perkins, Myles Expires 15 September 1995 [Page iii] Internet Draft Route Optimization in Mobile IP 15 March 1995 8. Foreign Agent Considerations 28 8.1. Setting up Temporary Mobility Security Associations . . . 28 8.2. Previous Foreign Agent Notification . . . . . . . . . . . 29 8.3. Receiving Tunneled Datagrams . . . . . . . . . . . . . . 30 8.4. Sending Special Tunnels . . . . . . . . . . . . . . . . . 30 9. Mobile Node Considerations 31 9.1. Requesting a Registration Key . . . . . . . . . . . . . . 31 9.2. Notifying Previous Foreign Agents . . . . . . . . . . . . 31 References 33 Appendix A. Using a Master Key at the Home Agent 34 Chairs' Addresses 35 Authors' Addresses 36 Johnson, Perkins, Myles Expires 15 September 1995 [Page iv] Internet Draft Route Optimization in Mobile IP 15 March 1995 1. Introduction The basic Mobile IP protocol [3] allows any mobile node to move about, changing its point of attachment to the Internet, while continuing to be addressed by its home IP address. Correspondent nodes sending IP datagrams to a mobile node address them to the mobile node's home address in the same way as to any destination. While the mobile node is connected to the Internet away from its home network, it is served by a "home agent" on its home network and is associated with a "care-of address" indicating its current location. The association between a mobile node's home address and its care-of address is known as a "mobility binding". The care-of address is generally the address of a "foreign agent" on the network being visited by the mobile node, which forwards arriving datagrams locally to the mobile node. Alternatively, the care-of address may be temporarily assigned to the mobile node using DHCP [1] or other means. All IP datagrams addressed to the mobile node are routed by the normal IP routing mechanisms to the mobile node's home network, where they are intercepted by the mobile node's home agent, which then tunnels each datagram to the mobile node's current care-of address. Datagrams sent by a mobile node use the foreign agent as a default router but require no other special handling or routing. This basic scheme allows transparent interoperation with mobile nodes, but forces all datagrams for a mobile node to be routed through its home agent; packets to the mobile node are often routed along paths that are significantly longer than optimal. For example, if a mobile node, say MN1, is visiting some subnet, even datagrams from a correspondent node on this same subnet must be routed through the Internet to MN1's home agent on MN1's home network, only to then be tunneled back to the original subnet to MN1's foreign agent for delivery to MN1. This indirect routing can significantly delay the delivery of the datagram to MN1 and places an unnecessary burden on the networks and routers along this path through the Internet. If the correspondent node in this example is actually another mobile node, say MN2, then datagrams from MN1 to MN2 must likewise be routed through MN2's home agent on MN2's home network and back to the original subnet for delivery to MN1. This document defines extensions to the basic Mobile IP protocol to allow for the optimization of datagram routing from a correspondent node to a mobile node. These extensions provide a means for nodes that implement them to cache the care-of address of a mobile node and to then tunnel their own datagrams directly there, bypassing the possibly lengthy route to and from that mobile node's home agent. Extensions are also provided to allow datagrams in flight when a mobile node moves, and datagrams sent based on an out-of-date cached Johnson, Perkins, Myles Expires 15 September 1995 [Page 1] Internet Draft Route Optimization in Mobile IP 15 March 1995 care-of address, to be forwarded directly to the mobile node's new care-of address. These extensions are collectively referred to as Route Optimization in this document. All operation of Route Optimization that changes the routing of IP datagrams to the mobile node is authenticated using the same type of authentication mechanism used in the basic Mobile IP protocol. This authentication generally relies on a "mobility security association" established in advance between the node sending a message and the node receiving the message that must authenticate it. When the required mobility security association has not been established, a Mobile IP implementation using Route Optimization operates in the same way as the basic Mobile IP protocol. Section 2 of this document provides an overview of the operation of Route Optimization. Section 3 defines the message types used by Route Optimization, and Section 4 defines the message extensions used. Section 5 discusses the problem of managing the mobility security associations needed to provide authentication of all messages that affect the routing of datagrams to a mobile node. The final four sections of this document define in detail the operation of Route Optimization from the point of view of each of the entities involved: considerations for nodes maintaining a location cache are presented in Section 6, mobile node considerations in Section 9, foreign agent considerations in Section 8, and home agent considerations in Section 7. Johnson, Perkins, Myles Expires 15 September 1995 [Page 2] Internet Draft Route Optimization in Mobile IP 15 March 1995 2. Route Optimization Overview 2.1. Location Caching Route Optimization provides a means for any node that wishes to optimize its own communication with mobile nodes to maintain a "location cache" containing the mobility binding of one or more mobile nodes. When sending an IP datagram to a mobile node, if the sender has a location cache entry for the destination mobile node, it may tunnel the datagram directly to the care-of address indicated in the cached mobility binding. In the absence of any location cache entry, datagrams destined for a mobile node will be routed to the mobile node's home network in the same way as any other IP datagram, and are then tunneled to the mobile node's current care-of address by the mobile node's home agent. This is the only routing mechanism supported by the basic Mobile IP protocol. With Route Optimization, as a side effect of this indirect routing of a datagram to a mobile node, the original sender of the datagram may be informed of the mobile node's current mobility binding, giving the sender an opportunity to cache the binding. A node may create a location cache entry for a mobile node only when it has received and authenticated the mobile node's mobility binding. Likewise, a node may update an existing location cache entry for a mobile node, such as after the mobile node has moved to a new foreign agent, only when it has received and authenticated the mobile node's new mobility binding. A location cache will, by necessity, have a finite size. Any node implementing a location cache may manage the space in its cache using any local cache replacement policy. If a datagram is sent to a destination for which the cache entry has been dropped from the cache, the datagram will be routed normally through the mobile node's home network and will be tunneled to the mobile node's care-of address by its home agent. This indirect routing to the mobile node will result in the original sender of the datagram being informed of the mobile node's current mobility binding, allowing it to add this entry again to its location cache. 2.2. Foreign Agent Handoff When a mobile node moves and registers with a new foreign agent, the basic Mobile IP protocol does not notify the mobile node's previous foreign agent. IP datagrams intercepted by the home agent after the new registration are tunneled to the mobile node's new care-of Johnson, Perkins, Myles Expires 15 September 1995 [Page 3] Internet Draft Route Optimization in Mobile IP 15 March 1995 address, but datagrams in flight that had already been intercepted by the home agent and tunneled to the old care-of address when the mobile node moved are lost and are assumed to be retransmitted by higher-level protocols if neeeded. The old foreign agent eventually deletes the mobile node's registration after the expiration of the lifetime period established when the mobile node registered there. Route Optimization provides a means for the mobile node's previous foreign agent to be reliably notified of the mobile node's new mobility binding, allowing datagrams in flight to the mobile node's previous foreign agent to be forwarded to its new care-of address. This notification also allows any datagrams tunneled to the mobile node's previous foreign agent from correspondent nodes with out-of-date location cache entries for the mobile node (that have not yet learned that the mobile node has moved), to be forwarded to its new care-of address. Finally, this notification allows any resources consumed by the mobile node's binding at the previous foreign agent (such as radio channel reservations) to be released immediately, rather than waiting for the mobile node's registration to expire. During registration with a new foreign agent, the mobile node and the new foreign agent may establish a "registration key", which acts as a session key for this registration. When a Registration Key Request extension is included in the Registration Request message to the mobile node's home agent, the home agent may choose a registration key and include it in its Registration Reply message. The home agent includes a Mobile Node Registration Key extension, containing a copy of the chosen key encrypted under a key and algorithm shared between the home agent and the mobile node, and a Foreign Agent Registration Key extension, containing a copy of the same key encrypted under a key and algorithm shared between the home agent and the foreign agent. In order for the registration key to be established, the foreign agent must have a mobility security association with the home agent. This security association may either be preestablished or may be established for purposes of this registration through exchange of the foreign agent's public encryption key in the Agent Advertisement and Registration Request messages. The registration key for a mobile node can be stored by the foreign agent with the mobile node's visitor list entry. When a mobile node registers with a new foreign agent, if it established a registration key during registration with its previous foreign agent, it may use this key to notify the previous foreign agent that it has moved. This notification may also optionally include the mobile node's new care-of address, allowing the previous foreign agent to create a location cache entry for the mobile node to serve as a "forwarding pointer" to its new location. Any tunneled datagrams for the mobile node that arrive at this previous foreign Johnson, Perkins, Myles Expires 15 September 1995 [Page 4] Internet Draft Route Optimization in Mobile IP 15 March 1995 agent after this location cache entry has been created will then be re-tunneled by this foreign agent to the mobile node's new location using the mobility binding in this location cache entry. The registration key is used to authenticate the notification sent to the previous foreign agent. As part of the registration procedure, the mobile node may request that its new foreign agent attempt to notify its previous foreign agent on its behalf, by including a Previous Foreign Agent Notification extension in its Registration Request message sent to the new foreign agent. The new foreign agent then builds a Binding Update message and transmits it to the mobile node's previous foreign agent as part of registration, requesting an acknowledgement from the previous foreign agent. The Previous Foreign Agent Notification extension includes only those values needed to construct the Binding Update message that are not already contained in the Registration Request message. The authenticator for the Binding Update message is computed by the mobile node based on its registration key shared with its previous foreign agent. The mobile node is responsible for occasionally retransmitting a Binding Update message to its previous foreign agent until the matching Binding Acknowledge message is received, or until the mobile node can be sure of the expiration of its registration with that foreign agent. The location cache entry created at the mobile node's previous foreign agent is treated in the same way as any other location cache entry. In particular, it is possible that this location cache entry will be deleted from the cache at any time. In this case, the foreign agent will be unable to re-tunnel subsequently arriving tunneled datagrams for the mobile node directly to its new location. Suppose a node (for instance, such a previous foreign agent) receives a datagram that has been tunneled to this node, but this node is unable to deliver the datagram locally to the destination mobile node (the node is not the mobile node itself, and it is not a foreign agent with a visitor list entry for the mobile node). To attempt delivery of the datagram in this case, the node must encapsulate the datagram as a "special tunnel" datagram (Section 8.4), destined to the mobile node. Otherwise, the datagram would eventually reach the mobile node's home network, be intercepted by the mobile node's home agent, and be tunneled to the mobile node's current care-of address. If the home agent were to tunnel the datagram back to the same foreign agent, a loop would be created. Johnson, Perkins, Myles Expires 15 September 1995 [Page 5] Internet Draft Route Optimization in Mobile IP 15 March 1995 2.3. Location Cache Updates When a mobile node's home agent intercepts a datagram from the home network and tunnels it to the mobile node, the home agent may deduce that the original sender of the datagram has no location cache entry for the destination mobile node. In this case, the home agent MAY send a Binding Update message to the sender, informing it of the mobile node's current mobility binding. No acknowledgement for this Binding Update message is needed, since additional future datagrams from this sender intercepted by the home agent for the mobile node will cause transmission of another update. In order for this Binding Update to be authenticated by the sender of the datagram, the home agent and the sender must have established a mobility security association. Similarly, when any node receives a tunneled datagram tunneled to this node, if it is not the current foreign agent serving the destination as a mobile node the source of the tunneled datagram probably has an out-of-date location cache entry for the destination mobile node. In this case, this node MAY send a Binding Warning message to the originator of the tunneled datagram. As above, no acknowledgement of this Binding Warning is needed. Unlike the Binding Update message, though, no authentication of the Binding Warning message is necessary, since it does not directly affect the routing of IP datagrams to the mobile node. Instead, when a node receives a Binding Warning message, that node sends a Binding Request message to the indicated mobile node's home agent, requesting the mobile node's current mobility binding. The home agent then answers this Binding Request message with a Binding Update message, and when the Binding Update message is received, the node may then create a location cache entry for the mobile node. In order for this node and the home agent to exchange these Binding Request and Binding Update messages, they must have established a mobility security association. Each Binding Update message indicates the maximum lifetime of any location cache entry created from the Binding Update. When sending the Binding Update message, the home agent SHOULD set this lifetime to the remaining service lifetime associated with the mobile node's current registration. Any location cache entry established or updated in response to this Binding Update message must be marked to be deleted after the expiration of this period. A node wanting to provide continued service with a particular location cache entry may attempt to reconfirm that mobility binding before the expiration of this lifetime period. Location cache entry reconfirmation may be appropriate when the node has indications (such as an open transport-level connection to the mobile node) that the location Johnson, Perkins, Myles Expires 15 September 1995 [Page 6] Internet Draft Route Optimization in Mobile IP 15 March 1995 cache entry is still needed. This reconfirmation is performed by the node sending a Binding Request message to the mobile node's home agent, requesting it to reply with the mobile node's current mobility binding in a new Binding Update message. Johnson, Perkins, Myles Expires 15 September 1995 [Page 7] Internet Draft Route Optimization in Mobile IP 15 March 1995 3. Route Optimization Message Formats Route Optimization defines four message types used for management of location cache entries. Each of these messages begins with a one-octet field indicating the type of the message. The following Type codes are defined in this document: 16 = Binding Warning message 17 = Binding Request message 18 = Binding Update message 19 = Binding Acknowledge message Johnson, Perkins, Myles Expires 15 September 1995 [Page 8] Internet Draft Route Optimization in Mobile IP 15 March 1995 3.1. Binding Warning Message A Binding Warning message is used to advise a node that it appears to have either no location cache entry or an out-of-date location cache entry for some mobile node. When any node receives a datagram tunneled to itself, if it is not the current foreign agent for the destination mobile node, it MAY send a Binding Warning message to the node that originated the tunneled datagram. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile Node Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 16 Reserved Sent as 0; ignored on reception. Mobile Node Home Address The home address of the mobile node to which the Binding Warning message refers. Johnson, Perkins, Myles Expires 15 September 1995 [Page 9] Internet Draft Route Optimization in Mobile IP 15 March 1995 3.2. Binding Request Message A Binding Request message is used by a node to request a mobile node's current mobility binding from the mobile node's home agent. It is sent by a node upon receiving a Binding Warning message, or by a node desiring to update the mobility binding in a location cache entry that it holds for the mobile node. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile Node Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 17 Reserved Sent as 0; ignored on reception. Mobile Node Home Address The home address of the mobile node to which the Binding Request refers. Identification A 64-bit sequence number, assigned by the node sending the Binding Request message, used to assist in matching requests with replies, and in protecting against replay attacks. Johnson, Perkins, Myles Expires 15 September 1995 [Page 10] Internet Draft Route Optimization in Mobile IP 15 March 1995 3.3. Binding Update Message The Binding Update message is used to notify another node of a mobile node's current mobility binding. It MAY be sent by the mobile node's home agent in response to a Binding Request message. It MAY also be sent by a mobile node, or by the foreign agent with which the mobile node is registering, when notifying the mobile node's previous foreign agent that the mobile node has moved. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |A|I| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile Node Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+- Type 18 Acknowledge (A) The Acknowledge (A) bit is set by the node sending the Binding Update message to request a Binding Acknowledge message be returned acknowledging its receipt. Identification Present (I) The (I) bit is set by the node sending the Binding Update message to indicate whether or not the Identification field is present. Reserved Sent as 0; ignored on reception. Johnson, Perkins, Myles Expires 15 September 1995 [Page 11] Internet Draft Route Optimization in Mobile IP 15 March 1995 Lifetime The number of seconds remaining before the location cache entry must be considered expired. A value of all ones indicates infinity. A value of zero indicates that no location cache entry for the mobile node should be created, and any existing location cache entry (and visitor list entry, in the case of a mobile node's previous foreign agent) for the mobile node should be deleted. The lifetime is typically equal to the remaining lifetime of the mobile node's registration. Mobile Node Home Address The home address of the mobile node to which the Binding Update message refers. Care-of Address The current care-of address of the mobile node. When set equal to the home address of the mobile node, the Binding Update message instead indicates that no location cache entry for the mobile node should be created, and any existing location cache entry (and visitor list entry, in the case of a mobile node's previous foreign agent) for the mobile node should be deleted. Identification If present, a 64-bit number, assigned by the node sending the Binding Request message, used to assist in matching requests with replies, and in protecting against replay attacks. The Route Optimization Authentication extension (Section 4.2) is required. Johnson, Perkins, Myles Expires 15 September 1995 [Page 12] Internet Draft Route Optimization in Mobile IP 15 March 1995 3.4. Binding Acknowledge Message A Binding Acknowledge message is used to acknowledge receipt of a Binding Update message. It is sent by a node receiving the Binding Update message, if the Acknowledge (A) bit is set in the Binding Update message. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |N| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile Node Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 19 N This bit is set if the acknowledgement is negative. For instance, if the binding update was not accepted, but the incoming datagram has the Acknowledge flag set, then the N bit is set in this Binding Acknowledge message. DISCUSSION: Alternatively, we could replace this bit with a status code, as in the Registration Reply message. The mobile node could log the error, but currently has no real way to recover from it. Reserved Sent as 0; ignored on reception. Mobile Node Home Address Copied from the Binding Update message being acknowledged. Identification Copied from the Binding Update message being acknowledged, if present there. Johnson, Perkins, Myles Expires 15 September 1995 [Page 13] Internet Draft Route Optimization in Mobile IP 15 March 1995 4. Route Optimization Extension Formats Route Optimization defines the following Mobile IP message extensions: 96 = Previous Foreign Agent Notification extension 97 = Route Optimization Authentication extension 98 = Registration Key Request extension 99 = Mobile Node Registration Key extension 100 = Foreign Agent Registration Key extension 101 = Foreign Agent Public Key extension Johnson, Perkins, Myles Expires 15 September 1995 [Page 14] Internet Draft Route Optimization in Mobile IP 15 March 1995 4.1. Previous Foreign Agent Notification Extension The Previous Foreign Agent Notification Extension may be included in a Registration Request message sent to a foreign agent. It requests the new foreign agent to send a Binding Update message on behalf of the mobile node, to the mobile node's previous foreign agent, to notify it that the mobile node has moved. The previous foreign agent deletes the mobile node's visitor list entry and creates a location cache entry for the mobile node pointing to its new care-of address. The extension contains only those values not otherwise already contained in the Registration Request message, which are needed for the new foreign agent to construct the Binding Update message. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Cache Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Previous Foreign Agent Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authenticator ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 96 Length 6 plus the length of the Authenticator Cache Lifetime The number of seconds remaining before the location cache entry created by the previous foreign agent must be considered expired. A value of all ones indicates infinity. A value of zero indicates that the previous foreign agent should not create a location cache entry for the mobile node once it has deleted the mobile node's visitor list entry. The Cache Lifetime value is copied into the Lifetime field of the Binding Update message. Previous Foreign Agent Address The IP address of the mobile node's previous foreign agent to which the new foreign agent should send a Binding Update message on behalf of the mobile node. Johnson, Perkins, Myles Expires 15 September 1995 [Page 15] Internet Draft Route Optimization in Mobile IP 15 March 1995 Authenticator The authenticator value to be used in the Route Optimization Authentication extension in the Binding Update message sent by the new foreign agent to the mobile node's previous foreign agent. This authenticator is calculated only over the Binding Update message body. Johnson, Perkins, Myles Expires 15 September 1995 [Page 16] Internet Draft Route Optimization in Mobile IP 15 March 1995 4.2. Route Optimization Authentication Extension The Route Optimization Authentication Extension is used to authenticate certain Route Optimization management messages. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Authenticator ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 97 Length The length of the Authenticator Authenticator (variable length) A hash value taken over a stream of bytes including the shared secret, all prior extensions in their entirety, the the Route Optimization management data, and the type and length of this extension, but not including the Authenticator field itself. Johnson, Perkins, Myles Expires 15 September 1995 [Page 17] Internet Draft Route Optimization in Mobile IP 15 March 1995 4.3. Registration Key Request Extension The Registration Key Request extension may be used on Registration Request messages to request a registration key from the mobile node's home agent. The extension is authenticated along with the rest of the Registration Request message, and thus no additional authenticator is included in the extension. In response to a Registration Key Request extension, the home agent MAY include a Mobile Node Registration Key extension and a Foreign Agent Registration Key extension in its Registration Reply message, containing encrypted copies of the registration key for the mobile node the foreign agent. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Foreign Agent Public Key ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 98 Length The length of the Foreign Agent Public Key, or 0 if no Foreign Agent Public Key is present Foreign Agent Public Key If the mobile node received a Foreign Agent Public Key extension in the foreign agent's Agent Advertisement message, this field is present and contains the key advertised in that message, if the mobile node chooses to use the key. The mobility security association assumed to exist between the home agent and the mobile node will be used to encrypt the key unless a Key Identification extension is also included with the Registration Request message. The key returned by the home agent will be assumed, by default, to be 128 bits long. Johnson, Perkins, Myles Expires 15 September 1995 [Page 18] Internet Draft Route Optimization in Mobile IP 15 March 1995 4.4. Mobile Node Registration Key Extension The Mobile Node Registration Key extension may be used on Registration Reply messages to send a registration key from the mobile node's home agent to the mobile node. When used, the home agent must also include a Foreign Agent Registration Key extension in the Registration Reply message, giving a copy of the same key to the mobile node's new foreign agent. The Mobile Node Registration Key extension is authenticated along with the rest of the Registration Reply message, and thus no additional authenticator is included in the extension. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Mobile Node Encrypted Key ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 99 Length The length of the Mobile Node Encrypted Key Mobile Node Encrypted Key (variable length) The registration key, chosen by the home agent, encrypted based on the mobility security association between the home agent and the mobile node. The same key must be sent, encrypted for the foreign agent in a Foreign Agent Registration Key extension in this Registration Reply message. Johnson, Perkins, Myles Expires 15 September 1995 [Page 19] Internet Draft Route Optimization in Mobile IP 15 March 1995 4.5. Foreign Agent Registration Key Extension The Foreign Agent Registration Key extension may be used on Registration Reply messages to send a registration key from the mobile node's home agent to the mobile node's new foreign agent. When used, the home agent must also include a Mobile Node Registration Key extension in the Registration Reply message, giving a copy of the same key to the mobile node. The Foreign Agent Registration Key extension is authenticated by including an authenticator in the extension, computed based on the mobility security association shared between the home agent and the foreign agent. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Foreign Agent Encrypted Key ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authenticator ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 100 Length The length of the Foreign Agent Encrypted Key plus the length of the Authenticator Foreign Agent Encrypted Key (variable length) The registration key, chosen by the home agent, encrypted based on the mobility security association between the home agent and the foreign agent, if one exists, or based on the foreign agent public key from the Registration Key Request message. The same key must be sent, encrypted for the mobile node in a Mobile Node Registration Key extension in this Registration Reply message. Authenticator (variable length) A hash value taken over a stream of bytes including the shared secret and the fields in this extension other than the Authenticator field itself. Johnson, Perkins, Myles Expires 15 September 1995 [Page 20] Internet Draft Route Optimization in Mobile IP 15 March 1995 4.6. Foreign Agent Public Key Extension The Foreign Agent Public Key Extension MAY be included by a foreign agent in the Agent Advertisement messages that it sends. The extension advertises the foreign agent's public encryption key, to allow mobile nodes to include the key in a Registration Key Request extension to their Registration Request message. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Foreign Agent Public Key ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 101 Length The length of the Foreign Agent Public Key Foreign Agent Public Key The foreign agent's public encryption key Johnson, Perkins, Myles Expires 15 September 1995 [Page 21] Internet Draft Route Optimization in Mobile IP 15 March 1995 5. Mobility Security Association Management 5.1. Motivation One of the most difficult aspects of Route Optimization for Mobile IP in the Internet today is that of providing authentication for all messages that affect the routing of datagrams to a mobile node. In the basic Mobile IP protocol, all routing of datagrams to the mobile node while away from its home network is controlled by the home agent, since only the home agent is aware of the mobile node's mobility binding and only the home agent tunnels datagrams to the mobile node. Authentication is achieved based on a manually established "mobility security association" between the home agent and the mobile node. Since the home agent and the mobile node are both owned by the same organization (both are assigned IP addresses within the same IP subnet), this manual configuration is manageable, and (for example) can be performed while the mobile node is at home. With Route Optimization, though, there is a need in general to authenticate messages between two nodes belonging to different organizations, making establishment of a mobility security association more difficult. Since no general authentication or key distribution protocol is available in the Internet today, the Route Optimization procedures defined in this document rely partially on the same type of manually configured mobility security associations used in the basic Mobile IP protocol. For a correspondent node to be able to create a location cache entry for a mobile node so that it can tunnel its own IP datagrams directly to the mobile node at its current location, the correspondent node and the mobile node's home agent must have established a mobility security association. This mobility security association, though, may be used in creating and updating location cache entries at this correspondent node for all mobile nodes served by this home agent. This places the correspondent node in a fairly natural relationship with respect to the mobile nodes served by this home agent. For example, these mobile nodes may represent different people affiliated with the organization owning the home agent and these mobile nodes, with which the user of this correspondent node often collaborates. In this case, the effort of establishing the necessary mobility security association with this home agent may be justified. It is similarly possible for a mobile node to have a manually established mobility security association with the foreign agents that it commonly uses; when it does, there is no need to obtain a registration key from the home agent. However, the possibility of obtaining a registration key, as outlined in Section 8.1, allows smooth handoffs to occur even in the absence Johnson, Perkins, Myles Expires 15 September 1995 [Page 22] Internet Draft Route Optimization in Mobile IP 15 March 1995 of mutually assured identification between the mobile node and the foreign agent. This feature depends for its operation on the fact that the foreign agent has already agreed to provide service for the mobile node; no additional verification of identity is required. In other words, for the purposes of mobility protocols, if an agent acts like a foreign agent, then it is a foreign agent. In general, if the movement and communication patterns of a mobile node or the group of mobile nodes served by the same home agent are sufficient to justify establishing a mobility security association with the mobile node's home agent, users or network administrators are likely to do so. Establishing a mobility security association is not a requirement to using the protocol. In that case, however, the ability of correspondent nodes to use the Mobile IP protocol with Route Optimization is severely restricted; datagrams destined for a mobile node have to be routed through the mobile node's home agent, to be tunneled to the mobile node's current location. 5.2. Mobility Security Associations For use with Route Optimization, a mobility security association held by a correspondent node or a foreign agent must in general include the same parameters as required by the base Mobile IP protocol specification [3]. Johnson, Perkins, Myles Expires 15 September 1995 [Page 23] Internet Draft Route Optimization in Mobile IP 15 March 1995 6. Location Cache Considerations Any node may maintain a location cache in order to optimize its own communication with mobile nodes. When sending a datagram, if the node has a location cache entry for the destination node, it may tunnel the datagram to the mobile node's care-of address using the encapsulation techniques described for home agents in the base Mobile IP protocol specification [3]. When a node other than the foreign agent currently serving a mobile node receives a datagram for a mobile node, and this datagram has been tunneled to that node, the node tunneling the datagram generally has an out-of-date binding for the mobile node in its location cache. In such cases, the node receiving the tunneled datagram may send a Binding Warning message to the tunneling node, which should then request a new binding for the mobile node by sending a Binding Request message to the mobile node's home agent. Similarly, when a mobile node's home agent intercepts a datagram on the home network and tunnels it to the mobile node, the originating node typically has no location cache entry for the destination mobile node. In such cases, the home agent may send a Binding Update message to the originator. 6.1. Cache Management A node maintaining a location cache may use any reasonable strategy for managing the space within the cache. When a new entry needs to be added to the location cache, the node may choose to drop any entry already in the cache, if needed, to make space for the new entry. For example, a "least-recently used" (LRU) strategy for cache entry replacement is likely to work well. Each binding in the location cache also has an associated lifetime, specified by in the Binding Update message in which the node obtained the binding. After the expiration of this time period, the binding MUST be dropped from the cache. 6.2. Receiving Binding Warning Messages A node maintaining and using a location cache will receive a Binding Warning message if its location cache entry for a datagram it has tunneled is out-of-date, as determined by the node which receives the tunneled datagram. The node receiving the Binding Warning message then constructs a Binding Request message to obtain a new binding from the home agent serving the mobile node. Included in the Binding Request message is a 64-bit identification field, in the same format Johnson, Perkins, Myles Expires 15 September 1995 [Page 24] Internet Draft Route Optimization in Mobile IP 15 March 1995 described in the base Mobile IP protocol document, for matching the request with the returned Binding Update message. The node should silently discard any Binding Update messages that do not correspond with its latest Binding Request message for this mobile node. 6.3. Receiving Binding Update Messages When a node receives a Binding Update message, it uses the authentication technique indicated by the mobility security association between itself and the mobile node's home agent. The authentication data is found in the Route Optimization Authentication Extension (Section 4.2). If the authentication succeeds, then a location cache entry may be updated for use in future transmissions of data to the mobile node. Otherwise, an authentication exception SHOULD be raised. 6.4. Using Special Tunnels Whenever any node receives a tunneled datagram for a mobile node, for which no location cache entry or visitor list entry is known, the node may determine that it has received the tunneled datagram in error. In this case, the node should use a "special tunnel" to make sure the datagram arrives at the home agent for the mobile node. The home agent will then notify the originator of the tunnel about its out-of-date location cache entry, and take steps to deliver the datagram to the current care-of address of the mobile node. As part of this service, the home agent must also check to make sure that the datagram is not tunneled again to the node originating the special tunnel. Johnson, Perkins, Myles Expires 15 September 1995 [Page 25] Internet Draft Route Optimization in Mobile IP 15 March 1995 7. Home Agent Considerations The home agent will be the frequent source of and Binding Update messages sent to correspondent nodes which are communicating with its mobile nodes. Any correspondent node which has no cached bindings for a mobile node, will send normal, untunneled datagrams through the home agent by the normal routing in the Internet. When the home agent first gets a datagram for a mobile node, it SHOULD also send a Binding Update message to the originator of the datagram in hopes that the originator will be able to create a location cache entry for that mobile node. Then, future transmissions for the mobile node will not necessarily involve the home agent. As time goes on, more and more Internet nodes will be able to maintain location caches, and it is hoped that home agents will need to be involved only rarely with routing datagrams to mobile nodes. This might usually happen only when correspondent nodes first try to initiate a session from a mobile node which has not been in contact with the correspondent node for a long period of time. 7.1. Rate Limiting A home agent must provide some mechanism to limit the rate at which it sends Binding Update messages to to the same node about any given mobility binding, after tunneling a datagram intercepted on the home network. This is especially true because it is expected that most Internet nodes will not be equipped with location caches for a long time, and continual transmissions of Binding Warning messages to such nodes will only exacerbate the problem of the traffic bottleneck at the home agent. 7.2. Receiving Binding Request Messages 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 'P' bit in its Registration Request, then the home agent must not satisfy any binding Requests. Nevertheless, the home agent can return an empty Binding Update, with a zero care-of address and zero lifetime, so that the correspondent node will not go to the trouble of trying to obtain a binding. This situation can never arise by the action of any correctly operating node maintaining a location cache, but it is still possible that an intelligent correspondent node might try to obtain bindings for mobile nodes. Johnson, Perkins, Myles Expires 15 September 1995 [Page 26] Internet Draft Route Optimization in Mobile IP 15 March 1995 7.3. Receiving Registration Key requests When the home agent receives a Registration Request message, it may also be asked to compute registration keys for use with foreign agent handoffs (Section 2.2). In that event, the home agent employs a good algorithm for producing random keys [2] and encrypts the result separately for use by the foreign agent and by the mobile node. The chosen key is encrypted under a key and algorithm shared between the home agent and the mobile node, and the encrypted key is placed in a Mobile Node Registration Key extension (Section 4.4) in the Registration Reply message. The same key also is encrypted under a key and algorithm shared between the home agent and the foreign agent, and the encrypted key is placed in a Foreign Agent Registration Key extension (Section 4.5) in the Registration Reply message. By default, the home agent uses its mobility security association for the mobile node and for the foreign agent to encrypt the registration key. If the home agent has no preestablished mobility security association with the foreign agent and the Registration Key Request extension contained a public key from the foreign agent, the home agent may instead use this key to encrypt the registration key for the foreign agent. 7.4. Receiving Special Tunnels The home agent can also receive tunneled datagrams destined for the mobile node. If the tunnel source is the same as the foreign agent shown in the home list entry for the mobile node, then the home agent MUST NOT send the datagram back to that same foreign agent. Otherwise, the home agent can tunnel the tunneled datagram to the current foreign agent, encapsulating the incoming tunneled datagram in its entirety. The home agent also, in this case, takes responsibility for sending information to the originator of the datagram (whose source address will be in the inner datagram header inside the encapsulation), to allow that originator to update its location cache entry for the target mobile node. If the home agent has a mobility security association with the correspondent node which originated the datagram, an authenticated Binding Update message can be sent directly. Johnson, Perkins, Myles Expires 15 September 1995 [Page 27] Internet Draft Route Optimization in Mobile IP 15 March 1995 8. Foreign Agent Considerations In addition to managing the resources needed to handle basic Mobile IP registrations, the foreign agent assisting with Route Optimization assumes two additional responsibilities. The first is the maintenance of a location cache for forwarding datagrams to mobile nodes as they switch connections to new foreign agents. The second is a slight modification of the registration procedure, to allow for timely notification possible for previous foreign agents. 8.1. Setting up Temporary Mobility Security Associations As part of the registration procedure, a mobile node and foreign agent can agree on a registration key. This registration key is, as described in Section 7.3, computed by the mobile node's home agent and transmitted back to the foreign agent along with the Registration Reply message. Within this document, the registration key is used only for authentication of a single Binding Update message; other uses for the registration key are possible, but are outside the scope of this discussion. For instance, the foreign agent and mobile node may negotiate to use the registration key to provide confidentiality along the wireless link connecting them. If a foreign agent is unable to process a registration request because the mobile node also expects a registration key, the foreign agent returns the appropriate status code immediately in a Registration Reply message. DISCUSSION: Alternatively, we could add a bit to the Agent Advertisement message. The actual request for the registration key is made by the mobile node (Section 2.2). Since the foreign agent and the home agent may have no mobility security association, the home agent cannot be assured of the identity of the foreign agent. This does not matter, however, for the production of the registration key. When the foreign agent receives the registration reply, with both foreign agent registration key extensions, it strips off the extension containing its own registration key, and relays the rest to the mobile node. This registration key can be trusted for the purposes outlined, even though the mobile node and the foreign agent cannot be expected to always authenticate each other's identity. They can, however, expect each other to follow the operational procedures comprising the Route Optimization protocols. Any further use made of the registration key must take into account the fact that the nodes involved have not yet mutually identified each other in a trustworthy fashion; they have Johnson, Perkins, Myles Expires 15 September 1995 [Page 28] Internet Draft Route Optimization in Mobile IP 15 March 1995 only agreed that the foreign agent will provide certain desirable services to the mobile node. 8.2. Previous Foreign Agent Notification When a mobile node registers with a new foreign agent, it may request that the new foreign agent send a Binding Update message to its previous foreign agent. This Binding Update must be authenticated, using the Route Optimization Authentication extension (Section 4.2), as must all Binding Updates. The Acknowledge bit in this Binding Update message must be set. When the previous foreign agent receives the Binding Update, it will use the mobility security association set up with the mobile node during its previous registration to authenticate the message. If the message authentication is correct, the old visitor list entry will be deleted and a Binding Acknowledge message returned to the sender. In addition, if a new care-of address was included with the new binding, a location cache entry will be created for it, and the previous foreign agent can tunnel datagrams to the mobile node's current care-of address using that location cache, just as any node maintaining a location cache. In particular, the previous foreign agent can tunnel the Binding Acknowledge message back to the new care-of address specified in the received binding. This creates an interesting problem for the new foreign agent when it receives the acknowledgment before the registration reply from the home agent. It is suggested that the new foreign agent deliver the acknowledgment to the mobile node anyway, even though the mobile node is technically unregistered. If there is concern that this provides a loophole for unauthorized traffic to the mobile node, the new foreign agent could limit the number of datagrams delivered to the unregistered mobile node to this single instance. Alternatively, a new extension to the Registration Reply message can be defined to carry along the acknowledgement from the previous foreign agent. This latter approach would have the benefit that fewer datagrams would be transmitted over bandwidth-constrained wireless media during registrations. The lifetime associated with the location cache, in this situation, can be substantially shorter than other location caches for several reasons. First, the home agent is presumably tunneling datagrams to the new foreign agent; second, any active correspondent node will probably get a new location cache entry for the mobile node after receiving the Binding Warning message from the previous foreign agent. Lastly, even if the location cache entry expires prematurely, Johnson, Perkins, Myles Expires 15 September 1995 [Page 29] Internet Draft Route Optimization in Mobile IP 15 March 1995 the previous foreign agent can special tunnel any straggling datagrams back to the home agent for further delivery. 8.3. Receiving Tunneled Datagrams If the mobile node's current foreign agent receives a tunneled datagram for the mobile node, it can be assumed that the tunneled datagram was originated by a node maintaining a location cache. There may be pathological or special cases where this assumption is false, but one would almost have to intentionally run custom code to invalidate the assumption. Since the foreign agent currently serving a mobile node can assume that the sending node forwarded the datagram based on correct location cache information, the foreign agent can also assume that the sending cache agent has already issued notification to the source of the original datagram. Thus, the current foreign agent never needs to send a Binding Warning message to the node which last tunneled the datagram. On the other hand, a foreign agent which is tunneling received datagrams on behalf of a mobile node not in its visitor list should, just as any other node implementing Route Optimization, send Binding Warning messages to the originator of these datagrams. If the datagrams it receives are not tunneled, the foreign agent should limit the rate at which it sends Binding Warning messages to the originators, since those originators may be unable to interpret such notifications. It is expected that reception of such un-tunneled datagrams by any foreign agent will be rare. 8.4. Sending Special Tunnels If a foreign agent receives a tunneled datagram for a mobile node which is unknown, then the foreign agent can tunnel the datagram back to the home agent. This requires special care at the home agent. The foreign agent must use the mobile node's address as the tunnel destination, and its own address as the tunnel source. The home agent will then capture the special tunneled datagram and re-tunnel it to the mobile node via its current foreign agent. The foreign agent sending the special tunnel should not notify the originator of the datagram about its out-of-date binding, as this will be done by the home agent which receives the special tunnel datagram. Johnson, Perkins, Myles Expires 15 September 1995 [Page 30] Internet Draft Route Optimization in Mobile IP 15 March 1995 9. Mobile Node Considerations 9.1. Requesting a Registration Key When a mobile node makes a registration request, it can request a registration key to be shared between itself and the prospective foreign agent. The key will be used to authenticate a future disconnection notice from the mobile node, when the mobile node has moved to a new cell. The mobile node allows the home agent to pick the registration key, because it is expected that the mobile node is less likely to have good means for computing pseudo-random numbers [2]. The registration key will be returned in an extension to the expected registration reply, and the foreign agent can use it to compute a "mobile-foreign" authentication extension to the registration reply. If this is done, the mobile node will have complete confidence that it does in fact share a secret registration key. If not, the mobile node can still act on the supposition that the key has been correctly received by the foreign agent, but the delivery of the key to the foreign agent can be compromised by an active attack which modifies some of the bits of the extension which the home agent uses to deliver the key to the foreign agent. In the latter case, the foreign agent does not have a good way to detect the corruption. Since the problem will only show up by possibly causing some datagrams to be lost after some unpredictably distant future movement by the mobile node, it is not absolutely required to test the validity of the registration key. If the mobile node detects that the foreign agent has a corrupted registration key, it can re-register immediately. 9.2. Notifying Previous Foreign Agents If the mobile node wishes to instruct its prospective foreign agent to send a Binding Update message to the mobile node's previous foreign agent, it uses the appropriate extension (see 4.1) to the Registration Request message. This usually results in quicker establishment of a location cache entry at the previous foreign agent, because the previous foreign agent is likely to be much closer to the new foreign agent than the home agent is. Since the prospective new foreign agent does not have access to the registration key which was established between the mobile node and its previous foreign agent, the mobile node has to compute the appropriate authentication value for use by the prospective foreign agent. This authentication is computed over the fields of the expected Binding Update message, with the 'I' bit set and no identification present. Reply protection is considered unnecessary Johnson, Perkins, Myles Expires 15 September 1995 [Page 31] Internet Draft Route Optimization in Mobile IP 15 March 1995 since the binding update is expected to be sent only once with the registration key. When the acknowledgment arrives, the new foreign agent detunnels it and sends it to the mobile node. In this way, the mobile node can still discover that its previous foreign agent has updated its visitor list and location cache. This is important, because otherwise the previous foreign agent would often become a "black hole" for datagrams destined for the mobile node. The new foreign agent has no further responsibility for helping to update the location cache at the previous foreign agent. The mobile node expects to eventually receive an acknowledgement from its previous foreign agent, signifying that the mobile node's entry has been erased from its visitor list. If the acknowledgement has not been received after sufficient time, the mobile node is responsible for retransmitting another Binding Update message to its previous foreign agent. Although the previous foreign agent may have already deleted the registration key from its records, the mobile node should continue to retransmit its Binding Update message until the previous foreign agent responds with either a positive or negative acknowledgment. Since the mobile node is responsible for fielding the acknowledgement from its previous foreign agent, there is no need to add any status code or bit to the Registration Reply from its prospective new foreign agent Johnson, Perkins, Myles Expires 15 September 1995 [Page 32] Internet Draft Route Optimization in Mobile IP 15 March 1995 References [1] Ralph Droms. Dynamic Host Configuration Protocol. RFC 1541, October 1993. [2] Donald E. Eastlake 3rd, Stephen D. Crocker, and Jeffrey I. Schiller. Randomness recommendations for security. RFC 1750, December 1994. [3] Charles Perkins, editor. IP mobility support. Internet Draft, draft-ietf-mobileip-protocol-08.txt, January 1995. Work in progress. Johnson, Perkins, Myles Expires 15 September 1995 [Page 33] Internet Draft Route Optimization in Mobile IP 15 March 1995 Appendix A. Using a Master Key at the Home Agent Rather than storing each mobility security association that it has established with many different correspondent nodes and foreign agents, a home agent may manage its mobility security associations so that each of them can be generated from a single "master" key. With the master key, the home agent could build a key for any given other node by computing the node-specific key as MD5(node-address || master-key || node-address) where node-address is the IP address of the particular node for which the home agent is building a key, and master-key is the single master key held by the home agent for all mobility security associations it has established with correspondent nodes. The node-specific key is built by computing an MD5 hash over a string consisting of the master key with the node-address concatenated as a prefix and as a suffix. Using this scheme, when establishing each mobility security association, the network administrator managing the home agent computes the node-specific key and communicates this key to the network administrator of the other node through some "secure" channel, such as over the telephone. The mobility security association is configured at this other node in the same way as any mobility security association. At the home agent, though, no record need be kept that this key has been given out. The home agent need only be configured to know that this scheme is in use for all of its mobility security associations. When the home agent then needs a mobility security association as part of the Route Optimization protocol, it builds the node-specific key based on the master key and the IP address of the other node with which it is attempting to authenticate. If the other node knows the correct node-specific key, the authentication will succeed; otherwise, it will fail as it should. Johnson, Perkins, Myles Expires 15 September 1995 [Page 34] Internet Draft Route Optimization in Mobile IP 15 March 1995 Chairs' Addresses The working group can be contacted via the current chairs: Tony Li cisco Systems 170 W. Tasman Dr. San Jose CA 95134 Phone: +1-408-526-8186 E-mail: tli@cisco.com Jim Solomon Motorola, Inc. Phone: +1-708-576-2753 E-mail: solomon@comm.mot.com Johnson, Perkins, Myles Expires 15 September 1995 [Page 35] Internet Draft Route Optimization in Mobile IP 15 March 1995 Authors' Addresses Questions about this document can also be directed to the authors: David B. Johnson Computer Science Department Carnegie Mellon University 5000 Forbes Avenue Pittsburgh, PA 15213-3891 Phone: +1-412-268-7399 Fax: +1-412-268-5576 E-mail: dbj@cs.cmu.edu Charles Perkins Room J1-A25 T. J. Watson Research Center IBM Corporation 30 Saw Mill River Rd. Hawthorne, NY 10532 Phone: +1-914-784-7350 Fax: +1-914-784-7007 E-mail: perk@watson.ibm.com Andrew Myles Electronics Department Macquarie University 2109 Sydney, Australia Phone: +61-2-8059071 Fax: +61-2-8059128 E-mail: andrewm@mpce.mq.edu.au Johnson, Perkins, Myles Expires 15 September 1995 [Page 36]