Mobile IP Working Group Charles Perkins INTERNET DRAFT Sun Microsystems 29 July 1997 David B. Johnson Carnegie Mellon University Route Optimization in Mobile IP draft-ietf-mobileip-optim-6.txt Status of This Memo This document is a submission by the Mobile IP Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the mobile-ip@SmallWorks.COM mailing list. 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.'' 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 (North Europe), ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). The Route Optimization protocol extensions for Mobile IP for IPv4 are actively being worked on within the Mobile IP Working Group, although recent emphasis has been on the design and specification of Mobile IP for IPv6. This document represents the current state of the Mobile IPv4 Route Optimization extensions. The design of Route Optimization may evolve to more closely follow the design of Mobile IPv6, depending upon the suitability of the IPv6 design revisions for IPv4, especially the trust model that may be assumed between the home agent and correspondent node. This document may be revised and resubmitted once those revisions are evaluated and further developed. Perkins and Johnson Expires 29 January 1998 [Page i] Internet Draft Route Optimization in Mobile IP 29 July 1997 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. Perkins and Johnson Expires 29 January 1998 [Page ii] Internet Draft Route Optimization in Mobile IP 29 July 1997 Contents Status of This Memo i Abstract ii 1. Introduction 1 2. Terminology 2 3. Route Optimization Overview 3 3.1. Binding Caches . . . . . . . . . . . . . . . . . . . . . 3 3.2. Foreign Agent Smooth Handoff . . . . . . . . . . . . . . 5 3.3. Establishing Registration Keys . . . . . . . . . . . . . 6 3.3.1. The Home Agent as a KDC . . . . . . . . . . . . . 8 3.3.2. Using the Foreign Agent as a KDC . . . . . . . . 9 3.4. Using Diffie-Hellman with the Foreign Agent . . . . . . . 9 3.5. Special Tunnels . . . . . . . . . . . . . . . . . . . . . 12 4. Route Optimization Message Formats 12 4.1. Binding Warning Message . . . . . . . . . . . . . . . . . 13 4.2. Binding Request Message . . . . . . . . . . . . . . . . . 14 4.3. Binding Update Message . . . . . . . . . . . . . . . . . 15 4.4. Binding Acknowledge Message . . . . . . . . . . . . . . . 17 4.5. Route Optimization Authentication Extension . . . . . . . 18 4.6. Modified Registration Request Message . . . . . . . . . . 19 5. Format of Smooth Handoff Extensions 19 5.1. Previous Foreign Agent Notification Extension . . . . . . 20 5.2. Modified Mobility Agent Advertisement Extension . . . . . 21 6. Messages Requesting A Registration Key 22 6.1. Foreign Agent Key Request extension . . . . . . . . . . . 22 6.2. Mobile Node Public Key extension . . . . . . . . . . . . 23 6.3. Foreign Agent Public Key extension . . . . . . . . . . . 24 6.4. Registration Key Request Extension . . . . . . . . . . . 24 7. Extensions to Supply A Registration Key 25 7.1. Home-Mobile Key Reply Extension . . . . . . . . . . . . . 26 7.2. Foreign Agent Key Reply Extension . . . . . . . . . . . . 27 7.3. Mobile Node Public Key Reply Extension . . . . . . . . . 28 7.4. Foreign Agent Public Key Reply Extension . . . . . . . . 28 7.5. Diffie-Hellman Key Reply Extension . . . . . . . . . . . 29 Perkins and Johnson Expires 29 January 1998 [Page iii] Internet Draft Route Optimization in Mobile IP 29 July 1997 8. Using Special Tunnels 30 8.1. Home Agent Handling of Special Tunnels . . . . . . . . . 31 8.2. Foreign Agents and Special Tunnels . . . . . . . . . . . 31 9. Mobile Node Key Requests 32 10. Miscellaneous Home Agent Operations 33 10.1. Home Agent Rate Limiting . . . . . . . . . . . . . . . . 33 10.2. Receiving Registration Key Requests . . . . . . . . . . . 33 10.3. Mobility Security Association Management . . . . . . . . 34 10.4. Home Agent Supplying Registration Keys . . . . . . . . . 35 11. Miscellaneous Foreign Agent Operations 36 11.1. Previous Foreign Agent Notification . . . . . . . . . . . 36 11.2. Maintaining Binding Caches . . . . . . . . . . . . . . . 37 11.3. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . 38 11.4. Foreign Agent Handling Key Requests . . . . . . . . . . . 38 12. Security Considerations 39 13. Summary 39 A. Using a Master Key at the Home Agent 40 References 42 Chairs' Addresses 43 Authors' Addresses 44 Perkins and Johnson Expires 29 January 1998 [Page iv] Internet Draft Route Optimization in Mobile IP 29 July 1997 1. Introduction The base Mobile IP protocol [10], allows any mobile node to move about, changing its point of attachment to the Internet, while continuing to be identified by its home IP address. Correspondent nodes sending IP datagrams to a mobile node send them to the mobile node's home address in the same way as with any other destination. This scheme allows transparent interoperation between mobile nodes and their correspondent nodes, but forces all datagrams for a mobile node to be routed through its home agent. Thus, datagrams to the mobile node are often routed along paths that are significantly longer than optimal. For example, if a mobile node is visiting some subnet, even datagrams from a correspondent node on the same subnet must be routed through the Internet to the mobile node's home agent (on its home network), only then to be tunneled back to the original subnet for final delivery. This indirect routing can significantly delay the delivery of the datagrams to mobile nodes, and places an unnecessary burden on the networks and routers along their paths through the Internet. In this document, we will define extensions to the operation of the base Mobile IP protocol to allow for better routing, so that datagrams can be routed from a correspondent node to a mobile node without going to the home agent first. In this document, we refer collectively to these extensions as Route Optimization. Route Optimization 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 based on an out-of-date cached binding, to be forwarded directly to the mobile node's new care-of address. All operation of Route Optimization that changes the routing of IP datagrams to the mobile node is authenticated using the same type of mechanisms used in the base Mobile IP protocol. This authentication generally relies on a mobility security association established in advance between the sender and receiver of such messages. After Section 2 gives some extra terminology, Section 3 provides an overview of the basic protocol operations associated with Route Optimization. Section 4 defines the message types used to update binding caches. Subsequent sections show the formats for each message and registration extension in detail, explaining the function of each field within the messages. The formats are presented in the same basic order corresponding to the topic outline of the Perkins and Johnson Expires 29 January 1998 [Page 1] Internet Draft Route Optimization in Mobile IP 29 July 1997 document. Home agent considerations in Section 10, and foreign agent considerations in Section 11. Details about the management of special tunnels are given in Section 8. 2. Terminology This document introduces the following terminology, in addition to that used to describe the base Mobile IP protocol: Binding cache A cache of mobility bindings of mobile nodes, maintained by a node for use in tunneling datagrams to those mobile nodes. Binding update A message indicating a mobile node's current mobility binding, and in particular its care-of address. Registration Key A secret key shared between a mobile node and a foreign agent, that may optionally be established during registration with that foreign agent. When later moving and registering a new care-of address elsewhere, the mobile node uses the registration key shared with its previous foreign agent to send it an authenticated Binding Update to this foreign agent. Registration Lifetime The registration lifetime is the time duration for which a binding is valid. The term remaining registration lifetime means the amount of time remaining for which a registration lifetime is still valid, at some time after the registration was approved by the home agent. Security Parameter Index (SPI) An index identifying a security context between a pair of nodes among the contexts available in the Mobility Security Association. SPI values 0 through 255 are reserved and MUST NOT be used in any Mobility Security Association. Special tunnel A method of tunneling a datagram in which the outer destination address when encapsulating the datagram is set equal to the Perkins and Johnson Expires 29 January 1998 [Page 2] Internet Draft Route Optimization in Mobile IP 29 July 1997 inner destination address (the original destination address of the datagram). A special tunnel is used in Route Optimization for returning a datagram, addressed to a mobile node, to the mobile node's home agent without knowing the home agent's address. Triangle Routing A situation in which a Correspondent Host's packets to a Mobile Host follow a path which is longer than the optimal path because the packets must be forwarded to the Mobile Host via a Home Agent. 3. Route Optimization Overview This section provides an overview of the protocols and operations of Route Optimization. These can be divided into four main parts: 1. Updating binding caches 2. Managing smooth handoffs between foreign agents 3. Acquiring registration keys for smooth handoffs 4. Special tunnels The rest of the document goes into detail about each general part of the protocol, in the order suggested above. 3.1. Binding Caches Route Optimization provides a means for any node to maintain a binding cache containing the care-of address 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 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 Perkins and Johnson Expires 29 January 1998 [Page 3] Internet Draft Route Optimization in Mobile IP 29 July 1997 datagram may be informed of the mobile node's current mobility binding, giving the sender an opportunity to cache the binding. Any node may maintain a binding cache to optimize its own communication with mobile nodes. A node may create or update a binding cache entry for a mobile node only when it has received and authenticated the mobile node's mobility binding. As before, each binding in the binding cache also has an associated lifetime, specified in the Binding Update message in which the node obtained the binding. After the expiration of this time period, the binding is deleted from the cache. In addition, a node cache may use any reasonable strategy for managing the space within the binding 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. 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. The home agent should then send a Binding Update message to the original source node, informing it of the mobile node's current mobility binding. No acknowledgment for such a 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. For a Binding Update to be authenticated by the original source node, the source node and the home agent must have established a mobility security association. Similarly, when any node (e.g., a foreign agent) receives a tunneled datagram, if it has a binding cache entry for the destination mobile node (and thus 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 this mobile node. In this case, the receiving node should send a Binding Warning message to the mobile node's home agent, advising it to send a Binding Update message to the node that tunneled this datagram. The mobile node's home agent can be determined from the binding cache entry, because the home agent address is learned from the Binding Update that established this cache entry. The address of the node that tunneled this datagram can be determined from the datagram's header, since the address of the node tunneling this datagram is the outer source address of the encapsulated datagram. As in the case of a Binding Update sent by the mobile node's home agent, no acknowledgment 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 Perkins and Johnson Expires 29 January 1998 [Page 4] Internet Draft Route Optimization in Mobile IP 29 July 1997 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. When sending an IP datagram, if the sending node has a binding cache entry for the destination node, it should tunnel the datagram to the mobile node's care-of address using the encapsulation techniques used by home agents, and described in [8, 9, 4]. 3.2. Foreign Agent Smooth 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 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 needed. The old foreign agent eventually deletes its registration for the mobile node after the expiration of the registration lifetime. 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, to be forwarded to its new care-of address. Finally, this notification allows any resources consumed by the mobile node at the previous foreign agent (such as radio channel reservations) to be released immediately, rather than waiting for its registration lifetime to expire. 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 acknowledgment from the previous foreign agent. The 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 using the registration key shared with its previous foreign agent. This Perkins and Johnson Expires 29 January 1998 [Page 5] Internet Draft Route Optimization in Mobile IP 29 July 1997 notification will typically 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 [5] to its new location. Any tunneled datagrams for the mobile node that arrive at its previous foreign agent after the forwarding pointer has been created will then be re-tunneled by this foreign agent to the mobile node's new care-of address. For this smooth handoff to be secure, during registration with a new foreign agent, the mobile node and the foreign agent usually need to establish a new shared secret key called a registration key. 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 specification. Once established, the registration key for a mobile node can be stored by the foreign agent with the mobile node's visitor list entry. Section 3.3 gives an overview of methods for establishing a registration key. The Mobility Agent Advertisement extension of the agent advertisement message is revised under Route Optimization to include a bit indicating that the foreign agent sending the advertisement supports smooth handoffs. If this bit is not set in the agent advertisement from the foreign agent, the mobile node SHOULD not request a registration key in its Registration Request message. 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 that foreign agent has expired its binding. The mobile node is likely to select a small timeout value for the remaining registration lifetime available to such bindings sent to previous foreign agents. 3.3. Establishing Registration Keys Foreign agents are expected to be cheap and widely available, as Mobile IP becomes fully deployed. Mobile nodes will likely find it difficult to manage long-term security relationships with so many foreign agents. To securely perform the operations needed for smooth handoffs from one foreign agent to the next, however, any careful foreign agent should require assurance that it is getting authentic handoff information, and not arranging to forward in-flight datagrams to a bogus destination. The biggest complication in the Route Optimization protocol involves the creation of (sufficient) trust between mobile node and foreign agent when none exists beforehand, Perkins and Johnson Expires 29 January 1998 [Page 6] Internet Draft Route Optimization in Mobile IP 29 July 1997 while allowing the use of fully trustworthy security associations between foreign agents and mobile nodes whenever they do exist. Note that the mobile node can only rarely verify the identity of the foreign agent in any absolute terms. It can only act on the presumption that the foreign agent is performing its duties by correct adherence to protocol. Again, foreign agents are mostly passive devices. Any entity that is willing to perform the services would be accepted by the mobile node, even if the foreign agent were somehow malicious "on-the-side". For instance, neither the mobile node nor any home agent would be likely to be able to determine if a foreign agent duplicated the mobile node's traffic stream, shared the mobile node's data with some adversary, or replayed mobile node data after the expiration of the mobile node's binding at that care-of address. If the foreign agent were to perform more active attacks, such as dropping datagrams intentionally, or modifying the datagrams according to some dark purpose, the mobile node would not necessarily know where the problem was originating. However, all of these same points are true as well for existing infrastructure routers, so the situation is no worse than already exists. In short, the exact identity of the foreign agent is not crucial to the process of establishing a registration key. Only an agreement to follow protocol can be expected or enforced. If the mobile node has a way to obtain a certified public key for the foreign agent, then the identity may be established in a firmer fashion, but the needed public key infrastructure seems to be at least five years distant. Therefore, methods are proposed in this document by which an anonymous foreign agent (i.e., one whose identity we cannot establish) can create a registration key with a mobile node during the registration process. In this document, we propose the following methods for establishing a registration key, in order of declining preference. Other methods of establishing keys may become available in the future. 1. If the foreign agent and mobile node share a security association, it can be used to secure the Previous Foreign Agent Notification. 2. If the home agent and foreign agent share a security association, the home agent can choose the new registration key. 3. If the foreign agent has a public key, it can again use the home agent to supply a registration key. 4. If the mobile node includes its public key in its Registration Request, the foreign agent can choose the new registration key. Perkins and Johnson Expires 29 January 1998 [Page 7] Internet Draft Route Optimization in Mobile IP 29 July 1997 5. The mobile node and its foreign agent can execute a Diffie-Hellman key exchange protocol [2] as part of the registration protocol. Once the registration key is established, the method for performing smooth handoff seems natural. The following sections give a brief overview of the above listed methods for establishing the registration key. Once the key is established, and able to be used by way of a (possibly newly created) SPI, the smooth handoff just involves sending a Binding Update to the previous foreign agent at the right time. If a request for key establishment cannot be accommodated by the foreign agent and/or the home agent, then the mobile node's key request must go unfulfilled. This does not mean that the Registration Request itself fails, so it has no effect on the status code returned by the home agent to the mobile node. The mobile node has to be able to handle the case in which it has requested a key but the Registration Reply arrives without any key reply extension. 3.3.1. The Home Agent as a KDC Crucial to methods (2) and (3) listed above is that the home agent and mobile node already are known to share a mobility security association, which can be used to encode the registration key for delivery to the mobile node. Thus, if the home agent can securely deliver the key to the foreign agent, it can be used as a Key Distribution Center (KDC) for the mobile node and its new foreign agent. The mobile node requests this by including a Registration Key Request extension in its Registration Request message. When the home agent chooses the registration key, it sends it back in two different extensions to the Registration Reply. One extension has the encrypted key for the foreign agent, and the other extension has the same key encrypted differently for the mobile node. For the registration key to be established using this method, the home agent must be able to securely transmit an encrypted copy of the registration key to the foreign agent. This is straightforward if the foreign agent already has a mobility security association with the home agent. If mobile nodes from some home network often visit a foreign agent, then the effort of creating such a mobility security association between that foreign agent and the home agent serving their home network may be worthwhile. Note that MD5 can be used here for the purpose of transmitting registration keys, secure against eavesdroppers. The expression expr1 = MD5(secret | regrep | secret) XOR (key) Perkins and Johnson Expires 29 January 1998 [Page 8] Internet Draft Route Optimization in Mobile IP 29 July 1997 (where regrep is the Registration Reply message payload, and XOR is exclusive-or) can be included within the appropriate Registration Reply extension and encodes the key in a way which allows recovery only by the recipient. It is secure against replay because of the identification field within the Registration Reply message. The recipient recovers the key by computing expr2== MD5(secret | regrep | secret) which then yields key = expr1XOR expr2. Use of MD5 avoids entanglements with the legal issues surrounding the export of encryption technology, and reducing the computational power needed to secure the password against eavesdroppers. If no such mobility security association exists, but the foreign agent has a public key available, it can still ask the home agent to use it to pick a registration key. This is preferable than asking the mobile node to pick a good registration key, because doing so may depend upon using resources not available to all mobile nodes. Just selecting pseudo-random numbers is by itself a significant computational burden. Moreover, allowing the home agent to pick the key fits well into the existing registration procedures. On the other hand, it is possible that a mobile node could do with less than perfect pseudo-random numbers as long as the registration key were to be used in the restricted fashion envisioned for smooth handoffs. 3.3.2. Using the Foreign Agent as a KDC When the foreign agent and mobile node share a mobility security association, there is no need to pick a registration key. The mobile node can secure its Binding Update to the foreign agent whenever it needs to, by using the existing security association. This is the most desirable case. Otherwise, if available, the mobile node can include its public key (such as RSA [11]) in its Registration Request to the foreign agent, using a mobile node public key extension. The foreign agent chooses the new registration key and returns a copy of it encrypted with the mobile node's public key, using a foreign-mobile registration key reply extension. 3.4. Using Diffie-Hellman with the Foreign Agent The Diffie-Hellman key-exchange algorithm [2] can be used. Diffie-Hellman 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 already used, for example, in Perkins and Johnson Expires 29 January 1998 [Page 9] Internet Draft Route Optimization in Mobile IP 29 July 1997 other protocols that require a key exchange, such as in the Cellular Digital Packet Data (CDPD) system [1]. This technique is known to suffer from a man-in-the-middle attack. In other words, a malicious agent could pretend to the foreign agent to be the mobile node, and pretend to the mobile node to be the foreign agent, and participate as an unwanted third member in the key exchange Armed with knowledge of the registration key, the malicious agent could at a later time disrupt the smooth handoff, or initiate the handoff prematurely. The man-in-the-middle attack is no worse than a malicious agent pretending to be a foreign agent in any other circumstance; that is, it is no worse than already exists with the base Mobile IP specification [10]. In route optimization, the man-in-the-middle attack is prevented in most circumstances because each registration key produced by the techniques in this chapter is effectively authenticated by the home agent. Even so, if Diffie-Hellman were not computationally so expensive, it could likely serve the needs of many mobile nodes. Moreover, the mobile node and/or the foreign agent are presumably in direct contact, so that the malicious man-in-the-middle would be detectable with high probability if either of the former nodes notices the reception of duplicate packets, and corrective action taken. Diffie-Hellman results are returned by the protocol in a way intended to avoid such attacks. But, the algorithm itself uses exponentiations involving numbers with hundreds of digits. That may take a long time for some mobile nodes to do, time which would come at the expense of interactivity or convenient operation of user application programs. For this reason, Diffie-Hellman is considered the least desirable alternative for establishing registration keys. Even so, since it requires no other configuration, it should be required in all implementations of foreign agents that advertise support for smooth handoffs. 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 the same or 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, the prime and the generator, and sends the computed value in a message to the other party. The computed value is the number g**x mod p, where x is the private random number, p is the prime which is sent as part of the transaction, and g is the generator. Each party then computes the (same) shared secret key using its own private random number, the computed value received from the other party, and Perkins and Johnson Expires 29 January 1998 [Page 10] Internet Draft Route Optimization in Mobile IP 29 July 1997 the prime and generator values. The shared secret is the number c**y mod p, where c is the computed value which uses the other party's private number, p is the same as before, and y is the receiver's private number. Since (g**x)**y == (g**y)**x, and since knowing the computed values mod p does not enable passive listeners to determine the private values, the algorithm does successfully allow the two parties to agree on an otherwise undetectable secret. To use this algorithm during registration with a foreign agent, the mobile node includes a Registration Key Request extension in its Registration Request message, containing its nonzero values for the prime and generator, along with the computed value from its own private random number. If no other strategy is available, the foreign agent then chooses 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. Establishing a registration key using Diffie-Hellman is computationally more expensive than most methods described in Section 3.3. 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 calculate 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. Even more simply, 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. 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 currently seems the only Perkins and Johnson Expires 29 January 1998 [Page 11] Internet Draft Route Optimization in Mobile IP 29 July 1997 obvious choice, though; an implementation is available in the free RSAREF toolkit from RSA Laboratories [7]. 3.5. Special Tunnels Suppose a foreign agent receives a tunneled datagram, but it doesn't have a visitor list entry for the mobile node. Moreover, suppose the foreign agent has no binding cache entry for the destination mobile node. To attempt delivery of the datagram in this case, the node must encapsulate the datagram as a special tunnel datagram (see Section 8), destined to the mobile node. Using a special tunnel allows the home agent to avoid a possible routing loop when a foreign agent has forgotten that it is serving the mobile node, perhaps because the foreign agent 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. 4. Route Optimization Message Formats Route Optimization defines four message types used for management of binding cache entries. These message types fit in the numbering space defined in the base Mobile IP specification for messages sent to UDP port 454. Each of these messages begins with a one-octet field indicating the type of the message. The binding cache management messages in this section are carried by way of UDP, sent to port 434. 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. Perkins and Johnson Expires 29 January 1998 [Page 12] Internet Draft Route Optimization in Mobile IP 29 July 1997 4.1. Binding Warning Message A Binding Warning message is used to advise a mobile node's home agent that another node appears to have either no binding cache entry or an out-of-date binding cache entry for some mobile node. When any node detunnels a datagram, if it is not the current foreign agent for the destination mobile node, it should send a Binding Warning message to the mobile node's home 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile Node Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target Node Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of the Binding Warning message is illustrated above, and contains the following fields: 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. Target Node Address The address of the node tunneling the datagram that caused the Binding Warning message. This node should be the target of the Binding Update message sent by the home agent. A home agent will receive a Binding Warning message if a node maintaining a binding cache entry for one of the home agent's mobile nodes uses an out-of-date entry. When a home agent receives a Binding Warning message, it should send a Binding Update message to the target node address identified in the Binding Warning, giving it the current binding for the mobile node identified in the mobile node home address field of the Binding Warning. Perkins and Johnson Expires 29 January 1998 [Page 13] Internet Draft Route Optimization in Mobile IP 29 July 1997 4.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. 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 + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of the Binding Request message is illustrated above, and contains the following fields: 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. 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 is required to 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 make no further attempt to satisfy Binding Requests on behalf of that mobile node. 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. Perkins and Johnson Expires 29 January 1998 [Page 14] Internet Draft Route Optimization in Mobile IP 29 July 1997 4.3. Binding Update Message The Binding Update message is used for notification of a mobile node's current mobility binding. It should be sent by the mobile node's home agent in response to a Binding Request message or a Binding Warning message. It should 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 ... +-+-+-+-+-+-+-+- The format of the Binding Update message is illustrated above, and contains the following fields: Type 18 A The 'A' (acknowledge) bit is set by the node sending the Binding Update message to request a Binding Acknowledge message be returned. I The 'I' (identification present) bit is set by the node sending the Binding Update message if the identification field is present in the message. M If the 'M' (minimal encapsulation) bit is set, datagrams may be tunneled to the mobile node using the minimal encapsulation protocol [9]. G If the 'G' (Generic Record Encapsulation, or GRE) bit is set, datagrams may be tunneled to the mobile node using GRE [4]. Rsvd Reserved. Sent as 0; ignored on reception. Perkins and Johnson Expires 29 January 1998 [Page 15] Internet Draft Route Optimization in Mobile IP 29 July 1997 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. Each Binding Update message indicates the binding's maximum lifetime. When sending the Binding Update message, the home agent should set this lifetime to the remaining registration lifetime. A node wanting to provide continued service with a particular binding cache entry may attempt to reconfirm that mobility binding before the expiration of the registration lifetime. 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. Note that the node maintaining the binding should also keep track of the home agent's address, to be able to fill in the destination IP address of future Binding Requests. When a node receives a Binding Update message, it is required to verify the authentication in the message, using the mobility security association it shares with the mobile node's home agent. The Perkins and Johnson Expires 29 January 1998 [Page 16] Internet Draft Route Optimization in Mobile IP 29 July 1997 authentication data is found in the Route Optimization Authentication extension (Section 4.5), which is required. 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. Under all circumstances, the sending of Binding Update messages is subject to the rate limiting restriction described in Section 10.1. When using nonces for replay protection, the identification field in the Binding Update message is used differently in this case, to still allow replay protection even though the Binding Update is not being sent in reply to a request directly from the target node. In this case, the home agent is required to set the high-order 32 bits of the identification field to the value of the nonce that will be used by the home agent in the next Binding Update message sent to this node. The low-order 32 bits of the identification field are required to be set to the value of the nonce being used for this message. Thus, on each Binding Update message, the home agent communicates to the target node, the value of the nonce that will be used next time, and if no Binding Updates are lost in the network, the home agent and the target node can remain synchronized with respect to the nonces being used. If, however, the target node receives a Binding Update with what it believes to be an incorrect nonce, it may resynchronize with the home agent by using a Binding Request message. 4.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 Perkins and Johnson Expires 29 January 1998 [Page 17] Internet Draft Route Optimization in Mobile IP 29 July 1997 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 + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of the Binding Acknowledge message is illustrated above, and contains the following fields: Type 19 N If the 'N' (negative acknowledge) bit is set, this acknowledgment is negative. For instance, if the Binding Update was not accepted, but the incoming datagram has the Acknowledge flag set, then the 'N' bit should be set in this Binding Acknowledge message. 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. DISCUSSION: Should there be a code field defined, as with the Registration Reply message, instead of the 'N' bit? 4.5. Route Optimization Authentication Extension The Route Optimization Authentication extension is used to authenticate certain Route Optimization management messages. It has the same format as the three authentication extensions defined for base Mobile IP [10], but is distinguished by its type, which is Perkins and Johnson Expires 29 January 1998 [Page 18] Internet Draft Route Optimization in Mobile IP 29 July 1997 35. The authenticator value is computed, as before, from the 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. This extension is required to be used in any Binding Update message. 4.6. Modified 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 any Binding Update message. 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 shown below: 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|V|P|r| Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Unchanged ...) +-+-+-+-+-+-+-+-+-+-+-+-+ 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. 5. Format of Smooth Handoff Extensions This section describes the format details for messages which are used to enable a smooth handoff from the previous foreign agent to the new foreign agent when a mobile node initiates a new registration. Perkins and Johnson Expires 29 January 1998 [Page 19] Internet Draft Route Optimization in Mobile IP 29 July 1997 5.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 may then delete the mobile node's visitor list entry and, if a new care-of address is included in the Binding Update message, create a binding cache entry for the mobile node with 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authenticator ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 96 Length 14 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. 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. Perkins and Johnson Expires 29 January 1998 [Page 20] Internet Draft Route Optimization in Mobile IP 29 July 1997 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 delete its visitor list entry only for the mobile node, but not forward datagrams for it). SPI Security Parameters Index (4 bytes). An opaque identifier. The SPI is copied over into the Route Optimization Authentication extension by the new foreign agent. 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. 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 [10]. 5.2. Modified Mobility Agent Advertisement Extension Performing smooth handoffs requires one minor change to the existing Mobile IP Mobility Agent Advertisement extension [10]. A new flag bit, the 'S' bit, replaces a previously unused reserved bit in the extension, to indicate that the foreign agent supports smooth handoffs, and thus registration key establishment. By default, every foreign agent that supports smooth handoffs SHOULD at Perkins and Johnson Expires 29 January 1998 [Page 21] Internet Draft Route Optimization in Mobile IP 29 July 1997 least to support the establishment of a registration key by using Diffie-Hellman 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 | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime |R|B|H|F|M|G|V|T|S| reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (unchanged...) +-+-+- Thus, the proposed modification to the Mobility Agent Advertisement extension, illustrated above, keeps the advertisement almost the same as in the base Mobile IP specification, except for adding following bit: S The 'S' smooth handoff bit is set by the foreign agent sending the agent advertisement message to indicate that it supports the smooth handoffs and registration key establishment, and thus the Registration Key Request and Diffie-Hellman Registration Key Reply extensions. More detailed information about the handling of this extension by foreign agents is deferred until Section 11.1. 6. Messages Requesting A Registration Key The following extensions may be used by mobile nodes or foreign agents to request the establishment of a registration key. See sections 9,10.4, and 11 for appropriate algorithms which allow each node to tailor the use of these extensions to most closely fit its configured requirements. 113 Foreign Agent Key Request Extension 114 Mobile Node Public Key Extension 115 Foreign Agent Public Key Extension 116 Diffie-Hellman Key Request Extension 6.1. Foreign Agent Key Request extension If the foreign agent receives a Registration Key Request from a mobile node, and it has a security association with the home agent, it may append the Foreign Agent Key Request extension to the Registration Request after the mobile-home authentication Perkins and Johnson Expires 29 January 1998 [Page 22] Internet Draft Route Optimization in Mobile IP 29 July 1997 extension. The home agent will use the SPI specified in the key request extension to encode the registration key in the subsequent Registration Reply message. The format of the Foreign Agent Key Request extension is illustrated below. 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 | SPI ..... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... SPI (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 113 Length 4 SPI Security Parameters Index (4 bytes). An opaque identifier. 6.2. Mobile Node Public Key extension If the mobile node has a public key, it can ask its prospective foreign agent to choose a registration key, and to use the mobile node's public key to encode the chosen registration key. No eavesdropper will be able to decode the registration key, even if it is broadcast to all entities with access to the network medium used by the mobile node. If using the public key, the foreign agent should still include the selected key in the Registration Request before it goes to the home agent. Then, the home agent can authenticate the selected encoded registration key as part of the Registration Reply message. The format of the mobile node public key extension is as illustrated below. 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 |MN Public Key .. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Mobile Node Public Key, continued ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 114 Length The length (typically larger than 255) of the mobile node's public key Perkins and Johnson Expires 29 January 1998 [Page 23] Internet Draft Route Optimization in Mobile IP 29 July 1997 6.3. Foreign Agent Public Key extension If the foreign agent has a public key, it can ask the home agent to choose a registration key, and to use the foreign agent's public key to encode the chosen registration key. Then, the home agent can authenticate the selected encoded registration key as part of the Registration Reply message. The format of the foreign agent public key extension is as illustrated below. 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 | SPI ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... SPI (continued) |FA Public Key .. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Foreign Agent Public Key (continued) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 115 Length 4 plus the length (typically larger than 255) of the foreign agent's public key SPI Security Parameters Index (4 bytes). An opaque identifier. Foreign Agent's Public Key The SPI is provided for the home agent to transcribe into the eventual Foreign Agent Public Key Reply extension to the Registration Reply message. 6.4. Registration Key Request Extension The Registration Key Request extension, illustrated below, may be included in a Registration Request message sent to a foreign agent. If the length of the parameters in the key request extension are all zero, then the mobile node is asking the foreign agent to supply a key by any means it has available except for Diffie-Hellman. If the lengths are nonzero, then the mobile node is enabling the foreign agent to also perform the Diffie-Hellman key exchange algorithm (as described in Section 3.4) if the other possible key establishment methods are not available. The foreign agent should then select a good pseudo-random registration key, and include a Diffie-Hellman Registration Key Reply extension, in the Registration Perkins and Johnson Expires 29 January 1998 [Page 24] Internet Draft Route Optimization in Mobile IP 29 July 1997 Request message sent to the home agent to complete the key exchange. The home agent will also include same extension in the Registration Reply sent to the mobile node, and then it will be authenticated as part of the reply 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 | Prime ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Prime (continued) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Generator ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Computed Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 116 Length 3 times the length (in bytes) 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 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 generator should be less than p, and should be a primitive root of p. 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. 7. Extensions to Supply A Registration Key The following extensions are used to supply a registration key to a requesting entity, either a foreign agent or a mobile node, and Perkins and Johnson Expires 29 January 1998 [Page 25] Internet Draft Route Optimization in Mobile IP 29 July 1997 are the counterparts to corresponding extensions used to request registration keys that are described in the last section. 120 Home-Mobile Key Reply Extension 121 Foreign Agent Key Reply Extension 122 Mobile Node Public Key Reply Extension 123 Foreign Agent Public Key Reply Extension 124 Diffie-Hellman Key Reply Extension 7.1. Home-Mobile Key Reply Extension The home-mobile 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 is required to also include a key reply extension in the Registration Reply message, which gives a copy of the same key to the mobile node's new foreign agent. The home-mobile key reply extension, illustrated below, is authenticated along with the rest of the Registration Reply message, and thus no additional authenticator is included in the extension. The SPI used to encode the registration key may be different than the SPI used to authenticate the Registration Reply 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 | SPI ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... SPI (continued) | MN Enc. Key ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile Node Encrypted Key ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 120 Length 4 plus the length of the encrypted key for the mobile node SPI Security Parameters Index (4 bytes). An opaque identifier. 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. Perkins and Johnson Expires 29 January 1998 [Page 26] Internet Draft Route Optimization in Mobile IP 29 July 1997 7.2. Foreign Agent Key Reply Extension The home-foreign 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 is required to also include a home-mobile registration key reply extension in the Registration Reply message, giving a copy of the same key to 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 | Length | SPI ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... SPI (continued) | FA Enc. Key ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Foreign Agent Encrypted Key ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 121 Length 4 plus the length of the encrypted foreign agent's key plus the length of the authenticator SPI Security Parameters Index (4 bytes). An opaque identifier. 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 key which is sent in this extension must also be sent by the home agent to the mobile node, encoded for the mobile node in a mobile node registration key extension in the same Registration Reply message. Authentication of the key is performed by use of data within a HA-FA Authentication extension to the Registration Reply message which is required when the Foreign Agent Key Reply extension is used. Replay protection is accomplished using the identification field in the Registration Request message, which is also used by the foreign agent to identify the pending registration data. Perkins and Johnson Expires 29 January 1998 [Page 27] Internet Draft Route Optimization in Mobile IP 29 July 1997 7.3. Mobile Node Public Key Reply Extension When the mobile node sends a Mobile Node Public Key Request to its prospective foreign agent, the foreign agent can immediately select a registration key. The foreign agent encodes this registration key into the Mobile Node Public Key Reply extension to the Registration Request, along with an SPI for future reference. The home agent subsequently transcribes the extension without change into the Registration Reply message. This procedure allows the mobile node to be protected against common man-in-the-middle attacks. The Mobile Node Public Key Reply message is illustrated below. 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 | SPI ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... SPI (continued) | MN Enc. Key ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Mobile Node's Encoded Key (continued) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 122 Length The length (in bytes) of the computed value. SPI Security Parameters Index (4 bytes). An opaque identifier. Mobile Node's Encoded Key The foreign agent chooses a suitable key, possibly a pseudo-random number, and encodes it using the mobile node's public key. 7.4. Foreign Agent Public Key Reply Extension In response to a foreign agent public key request extension, the home agent will select a registration key and encode it twice into two separate key reply extensions of the Registration Reply message. The Foreign Agent Public Key Reply extension contains the registration key encoded with the public key of the foreign agent. Perkins and Johnson Expires 29 January 1998 [Page 28] Internet Draft Route Optimization in Mobile IP 29 July 1997 The Foreign Agent Public Key Reply message is illustrated below. 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 | SPI ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... SPI (continued) | FA Enc. Key ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...Foreign Agent's Encoded Key (continued) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 123 Length 4 plus the length (in bytes) of the Foreign Agent's Encoded Key. SPI Security Parameters Index (4 bytes). An opaque identifier. Foreign Agent's Encoded Key The foreign agent chooses a suitable pseudo-random number, and encodes it using the mobile node's public key. The SPI, provided by the foreign agent for transcribing into this extension, is ultimately targeted for use by the mobile node. 7.5. Diffie-Hellman Key Reply Extension The Diffie-Hellman Registration Key Reply extension, illustrated below, should be included in a Registration Request message sent by a foreign agent to the home agent, when the following conditions are met: - mobile node has included a Registration Key Request extension with nonzero prime and generator in its Registration Request message to the foreign agent, and - the foreign agent has no public key or security association with the home agent or mobile node. Perkins and Johnson Expires 29 January 1998 [Page 29] Internet Draft Route Optimization in Mobile IP 29 July 1997 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 | SPI ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... SPI (continued) |Computed Val.... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Computed Value (continued) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 125 Length 4 plus the length (in bytes) of the computed value. SPI Security Parameters Index (4 bytes). An opaque identifier. 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 gymod p. The values of the generator and prime, if nonzero, are taken from the Registration Key Request extension from the mobile node's Registration Request message. The foreign agent supplies a new SPI along with the new registration key, so that the new key will be useful in the same way as registration keys created by any other method. 8. Using Special Tunnels Whenever any node receives a tunneled datagram for which it has no visitor list entry for the datagram's destination, the node is not serving the mobile node as a foreign agent, and thus the care-of address used by the tunnel originator is surely incorrect. Thus, 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 its binding cache entry. If a foreign agent receiving the tunneled datagram has no binding cache entry for the destination, it cannot re-tunnel the node to its destination. Instead, the foreign agent 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 Perkins and Johnson Expires 29 January 1998 [Page 30] Internet Draft Route Optimization in Mobile IP 29 July 1997 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. 8.1. Home Agent Handling of Special Tunnels The home agent should then tunnel the datagram to the current care-of address for the mobile node. However, the home agent may not tunnel the datagram to the current care-of address if the special tunnel of the datagram originated at that care-of address, as indicated by the outer source address of the special tunnel. 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. When that happens, the foreign agent serving the mobile node appears to have lost its entry for the mobile node in its visitor list. For example, the foreign agent may have crashed and rebooted. Otherwise, after tunneling the datagram to the current care-of address for the mobile node, the home agent should notify the source of the special tunnel of the mobile node's current binding, by sending it a Binding Update message. 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. 8.2. Foreign Agents and Special Tunnels When a foreign agent is the endpoint of a tunneled datagram, it examines its visitor list for an entry for the destination mobile node, as in the base Mobile IP protocol. 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 infer 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 mobile node's home agent. The foreign agent probably learned the address of the home agent in the Registration Reply message for the mobile node, or Perkins and Johnson Expires 29 January 1998 [Page 31] Internet Draft Route Optimization in Mobile IP 29 July 1997 a later Binding Update message from which the binding cache entry was created. 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 should forward the datagram to the mobile node's home agent by sending it as a special tunnel (Section 3.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. 9. Mobile Node Key Requests If the mobile node detects that its new foreign agent supports smooth handoffs, it may initiate that process with its previous foreign agent, as well as asking its new foreign agent to aid in supplying a registration key for the new registration. The following code fragment illustrates a good algorithm for the mobile node to use during registration, to allow the maximum flexibility in the selection of the new registration key. Any particular mobile node may be configured to use one, none, or any subset of the key establishment procedures made available as part of the Route Optimization protocol. if (got 'S' bit from advertisement) { if (have registration key with previous FA) { ; /* append Previous Foreign Agent Notification */ } /* Set up registration key */ if (have security association with current FA) { ; /* Don't need to create a registration key */ } else if (have a public key) { ; /* append MN Public Key request */ } else if (want D-H exchange) { /* compute a value for prime p and generator g */ /* use it and append MN Key request */ } else /* append MN key request with null computed value, etc */ } In this way, the mobile node can get a registration key whenever one is available by any mechanism specified in this document. Perkins and Johnson Expires 29 January 1998 [Page 32] Internet Draft Route Optimization in Mobile IP 29 July 1997 10. Miscellaneous Home Agent Operations 10.1. Home Agent Rate Limiting A home agent is required to 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, most 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. 10.2. Receiving Registration Key Requests When the home agent receives a Registration Request message, an extension requesting a registration key (Section 6) 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 Section 3.2. In that event, the home agent employs a good algorithm for producing random keys [3] 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 home-mobile registration key reply extension (Section 7.1) 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 home-foreign registration key reply extension (Section 7.2) in the Registration Reply message. When the home agent transmits the Registration Reply message containing reply extensions to the foreign agent, the message has the overall structure as follows: ------------------------------------------------------------- |IP|UDP| Reg-Reply| MN Key| FA Key| HA-MH Auth.| HA-FA Auth.| ------------------------------------------------------------- The mobile node gets the registration key, typically encoded using an algorithm such as that described in Section 3.3.1. The encoding of the foreign agent's copy of the key depends on the particular key request made by the foreign agent, and may depend upon the SPI specified along with the encoded key. The HA-FA authentication extension is only included if the home agent and foreign agent share a mobility security association. Perkins and Johnson Expires 29 January 1998 [Page 33] Internet Draft Route Optimization in Mobile IP 29 July 1997 If the home agent cannot satisfy a request to select a registration key, it MAY still satisfy the registration attempt. In this case, the home agent returns a Registration Reply message indicating success, but does not include any key reply extension. 10.3. 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, only the home agent is aware of the mobile node's mobility binding and only the home agent tunnels datagrams to the mobile node. Thus, all routing of datagrams to the mobile node while away from its home network is controlled by the home agent. 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 almost any node in the Internet. Since no authentication or key distribution protocol is generally available in the Internet today, the Route Optimization procedures defined in this document make use of the same type of manually key distributing 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 include the same parameters as required by base Mobile IP [10]. 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 are required to have established a mobility security association. This mobility security association, though, could conceivably be used in creating and updating binding cache entries at this correspondent node for all mobile nodes served by this home agent. Doing so places the correspondent node in a fairly natural relationship with respect to the mobile nodes served by this home agent. For example, the mobile nodes may represent different people affiliated with the same organization owning the home agent, with which the user of the correspondent node often collaborates. The effort of establishing such a mobility security association with the relevant home agent may be more easily justified (appendix A) than the effort of doing so with each mobile node. 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 Perkins and Johnson Expires 29 January 1998 [Page 34] Internet Draft Route Optimization in Mobile IP 29 July 1997 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. 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. 10.4. Home Agent Supplying Registration Keys When the home agent receives a Registration Request message with registration key extensions, it usually performs one of two operations: - select and encode a registration key for both the mobile node and the foreign agent, or - transcribe the registration key already selected by the foreign agent into the appropriate extension to the Registration Reply message. Both operations ensure that the mobile node and home agent are dealing with the same foreign agent. When building the Registration Reply, the home agent should follow an algorithm such as the one illustrated below, to be as useful as possible for the range of registration key establishment scenarios that are possible given the current route optimization protocol. /* Set up registration key */ if (Foreign Agent Key Request) { /* then have security assn. */ /* append MN Key Reply to Registration Reply */ /* append FA key reply to Registration Reply */ } else if ((have foreign agent public key) || (have FA Public Key Reply)) { /* append MN Key Reply to Registration Reply */ /* append FA Public Key Reply to Registration Reply */ } else { /* do nothing */ } /* append mobile-home authentication extension at end */ Perkins and Johnson Expires 29 January 1998 [Page 35] Internet Draft Route Optimization in Mobile IP 29 July 1997 11. Miscellaneous Foreign Agent Operations This section details various operational considerations important for foreign agents wishing to support smooth handoff. This includes processing Previous Foreign Agent Notification messages, algorithms for establishment of registration keys, use of special tunnels, and the maintenance of up-to-date binding cache entries. 11.1. Previous Foreign Agent Notification When a foreign agent receives a Previous Foreign Agent Notification message, it creates a Binding Update for the previous foreign agent, using the specified SPI and precomputed authenticator sent to it by the mobile node. The Binding Update message is also required to set the 'A' bit, so that the previous foreign agent will know to send a Binding Acknowledge message back to the mobile node. When the previous foreign agent receives the Binding Update, it will authenticate the message using the mobility security association and SPI 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 message, the previous foreign agent will create a binding cache entry for the mobile node; the previous foreign agent can then tunnel datagrams to the mobile node's new care-of address using that binding cache, just as any node maintaining a binding cache. The previous foreign agent is also expected to return a Binding Acknowledge message to the mobile node. Note that this Binding Acknowledge is addressed to the mobile node, and thus needs to be tunneled using the new binding cache entry. The tunneled acknowledgment then should be delivered directly to the new foreign agent, without having to go to the home network. 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 acknowledgment from the previous foreign agent. This latter approach would have the benefit that fewer datagrams would Perkins and Johnson Expires 29 January 1998 [Page 36] Internet Draft Route Optimization in Mobile IP 29 July 1997 be transmitted over bandwidth-constrained wireless media during registration. When the Binding Acknowledge 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 message. The mobile node has to be certain that its previous foreign agent has been notified about its new care-of address, because otherwise the previous foreign agent could 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, and does not retransmit the message even if no acknowledgment is received. If the acknowledgment 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 Acknowledge. The registration key established with this previous foreign agent is typically destroyed as a part of the processing of this Binding Update message, or soon afterwards. 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. When no subsequent use of this registration key is expected, no reply protection is necessary for the Binding Update message used for the notification. Some foreign agents may choose to retain the key for a short time in case the mobile node does not receive the acknowledgment and resends the Binding Update later. 11.2. Maintaining Binding Caches It is possible that the binding cache entry taken by the previous foreign agent from the information in the abovementioned extension will be deleted from its cache at any time. In this case, the previous foreign agent will be unable to re-tunnel subsequently arriving tunneled datagrams for the mobile node, and would resort to using a special tunnel. Mobile nodes SHOULD assign small lifetimes Perkins and Johnson Expires 29 January 1998 [Page 37] Internet Draft Route Optimization in Mobile IP 29 July 1997 to such bindings so that they will not take up space in the foreign agent's binding cache for very long. 11.3. Rate Limiting A foreign agent is required to provide some mechanism to limit the rate at which it sends Binding Warning messages 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. 11.4. Foreign Agent Handling Key Requests The foreign agent, when it receives a request from a mobile node for a registration key, is faced with a variety of possible actions. The action selected by the foreign agent depends on the resources it has available. The foreign agent typically attempts to reduce as much as possible the computational burden placed on the mobile node, but relies on the security association with the greatest cryptographic strength to encode the registration key. Furthermore, if the foreign agent performs the key selection, it still supplies the encoded key in an extension to the Registration Request message, so that the process of registration will also have the effect of authenticating its choice of registration key to the mobile node. This strategy reduces the opportunity for interlopers to mount man-in-the-middle attacks. The following code fragment, executed when the foreign agent receives a key request of some variety, exhibits an algorithm which may be useful for implementors of foreign agents. The algorithm is supposed to be used when a foreign agent gets a Registration Request with one of the key request extensions included. if (Previous Foreign Agent Notification) { /* build the Binding Update and authentication extension */ } /* Set up registration key */ if (have security association with HA) { /* Append FA key request to Registration Request */ } else if (have a public key) { Perkins and Johnson Expires 29 January 1998 [Page 38] Internet Draft Route Optimization in Mobile IP 29 July 1997 /* append FA Public Key request to Registration Request */ } else if (have mobile node's public key) { /* pick a good key */ /* append FA Public Key Reply to Registration Request */ } else if (want D-H exchange) { /* start the computation */ /* append the result to the Registration Key Request */ else { /* do nothing */ } 12. Security Considerations Whenever the foreign agent is involved with the production of a registration key by use of the Diffie-Hellman algorithm, the process is susceptible to the "man-in-the-middle" attack, as detailed in Section 3.4. This attack is not known to produce further difficulty, and susceptibility is already inherent in the operation of the base Mobile IP specification [10]. Attention to this detail is warranted during any future changes to the Route Optimization protocol, and ways to reduce the risk of direct interest for inclusion into future revisions of this document. The calculation of the authentication data described in Section 3.3.1 is specified to be the same as in the base Mobile IP document for ease of implementation. There is a better method available (HMAC), specified in RFC 2104 [6]. If the base Mobile IP specification is updated to use HMAC, then this route optimization specification should also be updated similarly. Registration keys should typically NOT be used as master keys for producing other derived keys, because of the man-in-the-middle attack associated with unidentifiable foreign agents. 13. Summary In this document, we have presented the current protocol definition for Route Optimization, by which is meant the elimination of triangle routing whenever the correspondent node is able to perform the necessary protocol operations. The Route Optimization protocol definition is largely concerned with three areas: Perkins and Johnson Expires 29 January 1998 [Page 39] Internet Draft Route Optimization in Mobile IP 29 July 1997 - Supplying a Binding Update to any correspondent node that needs one (and has some realistic chance to process it correctly) - Providing means to create the needed authentication and replay protection so that the recipient of a binding update message can believe it, and - Allowing for the mobile node and foreign agent to create a registration key for later use in making a smooth transitions to a new point of attachment. The ways provided for the mobile node and foreign agent to obtain a registration key are as follows: - Use the mobility security association they share if it exists - Use the mobile node's public key if it exists - Use the foreign agent's public key, if it exists, to enable the home agent to create public keys for both entities, or - Use the security association between the foreign agent and home agent, if it exists, to enable the home agent to create the registration keys for both entities, or - Use the Diffie-Hellman key exchange algorithm. Lastly, we detail the use of special tunnels, so that foreign agents that lose track of one of their visiting mobile nodes can still forward datagrams to the home agent for another try at delivery. 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. Perkins and Johnson Expires 29 January 1998 [Page 40] Internet Draft Route Optimization in Mobile IP 29 July 1997 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 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. Perkins and Johnson Expires 29 January 1998 [Page 41] Internet Draft Route Optimization in Mobile IP 29 July 1997 References [1] CDPD consortium. Cellular Digital Packet Data Specification, July 1993. [2] W. Diffie and M. Hellman. New Directions in Cryptography. IEEE Transactions on Information Theory, 22:644--654, November 1976. [3] Donald E. Eastlake, Stephen D. Crocker, and Jeffrey I. Schiller. Randomness Recommendations for Security. RFC 1750, December 1994. [4] Stan Hanks, Tony Li, Dino Farinacci, and Paul Traina. Generic Routing Encapsulation (GRE). RFC 1701, October 1994. [5] David B. Johnson. Scalable and Robust Internetwork Routing for Mobile Hosts. In Proceedings of the 14th International Conference on Distributed Computing Systems, pages 2--11, June 1994. [6] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: Keyed-Hashing for Message Authentication. RFC 2104, February 1997. [7] RSA Laboratories. Rsaref: A cryptographic toolkit, version 2.0, 1994. http://www.consensus.com/rsaref/index.html. [8] Charles Perkins. IP Encapsulation within IP. RFC 2003, May 1996. [9] Charles Perkins. Minimal Encapsulation within IP. RFC 2004, May 1996. [10] C. Perkins, Editor. IPv4 Mobility Support. RFC 2002, October 1996. [11] Bruce Schneier. Applied Cryptography: Protocols, Algorithms, and Source Code in C. John Wiley, New York, NY, USA, 1994. Perkins and Johnson Expires 29 January 1998 [Page 42] Internet Draft Route Optimization in Mobile IP 29 July 1997 Chairs' Addresses The working group can be contacted via the current chairs: Jim Solomon Motorola, Inc. 1301 E. Algonquin Road Schaumburg, IL 60196 USA Phone: +1-847-576-2753 E-mail: solomon@comm.mot.com Erik Nordmark Sun Microsystems, Inc. 901 San Antonio Road Palo Alto, California 94303 USA Phone: +1 415 786-5166 Fax: +1 415 786-5896 E-mail: nordmark@sun.com Perkins and Johnson Expires 29 January 1998 [Page 43] Internet Draft Route Optimization in Mobile IP 29 July 1997 Authors' Addresses Questions about this document can also be directed to the authors: Charles E. Perkins Technology Development Group Mail Stop MPK15-214 Room 2682 Sun Microsystems, Inc. 901 San Antonio Road Palo Alto, California 94303 USA Phone: +1-415-786-6464 Fax: +1-415-786-6445 email: charles.perkins@Sun.COM 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 Perkins and Johnson Expires 29 January 1998 [Page 44]