[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Internet Engineering Task Force                               C. Perkins
INTERNET DRAFT                                                       IBM
                                                        22 February 1996


     Mobile-IP Local Registration with Hierarchical Foreign Agents
              <draft-perkins-mobileip-hierfa-00.txt>

Status of This Memo

   This document is a submission to 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 (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).


Abstract

   The base mobile-IP specification allows mobile computers to move
   freely between various points of attachment to the Internet.
   However, each time the mobile computer moves, a Registration Request
   message has to be approved by the mobile node's Home Agent.  In cases
   where the home agent is far away, it may become too expensive or (in
   the cases of network partition) even impossible to complete these
   frequent registrations.  In this draft document, we specify a new
   variety of registration, using a Regional Registration Request and
   Regional Registration Reply, that is no longer always required to be
   transacted with the home agent.








Perkins                 Expires 22 August 1996                  [Page i]


Internet Draft       Hierarchical Foreign Agents        22 February 1996


                                Contents



Status of This Memo                                                    i

Abstract                                                               i

 1. Introduction                                                       1
     1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . .    2

 2. Operation                                                          2
     2.1. Finding the Right Foreign Agent . . . . . . . . . . . . .    2
     2.2. Security  . . . . . . . . . . . . . . . . . . . . . . . .    3
     2.3. Forwarding Datagrams to the Mobile Node . . . . . . . . .    5

 3. Agent Advertisements                                               5

 4. Regional Registration Request                                      7

 5. Regional Registration Reply                                        9

 6. Replay Protection                                                 13
     6.1. Replay Protection using Nonces  . . . . . . . . . . . . .   13

Chair's Address                                                       16

Author's Address                                                      16























Perkins                 Expires 22 August 1996                 [Page ii]


Internet Draft       Hierarchical Foreign Agents        22 February 1996


1. Introduction

   The base mobile-IP specification allows mobile computers to move
   freely between various points of attachment to the Internet.
   However, each time the mobile computer moves, a Registration Request
   message has to be approved by the mobile node's Home Agent.  In cases
   where the home agent is far away, it may become too expensive or (in
   the cases of network partition) even impossible to complete these
   frequent registrations.

   In this draft document, we specify a new variety of registration,
   using a Regional Registration Request and Regional Registration
   Reply, that is no longer always required to be transacted with the
   home agent.  Using this new registration technique, the foreign
   agents in the local and/or regional area provide mobility services
   to the mobile node and allow some degree of independence from the
   home agent.  The foreign agents are arranged hierarchically in the
   regional topology, and the mobile node is then allowed to move from
   one local area of the regional topology to another area of the same
   regional topology without requiring approval by or rebinding at the
   home agent.

   In this document, when a mobile node changes its point of attachment
   to the Internet, we say it "moves".  Thus, a change in point of
   attachment is a movement.

   It is possible to make improvements by allowing a mobile node to
   inform only local mobility agents each time it moves.  However, the
   local agents must then cooperate to allow the home agent to have
   incomplete knowledge of the mobile node's true point of attachment.
   For example, if the mobile node is currently located at one
   care-of address, but the home agent stores another care-of address
   in the mobile node's binding, then the two foreign agents offering
   those two care-of addresses in question must cooperate to make sure
   all datagrams tunneled to the latter care-of address are actually
   delivered to the mobile node.

   One approach to this problem is to allow the mobile node to send
   Registration Requests to a regional foreign agent that tracks its
   regional movements but does not forward the mobile node's Request
   to its home agent.  If the regional foreign agent is the tunnel
   endpoint for datagrams encapsulated by the home agent, then the
   regional foreign agent can make further arrangements for delivery of
   the datagram.  In this document, we further enhance this regional
   handling by effectively allowing subregions of regions and so on,
   and structuring the foreign agents which manage each region in a
   hierarchy.




Perkins                 Expires 22 August 1996                  [Page 1]


Internet Draft       Hierarchical Foreign Agents        22 February 1996


   Since Agent Advertisements can contain multiple care-of addresses,
   a natural implementation of the hierarchy presents itself.  Each
   foreign agent simply includes its ancestors in the tree of regional
   foreign agents in the list of care-of addresses in the Agent
   Advertisement.  In order to maintain compatibility with mobile nodes
   that do not implement any processing for the foreign agent hierarchy,
   each foreign agent must advertise its own care-of address first in
   the list.

   In this specification, the mobile node will re-register using a new
   Registration Request that includes all the fields of the existing
   Registration Request, but which includes more "care-of addresses and
   places a different meaning on the address found in the Home Agent
   field in the existing Registration Request.  Put briefly, the Home
   Agent address is replaced by the address of the nearest "regional
   foreign agent" that has a previous registration with the mobile node.


1.1. Terminology

   In addition to all the terminology in the base mobile-IP
   specification, this document frequently uses the following terms:

      Targeted Mobility Agent

         The mobility agent to which a Regional Registration Request is
         sent.


2. Operation

   Conceptually, the mobile node attempts to minimize the amount of
   tracking required to maintain its traffic flow.  This amounts to
   identifying the smallest region for which the mobile node has not
   travesed any regional boundary.  That amounts to finding the closest
   ancestor to the foreign agent advertising the first care-of address
   in the list in the Advertisement, which was also an ancestor at the
   mobile node's last point of attachment.  The mobile node may do this
   as outlined below.


2.1. Finding the Right Foreign Agent

   Each time a mobile node determines that it has moved, it keeps
   track of the hierarchy of foreign agents serving its new point of
   attachment.  At least the first care-of address will be different in
   the Agent Advertisements detected at the mobile node's new point of
   attachment.



Perkins                 Expires 22 August 1996                  [Page 2]


Internet Draft       Hierarchical Foreign Agents        22 February 1996


   When a mobile node moves to a new point of attachment, it checks the
   list of care-of addresses, starting with the last one.  If the last
   care-of address is the same as the previous last care-of address, it
   looks at the next-last care-of address.  If that one is also the same
   as the next-last care-of address at its previous point of attachment,
   the mobile node checks the next-next-last care-of address, and so
   on until a care-of address is found that is different than the
   corresponding care-of address in the list which was advertised at the
   mobile node's previous point of attachment.

   Once the mobile node finds out the lowest level of the hierarchy,
   which has a different care-of address, it notifies the foreign
   agent at the next-higher level of the hierarchy about the different
   care-of address.  This is done by the new Registration Request
   message, called the Regional Registration Request message.  The
   foreign agent nearest the mobile node (the first care-of address)
   relays the Registration Request to next-higher level of the hierarchy
   and thus along towards the target of the Registration Request, just
   as if the target foreign agent (call it the targeted mobilitye agent)
   were the home agent.

   If the targeted mobility agent approves the Regional Registration
   Request, it returns a Registration Reply of similar type and format
   as inthe base mobile-IP specification.

   The processing of the Regional Registration Request and Registration
   Reply requires further refinement compared to the registration
   processing in the base mobile-IP specification.  When the foreign
   agent receives the Request from the mobile node, it must pass the
   Request along to its next nearest ancestor in the hierarchy along the
   way to the agent listed as the Home Agent.  In this way, each foreign
   agent in the hierarchy between the mobile node and the home agent
   will be able to maintain a binding for the mobile node.  Similarly,
   Regional Registration Replies are passed down from one level of the
   hierarchy to the next along the way to the mobile node, so that
   each foreign agent can determine the status of the corresponding
   Registration Request and create the appropriate binding for the
   mobile node.  Note that each foreign agent's binding will be for
   the care-of address at the next lower level of the hierarchy, not
   necessarily the care-of address of the foreign agent advertising the
   care-of address hierarchy to the mobile node.


2.2. Security

   Note that home agent can be considered a "universal root" for all
   such hierarchies of foreign agents as described above.  In fact,
   considered as an implicit care-of address, the home agent's address



Perkins                 Expires 22 August 1996                  [Page 3]


Internet Draft       Hierarchical Foreign Agents        22 February 1996


   is an ancestor of every other care-of address, and the mobile node
   is guaranteed of never straying from the boundaries of the region
   defined by the home agent's "care-of address".

   Thought of in this way, there is the same clear threat posed
   by illicit Registration Requests, and thus the same need for
   authenticating that Registration Requests.

   Unfortunately, the mobile node and the home agent currently share
   keys which are configured manually.  Such manual configuration is
   unrealistic with the Regional Registration Request.  Fortunately, the
   problem is analogous to the requirement in the Route Optimization [2]
   protocol specification, for a mobile node's current foreign agent to
   obtain a session key with the mobile node for as long as the mobile
   node is on the foreign agent's visitor list.

   As outlined in this document, when a mobile node registers with
   its home agent, it "registers" with all the foreign agents in the
   hierarchy between the home agent and the mobile node.  When it
   registers the top-level care-of address with its home agent, the
   mobile node acquires a session key, using one of the extensions
   specified for Route Optimization [2].  Suppose that each foreign
   agent in the hierarchy shares the same session key that the home
   agent sent to the foreign agent at the top level of the hierarchy.

   Subsequent moves by the mobile node may require re-registration with
   some (or all) of the foreign agents in the hierarchy without causing
   any change to the home agent's binding for the mobile node.  Since
   each foreign agent between the mobile node's previous care-of address
   and the home agent shares the same session key, when the mobile
   re-registers an intermediate care-of address with an unchanged
   care-of address immediately above it in the hierarchy, the mobile
   node already shares a session key with the care-of address which
   didn't change.  To effect the move, then, the mobile node just has
   to send the session key along with its registration through the
   changed parts of the hierarchy, until the re-registration occurs at
   the lowest-level care-of address which has not changed and which is
   handled by a foreign agent which shares the same session key with the
   mobile node.

   Since each Regional Registration Request is passed to every foreign
   agent between the mobile node and the "closest" foreign agent that
   didn't change, when the Regional Registration Reply comes back, the
   targeted mobility agent processing the Request can encode the session
   key for each new foreign agent which will handle the Reply.






Perkins                 Expires 22 August 1996                  [Page 4]


Internet Draft       Hierarchical Foreign Agents        22 February 1996


2.3. Forwarding Datagrams to the Mobile Node

   At each level of the hierarchy, the foreign agent advertising the
   care-of address at that level has a binding for the mobile node.  The
   mobile node's binding shows that it is "regionally registered" at the
   care-of address at the next lower level of the hierarchy.

   Thus, a datagram arriving at the top of the hierarchy from the
   home agent will (figuratively speaking) be decapsulated and
   re-encapsulated with a new tunnel endpoint, viz.  the care-of address
   at the next lower level of the hierarchy.  This decapsulation and
   re-encapsulation occurs at each level of the hierarchy, until the
   datagram reaches the last tunnel endpoint which is either the mobile
   node itself (in case of a co-located care-of address) or a foreign
   agent that can deliver the decapsulated datagram to the mobile node
   with no further special mobile-IP handling.

   Note that the actual decapsulation need not occur at each step of
   the hierarchy.  Instead, the foreign agent at that level can merely
   change the source and destination IP addresses of the encapsulating
   IP header.


3. Agent Advertisements

   A foreign agent wishing to participate in a hierarchy of foreign
   agents advertises its services using the Mobility Extension to
   ICMP Router Advertisement which is defined in the base mobile-IP
   document.  However, a strict ordering is imposed on the list of
   care-of addresses; the first care-of address is associated with
   the advertising agent, and each successive care-of address must be
   associated with the next-higher foreign agent in the hierarchy.

   In addition, a new bit (the 'I' bit, for hIerarchical) is defined
   in the "flags" field of the Agent Advertisement, so that the mobile
   node can be assured that the advertising agent is indeed equipped to
   handle the Regional Registration Request 4.  The format is as follows














Perkins                 Expires 22 August 1996                  [Page 5]


Internet Draft       Hierarchical Foreign Agents        22 February 1996


   (all other fields not defined here are unchanged from the definition
   given in the base mobile-IP document [1]).

    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        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Registration Lifetime      |R|B|H|F|M|G|V|I|   reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  zero or more Care-of Addresses               |
   |                              ...                              |

      I                       If set, the foreign agent is advertising
                              a hierarchy of care-of addresses, and can
                              properly process a Regional Registration
                              Request.


































Perkins                 Expires 22 August 1996                  [Page 6]


Internet Draft       Hierarchical Foreign Agents        22 February 1996


4. Regional Registration Request

   A mobile node registers with all of the hierarchical mobility agents
   between itself and its home agent using a Regional Registration
   Request message.  When using a co-located care-of address as the
   lowest level care-of address of the foreign agent hierarchy, the
   mobile node may re-register with its previous care-of address if that
   care-of address wasn't a co-located care-of address.

   Each mobility agent receiving the Request relays it to the next
   higher-level care-of address in the hierarchy.  For each pending
   Regional Registration Request, in addition to the information stored
   for the processing of Registration Requests as required by the base
   specification, each foreign agent stores the care-of address of the
   next-lower foreign agent in the hierarchy.  This address is available
   in the Request message, as shown below.

   Note the similarity between the Regional Registration Request and
   the conventional Registration Request defined in the base mobile-IP
   specification [1].  Unless specifically superseded in this document,
   all processing of Regional Registration Requests by mobility agents
   is required to be the same as the processing by mobility agents in
   the base mobile-IP draft specification [1].  The UDP fields also are
   the same as in the base draft specification.

   IP fields:

      Source Address        Typically the interface address from which
                            the message is sent.

      Destination Address   Typically that of the mobility agent at
                            the next higher level of the hierarchy of
                            mobility agents.


















Perkins                 Expires 22 August 1996                  [Page 7]


Internet Draft       Hierarchical Foreign Agents        22 February 1996


   The UDP header is followed by the Mobile IP fields 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|rsv|          Lifetime             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Care-of Address Count     |          Reserved             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Home Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Mobility Agent                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Care-of Addresses ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                         Identification                        +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Extensions ...
   +-+-+-+-+-+-+-+-

   All fields not listed here are definied just as in the base mobile-IP
   document.

      Type                8 (Regional Registration Request)

      Mobility Agent      The IP address of the targeted mobility agent,
                          which is the lowest-level foreign agent which
                          is present in Agent Advertisements received
                          both at the mobile node's previous and current
                          points of attachment.

      Care-of Addresses   The care-of addresses of the mobile node
                          sending the Regional Registration Request.

      Extensions          The fixed portion of the Regional Registration
                          Request is followed by one or more Extensions
                          which are applicable to Registration Requests.

   The Registration Request MUST include an authentication extension
   appropriate to the targeted mobility agent (either a Mobile-Home
   Authentication Extension, or a Mobile-Foreign Authentication
   Extension).  In the case of the Mobile-Foreign Authentication
   Extension the mobile node MAY use the Mobility Security Association
   set up when it obtained a session key (e.g., using extension numbers
   104 and 105 [2]).  from a previous Regional Registration Extension it




Perkins                 Expires 22 August 1996                  [Page 8]


Internet Draft       Hierarchical Foreign Agents        22 February 1996


   transacted with its home agent and all intervening foreign agents at
   that time.

   The same rules apply to the Regional Registration Request as
   apply to the Registration Request, regarding the relative order in
   which different extensions, when present, MUST be placed in a the
   registration message.

   Each foreign agent which receives a Regional Registration Request
   compares its offered care-of address to the target mobility agent
   listed in the Request.  If they are the same, the foreign agent
   determines whether or not to accept the request, and returns a
   Regional Registration Reply with the appropriate status code,
   as specified in 5.  Otherwise, the foreign agent delivers the
   Registration Request to the next-higher care-of address in the
   hierarchy.  The session-key extension selected by the mobile node is
   processed appropriately at each level of the hierarchy, if necessary.
   All foreign agents in the hierarchy between the mobile node and the
   home agents can share the same session key.

   Each foreign agent MUST check to make sure that its address is
   included in the list of care-of addresses within the Request.  If
   not, it rejects the request with status code 70.

   Otherwise, the foreign agent makes note of the next lower-level
   care-of address, for future association with the mobile node's home
   address.


5. Regional Registration Reply

   A mobility agent returns a Regional Registration Reply message
   to a mobile node which has sent a Regional Registration Request
   (Section 4) message, and to the foreign agent at each intermediate
   level of the hierarchy between itself and the mobile node.  Each
   foreign agent above the mobile node in the hierarchy will receive
   the Regional Reply from the mobility agent at the next higher level
   of the hierarchy.  The Regional Reply message contains the necessary
   codes to inform the mobile node about the status of its Request,
   along with the lifetime granted by the targeted agent, which MUST
   NOT be great enough to last longer than time at which the binding at
   the home agent would expire, as determined by the original lifetime
   granted by the mobile node's home agent in the last Registration
   Request (or Regional Registration Request) approved by the home
   agent.

   When the foreign agent receives a successful Regional Registration
   Reply, it updates its binding for the mobile node, using the



Perkins                 Expires 22 August 1996                  [Page 9]


Internet Draft       Hierarchical Foreign Agents        22 February 1996


   next-lower care-of address in the hierarchy as the care-of address of
   the mobile node.

   The foreign agent MUST NOT increase the Lifetime selected by the
   mobile node in the Regional Registration Request, since the Lifetime
   is covered by an Authentication Extension.  The targeted mobility
   agent MUST NOT increase the Lifetime selected by the mobile node in
   the Regional Registration Request, since doing so could increase
   it beyond the maximum Registration Lifetime allowed by the foreign
   agent.  If the Lifetime received in the Regional Registration Reply
   is greater than that in the Regional Registration Request, the
   Lifetime in the Request MUST be used.  When the Lifetime received in
   the Regional Registration Reply is less than that in the Regional
   Registration Request, the Lifetime in the Reply MUST be used.

   Note the similarity between the Regional Registration Reply and
   the conventional Registration Reply defined in the base mobile-IP
   specification [1].  Unless specifically superseded in this document,
   all processing of Regional Registration Replies by mobility agents
   is specified to be the same as the processing by mobility agents
   in the base mobile-IP draft specification [1].  This includes
   determining the validity of the Registration Request, and selecting
   the appropriate status code for the reply.  The IP fields and UDP
   fields are chosen just as with the Registration Reply message in the
   base mobile-IP specification.

   The UDP header is followed by the Mobile IP fields 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      |     Code      |           Lifetime            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Home Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Mobility Agent                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                         Identification                        +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Extensions ...
   +-+-+-+-+-+-+-+-

      Type                  9 (Regional Registration Reply)






Perkins                 Expires 22 August 1996                 [Page 10]


Internet Draft       Hierarchical Foreign Agents        22 February 1996


      Code                  A value indicating the result of the
                            Regional Registration Request.  See below
                            for a list of currently defined Code values.

      Home Agent            The IP address of the mobile node's home
                            agent.

      Identification        A 64-bit number used for matching
                            Registration Requests with Registration
                            Replies, and for protecting against replay
                            attacks of registration messages.  The
                            value is based on the Identification field
                            from the Registration Request message
                            from the mobile node, and on the style of
                            replay protection used in the security
                            context between the mobile node and its home
                            agent (defined by the mobility security
                            association between them, and SPI value in
                            the Mobile-Home Authentication Extension).
                            See Section 6.

      Extensions            The fixed portion of the Regional
                            Registration Reply is followed by one or
                            more of Extensions.  An authentication
                            extension MUST be included in all
                            Registration Replies returned by the
                            mobility agent.
























Perkins                 Expires 22 August 1996                 [Page 11]


Internet Draft       Hierarchical Foreign Agents        22 February 1996


   The following values are available for use within the Code field.
   Registration successful:

        0 registration accepted
        1 registration accepted, but simultaneous mobility
          bindings unsupported

   Registration rejected:

       64 reason unspecified
       65 administratively prohibited
       66 insufficient resources
       67 mobile node failed authentication
       68 mobility agent failed authentication
       69 requested Lifetime too long
       70 poorly formed Request
       71 poorly formed Reply
       72 requested encapsulation unavailable
       73 requested Van Jacobson compression unavailable
       80 home network unreachable (ICMP error received)
       81 mobility agent host unreachable (ICMP error received)
       82 mobility agent port unreachable (ICMP error received)
       88 mobility agent unreachable (other ICMP error received)
      133 registration Identification mismatch
      135 too many simultaneous mobility bindings
      136 unknown mobility agent address
      144 Broadcast Preference Extension unsupported
      145 Multicast Preference Extension unsupported

   Up-to-date values of the Code field are specified in the most recent
   "Assigned Numbers" [3].

   Note that processing of the Identification field, as discussed in
   Section 6, is significantly different than in the base mobile-IP
   specification when nonces are to be used.  Each foreign agent
   receiving a successful Regional Registration Reply from the foreign
   agent immediately above it in the foreign agent hierarchy MUST
   replace any Identification stored and associated with the mobile
   node, with the fresh Identification in the received Reply message.

   Note also that, when the targeted mobility agent is unknown, the
   Regional Registration Request works as well as the base mobile-IP
   Registration Request in helping the mobile node to discover its
   home agent's address.  However, in that case the mobile node would
   probably prefer to use the base Registration Request, since the
   Request cannot be accepted anyway until the home agent's address is
   known.




Perkins                 Expires 22 August 1996                 [Page 12]


Internet Draft       Hierarchical Foreign Agents        22 February 1996


6. Replay Protection

   The Identification field is used to let the targeted mobility agent
   verify that a registration message has been freshly generated by
   the mobile node, not replayed by an attacker from some previous
   registration.  Two methods are described in the base mobile-IP
   specification:  timestamps (mandatory) and "nonces" (optional).  All
   mobile nodes and mobility agents using Regional Registration messages
   MUST implement timestamp-based replay protection.  These nodes MAY
   also implement nonce-based replay protection.

   The style of replay protection in effect between a mobile node and
   its mobility agents is part of the mobile security association.
   A mobile node and its mobility agent MUST agree on which method
   of replay protection will be used.  The interpretation of the
   Identification field depends on the method of replay protection as
   described in the subsequent subsections.

   All requirements of the base mobile-IP specification regarding replay
   protection must be followed by mobile nodes using the regional
   registration procedures specified in this document.  There is no
   change to the replay procedures when timestamps are used.  However,
   for nonce-based replay protection additional refinements must be
   instituted by the mobile node.  Other mobility agents process nonces
   as in the base protocol specification.

   The Identification in a new Registration Request MUST NOT be the
   same as in an immediately preceding Request, and SHOULD NOT repeat
   while the same security context is being used between the mobile
   node and the home agent.  Retransmission as in the base mobile-IP
   specification [1] is allowed.


6.1. Replay Protection using Nonces

   The basic principle of nonce replay protection does not change from
   that described in the base mobile-IP specification.  However, since
   there can now be multiple mobility agents all registering the same
   mobile node, the mobile node must maintain a vector of nonces, one
   for each mobility agent in its current hierarchy.

   Whenever a targeted mobility agent receives a Regional Registration
   Request, it selects a new nonce using the same methods described
   for home agents selecting a new nonce in the base mobile-IP
   specification.  The mobility agent then inserts the resulting
   Identification in the appropriate field of the Regional Registration
   Reply.  Each mobility agent at lower levels of the hierarchy copy,
   when it receives the Reply, copies the new Identification for



Perkins                 Expires 22 August 1996                 [Page 13]


Internet Draft       Hierarchical Foreign Agents        22 February 1996


   possible use in receiving future Regional Registration Requests
   from the mobile node.  In other words, new nonces from above in the
   hierarchy supersede existing nonces stored by intermediate foreign
   agents in the hierarchy.

   When a mobile node receives a Regional Registration Reply, it in
   turn associates the nonce from the Identification field with every
   intermediate foreign agent between itself and the targeted mobility
   agent to which it had sent the Regional Registration Request.

   If a registration message is rejected because of an invalid
   nonce, the Reply always provides the mobile node, and each other
   intermediate foreign agent at lower levels than the targeted mobility
   agent, with a new nonce to be used in the next registration.  Thus
   the nonce protocol is self-synchronizing.




































Perkins                 Expires 22 August 1996                 [Page 14]


Internet Draft       Hierarchical Foreign Agents        22 February 1996


References

   [1] IPv4 Mobility Support.  ietf-draft-mobileip-protocol-15.txt -
       work in progress, February 1996.

   [2] David B. Johnson and Charles E. Perkins.  Route Optimization in
       Mobile-IP.  draft-ietf-mobileip-optim-03.txt -- work in progress,
       November 1995.

   [3] Joyce K. Reynolds and Jon Postel.  Assigned Numbers.  RFC 1700,
       October 1994.








































Perkins                 Expires 22 August 1996                 [Page 15]


Internet Draft       Hierarchical Foreign Agents        22 February 1996


Chair's Addresses

   The working group can be contacted via the current chairs:

        Jim Solomon                       Tony Li
        Motorola, Inc.                    cisco systems
        1301 E. Algonquin Rd.             170 W. Tasman Dr.
        Schaumburg, IL  60196             San Jose, CA  95134

        Work:   +1-847-576-2753           Work:   +1-408-526-8186
        E-mail: solomon@comm.mot.com      E-mail: tli@cisco.com


Author's Address

   Questions about this memo can be directed to:

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

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
























Perkins                 Expires 22 August 1996                 [Page 16]