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

Versions: 00 01                                                         
Internet Engineering Task Force                               P. Calhoun
INTERNET DRAFT                                                      3Com
Mobile IP Working Group                                       C. Perkins
                                                        Sun Microsystems
                                                        21 November 1997


                     Tunnel Establishment Protocol
                 draft-ietf-mobileip-calhoun-tep-00.txt


Status of This Memo

   This document is a submission by the Mobile IP Working Group of the
   Internet Engineering Task Force (IETF).  Comments should be submitted
   to the mobile-ip@SmallWorks.COM mailing list.

   Distribution of this memo is unlimited.

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

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

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


Abstract

   A general tunnel establishment protocol (TEP) is defined to handle
   multiprotocol tunneling as well as multilevel domains guarded by
   tunnel agents which may be thought of as security gateways, or
   alternatively as modified foreign agents as used with Mobile IP.
   Mobile IP provides the model for TEP; the registration messages in
   RFC 2002 establish a tunnel between the home agent and the foreign
   agent.  TEP extends Mobile IP's model for tunnel establishment to
   allow multiple tunnel agents between the beginning and the end of the
   tunnel, but assumes the same end-to-end trust model.








Calhoun, Perkins              Expires 21 May 1998               [Page i]


Internet Draft      Tunnel Establishment Protocol       21 November 1997


1. Introduction

   Tunnels are needed for a variety of reasons in the Internet.  Two
   nodes may wish to communicate by using protocol data units (PDUs) for
   protocols other than IP that are not easily routed over the Internet
   infrastructure.  Such PDUs can, however, be transmitted over the
   Internet after encapsulation within IP. For remote access, one might
   wish to set up a secure tunnel between a current point of attachment
   and a enterprise network.  Mobile IP (RFC 2002) [9] requires the
   creation of a tunnel so that the home agent can transmit IP datagrams
   to the care-of address of the mobile node.  All of these separate
   needs share a common need for tunnel establishment and management,
   which can be fulfilled by enhancements of the tunnel establishment
   procedures specified in RFC 2002 [9], and the tunnel management
   procedures specified in RFC 2003 [7].  This document specifies those
   enhancements.

   Several previous documents have been drawn on for creating of
   this document -- notably "Integrated Mobility Extension" [4],
   "Hierarchical Foreign Agents" [6], "Virtual Tunneling Protocol
   (VTP)" [1], and "Tunnel Set-up Protocol" [5].


1.1. Terminology

   This document frequently uses the following terms:

      binding  An association between a mobile node's address and a the
               IP address of a Tunnel Agent nearer to the mobile node.

      home agent The tunnel agent which initially establishes a tunnel,
               and which initially encapsulates datagrams to be sent to
               the mobile node.

      surrogate Agent A tunnel agent establishing a tunnel on behalf of
               a mobile node which does not take any active role in the
               establishment process.

      Targeted Tunnel Agent
               The ultimate intended recipient for a Tunnel
               Establishment Request.

      Tunnel Agent
               An agent which can perform encapsulation and
               decapsulation

      Tunnel Requestor
               Either a mobile node, or a surrogate agent acting on its
               behalf.



Calhoun, Perkins              Expires 21 May 1998               [Page 1]


Internet Draft      Tunnel Establishment Protocol       21 November 1997


      Mobile Node
               The node on whose behalf the tunnel is established.

   Notice that in this document, the term "mobile node" is used to help
   understanding.  There is no protocol dependence upon the fact that
   the node is mobile, but we so far have not been very successful in
   finding suitable terminology.  The previous term we had used in this
   document was "PDU receiver".  Similarly, what was previously called
   the "encapsulator" is now called a home agent.  Finally, what was
   previously called the "decapsulator" is now called the "foreign
   agent", and is a tunnel agent capable of performing decapsulation on
   behalf of a mobile node for PDUs received through the tunnel from the
   home agent.


2. Overview of tunnel establishment

   Mobile IP [9] allows the registration (on behalf of some target
   node) of a tunnel endpoint with a remote encapsulating agent --
   namely, in the case of mobile IP, a home agent.  Almost all of the
   Mobile IP registration procedure can be modeled as way to establish a
   tunnel between the home agent and the foreign agent, on behalf of a
   mobile node.  The tunnel is then expected to be used for the specific
   purposes required by Mobile IP.

   In the Tunnel Establishment Protocol (TEP), the protocol methods used
   by Mobile IP are modified to work between arbitrary nodes.  When
   a tunnel is established, the encapsulating agent (called the home
   agent) then transmits PDUs to the tunnel endpoint (called the foreign
   agent) according to the tunnel establishment parameters.  Generally,
   the tunnel establishment parameters will include a network address
   of the node for which the the tunnel is being established, called
   the mobile node.  The foreign agent may then use any of a variety
   of methods, not specified in this document, to further transmit the
   decapsulated PDU so that it can be received by the mobile node.
   If the mobile node is the same node as the foreign agent, then no
   further network operations are needed to effect delivery of the PDU.

   When the home agent obtains a PDU which needs to be transmitted to
   the mobile node, the home agent consults a table to determine the
   appropriate tunnel endpoint for that mobile node.  In the case of
   mobile IP, the table is indexed by the mobile node's IP address, and
   the mobile node is the mobile node; this document specifies ways to
   allow the table to be indexed by other network-layer addresses.  Each
   table entry will contain, besides the address of the tunnel endpoint,
   other necessary tunnel parameters associated with the tunnel as part
   of the tunnel establishment process.  The act of creating or updating
   the table entry which contains all of the parameters associated to
   the tunnel is called tunnel establishment, or just establishment.



Calhoun, Perkins              Expires 21 May 1998               [Page 2]


Internet Draft      Tunnel Establishment Protocol       21 November 1997


   The procedures in this document deal with the actions of three
   separate network entities, as outlined above, called the home agent,
   the foreign agent, and the mobile node.  For simplicity, it is
   assumed that all home agents can also perform decapsulation and vice
   versa.  A tunnel agent is thus a node that can perform the functions
   of either the home agent or the foreign agent, and tunnels are said
   to be established between two tunnel agents.  The foreign agent and
   mobile node may be the same node.

   This document does not specify means by which a mobile node discovers
   a suitable tunnel endpoint (foreign agent) which can be used for
   the tunnel establishment.  An example of one such method, by which
   a mobile node (receiving IP data units) discovers a tunnel endpoint
   called a care-of address, is specified as part of the Mobile IP
   protocol.  One method suitable for use with TEP is a straightforward
   modification of the Mobile Service Extension to the ICMP Router
   Discovery protocol [2], as specified in Mobile IP [9].  This
   extension will soon be specified in a companion document.

   This document assumes that each tunnel endpoint will be equipped
   with an IP address.  If the establishment completes successfully,
   the foreign agent becomes one endpoint of a GRE tunnel [3].  The
   other endpoint is the home agent.  Once the tunnel is established,
   it provides IP (network layer) connectivity between the two tunnel
   agents.  The tunnel appears to be a virtual point-to-point link, and
   encapsulated PDUs traverse the tunnel as if it were a single link.

   Tunnel establishment is transacted between the foreign agent and
   the home agent by establishment messages transmitted on port 454.
   These messages have new message type numbers so that they are
   easily distinguished from existing mobile IP message types, but the
   format of the new tunnel establishment messages is a straightforward
   modification to the format of the existing messages, and is analogous
   to the Regional Registration messages defined earlier in the
   Hierarchical Foreign Agents proposal [6].  The tunnel establishment
   messages accept new extensions, which are defined in this document.

   Tunnel establishment requires authentication.  The tunnel
   establishment messages use the same Authentication extensions defined
   by the base mobile IP specification [9].  Even though the tunnel
   establishment message is transmitted by the foreign agent to the home
   agent, the authentication often relies on a security association
   between the mobile node and the home agent.  This security
   association between receiver and home agent may require additional
   security mechanisms such as encryption which are not part of the
   tunnel establishment, but which affect the format of the encapsulated
   datagrams which flow through the tunnel.  Intermediate nodes which
   are involved with the tunnel establishment may additionally impose
   their own authentication and privacy requirements.  Such nodes



Calhoun, Perkins              Expires 21 May 1998               [Page 3]


Internet Draft      Tunnel Establishment Protocol       21 November 1997


   follow the dictates of their security associations with the other
   nodes that they communicate with in the course of managing the
   established tunnel, but the security associations or the use of them
   are established by policy which is external to TEP.

   A requesting foreign agent MAY use procedures which are not specified
   in this document to obtain all tunnel establishment parameters,
   including authentication information for the mobile node, for use
   in the Tunnel Establishment Request message.  Alternatively, the
   mobile node MAY (as is the case with mobile IP) transmit a Tunnel
   Establishment Request message to a prospective tunnel endpoint to
   enable that node to transact a tunnel establishment with some home
   agent.

   TEP specifies that the decapsulating node issue the Tunnel
   Establishment Request message on behalf of the mobile node.  This
   MAY happen as a result of protocol operations transacted between the
   foreign agent and the mobile node.  The decapsulating tunnel agent
   could, on the other hand, be configured by any convenient means to
   have all the necessary tunnel establishment parameters needed to
   issue a request message on behalf of the mobile node.  TEP makes no
   restriction on the methods by which the foreign agent discovers the
   establishment parameters.

   Note that in some cases it would be beneficial to enable a sender of
   the PDUs to establish the tunnel on behalf of the receiver.  While
   TEP is likely to solve that problem, the exact operation of the
   protocol is not yet specified in that case.
























Calhoun, Perkins              Expires 21 May 1998               [Page 4]


Internet Draft      Tunnel Establishment Protocol       21 November 1997


2.1. Example hierachy

                              +---------------+
                              |               |
                              |      H A      |
                              |               |
                              +---------------+
                                      |
                                      |
                                      |
                                     / \
                                    /   \
                                   /     \
                                  /       -----------\
                                 /                    \
                                /                      \
                            +---------------+   +---------------+
                            |               |   |               |
                            |      F A      |   |      F A      |
                            |               |   |               |
                            +---------------+   +---------------+
                                       |
                                       |
                                       |
                                      / \
                                     /   \
                                    /     \
                                   /       --------\
                                  /                 \
                                 /                   \
                           +---------------+    +---------------+
                           |               |    |               |
                           |      F A      |    |      F A      |
                           |               |    |               |
                           +---------------+    +---------------+
                                 |
                                 |
                                 |
                                 |
                 +---------------+
                 |               |
                 |      M N      |
                 |               |









Calhoun, Perkins              Expires 21 May 1998               [Page 5]


Internet Draft      Tunnel Establishment Protocol       21 November 1997


                 +---------------+

   This example shows a two-level hierarchy of foreign agents
   (decapsulating agents) between the mobile node and its home agent.
   Although TEP is general enough for many more levels of hierarchy, it
   is likely that two levels of hierarchy will satisfy the needs of many
   network administrators.


3. Regionalized Tunnel Management

   TEP is designed to allow establishment of tunnels suitable for
   transmission of PDUs through multiple levels of security regions,
   in the same manner indicated for use with Hierarchical Foreign
   Agents [6].  Each security region is assumed to be accessible (from
   either the inside or the outside) by a tunnel agent, which is perhaps
   made known as part of an extension to Router Advertisements in
   the region.  Further discussion of such advertisements is outside
   the scope of this specification, but some points are developed in
   appendix A.

   One approach to this problem is to allow Tunnel Establishment
   Requests to be sent to a regional tunnel agent that tracks the mobile
   node's regional movements but does not forward each establishment
   Request all the way back to the home agent.  If the regional tunnel
   agent is the tunnel endpoint for PDUs encapsulated by the home
   agent, then the regional tunnel agent can make further arrangements
   for delivery of the PDU. 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.

   As each new Tunnel Establishment Request travels up the hierarchy,
   it includes all the tunnel agent addresses up to and including the
   Targeted Tunnel Agent.  Put briefly, the Target Tunnel Agent address
   is that of the nearest "regional foreign agent" that has previously
   established a tunnel on behalf of the mobile node.

   Conceptually, the mobile node, or a foreign agent acting on its
   behalf, 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 matching the first tunnel agent in the hierarchy, which
   was also an ancestor of the mobile node when a tunnel was established
   for it.  The mobile node may do this as outlined below.






Calhoun, Perkins              Expires 21 May 1998               [Page 6]


Internet Draft      Tunnel Establishment Protocol       21 November 1997


   All of these considerations are equally true a decapsulating agent is
   initiating tunnel establishment operations on behalf of the mobile
   node.  The protocol by which the decapsulating agent discovers the
   need for the tunnel establishment also needs to take into account the
   discovery of the previous hierarchy serving the mobile node in order
   for the regionalization operations to be effective.

   The foreign agent nearest the mobile node is the first foreign agent
   to find out that a tunnel establishment is needed.  This foreign
   agent relays the Tunnel Establishment 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
   tunnel agent) were the home agent.  If the targeted tunnel agent (or
   the home agent) receives Tunnel Establishment Request, it returns a
   Tunnel Establishment Reply.

   The processing of the Tunnel Establishment Request and Registration
   Reply requires further refinement compared to the registration
   processing in the base mobile-IP specification.  When a tunnel 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,
   Tunnel Establishment 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 Tunnel
   Establishment Request and create the appropriate binding for the
   mobile node.  Note that each foreign agent's binding will be for the
   tunnel agent's address at the next lower level of the hierarchy.


3.1. Security

   Note that home agent can be considered a "universal root" for
   all such hierarchies of foreign agents as described above.  In
   fact, the home agent's address is an ancestor of every other agent
   address, and the mobile node is guaranteed of never straying from the
   boundaries of the "region" defined by the home agent's agent address.
   There is a clear threat to the mobile node posed by illicit Tunnel
   Establishment Requests, and thus the same need for authenticating
   each Tunnel Establishment Request.  The mobile node and the home
   agent currently share keys which are configured by means outside the
   scope of the TEP protocol specification.  The problem is analogous to
   the requirement in the Route Optimization [8] 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 known to the
   decapsulating agent.




Calhoun, Perkins              Expires 21 May 1998               [Page 7]


Internet Draft      Tunnel Establishment Protocol       21 November 1997


   As outlined in this document, when a mobile node registers with
   its home agent, it sends a Tunnel Establishment Request to all the
   foreign agents in the hierarchy between the home agent and the mobile
   node.  When the top-level tunnel agent address is provided to its
   home agent, the mobile node acquires a session key, (say, using one
   of the extensions specified for Route Optimization [8]).  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.

   Any modification to the tunnel establishment parameters (by or on
   behalf of the mobile node) may require re-establishment of the
   tunnel with some (or all) of the foreign agents in the hierarchy.
   Changing the receivers point of attachment can, however, often be
   handled without causing any change to the home agent's binding for
   the mobile node.  Since each foreign agent between the mobile node's
   previous agent address and the home agent shares the same session
   key, when the mobile re-registers an intermediate agent address with
   an unchanged agent address immediately above it in the hierarchy, the
   mobile node already shares a session key with the agent address which
   didn't change.  To effect the reattachment, then, the mobile node
   just has to send the session key along with its establishment through
   the changed parts of the hierarchy, until the re-establishment occurs
   at the lowest-level agent 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 Tunnel Establishment Request is passed to every foreign
   agent between the mobile node and the "closest" foreign agent that
   didn't change, when the Tunnel Establishment Reply comes back, the
   targeted tunnel agent processing the Request can encode the session
   key for each new foreign agent which will handle the Reply.


3.2. Forwarding Datagrams to the mobile node

   At each level of the hierarchy, the tunnel agent at that level has a
   binding for the mobile node.  The mobile node's binding shows that
   it is served by the tunnel agent at the next lower level of the
   hierarchy.

   Thus, a PDU 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 tunnel agent at the next lower level
   of the hierarchy.  This decapsulation and re-encapsulation occurs at
   each level of the hierarchy, until the PDU reaches the last foreign
   agent which is either the mobile node itself (in case of a co-located
   agent address) or a foreign agent that can deliver the decapsulated
   PDU to the mobile node with no further TEP handling.



Calhoun, Perkins              Expires 21 May 1998               [Page 8]


Internet Draft      Tunnel Establishment Protocol       21 November 1997


   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.


4. Tunnel Establishment Request

   A Tunnel Establishment Request message is sent to all of the
   hierarchical tunnel agents between the mobile node and its home
   agent.

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

   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 tunnel agent at the
                            next higher level of the hierarchy of tunnel
                            agents.

   The UDP header is followed by the 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      |G| rsv | count |          Lifetime             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Targeted Tunnel Agent                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Agent Addresses ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                        Identification                         +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Extensions ...





Calhoun, Perkins              Expires 21 May 1998               [Page 9]


Internet Draft      Tunnel Establishment Protocol       21 November 1997


   +-+-+-+-+-+-+-+-

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

      Type              8 (Tunnel Establishment Request)

      G                 The requester expects to receive PDUs tunneled
                        using GRE [3].

      rsv               sent as zero, ignored on reception

      count             The number of Agent Addresses included in the
                        message, not including the Targeted Tunnel
                        Agent.

      Lifetime          The number of seconds before the Tunnel
                        Establishment must be considered expired by
                        all tunnel agents receiving the Establishment
                        message.

      Targeted Tunnel Agent The IP address of the targeted tunnel agent,
                        which is the lowest-level tunnel agent which is
                        present in the mobile node's current hierarchy
                        of decapsulating agents.

      Tunnel Agents     The tunnel agents serving the mobile node for
                        which the tunnel is to be established.

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

   Unless otherwise specified by the 'G' bit, the requestor expects to
   receive PDUs encapsulated within an IP header.  When the 'G' bit is
   set, the PDU is to be encapsulated within GRE, which can further be
   encapsulated within IP.

      TODO: specify encapsulation with PPTP...  L2TP?

   The Tunnel Establishment Request MUST include an authentication
   extension appropriate to the targeted tunnel agent.  The format of
   the authentication extension is identical to one of the extensions
   defined in the base Mobile IP specification, 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 SPI and Mobility Security
   Association set up when it obtained a session key (say, using Route
   Optimization extension numbers 104 and 105 [8]), from a previous
   Tunnel Parameters Extension it transacted with its home agent and all
Calinterveninghforeignoagentsuatnthat,time.Perkins              Expires 21 May
1998              [Page 10]


Internet Draft      Tunnel Establishment Protocol       21 November 1997


   The same rules apply to the Tunnel Establishment Request as apply to
   the Mobile IP Registration Request, regarding the relative order in
   which different extensions, when present, MUST be placed in a the
   establishment message.

   Each foreign agent which receives a Tunnel Establishment Request
   compares its IP address to the target tunnel agent listed in the
   request.  If they are the same, the foreign agent determines whether
   or not to accept the request, and returns a Tunnel Establishment
   Reply with the appropriate status code, as specified in 5.
   Otherwise, the foreign agent delivers the Tunnel Establishment
   Request to the next-higher agent 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 tunnel agent addresses within the Request.
   If not, it rejects the request with status code 70.

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


5. Tunnel Establishment Reply

   A tunnel agent returns a Tunnel Establishment Reply message to a
   tunnel requestor which has sent a Tunnel Establishment Request
   (Section 4) message, and to the foreign agent at each intermediate
   level of the hierarchy between itself and the tunnel requestor.  Each
   foreign agent above the mobile node in the hierarchy will receive
   the Tunnel Establishment Reply from the tunnel agent at the next
   higher level of the hierarchy.  The Tunnel Establishment Reply
   message contains the necessary codes to inform the tunnel requestor
   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 Tunnel Establishment Request (or Tunnel
   Establishment Request) approved by the home agent.

   When the foreign agent receives a successful Tunnel Establishment
   Reply, it updates its binding for the mobile node, using the
   next-lower tunnel agent in the hierarchy as the foreign agent for the
   mobile node.





Calhoun, Perkins              Expires 21 May 1998              [Page 11]


Internet Draft      Tunnel Establishment Protocol       21 November 1997


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

   The network address of the mobile node MUST be specified
   in an extension to the Tunnel Establishment Reply.  Unless
   specifically superseded in this document, all processing of Tunnel
   Establishment Replies by tunnel agents is specified to be the same
   as the processing by tunnel agents in the base mobile-IP draft
   specification [9].  This includes determining the validity of the
   Tunnel Establishment Request, and selecting the appropriate status
   code (from among those listed below) 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 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 Agent                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                         Identification                        +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Extensions ...















Calhoun, Perkins              Expires 21 May 1998              [Page 12]


Internet Draft      Tunnel Establishment Protocol       21 November 1997


   +-+-+-+-+-+-+-+-

      Type             9 (Tunnel Establishment Reply)

      Code             A value indicating the result of the Tunnel
                       Establishment 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 Tunnel
                       Establishment Requests with Registration Replies,
                       and for protecting against replay attacks of
                       establishment messages.  The value is based
                       on the Identification field from the Tunnel
                       Establishment 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 Tunnel Establishment
                       Reply is followed by one or more Extensions.  An
                       authentication extension MUST be included in all
                       Establishment Replies returned by the tunnel
                       agent.

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

        0 establishment accepted

   Establishment rejected:

       64 reason unspecified
       65 administratively prohibited
       66 insufficient resources
       67 mobile node failed authentication
       68 tunnel agent failed authentication
       69 requested Lifetime too long
       70 poorly formed Request
       71 poorly formed Reply
       72 requested encapsulation unavailable
       80 network unreachable (ICMP error received)
       81 tunnel agent host unreachable (ICMP error received)
       82 tunnel agent port unreachable (ICMP error received)
       88 tunnel agent unreachable (other ICMP error received)
      133 Identification mismatch
      136 unknown tunnel agent address

CalUp-to-datehvaluesoofuthenCode,fieldPareespecifiedrinktheimostnrecents
      Expires 21 May 1998              [Page 13]


   "Assigned Numbers" [10].

Internet Draft      Tunnel Establishment Protocol       21 November 1997


   Each foreign agent receiving a successful Tunnel Establishment 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.


6. Replay Protection

   The Identification field is used to let the targeted tunnel agent
   verify that a establishment message has been freshly generated by
   the mobile node, not replayed by an attacker from some previous
   establishment.  All mobile nodes and tunnel agents using Tunnel
   Establishment messages MUST implement timestamp-based replay
   protection.

   The style of replay protection in effect between a mobile node and
   its tunnel agents is part of the mobile security association.  A
   mobile node and its tunnel 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.

   Replay protection must be provided by mobile nodes using the
   timestamp procedures specified in this document.  The Identification
   in a new Tunnel Establishment 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 [9] is
   allowed.


7. Tunnel Parameters Extension

   This specification defines the Tunnel Parameters Extension, which
   is found in Tunnel Registration Request and Reply messages.  This
   extension is denoted by the value of 128 in the extension field.

    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     |  Addr Family  |   reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Data ...








Calhoun, Perkins              Expires 21 May 1998              [Page 14]


Internet Draft      Tunnel Establishment Protocol       21 November 1997


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   is encoded in the following Type-Length-Value format:

      Type     Indicates the particular type of Extension.

      Length   Indicates the length (in octets) of the data field within
               this Extension.  The length does NOT include the Type and
               Length octets.

      reserved sent as zero, ignored on reception

      Addr Family The Addr Family indicates which network layer protocol
               address is included in the Data field, and thus the
               particular type of tunnel to be registered with the home
               agent.

      Data     Data in the particular format, specified in subsequent
               sections, needed for the establishment of tunnel
               appropriate for the Addr Family.

   Each Addr Family defines a protocol and address format.  The values
   for the Addr Family are compatible with those defined by GRE [3].
   The contents of the Data field depend on the particular network
   layer.  For each value of the Addr Family, the format of the Data
   field is to be outlined in a subsequent Section.

   Current values for the tunnel type are as follows:

Message Type             Abbreviation     Function Value






















Calhoun, Perkins              Expires 21 May 1998              [Page 15]


Internet Draft      Tunnel Establishment Protocol       21 November 1997





7.1. IPX (Addr Family 11)

   An IPX address is either 6 or 10 octets.  If the target is an IPX
   host, the extension MUST supply its 6 octet IEEE 802 address.  If the
   target is an IPX router, the extension MUST supply both its network
   number and node number (its IEEE 802 address).  This extension is
   OPTIONAL and must be present only if the client being registered
   supports IPX. This extension may be sent to register a new client
   on an existing tunnel even if the initial tunnel establishment
   request did not register IPX support.  This extension can be repeated
   multiple times in the case that several IPX addresses are to be
   registered.  In this case, a conventional router or dial-up router is
   serving multiple IPX addresses in the remote LAN. The format of the
   extension is:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sub-Length   |1|  reserved   |       IPX Network Number      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  IPX Network Number (cont.)   |        IPX Node Number        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     IPX Node Number (cont.)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Sub-Length        12 (the length of the Data field)

      Flag              Bit 1 MUST be set

      reserved          MUST be zero

      IPX Network       This field contains the IPX Network number of
                        the remote client (as negotiated by IPXCP for a
                        dial-up user).

      IPX Node Number   This field contains the IPX Node number of the
                        remote client.

   It is possible to enable a routing protocol over an existing tunnel
   only if one was not already negotiated.  It is not possible to
   disable such a protocol.









Calhoun, Perkins              Expires 21 May 1998              [Page 16]


Internet Draft      Tunnel Establishment Protocol       21 November 1997


   The following routing protocols may be used over the tunnel by
   setting the indicated values into the Interface Flags field:

      IPX_RIP          0x0001

      NLSP             0x0002

      IPXWAN_2         0x0004


7.2. AppleTalk Address Extension

   An AppleTalk address is three octets.  If the target does not yet
   have an AppleTalk address, the tunnel endpoint should use the address
   0.0 (three octets of all zeros).

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sub-Length   |M|Z| reserved  |       Appletalk Network       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Node number  |              Zone             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Sub-Length          5 or 7 (the length of the Data field)

      M                   Mandatory

      Z                   If set, the Zone field is present

      Appletalk Network   Two octets for the Appletalk network number

      Node number         One octet for the Appletalk node number

      Zone                If present, an unsigned integer indicating
                          the Zone in which the Appletalk Address is
                          located.


7.3. Vines Address Extension

   A Vines address is either 6 or 10 octets.  If the target is a Vines
   host, it MUST supply its 6 octet Vines address (normally an IEEE 802
   address).  If the target is a Vines router, it MUST supply both its
   Vines address and the subnet number.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sub-Length   |1|  reserved   |       Vines Node Number ...   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Calhoun, Perkins              Expires 21 May 1998              [Page 17]


           Internet Draft      Tunnel Establishment Protocol       21 November
1997


              |            ...  Vines Node Number, continued.                 |
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              |                       Vines subnet Number                     |
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Sub-Length 12 (the length of the Data field)

             Flag Bit 1 MUST be set

         reserved MUST be zero

Vines Node Number This field contains the Vines Node number of the remote
client.

    Vines Network This field contains the Vines Network number of the remote
                  client.


           7.4. CLNP Address Extension

              CLNP uses NSAPs as its addresses, which are of variable length.
If
              the target knows its NET (NSAP with an NSEL of 0), it MUST
include
              its NET in the extension.  Targets which do not know their NET
may
              specify a zero length address.

               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
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              |  Sub-Length   |1|  reserved   |       NSAP ...
              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Sub-Length 12 (the length of the Data field)

             Flag Bit 1 MUST be set

         reserved MUST be zero

             NSAP Network address for use by NSAP


           7.5. Example

              A Mobile Node which desired IPX connectivity in addition to IP
              connectivity would include an extension of the form:

              0x80 0x06 0x81 0x37 0x00 0x00 0x0c 0x01 0x0e 0x36 0x00 0x00








           Calhoun, Perkins              Expires 21 May 1998              [Page
18]

Internet Draft      Tunnel Establishment Protocol       21 November 1997


   This indicates an extension of 128 [0x80] (Tunnel Establishment), a
   data length of 6 octets, a network layer protocol value of 0x8137
   (IPX), and an IEEE 802 address of 00:00:0c:01:03:36.  The final two
   octets of 0x00 are sent so that the extension terminates on a four-
   octet boundary, in accordance with the IP Mobility RFC.


8. Mobile Node Considerations

   The tunnel requestor MUST also include the Tunnel Parameters
   extension one or more times.  Only one such extension MAY be included
   per additional network layer protocol.  Note that a tunnel requestor
   may change which address families are to be used by establishing a
   tunnel with different Address Family fields in its establishment
   packets.

   If the mobile node receives a successful Reply message containing an
   Tunnel Establishment extension, the mobile node should immediately
   establish a GRE tunnel with the home agent as the other endpoint of
   the tunnel.  Then, all data packets at the mobile node with a next
   hop of the home agent will be tunneled to the home agent using GRE
   over IP as the transport mechanism.  This includes IP packets.  Once
   the packet reaches the home agent, the outer header (IP) and GRE
   header are stripped and the packet is submitted for local processing,
   as appropriate for the particular network layer protocol.


9. Foreign Agent Considerations

   The foreign agent MUST copy the Tunnel Establishment extension from
   the Mobile Request to the Establishment Request without modifying it
   in any way.  The foreign agent MUST NOT reject a Mobile Request due
   to the presence or contents of any well formed Tunnel Establishment
   extension.


10. Home Agent Considerations

   The home agent MAY reject an Establishment Request based on the
   contents of an Tunnel Establishment extension.  If the home agent
   accepts a Establishment Request with an Tunnel Establishment
   extension, it MUST provide connectivity to the mobile node for
   the network layer protocol described in the Tunnel Establishment
   extension.  Further, the Tunnel Establishment extensions MUST be
   copied into the Reply message.







Calhoun, Perkins              Expires 21 May 1998              [Page 19]


Internet Draft      Tunnel Establishment Protocol       21 November 1997


   If the home agent accepts a Establishment Request with an Integrated
   Mobility extension, the request MUST also have a Local Care-Of
   Address extension.  The home agent MUST use the Local Care-Of Address
   as the tunnel endpoint and MUST establish a GRE tunnel to the Local
   Care-Of Address.

   Once the GRE tunnel is established, a PDU arriving at the home agent
   for the mobile node will be tunneled to the receiver using GRE over
   IP as the transport mechanism.  Note that this includes IP packets.
   Once the packet reaches the mobile node, the outer header (IP)
   and GRE header are stripped and the packet is submitted for local
   processing, as appropriate for the particular network layer protocol.


11. Security

   Tunnel establishment follows the design philosophy of the
   Mobile IP specification to provide accceptable authentication
   of the establishment process.  This document does not discuss
   confidentiality of user data.

   Note that tunnel establishment often has the effect of controlling
   and possibly redirecting data streams to new points of attachment for
   the mobile node.  Thus, failure to provide sufficient authentication
   of Tunnel Registration Request messages can have the effect of
   allowing malicious disruption of traffic which is supposed to be
   received by the mobile node.  Even failure to properly authenticate
   Tunnel Registration Reply messages could have the effect of masking
   control or data errors in the establishment process.


12. Acknowledgements




















Calhoun, Perkins              Expires 21 May 1998              [Page 20]


Internet Draft      Tunnel Establishment Protocol       21 November 1997


A. Hierarchical Tunnel Agent advertisement

   Since an extension to Router Advertisements could contain multiple
   tunnel agent 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 agent 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 agent
   address first in the list.


References

    [1] Pat R. Calhoun and Ellis Won.  Virtual Tunneling Protocol
        (VTP).  draft-calhoun-vtp-protocol-00.txt, July 1996.  (work in
        progress).

    [2] Stephen E. Deering, Editor.  ICMP Router Discovery Messages.
        RFC 1256, September 1991.

    [3] Stan Hanks, Tony Li, Dino Farinacci, and Paul Traina.  Generic
        Routing Encapsulation (GRE).  RFC 1701, October 1994.

    [4] T. Li and Y. Rekhter.  Integrated Mobility Extension.
        draft-ietf-mobileip-integrated-00.txt, March 1994.  (work in
        progress).

    [5] G. Montenegro.  Tunnel Set-up Protocol (TSP).
draft-montenegro-tsp-00.txt,
        August 1997.  (work in progress).

    [6] C. Perkins.  Mobile-IP Local Registration with Hierarchical
        Foreign Agents.  draft-perkins-mobileip-hierfa-00.txt, February
        1996.  (work in progress).

    [7] Charles Perkins.  IP Encapsulation within IP.  RFC 2003, May
        1996.

    [8] Charles E. Perkins and David B. Johnson.  Route Optimization in
        Mobile-IP.  draft-ietf-mobileip-optim-07.txt, November 1997.
        (work in progress).

    [9] C. Perkins, Editor.  IP Mobility Support.  RFC 2002, October
        1996.

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





Calhoun, Perkins              Expires 21 May 1998              [Page 21]


Internet Draft      Tunnel Establishment Protocol       21 November 1997


Chairs' Addresses

   The working group can be contacted via the current chairs:

      Jim Solomon
      Motorola, Inc.
      1301 E. Algonquin Road
      Schaumburg, IL 60196
      USA

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


      Erik Nordmark
      Sun Microsystems, Inc.
      901 San Antonio Road
      Palo Alto, California 94303
      USA

      Phone:  +1 650 786-5166
      Fax:  +1 650 786-5896
      E-mail:  nordmark@sun.com



Author's Address

   Questions about this memo can be directed to:

      Pat Calhoun                        Charles E. Perkins
      Routing Consulting Engineering     Technology Development
      3com                               Sun Microcomputer Company
      Mount Prospect, IL 60056           901 San Antonio Rd.
                                         Palo Alto, California 94303

      Phone:  1-847-342-6898             1-415-786-6464
      Fax:  1-847-342-6785               1-415-786-6445
      E-mail:  pcalhoun@usr.com          charles.perkins@Sun.COM













Calhoun, Perkins              Expires 21 May 1998              [Page 22]