Mobile IP Working Group David B. Johnson INTERNET DRAFT Carnegie Mellon University 22 November 1995 Charles Perkins IBM Corporation Route Optimization in Mobile IP draft-ietf-mobileip-optim-03.txt 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 document 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". 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 and Perkins Expires 22 May 1996 [Page i] Internet Draft Route Optimization in Mobile IP 22 November 1995 Abstract This document defines extensions to the operation of the base 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 binding 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 binding, to be forwarded directly to the mobile node's new binding. Johnson and Perkins Expires 22 May 1996 [Page ii] Internet Draft Route Optimization in Mobile IP 22 November 1995 Contents Status of This Memo i Abstract ii 1. Introduction 1 2. Route Optimization Overview 3 2.1. Binding Caching . . . . . . . . . . . . . . . . . . . . . 3 2.2. Foreign Agent Handoff . . . . . . . . . . . . . . . . . . 3 2.3. Binding Cache Updates . . . . . . . . . . . . . . . . . . 5 2.4. Registration Key Establishment Using the Home Agent . . . 7 2.5. Registration Key Establishment Using Diffie-Hellman . . . 8 3. Route Optimization Message Formats 10 3.1. Binding Warning Message . . . . . . . . . . . . . . . . . 11 3.2. Binding Request Message . . . . . . . . . . . . . . . . . 12 3.3. Binding Update Message . . . . . . . . . . . . . . . . . 13 3.4. Binding Acknowledge Message . . . . . . . . . . . . . . . 15 3.5. Registration Request Message . . . . . . . . . . . . . . 17 4. Route Optimization Extension Formats 18 4.1. Previous Foreign Agent Notification Extension . . . . . . 19 4.2. Route Optimization Authentication Extension . . . . . . . 21 4.3. Home Agent Registration Key Request Extension . . . . . . 22 4.4. Mobile Node Registration Key Reply Extension . . . . . . 23 4.5. Foreign Agent Registration Key Reply Extension . . . . . 24 4.6. Diffie-Hellman Registration Key Request Extension . . . . 25 4.7. Diffie-Hellman Registration Key Reply Extension . . . . . 27 4.8. Mobile Service Extension . . . . . . . . . . . . . . . . 28 5. Mobility Security Association Management 29 6. Binding Cache Considerations 31 6.1. Cache Management . . . . . . . . . . . . . . . . . . . . 31 6.2. Receiving Binding Warning Messages . . . . . . . . . . . 31 6.3. Receiving Binding Update Messages . . . . . . . . . . . . 32 6.4. Using Special Tunnels . . . . . . . . . . . . . . . . . . 32 7. Home Agent Considerations 34 7.1. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . 34 7.2. Receiving Binding Request Messages . . . . . . . . . . . 34 7.3. Receiving Registration Key Requests . . . . . . . . . . . 34 Johnson and Perkins Expires 22 May 1996 [Page iii] Internet Draft Route Optimization in Mobile IP 22 November 1995 7.4. Receiving Special Tunnels . . . . . . . . . . . . . . . . 35 8. Foreign Agent Considerations 36 8.1. Establishing a Registration Key . . . . . . . . . . . . . 36 8.2. Previous Foreign Agent Notification . . . . . . . . . . . 37 8.3. Receiving Tunneled Datagrams . . . . . . . . . . . . . . 38 8.4. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . 39 8.5. Sending Special Tunnels . . . . . . . . . . . . . . . . . 39 9. Mobile Node Considerations 40 9.1. Establishing a Registration Key . . . . . . . . . . . . . 40 9.2. Notifying Previous Foreign Agents . . . . . . . . . . . . 40 References 42 Appendix A. Using a Master Key at the Home Agent 43 Chairs' Addresses 44 Authors' Addresses 45 Johnson and Perkins Expires 22 May 1996 [Page iv] Internet Draft Route Optimization in Mobile IP 22 November 1995 1. Introduction The base Mobile IP protocol [6] 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 [3] 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 scheme allows transparent interoperation with mobile nodes, but forces all datagrams for a mobile node to be routed through its home agent; datagrams 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 base 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 binding of a mobile node and to then tunnel their own datagrams directly to the care-of address indicated in that binding, 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 Johnson and Perkins Expires 22 May 1996 [Page 1] Internet Draft Route Optimization in Mobile IP 22 November 1995 based on an out-of-date cached binding, 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 base 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 base 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 binding 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 and Perkins Expires 22 May 1996 [Page 2] Internet Draft Route Optimization in Mobile IP 22 November 1995 2. Route Optimization Overview 2.1. Binding Caching Route Optimization provides a means for any node that wishes to optimize its own communication with mobile nodes to maintain a "binding 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 binding 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 binding 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 base 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 binding 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 binding 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 binding cache will, by necessity, have a finite size. Any node implementing a binding cache may manage the space in its cache using any local cache replacement policy. If a datagram is sent by a node to a destination for which it has dropped the cache entry from its binding cache, the datagram will be routed normally, leading to the mobile node's home network, where it will be intercepted by the mobile node's home agent and tunneled to the mobile node's care-of address. As when a binding cache entry is initially created, 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 binding cache. 2.2. Foreign Agent Handoff When a mobile node moves and registers with a new foreign agent, the base Mobile IP protocol does not notify the mobile node's previous Johnson and Perkins Expires 22 May 1996 [Page 3] Internet Draft Route Optimization in Mobile IP 22 November 1995 foreign agent. IP datagrams intercepted by the home agent after the new registration are tunneled to the mobile node's new care-of 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 binding 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. Optionally, during registration with a new foreign agent, the mobile node and the foreign agent may establish a new shared secret key as a "registration key". When the mobile node later 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 binding 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 agent after this binding 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 binding cache entry. The registration key is used to authenticate the notification sent to the previous foreign agent. Other uses of the registration key are possible, such as for use as an encryption key for providing privacy over a wireless link between the mobile node and its foreign agent, but such uses are beyond the scope of this document. Once established, the registration key for a mobile node can be stored by the foreign agent with the mobile node's visitor list entry. 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 Johnson and Perkins Expires 22 May 1996 [Page 4] Internet Draft Route Optimization in Mobile IP 22 November 1995 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 binding cache entry created at the mobile node's previous foreign agent is treated in the same way as any other binding cache entry. In particular, it is possible that this binding 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 the mobile node's 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.5), destined to the mobile node. This use of a "special tunnel" avoids a possible routing loop in the case in which the case-of address registered at the home agent is the address of this node, but this node has forgotten that it is serving as the mobile node's foreign agent, perhaps because the node has crashed and lost its visitor list state. The "special tunnel" allows the home agent to see the address of the node that tunneled the datagram, and to avoid tunneling the datagram back to the same node. 2.3. Binding 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 source of the datagram has no binding cache entry for the destination mobile node. In this case, the home agent MAY send a Binding Update message to the original source node, informing it of the mobile node's current mobility binding. Johnson and Perkins Expires 22 May 1996 [Page 5] Internet Draft Route Optimization in Mobile IP 22 November 1995 No acknowledgement for this Binding Update message is needed, since additional future datagrams from this source node intercepted by the home agent for the mobile node will cause transmission of another Binding Update. In order for this Binding Update to be authenticated by the original source node, the home agent and this source node must have established a mobility security association. Similarly, when any node receives a tunneled datagram that was tunneled to this node, if it is not the current foreign agent serving the destination (it has no visitor list entry for this mobile node), the node receiving this tunneled datagram may deduce that the tunneling node has an out-of-date binding cache entry for the destination mobile node. In this case, the receiving node MAY send a Binding Warning message to the tunneling node, advising it that its binding cache entry for the mobile node is out-of-date. As in the case of a Binding Update sent by the mobile node's home agent, no acknowledgement of this Binding Warning is needed, since additional future datagrams for the mobile node tunneled by the same node will cause the transmission of another Binding Warning. However, unlike the Binding Update message, 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; when the Binding Update message is received, the node may then create a binding 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. DISCUSSION: An alternative design would be to send a Binding Warning-like message directly to the home agent, which would then send a Binding Update to the correspondent node. This accomplishes the same thing in 2 messages instead of 3 (Binding Warning, Binding Request, Binding Update), but the authentication of the binding may be more difficult without a request-update exchange between the correspondent node and the home agent. In particular, the two-way exchange between the correspondent node and the home agent provides a means to return the new value to be used as a nonce for the next authentication, in the case in which nonces are being used for replay protection. Each Binding Update message indicates the maximum lifetime of any binding cache entry created from the Binding Update. When sending Johnson and Perkins Expires 22 May 1996 [Page 6] Internet Draft Route Optimization in Mobile IP 22 November 1995 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 binding 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 binding cache entry may attempt to reconfirm that mobility binding before the expiration of this lifetime period. Such reconfirmation of a binding cache entry may be appropriate when the node has indications (such as an open transport-level connection to the mobile node) that the binding 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. 2.4. Registration Key Establishment Using the Home Agent One method of establishing a registration key is for the mobile node to request its home agent to generate one during registration, and for the home agent to send a copy of this key to both the mobile node and its new foreign agent. The home agent in this case acts as a "key distribution center" (KDC) for the mobile node and the foreign agent. The mobile node requests this by including a Home Agent Registration Key Request extension in its Registration Request message. The home agent sends the generated key to the mobile node and to its foreign agent by including a Mobile Node Registration Key Reply extension and a Foreign Agent Registration Key Reply extension its Registration Reply message. The Mobile Node Registration Key Reply extension contains 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 Reply extension contains 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 using this method, the foreign agent must have a mobility security association with the home agent. For example, if mobile nodes from some home network often visit this foreign agent, it may in general be worth the effort of creating such a mobility security association between this foreign agent and the home agent serving that home network. If no mobility security association exists, a mobile node may instead be able to establish a registration key with its home agent using the alternative method described in the next section. Johnson and Perkins Expires 22 May 1996 [Page 7] Internet Draft Route Optimization in Mobile IP 22 November 1995 2.5. Registration Key Establishment Using Diffie-Hellman An alternate method defined in this document for establishing a registration key is for the mobile node and its foreign agent to execute the Diffie-Hellman key exchange algorithm [2] as part of the mobile node's registration. The Diffie-Hellman algorithm is a public key cryptosystem that allows two parties to establish a shared secret key, such that the shared secret key cannot be determined by other parties overhearing the messages exchanged during the algorithm. It is used, for example, in other protocols that require a key exchange, such as in the Cellular Digital Packet Data (CDPD) system [1]. Briefly, the Diffie-Hellman algorithm involves the use of two large public numbers, a Prime number (p) and a Generator (g). The Prime number and the Generator must be known by both parties involved in the algorithm, but need not be kept secret; these values may be different for each execution of the algorithm and are not used once the algorithm completes. Each party chooses a private random number, produces a Computed Value based on this random number and the Prime and the Generator, and sends the Computed Value in a message to the other party. Each party then computes the (same) shared secret key using its own private random number, the Computed Value received from the other party, and the Prime and Generator values. To use this algorithm during registration with a foreign agent, the mobile node includes a Diffie-Hellman Registration Key Request extension in its Registration Request message, containing its values for the Prime and Generator, along with the Computed Value from its own private random number. The foreign agent then choses its own private random number and includes a Diffie-Hellman Registration Key Reply extension in its Registration Reply message to the mobile node; the extension includes the foreign agent's own Computed Value based on its chosen random number and the supplied Prime and Generator values from the mobile node. The mobile node and foreign agent each independently form the (same) shared secret key from their own chosen random number, the Computed Value supplied by the other party, and the Prime and Generator values. The Diffie-Hellman algorithm allows the mobile node and its foreign agent to establish a registration key without any pre-existing mobility security associations, but the Diffie-Hellman algorithm itself is covered by a patent in the United States. The method of establishing a registration key using Diffie-Hellman thus may not be usable by those who have not licensed the patent. An implementation of the Diffie-Hellman key exchange algorithm is available, though, in the free RSAREF toolkit from RSA Laboratories [7]. Also, establishing a registration key using Diffie-Hellman is computationally more expensive than the method described in Johnson and Perkins Expires 22 May 1996 [Page 8] Internet Draft Route Optimization in Mobile IP 22 November 1995 Section 2.4. The use of Diffie-Hellman described here, though, is designed to allow the Diffie-Hellman computations to be overlapped with other activities. The mobile node may choose (or be manually configured with) the Prime and Generator values at any time, or may use the same two values for a number of registrations. The mobile node may also choose its private random number and compute its Computed Value at any time. For example, after completing one registration, the mobile node may choose the private random number for its next registration and begin the computation of its new Computed Value based on this random number, such that it has completed this computation before it is needed in its next registration; in its simplest form, the mobile node may use the same private random number and Computed Value for any number of registrations. The foreign agent may choose its private random number and begin computation of its Computed Value based on this number as soon as it receives the mobile node's Registration Request message, and need only complete this computation before it sends the matching Registration Reply message for the mobile node's registration. The Agent Advertisement message (Mobile Service extension) is revised under Route Optimization to include a bit to indicate that the foreign agent sending the advertisement supports this method of registration key establishment using the Diffie-Hellman algorithm. If this bit is not set in the Agent Advertisement from the foreign agent, the mobile node MUST NOT send a Diffie-Hellman Registration Key Request extension to the foreign agent in its Registration Request message. DISCUSSION: This could be extended to support other similar key exchange algorithms, either by adding a new Request and Reply extension for each, or by adding a field in the extensions to indicate which algorithm is to be used. Diffie-Hellman seems the only obvious choice, though, currently. Johnson and Perkins Expires 22 May 1996 [Page 9] Internet Draft Route Optimization in Mobile IP 22 November 1995 3. Route Optimization Message Formats Route Optimization defines four message types used for management of binding 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 Route Optimization also requires one minor change to existing Mobile IP messages: a new flag bit must be added to the Registration Request message, replacing a previously unused, reserved bit in the message. This section describes each of the new Route Optimization messages and the change to Registration Request message. Johnson and Perkins Expires 22 May 1996 [Page 10] Internet Draft Route Optimization in Mobile IP 22 November 1995 3.1. Binding Warning Message A Binding Warning message is used to advise a node that it appears to have either no binding cache entry or an out-of-date binding 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 and Perkins Expires 22 May 1996 [Page 11] Internet Draft Route Optimization in Mobile IP 22 November 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 binding 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 and Perkins Expires 22 May 1996 [Page 12] Internet Draft Route Optimization in Mobile IP 22 November 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|M|G| Rsvd | 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 Identification Present (I) bit is set by the node sending the Binding Update message to indicate that the Identification field is present in the message. Minimal Encapsulation (M) If the Minimal Encapsulation (M) bit is set, datagrams may be tunneled to the mobile node using the minimal encapsulation protocol used in the base Mobile IP protocol. Johnson and Perkins Expires 22 May 1996 [Page 13] Internet Draft Route Optimization in Mobile IP 22 November 1995 GRE Encapsulation (G) If the GRE Encapsulation (G) bit is set, datagrams may be tunneled to the mobile node using the GRE encapsulation protocol [5]. Reserved (Rsvd) Sent as 0; ignored on reception. Lifetime The number of seconds remaining before the binding cache entry must be considered expired. A value of all ones indicates infinity. A value of zero indicates that no binding cache entry for the mobile node should be created and that any existing binding 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 binding cache entry for the mobile node should be created, and any existing binding 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 and Perkins Expires 22 May 1996 [Page 14] Internet Draft Route Optimization in Mobile IP 22 November 1995 3.4. Binding Acknowledge Message A Binding Acknowledge message is used to acknowledge receipt of a Binding Update message. It SHOULD be 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 Negative Acknowledge (N) If the Negative Acknowledge (N) bit is set, this acknowledgement is negative. For instance, if the binding update was not accepted, but the incoming datagram has the Acknowledge flag set, then the Negative Acknowledge (N) bit SHOULD be 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, so perhaps the exact reason for the error isn't that useful. Reserved Sent as 0; ignored on reception. Mobile Node Home Address Copied from the Binding Update message being acknowledged. Johnson and Perkins Expires 22 May 1996 [Page 15] Internet Draft Route Optimization in Mobile IP 22 November 1995 Identification Copied from the Binding Update message being acknowledged, if present there. Johnson and Perkins Expires 22 May 1996 [Page 16] Internet Draft Route Optimization in Mobile IP 22 November 1995 3.5. Registration Request Message One bit is added to the flag bits in the Registration Request message to indicate that the mobile node would like its home agent to keep its mobility binding "private". Normally, the home agent sends Binding Update messages to correspondent nodes as needed to allow them to cache the mobile node's binding. If the mobile node sets the Private (P) bit in the Registration Request message, the home agent MUST not send the mobile node's binding in Binding Update messages. Instead, each Binding Update message should give the mobile node's care-of address equal to its home address, and should give a Lifetime value of 0. Thus, the Registration Request message under Route Optimization begins as follows: 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 |S|B|D|M|G|P|rvd| Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (unchanged...) +-+-+- Private (P) The Private (P) bit is set by the node sending the Binding Update message to indicate that the home agent should keep its mobility binding private. In any Binding Update message sent by the mobile node's home agent, the care-of address should be set equal to the mobile node's home address, and the Lifetime should be set equal to 0. Johnson and Perkins Expires 22 May 1996 [Page 17] Internet Draft Route Optimization in Mobile IP 22 November 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 = Home Agent Registration Key Request Extension 99 = Mobile Node Registration Key Reply Extension 100 = Foreign Agent Registration Key Reply Extension 101 = Diffie-Hellman Registration Key Request Extension 102 = Diffie-Hellman Registration Key Reply Extension Route Optimization also requires one minor change to existing Mobile IP message extensions: a new flag bit must be added to the Mobile Service extension, replacing a previously unused, reserved bit in the extension. This section describes each of the new Route Optimization message extensions and the change to Mobile Service extension. Johnson and Perkins Expires 22 May 1996 [Page 18] Internet Draft Route Optimization in Mobile IP 22 November 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 to the mobile node's previous foreign agent on behalf of the mobile node, to notify it that the mobile node has moved. The previous foreign agent deletes the mobile node's visitor list entry and, if a new care-of address is included in the Binding Update message, also creates a binding cache entry for the mobile node pointing to its new care-of address. The Previous Foreign Agent Notification extension contains only those values not otherwise already contained in the Registration Request message that 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | New Care-of Address Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authenticator ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 96 Length 10 plus the length of the Authenticator Cache Lifetime The number of seconds remaining before the binding 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 binding 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. Johnson and Perkins Expires 22 May 1996 [Page 19] Internet Draft Route Optimization in Mobile IP 22 November 1995 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. New Care-of Address The new care-of address for the new foreign agent to send in the Binding Update message to the previous foreign agent. This SHOULD be either the care-of address being registered in this new registration (i.e., to cause IP datagrams from the previous foreign agent to be tunneled to the new foreign agent) or the mobile node's home address (i.e., to cause the previous foreign agent to only delete its visitor list entry for the mobile node). 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 and Perkins Expires 22 May 1996 [Page 20] Internet Draft Route Optimization in Mobile IP 22 November 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 value computed from a stream of bytes including the shared secret, the UDP payload (that is, the Route Optimization management message), all prior extensions in their entirety, and the type and length of this extension, but not including the Authenticator field itself nor the UDP header. Johnson and Perkins Expires 22 May 1996 [Page 21] Internet Draft Route Optimization in Mobile IP 22 November 1995 4.3. Home Agent Registration Key Request Extension The Home Agent Registration Key Request extension may be used in Registration Request messages to request a registration key from the mobile node's home agent. The extension is included in the Registration Request message by the mobile node. It 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 Home Agent Registration Key Request extension, the home agent MAY include a Mobile Node Registration Key Reply extension and a Foreign Agent Registration Key Reply extension in its Registration Reply message, containing encrypted copies of the (same) new registration key for the mobile node and the foreign agent, respectively. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 98 Length 0 The mobility security association assumed to exist between the home agent and the mobile node will be used to encrypt the key sent in the Mobile Node Registration Key Reply extension, unless a Key Identification extension is also included with the Registration Request message. The home agent must also share a mobility security association with the foreign agent in order to return the requested registration key, and the home agent will use this security association to encrypt the key sent in the Foreign Agent Registration Key Reply extension. Johnson and Perkins Expires 22 May 1996 [Page 22] Internet Draft Route Optimization in Mobile IP 22 November 1995 4.4. Mobile Node Registration Key Reply Extension The Mobile Node Registration Key Reply extension may be used in 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 Reply 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 Reply 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 under 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 and Perkins Expires 22 May 1996 [Page 23] Internet Draft Route Optimization in Mobile IP 22 November 1995 4.5. Foreign Agent Registration Key Reply Extension The Foreign Agent Registration Key Reply extension may be used in 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 Reply extension in the Registration Reply message, giving a copy of the same key to the mobile node. The Foreign Agent Registration Key Reply 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. In order for this extionsion to be used, the home agent MUST share a mobility security association with 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 under the mobility security association between the home agent and the foreign agent. 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 value computed from a stream of bytes including the shared secret and the fields in this extension other than the Authenticator field itself. Johnson and Perkins Expires 22 May 1996 [Page 24] Internet Draft Route Optimization in Mobile IP 22 November 1995 4.6. Diffie-Hellman Registration Key Request Extension The Diffie-Hellman Registration Key Request extension may be included in a Registration Request message sent to a foreign agent. It begins the Diffie-Hellman key exchange algorithm [2] between the mobile node and its new foreign agent, as described in Section 2.5. The foreign agent SHOULD then include a Diffie-Hellman Registration Key Reply extension in its Registration Reply message sent to the mobile node in order to complete the key exchange. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prime ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Generator ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Computed Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 101 Length 3 times the length of each of Prime, Generator, and Computed Value. The values Prime, Generator, and Computed Value must all be the same length, which must be a multiple of 8 bits. Prime One of the two public numbers involved in the Diffie-Hellman key exchange algorithm. The value Prime should be a large prime number. Generator One of the two public numbers involved in the Diffie-Hellman key exchange algorithm. If p is the value of the Prime used for this Diffie-Hellman exchange, the value Generator should be less than p, and should be a primitive root of p. Johnson and Perkins Expires 22 May 1996 [Page 25] Internet Draft Route Optimization in Mobile IP 22 November 1995 Computed Value The public computed value from the mobile node for this Diffie-Hellman exchange. The mobile node chooses a large random number, x. If g is the value of the Generator and p is the value of the Prime, the Computed Value in the extension is (g**x) mod p. Johnson and Perkins Expires 22 May 1996 [Page 26] Internet Draft Route Optimization in Mobile IP 22 November 1995 4.7. Diffie-Hellman Registration Key Reply Extension The Diffie-Hellman Registration Key Reply extension SHOULD be included in a Registration Reply message sent by a foreign agent to a mobile node that included a Diffie-Hellman Registration Key Request extension in its Registration Request message to 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Computed Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 101 Length The length of the Computed Value. The length of the Computed Value must be a multiple of 8 bits. Computed Value The foreign agent chooses a large random number, y. If g is the value of the Generator and p is the value of the Prime, the Computed Value in the extension is (g**y) mod p. The values of the Generator and Prime are taken from the Diffie-Hellman Registration Key Request extension from the mobile node's Registration Request message. Johnson and Perkins Expires 22 May 1996 [Page 27] Internet Draft Route Optimization in Mobile IP 22 November 1995 4.8. Mobile Service Extension One bit is added to the flag bits in the Mobile Service extension (forming an Agent Advertisement message), when sent by a foreign agent, to indicate that the foreign agent supports registration key establishment using the Diffie-Hellman key exchange algorithm. When this bit is set in the Agent Advertisement, the mobile node MAY request a registration key be established by including a Diffie-Hellman Registration Key Request extension in its Registration Request message. The foreign agent replies with the Diffie-Hellman Registration Key Reply extension in its Registration Reply to the mobile node. Thus, the Mobile Service extension under Route Optimization begins as follows: 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 | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime |R|B|H|F|M|G|D| reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (unchanged...) +-+-+- Diffie-Hellman (D) The Diffie-Hellman (D) bit is set by the foreign agent sending the Agent Advertisement message to indicate that it supports the registration key establishment protocol using the Diffie-Hellman Registration Key Request and Diffie-Hellman Registration Key Reply extensions. Johnson and Perkins Expires 22 May 1996 [Page 28] Internet Draft Route Optimization in Mobile IP 22 November 1995 5. Mobility Security Association Management 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 base 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 currently 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. However, with Route Optimization, authentication is more difficult to manage, since a Binding Update may in general need to be sent to any node in the Internet. Since no general authentication or key distribution protocol is available in the Internet today, the Route Optimization procedures defined in this document make use of the same type of manually configured mobility security associations used in the base Mobile IP protocol. 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 [6]. For a correspondent node to be able to create a binding cache entry for a mobile node, 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 binding 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 home agent to have a manually established mobility security association with the foreign agents often used by its mobile nodes, or for a particular mobile node to have a manually established mobility security association with the foreign agents serving the foreign networks that it often visits. Johnson and Perkins Expires 22 May 1996 [Page 29] Internet Draft Route Optimization in Mobile IP 22 November 1995 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. Without establishing a mobility security association, nodes will not currently be able to use the Route Optimization extensions but can use the base Mobile IP protocol. Johnson and Perkins Expires 22 May 1996 [Page 30] Internet Draft Route Optimization in Mobile IP 22 November 1995 6. Binding Cache Considerations Any node may maintain a binding cache in order to optimize its own communication with mobile nodes. When sending an IP datagram, if the sending node has a binding 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 [6]. Any optional encapsulation methods supported are indicated by flag bits in the Binding Update message. When a mobile node's home agent intercepts a datagram on the home network and tunnels it to the mobile node, the originating node generally has no binding cache entry for the destination mobile node. In such cases, the home agent MAY send a Binding Update message to the originator. Similarly, 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 binding 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. 6.1. Cache Management A node maintaining a binding cache may use any reasonable strategy for managing the space within the cache. When a new entry needs to be added to the binding 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 binding 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 deleted from the cache. 6.2. Receiving Binding Warning Messages A node maintaining and using a binding cache will receive a Binding Warning message if its binding cache entry for a datagram it has tunneled is out-of-date, as determined by the node which receives the tunneled datagram. When a node receives a Binding Warning Johnson and Perkins Expires 22 May 1996 [Page 31] Internet Draft Route Optimization in Mobile IP 22 November 1995 message, it SHOULD request an updated binding for this mobile node from the mobile node's home agent, using a Binding Request message. Included in the Binding Request message is a 64-bit identification field, in the same format described in the base Mobile IP protocol specification, 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 MUST verify the authentication in the message, using the mobility security association it shares with 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 binding cache entry SHOULD 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 for which it has no visitor list entry for the datagram's destination, the node may deduce that the tunneling node has an out-of-date binding cache entry for the destination mobile node. If the node receiving the tunneled datagram has a binding cache entry for the destination, it SHOULD re-tunnel the datagram to the care-of address indicated in this binding cache entry. However, if the node receiving the tunneled datagram has no binding cache entry for the destination, it cannot re-tunnel the node to its destination. Instead, the node SHOULD forward the datagram to the destination mobile node's home agent, using a special form of tunneling called a "special tunnel". To tunnel the datagram using a special tunnel, the tunneled datagram's destination address is set equal to the destination address in the tunneled datagram. Thus, both the "inner" and "outer" destination addresses are set to the home address of the mobile node. The tunneled datagram will thus be routed to the mobile node's home network, where it will be intercepted by the mobile node's home agent in the same way as other datagrams addressed to the mobile node. The home agent SHOULD then tunnel the datagram to the current care-of address for the mobile node. However, the home agent MUST NOT tunnel the datagram to the current care-of address if the special tunnel of Johnson and Perkins Expires 22 May 1996 [Page 32] Internet Draft Route Optimization in Mobile IP 22 November 1995 the datagram originated at that care-of address, as indicated by the "outer" source address of the special tunnel datagram. The use of the special tunnel format allows the home agent to identify the node that tunneled the datagram to it (as well as the original sender of the datagram). If the home agent believes that the current care-of address for the mobile node is the same as the source of the special tunnel, then the home agent SHOULD discard the datagram; in this case, the foreign agent serving the mobile node appears to have lost its entry for the mobile node in its visitor list, for example, if the foreign agent has crashed and rebooted. After tunneling the datagram to the current care-of address for the mobile node, the home agent MAY notify the source of the special tunnel of the mobile node's current binding, by sending it a Binding Update message. Johnson and Perkins Expires 22 May 1996 [Page 33] Internet Draft Route Optimization in Mobile IP 22 November 1995 7. Home Agent Considerations The home agent will be the frequent source of Binding Update messages sent to correspondent nodes that are communicating with its mobile nodes. Any correspondent node that has no binding cache entry 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 receives 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 binding cache entry for that mobile node. Then, future datagrams sent by this node to the mobile node should not need the involvement of the home agent. 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. This rate limiting is especially important because it is expected that, within the short term, many Internet nodes will not support maintenance of a binding cache. In this case, continual transmissions of Binding Update messages to such a correspondent node will only add unnecessary overhead to at the home agent and correspondent node, and along the Internet path between these nodes. 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 Private (P) bit in its Registration Request message, then the home agent MUST not satisfy any Binding Requests. In this case, the home agent SHOULD return a Binding Update in which both the Care-of Address is set equal to the mobile node's home address and the Lifetime is set to zero. Such a Binding Update message indicates that the binding cache entry for the specified mobile node should be deleted. 7.3. Receiving Registration Key Requests When the home agent receives a Registration Request message, a Home Agent Registration Key Request extension (Section 4.3) may be present in the message, requesting the home agent to provide a registration key to the mobile node and its foreign agent, as described in Johnson and Perkins Expires 22 May 1996 [Page 34] Internet Draft Route Optimization in Mobile IP 22 November 1995 Section 2.2. In that event, the home agent employs a good algorithm for producing random keys [4] and encrypts the result separately for use by the foreign agent and by the mobile node. The chosen key is encrypted under the mobility security association shared between the home agent and the mobile node, and the encrypted key is placed in a Mobile Node Registration Key Reply extension (Section 4.4) in the Registration Reply message. The same key also is encrypted under the mobility security association shared between the home agent and the foreign agent, and the encrypted key is placed in a Foreign Agent Registration Key Reply extension (Section 4.5) in the Registration Reply message. If the home agent receives a Home Agent Registration Key Request extension in a Registration Request message, but it does not have an established mobility security association with the foreign agent with which the mobile node is registering, the home agent MUST reject the registration attempt. In this case, the home agent returns a Registration Reply message indicating that the foreign agent failed authentication. 7.4. Receiving Special Tunnels The home agent may also receive datagrams tunneled to the mobile node using a special tunnel (Section 6.4), which it has intercepted for the mobile node in the same way as any datagram destined to the mobile node while the mobile node is away from home. The home agent MUST examine the tunnel source address (the "outer" address of the tunneled datagram). If the tunnel source address differs from the care-of address shown in the home list entry for the mobile node, the home agent SHOULD decapsulate the inner datagram from the tunnel and re-tunnel it to the mobile node's care-of address. However, if the tunnel source address is the same as the mobile node's care-of address, the home agent MUST NOT tunnel the datagram back to that same node; the home agent SHOULD instead discard the datagram. In either case, the home agent SHOULD also send a Binding Update message to the sender of the original datagram (the "inner" source address of the tunneled datagram), if it shares a mobility security association with this node. The sending of this Binding Update message, though, is subject to the rate limiting restriction described in Section 7.1. Johnson and Perkins Expires 22 May 1996 [Page 35] Internet Draft Route Optimization in Mobile IP 22 November 1995 8. Foreign Agent Considerations In addition to managing the resources needed to handle registrations in the base Mobile IP protocol, a foreign agent participating in Route Optimization assumes two additional responsibilities. It SHOULD maintain a binding cache for forwarding datagrams to mobile nodes once they have moved to new care-of addresses, and it SHOULD support the use of a Binding Update message for norifying a mobile node's previous foreign agent that it has moved. 8.1. Establishing a Registration Key As part of the registration procedure, a mobile node and its new foreign agent can establish a registration key (Sections 2.4 and 2.5). 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, such as the use of this key to provide privacy along the wireless link connecting between the mobile node and its foreign agent; such additional uses of the registration key are outside the scope of this discussion. This document specifies two alternative methods for establishing a registration key as part of a mobile node's registration with a foreign agent. The foreign agent may receive a Home Agent Registration Key Request extension in the mobile node's Registration Request message (Section 2.4). The foreign agent need not process the Home Agent Registration Key Request extension. When the Registration Reply is received by the foreign agent from the home agent, it MAY contain a Foreign Agent Registration Key Reply extension and a Mobile Node Registration Key Reply extension. In this case, the foreign agent removes the Foreign Agent Registration Key Reply extension, and forwards the rest of the Registration Reply message to the mobile node. The Foreign Agent Registration Key Reply extension is covered by its own authentication, not by the authentication covering the Registration Reply message itself, and thus removing the Foreign Agent Registration Key Reply extension does not interfere with the mobile node's ability to verify the authentication on the Registration Reply message. The foreign agent decrypts the supplied registration key using the mobility security association it shares with the home agent, and stores the key as part fo the visitor list entry created for the mobile node for this registration. Alternatively, the foreign agent may receive a Diffie-Hellman Registration Key Request extension in the mobile node's Registration Request message (Section 2.5). The extension contains the Prime Johnson and Perkins Expires 22 May 1996 [Page 36] Internet Draft Route Optimization in Mobile IP 22 November 1995 and Generator values, chosen by the mobile node, to be used for this execution of the Diffie-Hellman algorithm. The foreign agent chooses its own private random number and returns the Diffie-Hellman Computed Value when it sends the Registration Reply message sent to the mobile node. The foreign agent uses Prime and Generator values and the Computed Value from the mobile node that it received in the Diffie-Hellman Registration Key Request extension, together with its own chosen private random number, to form the registration key. The foreign agent stores this registration key as part of the visitor list entry created for the mobile node for this registration. Establishing the registration key in effect establishes a mobility security association between the mobile node and the foreign agent. After the mobile node moves to a new care-of address, this mobility security association is used for authenticating the Binding Update message from the mobile node notifying this foreign agent of its movement. 8.2. Previous Foreign Agent Notification When a mobile node registers with a new foreign agent, the mobile node MAY request its new foreign agent to notify its previous foreign agent that it has moved. The mobile node includes a Previous Foreign Agent Notification extension in its Registration Request message to the foreign agent, requesting that the foreign agent send a Binding Update message to its previous foreign agent. As with all Binding Update messages, this Binding Update must be authenticated using the Route Optimization Authentication extension (Section 4.2). The foreign agent assembles the Binding Update message using the fields in the Registration Request message (including the Authenticator supplied in the Previous Foreign Agent Notification extension) and sends it to the previous foreign agent identified in the extension. The Acknowledge (A) bit MUST be set in this Binding Update message. When the previous foreign agent receives the Binding Update, it will authenticate the message using the mobility security association set up with the registration key established with the mobile node during its registration with this mobile node. If the message authentication is correct, the visitor list entry for this mobile node at the previous foreign agent will be deleted and a Binding Acknowledge message returned to the sender. In addition, if a new care-of address was included in the Binding Update mesasge, the previous foreign agent will create a binding cache entry for the mobile node; the previous foreign agent can then tunnel datagrams to Johnson and Perkins Expires 22 May 1996 [Page 37] Internet Draft Route Optimization in Mobile IP 22 November 1995 the mobile node's new care-of address using that binding cache, just as any node maintaining a binding 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 registration key established with this previous foreign agent is destroyed as a part of the processing of this Binding Update message. Since the previous foreign agent deletes the visitor list entry for the mobile node, it also deletes its record of the registration key. A registration key is thus useful only for the notification to the previous foreign agent after moving to a new care-of address. No subsequent use of this registration key is possible, and thus no reply protection is necessary for the Binding Update message used for this notification. 8.3. Receiving Tunneled Datagrams When a foreign agent receives a datagram tunneled to itself, it examines its visitor list for an entry for the destination mobile node, as in the base Mobile IP protocol. If a visitor list entry is found, the foreign agent delivers the datagram to the mobile node. However, if no visitor list entry is found, the foreign agent examines its binding cache for a cache entry for the destination mobile node. If one is found, the foreign agent re-tunnels the new care-of address indicated in the binding cache entry. In this case, the foreign agent also may deduce that the sender of the datagram has an out-of-date binding cache entry for this mobile node, since it otherwise would have tunneled the datagram directly to the correct new care-of address itself. The foreign agent SHOULD then send a Binding Warning message to the original sender of the datagram (the "inner" source address of the tunnel). Johnson and Perkins Expires 22 May 1996 [Page 38] Internet Draft Route Optimization in Mobile IP 22 November 1995 8.4. Rate Limiting A foreign agent MUST provide some mechanism to limit the rate at which it sends Binding Warning messages to to the same node about any given mobility binding. This rate limiting is especially important because it is expected that, within the short term, many Internet nodes will not support maintenance of a binding cache. In this case, continual transmissions of Binding Warning messages to such a correspondent node will only add unnecessary overhead to at the foreign agent and correspondent node, and along the Internet path between these nodes. 8.5. Sending Special Tunnels If a foreign agent receives a tunneled datagram for a mobile node for which it has no visitor list entry or binding cache entry, the foreign agent MAY forward the datagram to the mobile node's home agent by sending it as a special tunnel (Section 2.2). The home agent will intercept the special tunnel datagram addressed to the mobile node in the same way as any datagram for the mobile node while it is away from home. The foreign agent sending the special tunnel MUST NOT send a Binding Warning message in this case, since the home agent will send a Binding Update message when it received and re-tunnels the special tunnel datagram. Johnson and Perkins Expires 22 May 1996 [Page 39] Internet Draft Route Optimization in Mobile IP 22 November 1995 9. Mobile Node Considerations 9.1. Establishing a Registration Key When a mobile node sends a Registration Request message, it can also request a registration key to be established between itself and the new foreign agent. The key may be used later to authenticate the Binding Update sent to this foreign agent to notify it that the mobile node has moved to a new care-of address. The mobile node may include a Home Agent Registration Key Request extension in its Registration Request message to request its home agent to act as a "key distribution center" (KDC) for establishing a registration key with its new foreign agent (Section 2.4). The home agent chooses a new key and returns encrypted copies of it for the foreign agent and the mobile node. The mobile node receives its copy of the new key in the Mobile Node Registration Key Reply extension in the Registration Reply extension. The mobile node decrypts the key using the mobility security association it shares with its home agent, and stores the key for later use in notifying this foreign agent that it has moved to a new care-of address. Alternatively, the mobile node may include a Diffie-Hellman Registration Key Request extension in its Registration Request message to request its new foreign agent to participate in the Diffie-Hellman key exchange algorithm with it. The mobile node chooses a private random number and includes the Prime and Generator values to be used in this execution of the Diffie-Hellman algorithm, together with the Computed Value based on its chosen private random number, in the Diffie-Hellman Registration Request extension. The foreign agent chooses its own private random number, and returns the Computed Value based on this number in a Diffie-Hellman Registration Key Reply extension in the Registration Reply that it returns to the mobile node. The mobile node forms the registration key according to the Diffie-Hellman algorithm and stores it for later use in notifying this foreign agent that it has moved to a new care-of address. 9.2. Notifying Previous Foreign Agents During registration with a new foreign agent, a mobile node may request its new foreign agent to notify its previous foreign agent that it has moved. The new foreign agent sends a Binding Update message to the previous foreign agent on behalf of the mobile node. To nofity its previous foreign agent as part of the new registration, the mobile node includes a Previous Foreign Agent Notification extension (Section 4.1) in its Registration Request message. The Johnson and Perkins Expires 22 May 1996 [Page 40] Internet Draft Route Optimization in Mobile IP 22 November 1995 extension contains only those values needed by the new foreign agent to construct the Binding Update message that are not already included in the Registration Request message. In particular, the new foreign agent only sends the Binding Update message on behalf of the mobile node. The mobile node computes the correct Authenticator value for the Binding Update message, based on the registration key it established with its previous foreign agent, and includes this Authenticator value in the extension for inclusion in the Binding Update message by the new foreign agent. The new foreign agent does not learn the previous foreign agent registration key during the new registration or notification. When the Binding Acknowledgment message from the previous foreign agent is received by the new foreign agent, it detunnels it and sends it to the mobile node. In this way, the mobile node can discover that its previous foreign agent has received the Binding Update mesage. This is important, because otherwise the previous foreign agent would often become a "black hole" for datagrams destined for the mobile node based on out-of-date binding cache entries at other nodes. The new foreign agent has no further responsibility for helping to update the binding cache at the previous foreign agent. The mobile node expects to eventually receive a Binding Acknowledgement message from its previous foreign agent, signifying that the Binding Update message was received. 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 received and processed the Binding Update message (the Binding Acknowledge message may have been lost in transit to the new foreign agent), the mobile node should continue to retransmit its Binding Update message until the previous foreign agent responds with a Binding Acknowledgement. Johnson and Perkins Expires 22 May 1996 [Page 41] Internet Draft Route Optimization in Mobile IP 22 November 1995 References [1] CDPD Forum. Cellular Digital Packet Data system specification. Release 1.0, July 1993. [2] W. Diffie and M. E. Hellman. New directions in cryptography. IEEE Transactions on Information Theory, IT-22(6):644--654, November 1976. [3] Ralph Droms. Dynamic Host Configuration Protocol. RFC 1541, October 1993. [4] Donald E. Eastlake 3rd, Stephen D. Crocker, and Jeffrey I. Schiller. Randomness recommendations for security. RFC 1750, December 1994. [5] Stan Hanks, Tony Li, Dino Farinacci, and Paul Traina. Generic Routing Encapsulation (GRE). RFC 1701, October 1994. [6] Charles Perkins, editor. IP mobility support. Internet Draft, draft-ietf-mobileip-protocol-12.txt, August 1995. Work in progress. [7] RSA Laboratories. RSAREF(TM) 2.0: A free cryptographic toolkit, April 1994. Johnson and Perkins Expires 22 May 1996 [Page 42] Internet Draft Route Optimization in Mobile IP 22 November 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 (perhaps only for specific set of its mobile nodes). When the home agent then needs a mobility security association as part of Route Optimization, 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 and Perkins Expires 22 May 1996 [Page 43] Internet Draft Route Optimization in Mobile IP 22 November 1995 Chairs' Addresses The working group can be contacted via the current chairs: Tony Li cisco Systems 170 W. Tasman Drive San Jose, CA 95134 Phone: +1-408-526-8186 E-mail: tli@cisco.com Jim Solomon Motorola, Inc. 1301 E. Algonquin Road Schaumburg, IL 60196 Phone: +1-708-576-2753 E-mail: solomon@comm.mot.com Johnson and Perkins Expires 22 May 1996 [Page 44] Internet Draft Route Optimization in Mobile IP 22 November 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 Johnson and Perkins Expires 22 May 1996 [Page 45]