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

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

Network Working Group                                   David B. Johnson
INTERNET DRAFT                                Carnegie Mellon University
15 March 1995                                            Charles Perkins
                                                         IBM Corporation
                                                            Andrew Myles
                                                    Macquarie University



                    Route Optimization in Mobile IP

                    draft-ietf-mobileip-optim-01.txt


Abstract

   This document defines extensions to the operation of the basic
   Mobile IP protocol to allow for optimization of datagram routing from
   a correspondent node to a mobile node.  Without Route Optimization,
   all datagrams destined to a mobile node are routed through that
   mobile node's home agent, which then tunnels each datagram to the
   mobile node's current location.  The protocol extensions described
   here provide a means for correspondent nodes that implement them to
   cache the location of a mobile node and to then tunnel their own
   datagrams for the mobile node directly to that location, bypassing
   the possibly lengthy route for each datagram to and from the mobile
   node's home agent.  Extensions are also provided to allow datagrams
   in flight when a mobile node moves, and datagrams sent based on an
   out-of-date cached location, to be forwarded directly to the mobile
   node's new location.


Status of This Memo

   This document is a product of the Mobile IP Working Group of the
   Internet Engineering Task Force (IETF). Comments should be submitted
   to working group mailing list at mobile-ip@tadpole.com.  Distribution
   of this memo is unlimited.

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at
   any time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress".






Johnson, Perkins, Myles        Expires 15 September 1995        [Page i]


Internet Draft       Route Optimization in Mobile IP       15 March 1995


   To learn the current status of any Internet-Draft, please check
   the "1id-abstracts.txt" listing contained in the Internet- Drafts
   Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).














































Johnson, Perkins, Myles       Expires 15 September 1995        [Page ii]


Internet Draft       Route Optimization in Mobile IP       15 March 1995




                                Contents



Abstract                                                               i

Status of This Memo                                                    i

 1. Introduction                                                       1

 2. Route Optimization Overview                                        3
     2.1. Location Caching  . . . . . . . . . . . . . . . . . . . .    3
     2.2. Foreign Agent Handoff . . . . . . . . . . . . . . . . . .    3
     2.3. Location Cache Updates  . . . . . . . . . . . . . . . . .    6

 3. Route Optimization Message Formats                                 8
     3.1. Binding Warning Message . . . . . . . . . . . . . . . . .    9
     3.2. Binding Request Message . . . . . . . . . . . . . . . . .   10
     3.3. Binding Update Message  . . . . . . . . . . . . . . . . .   11
     3.4. Binding Acknowledge Message . . . . . . . . . . . . . . .   13

 4. Route Optimization Extension Formats                              14
     4.1. Previous Foreign Agent Notification Extension . . . . . .   15
     4.2. Route Optimization Authentication Extension . . . . . . .   17
     4.3. Registration Key Request Extension  . . . . . . . . . . .   18
     4.4. Mobile Node Registration Key Extension  . . . . . . . . .   19
     4.5. Foreign Agent Registration Key Extension  . . . . . . . .   20
     4.6. Foreign Agent Public Key Extension  . . . . . . . . . . .   21

 5. Mobility Security Association Management                          22
     5.1. Motivation  . . . . . . . . . . . . . . . . . . . . . . .   22
     5.2. Mobility Security Associations  . . . . . . . . . . . . .   23

 6. Location Cache Considerations                                     24
     6.1. Cache Management  . . . . . . . . . . . . . . . . . . . .   24
     6.2. Receiving Binding Warning Messages  . . . . . . . . . . .   24
     6.3. Receiving Binding Update Messages . . . . . . . . . . . .   25
     6.4. Using Special Tunnels . . . . . . . . . . . . . . . . . .   25

 7. Home Agent Considerations                                         26
     7.1. Rate Limiting . . . . . . . . . . . . . . . . . . . . . .   26
     7.2. Receiving Binding Request Messages  . . . . . . . . . . .   26
     7.3. Receiving Registration Key requests . . . . . . . . . . .   27
     7.4. Receiving Special Tunnels . . . . . . . . . . . . . . . .   27





Johnson, Perkins, Myles       Expires 15 September 1995       [Page iii]


Internet Draft       Route Optimization in Mobile IP       15 March 1995


 8. Foreign Agent Considerations                                      28
     8.1. Setting up Temporary Mobility Security Associations . . .   28
     8.2. Previous Foreign Agent Notification . . . . . . . . . . .   29
     8.3. Receiving Tunneled Datagrams  . . . . . . . . . . . . . .   30
     8.4. Sending Special Tunnels . . . . . . . . . . . . . . . . .   30

 9. Mobile Node Considerations                                        31
     9.1. Requesting a Registration Key . . . . . . . . . . . . . .   31
     9.2. Notifying Previous Foreign Agents . . . . . . . . . . . .   31

References                                                            33

Appendix A. Using a Master Key at the Home Agent                      34

Chairs' Addresses                                                     35

Authors' Addresses                                                    36


































Johnson, Perkins, Myles       Expires 15 September 1995        [Page iv]


Internet Draft       Route Optimization in Mobile IP       15 March 1995


1. Introduction

   The basic Mobile IP protocol [3] allows any mobile node to move
   about, changing its point of attachment to the Internet, while
   continuing to be addressed by its home IP address.  Correspondent
   nodes sending IP datagrams to a mobile node address them to the
   mobile node's home address in the same way as to any destination.

   While the mobile node is connected to the Internet away from its
   home network, it is served by a "home agent" on its home network
   and is associated with a "care-of address" indicating its current
   location.  The association between a mobile node's home address and
   its care-of address is known as a "mobility binding".  The care-of
   address is generally the address of a "foreign agent" on the network
   being visited by the mobile node, which forwards arriving datagrams
   locally to the mobile node.  Alternatively, the care-of address may
   be temporarily assigned to the mobile node using DHCP [1] or other
   means.  All IP datagrams addressed to the mobile node are routed by
   the normal IP routing mechanisms to the mobile node's home network,
   where they are intercepted by the mobile node's home agent, which
   then tunnels each datagram to the mobile node's current care-of
   address.  Datagrams sent by a mobile node use the foreign agent as a
   default router but require no other special handling or routing.

   This basic scheme allows transparent interoperation with mobile
   nodes, but forces all datagrams for a mobile node to be routed
   through its home agent; packets to the mobile node are often routed
   along paths that are significantly longer than optimal.  For example,
   if a mobile node, say MN1, is visiting some subnet, even datagrams
   from a correspondent node on this same subnet must be routed through
   the Internet to MN1's home agent on MN1's home network, only to then
   be tunneled back to the original subnet to MN1's foreign agent for
   delivery to MN1.  This indirect routing can significantly delay the
   delivery of the datagram to MN1 and places an unnecessary burden on
   the networks and routers along this path through the Internet.  If
   the correspondent node in this example is actually another mobile
   node, say MN2, then datagrams from MN1 to MN2 must likewise be routed
   through MN2's home agent on MN2's home network and back to the
   original subnet for delivery to MN1.

   This document defines extensions to the basic Mobile IP protocol to
   allow for the optimization of datagram routing from a correspondent
   node to a mobile node.  These extensions provide a means for nodes
   that implement them to cache the care-of address of a mobile node
   and to then tunnel their own datagrams directly there, bypassing the
   possibly lengthy route to and from that mobile node's home agent.
   Extensions are also provided to allow datagrams in flight when a
   mobile node moves, and datagrams sent based on an out-of-date cached



Johnson, Perkins, Myles        Expires 15 September 1995        [Page 1]


Internet Draft       Route Optimization in Mobile IP       15 March 1995


   care-of address, to be forwarded directly to the mobile node's new
   care-of address.  These extensions are collectively referred to as
   Route Optimization in this document.

   All operation of Route Optimization that changes the routing of IP
   datagrams to the mobile node is authenticated using the same type of
   authentication mechanism used in the basic Mobile IP protocol.  This
   authentication generally relies on a "mobility security association"
   established in advance between the node sending a message and the
   node receiving the message that must authenticate it.  When the
   required mobility security association has not been established, a
   Mobile IP implementation using Route Optimization operates in the
   same way as the basic Mobile IP protocol.

   Section 2 of this document provides an overview of the operation of
   Route Optimization.  Section 3 defines the message types used by
   Route Optimization, and Section 4 defines the message extensions
   used.  Section 5 discusses the problem of managing the mobility
   security associations needed to provide authentication of all
   messages that affect the routing of datagrams to a mobile node.
   The final four sections of this document define in detail the
   operation of Route Optimization from the point of view of each of the
   entities involved:  considerations for nodes maintaining a location
   cache are presented in Section 6, mobile node considerations in
   Section 9, foreign agent considerations in Section 8, and home agent
   considerations in Section 7.

























Johnson, Perkins, Myles        Expires 15 September 1995        [Page 2]


Internet Draft       Route Optimization in Mobile IP       15 March 1995


2. Route Optimization Overview

2.1. Location Caching

   Route Optimization provides a means for any node that wishes to
   optimize its own communication with mobile nodes to maintain a
   "location cache" containing the mobility binding of one or more
   mobile nodes.  When sending an IP datagram to a mobile node, if the
   sender has a location cache entry for the destination mobile node, it
   may tunnel the datagram directly to the care-of address indicated in
   the cached mobility binding.

   In the absence of any location cache entry, datagrams destined for
   a mobile node will be routed to the mobile node's home network in
   the same way as any other IP datagram, and are then tunneled to the
   mobile node's current care-of address by the mobile node's home
   agent.  This is the only routing mechanism supported by the basic
   Mobile IP protocol.  With Route Optimization, as a side effect of
   this indirect routing of a datagram to a mobile node, the original
   sender of the datagram may be informed of the mobile node's current
   mobility binding, giving the sender an opportunity to cache the
   binding.

   A node may create a location cache entry for a mobile node only when
   it has received and authenticated the mobile node's mobility binding.
   Likewise, a node may update an existing location cache entry for a
   mobile node, such as after the mobile node has moved to a new foreign
   agent, only when it has received and authenticated the mobile node's
   new mobility binding.

   A location cache will, by necessity, have a finite size.  Any node
   implementing a location cache may manage the space in its cache
   using any local cache replacement policy.  If a datagram is sent
   to a destination for which the cache entry has been dropped from
   the cache, the datagram will be routed normally through the mobile
   node's home network and will be tunneled to the mobile node's care-of
   address by its home agent.  This indirect routing to the mobile node
   will result in the original sender of the datagram being informed of
   the mobile node's current mobility binding, allowing it to add this
   entry again to its location cache.


2.2. Foreign Agent Handoff

   When a mobile node moves and registers with a new foreign agent, the
   basic Mobile IP protocol does not notify the mobile node's previous
   foreign agent.  IP datagrams intercepted by the home agent after
   the new registration are tunneled to the mobile node's new care-of



Johnson, Perkins, Myles        Expires 15 September 1995        [Page 3]


Internet Draft       Route Optimization in Mobile IP       15 March 1995


   address, but datagrams in flight that had already been intercepted
   by the home agent and tunneled to the old care-of address when the
   mobile node moved are lost and are assumed to be retransmitted by
   higher-level protocols if neeeded.  The old foreign agent eventually
   deletes the mobile node's registration after the expiration of the
   lifetime period established when the mobile node registered there.

   Route Optimization provides a means for the mobile node's previous
   foreign agent to be reliably notified of the mobile node's new
   mobility binding, allowing datagrams in flight to the mobile
   node's previous foreign agent to be forwarded to its new care-of
   address.  This notification also allows any datagrams tunneled to the
   mobile node's previous foreign agent from correspondent nodes with
   out-of-date location cache entries for the mobile node (that have not
   yet learned that the mobile node has moved), to be forwarded to its
   new care-of address.  Finally, this notification allows any resources
   consumed by the mobile node's binding at the previous foreign agent
   (such as radio channel reservations) to be released immediately,
   rather than waiting for the mobile node's registration to expire.

   During registration with a new foreign agent, the mobile node and the
   new foreign agent may establish a "registration key", which acts as a
   session key for this registration.  When a Registration Key Request
   extension is included in the Registration Request message to the
   mobile node's home agent, the home agent may choose a registration
   key and include it in its Registration Reply message.  The home agent
   includes a Mobile Node Registration Key extension, containing a copy
   of the chosen key encrypted under a key and algorithm shared between
   the home agent and the mobile node, and a Foreign Agent Registration
   Key extension, containing a copy of the same key encrypted under
   a key and algorithm shared between the home agent and the foreign
   agent.  In order for the registration key to be established, the
   foreign agent must have a mobility security association with the home
   agent.  This security association may either be preestablished or may
   be established for purposes of this registration through exchange of
   the foreign agent's public encryption key in the Agent Advertisement
   and Registration Request messages.  The registration key for a mobile
   node can be stored by the foreign agent with the mobile node's
   visitor list entry.

   When a mobile node registers with a new foreign agent, if it
   established a registration key during registration with its previous
   foreign agent, it may use this key to notify the previous foreign
   agent that it has moved.  This notification may also optionally
   include the mobile node's new care-of address, allowing the previous
   foreign agent to create a location cache entry for the mobile node to
   serve as a "forwarding pointer" to its new location.  Any tunneled
   datagrams for the mobile node that arrive at this previous foreign



Johnson, Perkins, Myles        Expires 15 September 1995        [Page 4]


Internet Draft       Route Optimization in Mobile IP       15 March 1995


   agent after this location cache entry has been created will then be
   re-tunneled by this foreign agent to the mobile node's new location
   using the mobility binding in this location cache entry.  The
   registration key is used to authenticate the notification sent to the
   previous foreign agent.

   As part of the registration procedure, the mobile node may
   request that its new foreign agent attempt to notify its previous
   foreign agent on its behalf, by including a Previous Foreign Agent
   Notification extension in its Registration Request message sent to
   the new foreign agent.  The new foreign agent then builds a Binding
   Update message and transmits it to the mobile node's previous foreign
   agent as part of registration, requesting an acknowledgement from
   the previous foreign agent.  The Previous Foreign Agent Notification
   extension includes only those values needed to construct the Binding
   Update message that are not already contained in the Registration
   Request message.  The authenticator for the Binding Update message is
   computed by the mobile node based on its registration key shared with
   its previous foreign agent.

   The mobile node is responsible for occasionally retransmitting a
   Binding Update message to its previous foreign agent until the
   matching Binding Acknowledge message is received, or until the mobile
   node can be sure of the expiration of its registration with that
   foreign agent.

   The location cache entry created at the mobile node's previous
   foreign agent is treated in the same way as any other location cache
   entry.  In particular, it is possible that this location cache
   entry will be deleted from the cache at any time.  In this case,
   the foreign agent will be unable to re-tunnel subsequently arriving
   tunneled datagrams for the mobile node directly to its new location.
   Suppose a node (for instance, such a previous foreign agent) receives
   a datagram that has been tunneled to this node, but this node is
   unable to deliver the datagram locally to the destination mobile node
   (the node is not the mobile node itself, and it is not a foreign
   agent with a visitor list entry for the mobile node).  To attempt
   delivery of the datagram in this case, the node must encapsulate
   the datagram as a "special tunnel" datagram (Section 8.4), destined
   to the mobile node.  Otherwise, the datagram would eventually reach
   the mobile node's home network, be intercepted by the mobile node's
   home agent, and be tunneled to the mobile node's current care-of
   address.  If the home agent were to tunnel the datagram back to the
   same foreign agent, a loop would be created.







Johnson, Perkins, Myles        Expires 15 September 1995        [Page 5]


Internet Draft       Route Optimization in Mobile IP       15 March 1995


2.3. Location Cache Updates

   When a mobile node's home agent intercepts a datagram from the home
   network and tunnels it to the mobile node, the home agent may deduce
   that the original sender of the datagram has no location cache entry
   for the destination mobile node.  In this case, the home agent MAY
   send a Binding Update message to the sender, informing it of the
   mobile node's current mobility binding.  No acknowledgement for this
   Binding Update message is needed, since additional future datagrams
   from this sender intercepted by the home agent for the mobile node
   will cause transmission of another update.  In order for this Binding
   Update to be authenticated by the sender of the datagram, the home
   agent and the sender must have established a mobility security
   association.

   Similarly, when any node receives a tunneled datagram tunneled
   to this node, if it is not the current foreign agent serving the
   destination as a mobile node the source of the tunneled datagram
   probably has an out-of-date location cache entry for the destination
   mobile node.  In this case, this node MAY send a Binding Warning
   message to the originator of the tunneled datagram.  As above, no
   acknowledgement of this Binding Warning is needed.

   Unlike the Binding Update message, though, no authentication of the
   Binding Warning message is necessary, since it does not directly
   affect the routing of IP datagrams to the mobile node.  Instead, when
   a node receives a Binding Warning message, that node sends a Binding
   Request message to the indicated mobile node's home agent, requesting
   the mobile node's current mobility binding.  The home agent then
   answers this Binding Request message with a Binding Update message,
   and when the Binding Update message is received, the node may then
   create a location cache entry for the mobile node.  In order for this
   node and the home agent to exchange these Binding Request and Binding
   Update messages, they must have established a mobility security
   association.

   Each Binding Update message indicates the maximum lifetime of any
   location cache entry created from the Binding Update.  When sending
   the Binding Update message, the home agent SHOULD set this lifetime
   to the remaining service lifetime associated with the mobile node's
   current registration.  Any location cache entry established or
   updated in response to this Binding Update message must be marked
   to be deleted after the expiration of this period.  A node wanting
   to provide continued service with a particular location cache entry
   may attempt to reconfirm that mobility binding before the expiration
   of this lifetime period.  Location cache entry reconfirmation
   may be appropriate when the node has indications (such as an open
   transport-level connection to the mobile node) that the location



Johnson, Perkins, Myles        Expires 15 September 1995        [Page 6]


Internet Draft       Route Optimization in Mobile IP       15 March 1995


   cache entry is still needed.  This reconfirmation is performed by
   the node sending a Binding Request message to the mobile node's home
   agent, requesting it to reply with the mobile node's current mobility
   binding in a new Binding Update message.















































Johnson, Perkins, Myles        Expires 15 September 1995        [Page 7]


Internet Draft       Route Optimization in Mobile IP       15 March 1995


3. Route Optimization Message Formats

   Route Optimization defines four message types used for management
   of location cache entries.  Each of these messages begins with a
   one-octet field indicating the type of the message.

   The following Type codes are defined in this document:

      16 = Binding Warning message
      17 = Binding Request message
      18 = Binding Update message
      19 = Binding Acknowledge message







































Johnson, Perkins, Myles        Expires 15 September 1995        [Page 8]


Internet Draft       Route Optimization in Mobile IP       15 March 1995


3.1. Binding Warning Message

   A Binding Warning message is used to advise a node that it appears
   to have either no location cache entry or an out-of-date location
   cache entry for some mobile node.  When any node receives a datagram
   tunneled to itself, if it is not the current foreign agent for the
   destination mobile node, it MAY send a Binding Warning message to the
   node that originated the tunneled datagram.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |                   Reserved                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Mobile Node Home Address                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

         16

      Reserved

         Sent as 0; ignored on reception.

      Mobile Node Home Address

         The home address of the mobile node to which the Binding
         Warning message refers.






















Johnson, Perkins, Myles        Expires 15 September 1995        [Page 9]


Internet Draft       Route Optimization in Mobile IP       15 March 1995


3.2. Binding Request Message

   A Binding Request message is used by a node to request a mobile
   node's current mobility binding from the mobile node's home agent.
   It is sent by a node upon receiving a Binding Warning message, or by
   a node desiring to update the mobility binding in a location cache
   entry that it holds for the mobile node.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |                  Reserved                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Mobile Node Home Address                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                         Identification                        +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

         17

      Reserved

         Sent as 0; ignored on reception.

      Mobile Node Home Address

         The home address of the mobile node to which the Binding
         Request refers.

      Identification

         A 64-bit sequence number, assigned by the node sending the
         Binding Request message, used to assist in matching requests
         with replies, and in protecting against replay attacks.













Johnson, Perkins, Myles       Expires 15 September 1995        [Page 10]


Internet Draft       Route Optimization in Mobile IP       15 March 1995


3.3. Binding Update Message

   The Binding Update message is used to notify another node of a mobile
   node's current mobility binding.  It MAY be sent by the mobile node's
   home agent in response to a Binding Request message.  It MAY also
   be sent by a mobile node, or by the foreign agent with which the
   mobile node is registering, when notifying the mobile node's previous
   foreign agent that the mobile node has moved.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |A|I| Reserved  |            Lifetime           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Lifetime                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Mobile Node Home Address                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Care-of Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                         Identification                        +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Extensions ...
   +-+-+-+-+-+-+-+-

      Type

         18

      Acknowledge (A)

         The Acknowledge (A) bit is set by the node sending the Binding
         Update message to request a Binding Acknowledge message be
         returned acknowledging its receipt.

      Identification Present (I)

         The (I) bit is set by the node sending the Binding Update
         message to indicate whether or not the Identification field is
         present.

      Reserved

         Sent as 0; ignored on reception.





Johnson, Perkins, Myles       Expires 15 September 1995        [Page 11]


Internet Draft       Route Optimization in Mobile IP       15 March 1995


      Lifetime

         The number of seconds remaining before the location cache entry
         must be considered expired.  A value of all ones indicates
         infinity.  A value of zero indicates that no location cache
         entry for the mobile node should be created, and any existing
         location cache entry (and visitor list entry, in the case of
         a mobile node's previous foreign agent) for the mobile node
         should be deleted.  The lifetime is typically equal to the
         remaining lifetime of the mobile node's registration.

      Mobile Node Home Address

         The home address of the mobile node to which the Binding Update
         message refers.

      Care-of Address

         The current care-of address of the mobile node.  When set equal
         to the home address of the mobile node, the Binding Update
         message instead indicates that no location cache entry for the
         mobile node should be created, and any existing location cache
         entry (and visitor list entry, in the case of a mobile node's
         previous foreign agent) for the mobile node should be deleted.

      Identification

         If present, a 64-bit number, assigned by the node sending the
         Binding Request message, used to assist in matching requests
         with replies, and in protecting against replay attacks.

   The Route Optimization Authentication extension (Section 4.2) is
   required.


















Johnson, Perkins, Myles       Expires 15 September 1995        [Page 12]


Internet Draft       Route Optimization in Mobile IP       15 March 1995


3.4. Binding Acknowledge Message

   A Binding Acknowledge message is used to acknowledge receipt of a
   Binding Update message.  It is sent by a node receiving the Binding
   Update message, if the Acknowledge (A) bit is set in the Binding
   Update message.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |N|               Reserved                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Mobile Node Home Address                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                         Identification                        +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

         19

      N

         This bit is set if the acknowledgement is negative.  For
         instance, if the binding update was not accepted, but the
         incoming datagram has the Acknowledge flag set, then the N bit
         is set in this Binding Acknowledge message.

         DISCUSSION: Alternatively, we could replace this bit with a
         status code, as in the Registration Reply message.  The mobile
         node could log the error, but currently has no real way to
         recover from it.

      Reserved

         Sent as 0; ignored on reception.

      Mobile Node Home Address

         Copied from the Binding Update message being acknowledged.

      Identification

         Copied from the Binding Update message being acknowledged, if
         present there.




Johnson, Perkins, Myles       Expires 15 September 1995        [Page 13]


Internet Draft       Route Optimization in Mobile IP       15 March 1995


4. Route Optimization Extension Formats

   Route Optimization defines the following Mobile IP message
   extensions:

       96 = Previous Foreign Agent Notification extension
       97 = Route Optimization Authentication extension
       98 = Registration Key Request extension
       99 = Mobile Node Registration Key extension
      100 = Foreign Agent Registration Key extension
      101 = Foreign Agent Public Key extension








































Johnson, Perkins, Myles       Expires 15 September 1995        [Page 14]


Internet Draft       Route Optimization in Mobile IP       15 March 1995


4.1. Previous Foreign Agent Notification Extension

   The Previous Foreign Agent Notification Extension may be included in
   a Registration Request message sent to a foreign agent.  It requests
   the new foreign agent to send a Binding Update message on behalf of
   the mobile node, to the mobile node's previous foreign agent, to
   notify it that the mobile node has moved.  The previous foreign agent
   deletes the mobile node's visitor list entry and creates a location
   cache entry for the mobile node pointing to its new care-of address.
   The extension contains only those values not otherwise already
   contained in the Registration Request message, which are needed for
   the new foreign agent to construct the Binding Update message.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Length    |         Cache Lifetime        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Previous Foreign Agent Address                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Authenticator ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

         96

      Length

         6 plus the length of the Authenticator

      Cache Lifetime

         The number of seconds remaining before the location cache
         entry created by the previous foreign agent must be considered
         expired.  A value of all ones indicates infinity.  A value
         of zero indicates that the previous foreign agent should not
         create a location cache entry for the mobile node once it
         has deleted the mobile node's visitor list entry.  The Cache
         Lifetime value is copied into the Lifetime field of the Binding
         Update message.

      Previous Foreign Agent Address

         The IP address of the mobile node's previous foreign agent
         to which the new foreign agent should send a Binding Update
         message on behalf of the mobile node.




Johnson, Perkins, Myles       Expires 15 September 1995        [Page 15]


Internet Draft       Route Optimization in Mobile IP       15 March 1995


      Authenticator

         The authenticator value to be used in the Route Optimization
         Authentication extension in the Binding Update message sent by
         the new foreign agent to the mobile node's previous foreign
         agent.  This authenticator is calculated only over the Binding
         Update message body.












































Johnson, Perkins, Myles       Expires 15 September 1995        [Page 16]


Internet Draft       Route Optimization in Mobile IP       15 March 1995


4.2. Route Optimization Authentication Extension

   The Route Optimization Authentication Extension is used to
   authenticate certain Route Optimization management messages.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Length    |        Authenticator ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

         97

      Length

         The length of the Authenticator

      Authenticator

         (variable length) A hash value taken over a stream of bytes
         including the shared secret, all prior extensions in their
         entirety, the the Route Optimization management data, and
         the type and length of this extension, but not including the
         Authenticator field itself.

























Johnson, Perkins, Myles       Expires 15 September 1995        [Page 17]


Internet Draft       Route Optimization in Mobile IP       15 March 1995


4.3. Registration Key Request Extension

   The Registration Key Request extension may be used on Registration
   Request messages to request a registration key from the mobile
   node's home agent.  The extension is authenticated along with the
   rest of the Registration Request message, and thus no additional
   authenticator is included in the extension.  In response to a
   Registration Key Request extension, the home agent MAY include
   a Mobile Node Registration Key extension and a Foreign Agent
   Registration Key extension in its Registration Reply message,
   containing encrypted copies of the registration key for the mobile
   node the foreign agent.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Length    |  Foreign Agent Public Key ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

         98

      Length

         The length of the Foreign Agent Public Key, or 0 if no Foreign
         Agent Public Key is present

      Foreign Agent Public Key

         If the mobile node received a Foreign Agent Public Key
         extension in the foreign agent's Agent Advertisement message,
         this field is present and contains the key advertised in that
         message, if the mobile node chooses to use the key.

   The mobility security association assumed to exist between the home
   agent and the mobile node will be used to encrypt the key unless a
   Key Identification extension is also included with the Registration
   Request message.  The key returned by the home agent will be assumed,
   by default, to be 128 bits long.











Johnson, Perkins, Myles       Expires 15 September 1995        [Page 18]


Internet Draft       Route Optimization in Mobile IP       15 March 1995


4.4. Mobile Node Registration Key Extension

   The Mobile Node Registration Key extension may be used on
   Registration Reply messages to send a registration key from the
   mobile node's home agent to the mobile node.  When used, the home
   agent must also include a Foreign Agent Registration Key extension in
   the Registration Reply message, giving a copy of the same key to the
   mobile node's new foreign agent.  The Mobile Node Registration Key
   extension is authenticated along with the rest of the Registration
   Reply message, and thus no additional authenticator is included in
   the extension.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Length    |  Mobile Node Encrypted Key ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

         99

      Length

         The length of the Mobile Node Encrypted Key

      Mobile Node Encrypted Key

         (variable length) The registration key, chosen by the home
         agent, encrypted based on the mobility security association
         between the home agent and the mobile node.  The same key must
         be sent, encrypted for the foreign agent in a Foreign Agent
         Registration Key extension in this Registration Reply message.


















Johnson, Perkins, Myles       Expires 15 September 1995        [Page 19]


Internet Draft       Route Optimization in Mobile IP       15 March 1995


4.5. Foreign Agent Registration Key Extension

   The Foreign Agent Registration Key extension may be used on
   Registration Reply messages to send a registration key from
   the mobile node's home agent to the mobile node's new foreign
   agent.  When used, the home agent must also include a Mobile Node
   Registration Key extension in the Registration Reply message,
   giving a copy of the same key to the mobile node.  The Foreign
   Agent Registration Key extension is authenticated by including an
   authenticator in the extension, computed based on the mobility
   security association shared between the home agent and the foreign
   agent.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Length    |  Foreign Agent Encrypted Key ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Authenticator ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

         100

      Length

         The length of the Foreign Agent Encrypted Key plus the length
         of the Authenticator

      Foreign Agent Encrypted Key

         (variable length) The registration key, chosen by the home
         agent, encrypted based on the mobility security association
         between the home agent and the foreign agent, if one exists, or
         based on the foreign agent public key from the Registration Key
         Request message.  The same key must be sent, encrypted for the
         mobile node in a Mobile Node Registration Key extension in this
         Registration Reply message.

      Authenticator

         (variable length) A hash value taken over a stream of bytes
         including the shared secret and the fields in this extension
         other than the Authenticator field itself.






Johnson, Perkins, Myles       Expires 15 September 1995        [Page 20]


Internet Draft       Route Optimization in Mobile IP       15 March 1995


4.6. Foreign Agent Public Key Extension

   The Foreign Agent Public Key Extension MAY be included by a foreign
   agent in the Agent Advertisement messages that it sends.  The
   extension advertises the foreign agent's public encryption key, to
   allow mobile nodes to include the key in a Registration Key Request
   extension to their Registration Request message.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Length    |  Foreign Agent Public Key ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

         101

      Length

         The length of the Foreign Agent Public Key

      Foreign Agent Public Key

         The foreign agent's public encryption key


























Johnson, Perkins, Myles       Expires 15 September 1995        [Page 21]


Internet Draft       Route Optimization in Mobile IP       15 March 1995


5. Mobility Security Association Management

5.1. Motivation

   One of the most difficult aspects of Route Optimization for Mobile IP
   in the Internet today is that of providing authentication for all
   messages that affect the routing of datagrams to a mobile node.
   In the basic Mobile IP protocol, all routing of datagrams to the
   mobile node while away from its home network is controlled by the
   home agent, since only the home agent is aware of the mobile node's
   mobility binding and only the home agent tunnels datagrams to
   the mobile node.  Authentication is achieved based on a manually
   established "mobility security association" between the home agent
   and the mobile node.  Since the home agent and the mobile node are
   both owned by the same organization (both are assigned IP addresses
   within the same IP subnet), this manual configuration is manageable,
   and (for example) can be performed while the mobile node is at home.

   With Route Optimization, though, there is a need in general to
   authenticate messages between two nodes belonging to different
   organizations, making establishment of a mobility security
   association more difficult.  Since no general authentication or key
   distribution protocol is available in the Internet today, the Route
   Optimization procedures defined in this document rely partially on
   the same type of manually configured mobility security associations
   used in the basic Mobile IP protocol.

   For a correspondent node to be able to create a location cache entry
   for a mobile node so that it can tunnel its own IP datagrams directly
   to the mobile node at its current location, the correspondent node
   and the mobile node's home agent must have established a mobility
   security association.  This mobility security association, though,
   may be used in creating and updating location cache entries at
   this correspondent node for all mobile nodes served by this home
   agent.  This places the correspondent node in a fairly natural
   relationship with respect to the mobile nodes served by this home
   agent.  For example, these mobile nodes may represent different
   people affiliated with the organization owning the home agent and
   these mobile nodes, with which the user of this correspondent node
   often collaborates.  In this case, the effort of establishing the
   necessary mobility security association with this home agent may be
   justified.  It is similarly possible for a mobile node to have a
   manually established mobility security association with the foreign
   agents that it commonly uses; when it does, there is no need to
   obtain a registration key from the home agent.

   However, the possibility of obtaining a registration key, as outlined
   in Section 8.1, allows smooth handoffs to occur even in the absence



Johnson, Perkins, Myles       Expires 15 September 1995        [Page 22]


Internet Draft       Route Optimization in Mobile IP       15 March 1995


   of mutually assured identification between the mobile node and the
   foreign agent.  This feature depends for its operation on the fact
   that the foreign agent has already agreed to provide service for the
   mobile node; no additional verification of identity is required.  In
   other words, for the purposes of mobility protocols, if an agent acts
   like a foreign agent, then it is a foreign agent.

   In general, if the movement and communication patterns of a mobile
   node or the group of mobile nodes served by the same home agent are
   sufficient to justify establishing a mobility security association
   with the mobile node's home agent, users or network administrators
   are likely to do so.  Establishing a mobility security association
   is not a requirement to using the protocol.  In that case, however,
   the ability of correspondent nodes to use the Mobile IP protocol with
   Route Optimization is severely restricted; datagrams destined for a
   mobile node have to be routed through the mobile node's home agent,
   to be tunneled to the mobile node's current location.


5.2. Mobility Security Associations

   For use with Route Optimization, a mobility security association held
   by a correspondent node or a foreign agent must in general include
   the same parameters as required by the base Mobile IP protocol
   specification [3].


























Johnson, Perkins, Myles       Expires 15 September 1995        [Page 23]


Internet Draft       Route Optimization in Mobile IP       15 March 1995


6. Location Cache Considerations

   Any node may maintain a location cache in order to optimize its
   own communication with mobile nodes.  When sending a datagram, if
   the node has a location cache entry for the destination node, it
   may tunnel the datagram to the mobile node's care-of address using
   the encapsulation techniques described for home agents in the base
   Mobile IP protocol specification [3].

   When a node other than the foreign agent currently serving a mobile
   node receives a datagram for a mobile node, and this datagram has
   been tunneled to that node, the node tunneling the datagram generally
   has an out-of-date binding for the mobile node in its location
   cache.  In such cases, the node receiving the tunneled datagram may
   send a Binding Warning message to the tunneling node, which should
   then request a new binding for the mobile node by sending a Binding
   Request message to the mobile node's home agent.  Similarly, when a
   mobile node's home agent intercepts a datagram on the home network
   and tunnels it to the mobile node, the originating node typically
   has no location cache entry for the destination mobile node.  In
   such cases, the home agent may send a Binding Update message to the
   originator.


6.1. Cache Management

   A node maintaining a location cache may use any reasonable strategy
   for managing the space within the cache.  When a new entry needs to
   be added to the location cache, the node may choose to drop any entry
   already in the cache, if needed, to make space for the new entry.
   For example, a "least-recently used" (LRU) strategy for cache entry
   replacement is likely to work well.

   Each binding in the location cache also has an associated lifetime,
   specified by in the Binding Update message in which the node obtained
   the binding.  After the expiration of this time period, the binding
   MUST be dropped from the cache.


6.2. Receiving Binding Warning Messages

   A node maintaining and using a location cache will receive a Binding
   Warning message if its location cache entry for a datagram it has
   tunneled is out-of-date, as determined by the node which receives the
   tunneled datagram.  The node receiving the Binding Warning message
   then constructs a Binding Request message to obtain a new binding
   from the home agent serving the mobile node.  Included in the Binding
   Request message is a 64-bit identification field, in the same format



Johnson, Perkins, Myles       Expires 15 September 1995        [Page 24]


Internet Draft       Route Optimization in Mobile IP       15 March 1995


   described in the base Mobile IP protocol document, for matching the
   request with the returned Binding Update message.  The node should
   silently discard any Binding Update messages that do not correspond
   with its latest Binding Request message for this mobile node.


6.3. Receiving Binding Update Messages

   When a node receives a Binding Update message, it uses the
   authentication technique indicated by the mobility security
   association between itself and the mobile node's home agent.  The
   authentication data is found in the Route Optimization Authentication
   Extension (Section 4.2).  If the authentication succeeds, then a
   location cache entry may be updated for use in future transmissions
   of data to the mobile node.  Otherwise, an authentication exception
   SHOULD be raised.


6.4. Using Special Tunnels

   Whenever any node receives a tunneled datagram for a mobile node,
   for which no location cache entry or visitor list entry is known,
   the node may determine that it has received the tunneled datagram
   in error.  In this case, the node should use a "special tunnel" to
   make sure the datagram arrives at the home agent for the mobile node.
   The home agent will then notify the originator of the tunnel about
   its out-of-date location cache entry, and take steps to deliver the
   datagram to the current care-of address of the mobile node.  As part
   of this service, the home agent must also check to make sure that the
   datagram is not tunneled again to the node originating the special
   tunnel.




















Johnson, Perkins, Myles       Expires 15 September 1995        [Page 25]


Internet Draft       Route Optimization in Mobile IP       15 March 1995


7. Home Agent Considerations

   The home agent will be the frequent source of and Binding Update
   messages sent to correspondent nodes which are communicating with its
   mobile nodes.  Any correspondent node which has no cached bindings
   for a mobile node, will send normal, untunneled datagrams through
   the home agent by the normal routing in the Internet.  When the home
   agent first gets a datagram for a mobile node, it SHOULD also send
   a Binding Update message to the originator of the datagram in hopes
   that the originator will be able to create a location cache entry for
   that mobile node.  Then, future transmissions for the mobile node
   will not necessarily involve the home agent.

   As time goes on, more and more Internet nodes will be able to
   maintain location caches, and it is hoped that home agents will need
   to be involved only rarely with routing datagrams to mobile nodes.
   This might usually happen only when correspondent nodes first try to
   initiate a session from a mobile node which has not been in contact
   with the correspondent node for a long period of time.


7.1. Rate Limiting

   A home agent must provide some mechanism to limit the rate at which
   it sends Binding Update messages to to the same node about any given
   mobility binding, after tunneling a datagram intercepted on the home
   network.  This is especially true because it is expected that most
   Internet nodes will not be equipped with location caches for a long
   time, and continual transmissions of Binding Warning messages to such
   nodes will only exacerbate the problem of the traffic bottleneck at
   the home agent.


7.2. Receiving Binding Request Messages

   When the home agent receives a Binding Request message, it consults
   its home list and determines the correct binding information to be
   sent to the requesting node.  Before satisfying the request, the
   home agent must check whether or not the mobile node has allowed the
   information to be disseminated.  If the mobile node specified the 'P'
   bit in its Registration Request, then the home agent must not satisfy
   any binding Requests.  Nevertheless, the home agent can return an
   empty Binding Update, with a zero care-of address and zero lifetime,
   so that the correspondent node will not go to the trouble of trying
   to obtain a binding.  This situation can never arise by the action of
   any correctly operating node maintaining a location cache, but it is
   still possible that an intelligent correspondent node might try to
   obtain bindings for mobile nodes.



Johnson, Perkins, Myles       Expires 15 September 1995        [Page 26]


Internet Draft       Route Optimization in Mobile IP       15 March 1995


7.3. Receiving Registration Key requests

   When the home agent receives a Registration Request message, it may
   also be asked to compute registration keys for use with foreign
   agent handoffs (Section 2.2).  In that event, the home agent employs
   a good algorithm for producing random keys [2] and encrypts the
   result separately for use by the foreign agent and by the mobile
   node.  The chosen key is encrypted under a key and algorithm shared
   between the home agent and the mobile node, and the encrypted key
   is placed in a Mobile Node Registration Key extension (Section 4.4)
   in the Registration Reply message.  The same key also is encrypted
   under a key and algorithm shared between the home agent and the
   foreign agent, and the encrypted key is placed in a Foreign Agent
   Registration Key extension (Section 4.5) in the Registration Reply
   message.  By default, the home agent uses its mobility security
   association for the mobile node and for the foreign agent to encrypt
   the registration key.  If the home agent has no preestablished
   mobility security association with the foreign agent and the
   Registration Key Request extension contained a public key from the
   foreign agent, the home agent may instead use this key to encrypt the
   registration key for the foreign agent.


7.4. Receiving Special Tunnels

   The home agent can also receive tunneled datagrams destined for the
   mobile node.  If the tunnel source is the same as the foreign agent
   shown in the home list entry for the mobile node, then the home
   agent MUST NOT send the datagram back to that same foreign agent.
   Otherwise, the home agent can tunnel the tunneled datagram to the
   current foreign agent, encapsulating the incoming tunneled datagram
   in its entirety.

   The home agent also, in this case, takes responsibility for sending
   information to the originator of the datagram (whose source address
   will be in the inner datagram header inside the encapsulation),
   to allow that originator to update its location cache entry for
   the target mobile node.  If the home agent has a mobility security
   association with the correspondent node which originated the
   datagram, an authenticated Binding Update message can be sent
   directly.










Johnson, Perkins, Myles       Expires 15 September 1995        [Page 27]


Internet Draft       Route Optimization in Mobile IP       15 March 1995


8. Foreign Agent Considerations

   In addition to managing the resources needed to handle basic
   Mobile IP registrations, the foreign agent assisting with Route
   Optimization assumes two additional responsibilities.  The first
   is the maintenance of a location cache for forwarding datagrams to
   mobile nodes as they switch connections to new foreign agents.  The
   second is a slight modification of the registration procedure, to
   allow for timely notification possible for previous foreign agents.


8.1. Setting up Temporary Mobility Security Associations

   As part of the registration procedure, a mobile node and foreign
   agent can agree on a registration key.  This registration key is, as
   described in Section 7.3, computed by the mobile node's home agent
   and transmitted back to the foreign agent along with the Registration
   Reply message.  Within this document, the registration key is used
   only for authentication of a single Binding Update message; other
   uses for the registration key are possible, but are outside the scope
   of this discussion.  For instance, the foreign agent and mobile node
   may negotiate to use the registration key to provide confidentiality
   along the wireless link connecting them.  If a foreign agent is
   unable to process a registration request because the mobile node also
   expects a registration key, the foreign agent returns the appropriate
   status code immediately in a Registration Reply message.

   DISCUSSION: Alternatively, we could add a bit to the Agent
   Advertisement message.

   The actual request for the registration key is made by the mobile
   node (Section 2.2).  Since the foreign agent and the home agent
   may have no mobility security association, the home agent cannot
   be assured of the identity of the foreign agent.  This does not
   matter, however, for the production of the registration key.  When
   the foreign agent receives the registration reply, with both foreign
   agent registration key extensions, it strips off the extension
   containing its own registration key, and relays the rest to the
   mobile node.

   This registration key can be trusted for the purposes outlined, even
   though the mobile node and the foreign agent cannot be expected to
   always authenticate each other's identity.  They can, however, expect
   each other to follow the operational procedures comprising the Route
   Optimization protocols.  Any further use made of the registration key
   must take into account the fact that the nodes involved have not yet
   mutually identified each other in a trustworthy fashion; they have




Johnson, Perkins, Myles       Expires 15 September 1995        [Page 28]


Internet Draft       Route Optimization in Mobile IP       15 March 1995


   only agreed that the foreign agent will provide certain desirable
   services to the mobile node.


8.2. Previous Foreign Agent Notification

   When a mobile node registers with a new foreign agent, it may request
   that the new foreign agent send a Binding Update message to its
   previous foreign agent.  This Binding Update must be authenticated,
   using the Route Optimization Authentication extension (Section 4.2),
   as must all Binding Updates.  The Acknowledge bit in this Binding
   Update message must be set.

   When the previous foreign agent receives the Binding Update, it will
   use the mobility security association set up with the mobile node
   during its previous registration to authenticate the message.  If
   the message authentication is correct, the old visitor list entry
   will be deleted and a Binding Acknowledge message returned to the
   sender.  In addition, if a new care-of address was included with the
   new binding, a location cache entry will be created for it, and the
   previous foreign agent can tunnel datagrams to the mobile node's
   current care-of address using that location cache, just as any node
   maintaining a location cache.

   In particular, the previous foreign agent can tunnel the Binding
   Acknowledge message back to the new care-of address specified in
   the received binding.  This creates an interesting problem for the
   new foreign agent when it receives the acknowledgment before the
   registration reply from the home agent.  It is suggested that the new
   foreign agent deliver the acknowledgment to the mobile node anyway,
   even though the mobile node is technically unregistered.  If there
   is concern that this provides a loophole for unauthorized traffic
   to the mobile node, the new foreign agent could limit the number of
   datagrams delivered to the unregistered mobile node to this single
   instance.  Alternatively, a new extension to the Registration Reply
   message can be defined to carry along the acknowledgement from the
   previous foreign agent.  This latter approach would have the benefit
   that fewer datagrams would be transmitted over bandwidth-constrained
   wireless media during registrations.

   The lifetime associated with the location cache, in this situation,
   can be substantially shorter than other location caches for several
   reasons.  First, the home agent is presumably tunneling datagrams to
   the new foreign agent; second, any active correspondent node will
   probably get a new location cache entry for the mobile node after
   receiving the Binding Warning message from the previous foreign
   agent.  Lastly, even if the location cache entry expires prematurely,




Johnson, Perkins, Myles       Expires 15 September 1995        [Page 29]


Internet Draft       Route Optimization in Mobile IP       15 March 1995


   the previous foreign agent can special tunnel any straggling
   datagrams back to the home agent for further delivery.


8.3. Receiving Tunneled Datagrams

   If the mobile node's current foreign agent receives a tunneled
   datagram for the mobile node, it can be assumed that the tunneled
   datagram was originated by a node maintaining a location cache.
   There may be pathological or special cases where this assumption is
   false, but one would almost have to intentionally run custom code
   to invalidate the assumption.  Since the foreign agent currently
   serving a mobile node can assume that the sending node forwarded the
   datagram based on correct location cache information, the foreign
   agent can also assume that the sending cache agent has already issued
   notification to the source of the original datagram.  Thus, the
   current foreign agent never needs to send a Binding Warning message
   to the node which last tunneled the datagram.

   On the other hand, a foreign agent which is tunneling received
   datagrams on behalf of a mobile node not in its visitor list should,
   just as any other node implementing Route Optimization, send Binding
   Warning messages to the originator of these datagrams.  If the
   datagrams it receives are not tunneled, the foreign agent should
   limit the rate at which it sends Binding Warning messages to the
   originators, since those originators may be unable to interpret such
   notifications.  It is expected that reception of such un-tunneled
   datagrams by any foreign agent will be rare.


8.4. Sending Special Tunnels

   If a foreign agent receives a tunneled datagram for a mobile node
   which is unknown, then the foreign agent can tunnel the datagram back
   to the home agent.  This requires special care at the home agent.
   The foreign agent must use the mobile node's address as the tunnel
   destination, and its own address as the tunnel source.  The home
   agent will then capture the special tunneled datagram and re-tunnel
   it to the mobile node via its current foreign agent.  The foreign
   agent sending the special tunnel should not notify the originator of
   the datagram about its out-of-date binding, as this will be done by
   the home agent which receives the special tunnel datagram.









Johnson, Perkins, Myles       Expires 15 September 1995        [Page 30]


Internet Draft       Route Optimization in Mobile IP       15 March 1995


9. Mobile Node Considerations

9.1. Requesting a Registration Key

   When a mobile node makes a registration request, it can request a
   registration key to be shared between itself and the prospective
   foreign agent.  The key will be used to authenticate a future
   disconnection notice from the mobile node, when the mobile node
   has moved to a new cell.  The mobile node allows the home agent to
   pick the registration key, because it is expected that the mobile
   node is less likely to have good means for computing pseudo-random
   numbers [2].  The registration key will be returned in an extension
   to the expected registration reply, and the foreign agent can use
   it to compute a "mobile-foreign" authentication extension to the
   registration reply.  If this is done, the mobile node will have
   complete confidence that it does in fact share a secret registration
   key.  If not, the mobile node can still act on the supposition that
   the key has been correctly received by the foreign agent, but the
   delivery of the key to the foreign agent can be compromised by an
   active attack which modifies some of the bits of the extension which
   the home agent uses to deliver the key to the foreign agent.  In the
   latter case, the foreign agent does not have a good way to detect the
   corruption.  Since the problem will only show up by possibly causing
   some datagrams to be lost after some unpredictably distant future
   movement by the mobile node, it is not absolutely required to test
   the validity of the registration key.

   If the mobile node detects that the foreign agent has a corrupted
   registration key, it can re-register immediately.


9.2. Notifying Previous Foreign Agents

   If the mobile node wishes to instruct its prospective foreign agent
   to send a Binding Update message to the mobile node's previous
   foreign agent, it uses the appropriate extension (see 4.1) to the
   Registration Request message.  This usually results in quicker
   establishment of a location cache entry at the previous foreign
   agent, because the previous foreign agent is likely to be much closer
   to the new foreign agent than the home agent is.

   Since the prospective new foreign agent does not have access to
   the registration key which was established between the mobile node
   and its previous foreign agent, the mobile node has to compute
   the appropriate authentication value for use by the prospective
   foreign agent.  This authentication is computed over the fields of
   the expected Binding Update message, with the 'I' bit set and no
   identification present.  Reply protection is considered unnecessary



Johnson, Perkins, Myles       Expires 15 September 1995        [Page 31]


Internet Draft       Route Optimization in Mobile IP       15 March 1995


   since the binding update is expected to be sent only once with the
   registration key.

   When the acknowledgment arrives, the new foreign agent detunnels
   it and sends it to the mobile node.  In this way, the mobile node
   can still discover that its previous foreign agent has updated
   its visitor list and location cache.  This is important, because
   otherwise the previous foreign agent would often become a "black
   hole" for datagrams destined for the mobile node.  The new foreign
   agent has no further responsibility for helping to update the
   location cache at the previous foreign agent.

   The mobile node expects to eventually receive an acknowledgement
   from its previous foreign agent, signifying that the mobile node's
   entry has been erased from its visitor list.  If the acknowledgement
   has not been received after sufficient time, the mobile node is
   responsible for retransmitting another Binding Update message to
   its previous foreign agent.  Although the previous foreign agent
   may have already deleted the registration key from its records, the
   mobile node should continue to retransmit its Binding Update message
   until the previous foreign agent responds with either a positive or
   negative acknowledgment.

   Since the mobile node is responsible for fielding the acknowledgement
   from its previous foreign agent, there is no need to add any status
   code or bit to the Registration Reply from its prospective new
   foreign agent
























Johnson, Perkins, Myles       Expires 15 September 1995        [Page 32]


Internet Draft       Route Optimization in Mobile IP       15 March 1995


References

   [1] Ralph Droms.  Dynamic Host Configuration Protocol.  RFC 1541,
       October 1993.

   [2] Donald E. Eastlake 3rd, Stephen D. Crocker, and Jeffrey I.
       Schiller.  Randomness recommendations for security.  RFC 1750,
       December 1994.

   [3] Charles Perkins, editor.  IP mobility support.  Internet Draft,
       draft-ietf-mobileip-protocol-08.txt, January 1995.  Work in
       progress.







































Johnson, Perkins, Myles       Expires 15 September 1995        [Page 33]


Internet Draft       Route Optimization in Mobile IP       15 March 1995


Appendix A. Using a Master Key at the Home Agent

   Rather than storing each mobility security association that it has
   established with many different correspondent nodes and foreign
   agents, a home agent may manage its mobility security associations so
   that each of them can be generated from a single "master" key.  With
   the master key, the home agent could build a key for any given other
   node by computing the node-specific key as

      MD5(node-address || master-key || node-address)

   where node-address is the IP address of the particular node for which
   the home agent is building a key, and master-key is the single master
   key held by the home agent for all mobility security associations it
   has established with correspondent nodes.  The node-specific key is
   built by computing an MD5 hash over a string consisting of the master
   key with the node-address concatenated as a prefix and as a suffix.

   Using this scheme, when establishing each mobility security
   association, the network administrator managing the home agent
   computes the node-specific key and communicates this key to the
   network administrator of the other node through some "secure"
   channel, such as over the telephone.  The mobility security
   association is configured at this other node in the same way as any
   mobility security association.  At the home agent, though, no record
   need be kept that this key has been given out.  The home agent need
   only be configured to know that this scheme is in use for all of its
   mobility security associations.

   When the home agent then needs a mobility security association as
   part of the Route Optimization protocol, it builds the node-specific
   key based on the master key and the IP address of the other node with
   which it is attempting to authenticate.  If the other node knows
   the correct node-specific key, the authentication will succeed;
   otherwise, it will fail as it should.
















Johnson, Perkins, Myles       Expires 15 September 1995        [Page 34]


Internet Draft       Route Optimization in Mobile IP       15 March 1995


Chairs' Addresses

   The working group can be contacted via the current chairs:

      Tony Li
      cisco Systems
      170 W. Tasman Dr.
      San Jose CA 95134

      Phone:  +1-408-526-8186
      E-mail: tli@cisco.com



      Jim Solomon
      Motorola, Inc.

      Phone:  +1-708-576-2753
      E-mail: solomon@comm.mot.com
































Johnson, Perkins, Myles       Expires 15 September 1995        [Page 35]


Internet Draft       Route Optimization in Mobile IP       15 March 1995


Authors' Addresses

   Questions about this document can also be directed to the authors:

      David B. Johnson
      Computer Science Department
      Carnegie Mellon University
      5000 Forbes Avenue
      Pittsburgh, PA  15213-3891

      Phone:  +1-412-268-7399
      Fax:    +1-412-268-5576
      E-mail: dbj@cs.cmu.edu



      Charles Perkins
      Room J1-A25
      T. J. Watson Research Center
      IBM Corporation
      30 Saw Mill River Rd.
      Hawthorne, NY  10532

      Phone:  +1-914-784-7350
      Fax:    +1-914-784-7007
      E-mail: perk@watson.ibm.com



      Andrew Myles
      Electronics Department
      Macquarie University 2109
      Sydney, Australia

      Phone:  +61-2-8059071
      Fax:    +61-2-8059128
      E-mail: andrewm@mpce.mq.edu.au














Johnson, Perkins, Myles       Expires 15 September 1995        [Page 36]


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