[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11

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-06.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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/