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

Versions: 00                                                            
                                                            Pat R. Calhoun
Internet Draft                                    US Robotics Access Corp.
expires in six months                                           Ellis Wong
                                                        Bay Networks, Inc.
                                                                 July 1996

                     Virtual Tunneling Protocol (VTP)
                    <draft-calhoun-vtp-protocol-00.txt>


Status of this Memo

   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

   This document specifies a protocol which allows various Layer 2 and
   Layer 3 protocols to be tunneled through an IP network.  VTP does not
   specify any change to the protocol to be tunneled.  It describes the
   mechanisms for dynamically establishing and maintaining secure IP
   tunnels, and carrying multiprotocol data over those tunnels.  VTP
   can be used in the implementation of Virtual Private Networks (VPNs).

   A client-server architecture is defined in order to decouple functions
   which exist in the tunnel initiation node and those in the tunnel
   termination node.  This protocol can be implemented in network
   devices such as network access servers, routers and application servers.

   VTP specifies a Mobile IP-like message exchange protocol to create
   and manage IP tunnel sessions dynamically.  VTP uses the GRE (Generic
   Routing Encapsulation) mechanism to encapsulate multi-protocol
   payload traffic.

Calhoun et. al.                                                   [Page 1]


DRAFT                  Virtual Tunneling Protocol               July 1996


1.  Introduction

   The Virtual Tunneling Protocol (VTP) is a protocol which enables a
   service provider to offer Virtual Private Network (VPN) services and
   dial access services to corporate home networks.  The corporate
   enterprise can subscribe to the service to allow its telecommuters,
   mobile professionals and users in remote branch offices to connect
   back to the corporate network, via the service provider's network.

   In order to provide a true "multiprotocol" VPN technology, it is
   necessary to perform some form of encapsulation and tunneling in
   order to mask the private address space being used.  This technology
   must be sufficiently secure in order to protect the network resources
   from outside attack.

   There exists some basic form of VPN technology today by some
   manufacturers, however these are either very static in nature or are
   proprietary solutions.  The intent of this document is to establish a
   standard, dynamic tunnel establishment scheme which require minimal
   configuration in order to ease deployment of such products.

   This protocol allows dynamic tunnel establishment between two
   network elements over an IP network infrastructure, with extensibility
   to provide tunnel security.  This protocol can be used to construct a
   corporate VPN by implementing the VTP client functions in a remote
   office router and the VTP server functions a router in the corporate
   network.  This protocol can also be used to enable dial access to
   corporate networks via an IP tunnel, through the service provider's
   infrastructure. To support this capability, the VTP client functions
   can be implemented in a service provider Network Access Server (NAS)
   and the VTP server functions can be implemented in a router in a
   corporate network.  In this case, the corporate enterprise can out-
   source the purchase, installation and management of the remote access
   equipment, such as the NAS, to service providers for cost savings.

   The protocol is extensible to support any Layer 2 and Layer 3 protocol
   to be tunneled over an IP network.  The protocol is also flexible by
   allowing the IP tunnel to be terminated within a customer premise, or
   within a service provider network.  Many corporate enterprises may
   already have subscribed to service providers for VPN services such as
   Frame Relay, SMDS, or even ATM.  By terminating IP tunnels in a
   gateway residing within the service provider network, the provider can
   now offer dial-up IP tunnel  interworking with other existing VPN
   services.  With this offering, the corporate enterprise may now obtain
   remote dial access service from the same provider with no hardware or
   software change required in the customer premise equipment (CPE).

   This specification simply details the protocol which is used for

Calhoun et. al.                                                   [Page 2]


DRAFT                  Virtual Tunneling Protocol               July 1996


   tunnel management between two devices.  In the case of support for a
   dial-up PPP connection, user authentication is assumed to be managed
   by the corporate enterprise, not the service provider.  This protocol
   does not require the use of a specific user authentication protocol.
   The PPP CHAP and RADIUS protocols are used in examples to
   facilitate discussion.

   In case of support for LAN interconnection across the service
   provider's IP network infrastructure, routers are used in examples to
   describe the router to router tunneling capability of the protocol.
   The VTP protocol does not require the use of a specific IP
   security mechanism.  A public/private key management mechanism can
   be used to provide secure tunneling functionality.


1.1.  Protocol Goals and Assumptions

   The VTP protocol only needs to be implemented in a tunnel initiation
   node and a tunnel termination node.  The tunneling functions are
   transparent to the dial-up hosts or remote office routers, as well as
   the intermediate systems in the IP backbone.  Hence, no change is
   required in those systems.

   If the tunnel initiation node is a NAS, then it is responsible for
   physical interfacing to the PSTN or ISDN.  It is also responsible for
   the logical termination of the PPP or SLIP connection, and the tunnel
   initiation from an IP network interface.  If the tunnel termination
   node is a router, then it simply consists of one of more LAN
   interfaces, and at least one IP network interface which the IP tunnel
   is initiated from.

   Authentication is provided via PPP CHAP or PAP, or through
   other dialogs as needed for protocols which do not use authentication
   (i.e. SLIP).  User authentication is managed from the enterprise home
   network.   This specification does not require the use of one specific
   user authentication protocol (i.e., RADIUS, TACACS+).

   The VTP protocol also must support enterprises which use private
   network addresses for corporate virtual private networking.  In the
   case the tunnel initiator is a NAS, the enterprise assigns an address
   for the dial-up node, which is meaningful to the enterprise home
   network, during the user authentication process.







Calhoun et. al.                                                   [Page 3]


DRAFT                  Virtual Tunneling Protocol               July 1996


 1.2. Terminology

   This document frequently uses the following terms:

      DLCI     Data Link Connection Identifier is a unique identifier
               for a virtual circuit at each Frame Relay interface.

      PVC      Permanent Virtual Circuits are connections which are
               permanent in nature.

      SVC      Switched Virtual Circuits are connections which are
               dynamic in nature.

      Care-of Address
               The termination point of a tunnel towards a mobile node,
               for datagrams forwarded to the mobile node while it is
               away from home.  This protocol specifies the use of a
               "co-located care-of address", which is an externally
               obtained local address which the mobile node has
               associated with one of its own network interfaces.

      Foreign Agent
               A router on a mobile node's visited network which
               provides routing relay services to the registered mobile
               node.  The foreign agent decapsulates and delivers
               datagrams to the mobile node which were tunneled by the
               mobile node's home agent.

               For datagrams sent by the a mobile node, the foreign
               agent may serve as a default router for mobile nodes.

      Gateway
               A router which resides within the service provider network.
               It is connected to multiple VPNs  (such as Frame Relay), as
               well as the IP backbone.  The gateway may provide the
               home agent processing functions.

      Home Address
               An address which is assigned to a Mobile Node for an
               extended period of time.  This address is assigned from
               the home network.

      Home Agent
               A router on a mobile node's home network which tunnels
               datagrams for delivery to the mobile node when it is away
               from home, and maintains current location information for
               the mobile node.


Calhoun et. al.                                                   [Page 4]


DRAFT                  Virtual Tunneling Protocol               July 1996


      Home Network
               The network address domain which the mobile node's home
               address belongs in.

      Mobile Node
               A host or router which changes its point of attachment
               from one network or subnetwork to another.  A mobile node
               may change its location without changing its IP address.
               It may continue to communicate with other Internet nodes
               at any location using its (constant) IP address, assuming
               link-layer connectivity to a point of attachment is
               available.  The Mobile Node initiates the registration
               request to its home agent to indicate its current point
               of network attachment.

      NAS      A Network Access Server is a router which supports
               dial-up PPP and SLIP users.

      VPN      Virtual Private Networks are logical networks over a
               physical public network.  This logical network forms a
               private network for an enterprise.


1.3. Specification Language

   In this document, several words are used to signify the requirements
   of the specification.  These words are often capitalized.

      MUST                This word, or the adjective "required", means
                          that the definition is an absolute requirement
                          of the specification.

      MUST NOT            This phrase means that the definition is an
                          absolute prohibition of the specification.

      SHOULD              This word, or the adjective "recommended",
                          means that, in some circumstances, valid
                          reasons may exist to ignore this item, but the
                          full implications must be understood and
                          carefully weighed before choosing a different
                          course. Unexpected results may result
                          otherwise.

      MAY                 This word, or the adjective "optional", means
                          that this item is one of an allowed set of
                          alternatives.  An implementation which does
                          not include this option MUST be prepared to
                          interoperate with another implementation which

Calhoun et. al.                                                   [Page 5]


DRAFT                  Virtual Tunneling Protocol               July 1996


                          does include the option.

      silently discard    The implementation discards the datagram
                          without further processing, and without



                          indicating an error to the sender.  The
                          implementation SHOULD provide the capability
                          of logging the error, including the contents
                          of the discarded datagram, and SHOULD record
                          the event in a statistics counter.


2. Protocol Overview

   The basic functionality defined in VTP is derived from the Mobile
   IP protocol [3].  The Mobile IP specification provides much more
   functionality than required for this protocol.  Thus, only a subset of
   the specification will be used in this protocol.  The Mobile IP
   specification defined a registration mechanism for creating a one-way
   tunnel from the home agent to the mobile node, and allows for roaming
   of the mobile node.  VTP uses the registration mechanism to create
   two-way tunnels and does not support any roaming (as in cellular
   roaming) capability.  The subset which will be implemented will be the
   Registration Request/Response messages which are used for the Tunnel
   Establishment, Shutdown and Refresh functions.  The VTP protocol also
   takes the advantage of the extensibility defined as registration
   extensions in the Mobile IP specification to carry tunnel specific
   information which are important in establishing secure VPN tunneling.

   The VTP protocol defines a resource called the Mobile Node Proxy.
   The mobile node proxy has similar functionality to a mobile node
   which has a co-located care-of address.  However, the mobile node
   proxy is the device which initiates a two-way IP tunnel by registering
   to the home agent.  The home agent is the device which terminates
   the two-way tunnel.  The mobile node proxy can perform
   encapsulation of datagrams to be tunneled to its home agent and
   decapsulation of datagrams tunneled from its home agent.  Similarly,
   the home agent can perform encapsulation of datagrams to be
   tunneled to a mobile node proxy and decapsulation of datagrams
   tunneled from a mobile node proxy.

   For virtual dial-up tunneling support, the mobile node proxy can
   be implemented in a NAS.  The home agent functions can be
   implemented in a customer CPE router or in a gateway router which
   resides in the service provider network.  The mobile node proxy can
   initiate a two-way IP tunnel in response to a remote PPP dial-in

Calhoun et. al.                                                   [Page 6]


DRAFT                  Virtual Tunneling Protocol               July 1996


   connection attempt.  A dial-up PPP client will be referred to as a
   dial-up client in this specification, however VTP does inherently
   support SLIP as well.

   The mobile node proxy, in a sense, acts as a proxy agent for the dial-
   up client.  This proxy capability will allow dial-up clients to
   connect to the corporate network via the IP backbone without having to
   install Mobile IP capable software.  The IP address of the NAS then
   becomes the care-of address for each of these mobile node proxy
   instances.

   For router to router tunneling support, the mobile node proxy can be
   implemented in the router which initiates a tunnel establishment
   attempt to interconnect remote networks over an IP backbone.  The home
   agent can be implemented in a peer router which terminates the tunnel.
   In this case, the router which initiates the tunnel has a co-located
   care-of address.  The care-of address is the address of the IP
   interface which connects to the IP backbone.

   For both virtual dial-up tunneling and router-to-router tunneling
   cases, the mobile node proxy and the a home agent can coexist in one
   element.  This will allow the network element to initiate one bi-
   directional tunnel and to terminate another independently.

   This protocol defines another resource called the VPN Identifier. This
   identifier has no significance for router to router tunnel
   establishment, but is used by devices which support multiple VPNs
   simultaneously.  This numerical representation of the domain allows
   network devices to protect network resources by allowing only
   resources from one domain to access other resources within the same
   domain.  The VPN identifier is included in the tunnel manangement
   messages as a registration extension.

   This protocol also defines another resource called the Tunnel
   Identifier.  This identifier is also used to distinguish each tunnel
   from the other. The tunnel identifier allows the each end of the
   tunnel to associate the tunneled data stream with the appropriate
   tunnel.  The tunnel identifier is included in each of the tunnel
   management messages as a registration extension.  It is also included
   in the encapsulation header of each tunneled data packet.

   Tunnel security is performed by authenticating each peer of the tunnel
   as defined in the Mobile-Home Authentication section of the Mobile IP
   specification, which is done with the use of session keys.   In order
   to provide a good authentication scheme, a session key must have a
   short life span, where it is valid only for the duration of a tunnel,
   and in the case of a long term tunnel it is possible to re-negotiate a
   new session key.

Calhoun et. al.                                                   [Page 7]


DRAFT                  Virtual Tunneling Protocol               July 1996


   This protocol provides flexibility as far as a session key encryption
   technique.  However, MD5 is the default technique which MUST be
   supported by all implementations.


2.1.  Dynamic Tunnel Establishment

   This section will detail the events which are necessary for tunnel
   establishment.  We will attempt to describe the events of a tunnel
   establishment, followed by two sections which describe the
   applicability with a router to router and a NAS to router scenario.
   A final section detailing how to recover from a race condition.

   In order to establish a tunnel, it is necessary to send a Registration
   Request message.  The sender (or tunnel initiator) is known as the
   Mobile Node Proxy.  Each registration request message contains a
   field known as Lifetime.  This field contains a value which defines the
   number of seconds before the tunnel expires.  The tunnel initiator is
   responsible for "refreshing" the tunnel before the peer considers the
   tunnel expired.

   When creating a registration request message, the mobile node proxy
   must know if it is simply registering a new remote client to use an
   existing tunnel, or if a new tunnel needs to be created for a new
   remote client.  In the case of a new tunnel, the mobile node proxy must
   set the least significant two bytes of the four-byte field to a locally
   unique value (unused by the sender).  This value may be used locally as
   an index into a local table.  The decision to register a new client
   using an existing tunnel (multiplexing many remote clients over one
   tunnel), or to create a new tunnel for each new remote client is
   implementation specific.

   If a tunnel already exists and the mobile node proxy wishes to register
   a new remote address to an existing tunnel, the mobile node proxy
   must insert the full tunnel identifier into the request.  Registering a
   new remote address on an existing tunnel resets the lifetime for the
   tunnel (same as the Refresh Request message).  The tunnel identifier,
   is used in all subsequent exchanges in order to identify the tunnel.

   All protocols which are used by the client must be registered with the
   home agent.  Each network protocol used by the client is indicated in
   a separate registration extension.

   If the dial-up PPP station is a network device which requires routing
   updates (i.e. a router), routing may be required on the tunnel.  The
   tunnel registration mechanism also negotiates a set of attributes for
   the tunnel itself; including routing, compression and others.


Calhoun et. al.                                                   [Page 8]


DRAFT                  Virtual Tunneling Protocol               July 1996


   An encrypted session key MUST be present in the registration request
   message, which is used by the home agent (tunnel terminator) in order
   to verify the authenticity of the message.  The message also
   contains an MD5 message digest as the last extension.

   Upon receipt of this message, the home agent must decrypt the session
   key, and use the same key to verify the authenticity of the message by
   generating an MD5 hash of the message and comparing it with the
   value in the extension.  If the message digest does not compare, a
   response with the appropriate error code is returned to the mobile node
   proxy.

   If the home agent receives an extension which MUST be supported
   and cannot be supported locally, the home agent MUST respond with
   the appropriate error code.  If an extension is malformed or contains
   an invalid value, the same processing policy applies in these cases.

   If the registration request is for a new tunnel, the home agent must
   insert an unused, locally unique, value into the most significant two
   bytes of the four-byte tunnel identifier.  In the case of a request to
   register a new address on an existing tunnel, the home agent must
   verify that the tunnel is active and the tunnel's peer is with the
   requesting mobile node proxy.

   If the mobile node proxy is requesting an existing tunnel which does
   not exist on the home agent (or exists with a different peer), the home
   agent must insert a new value into the most significant two bytes
   (this could occur if the home agent had reset for some reason) of the
   tunnel identifier.

   If the request is valid and contains all of the required extensions,
   the home agent will create a dynamic tunnel interface.  The tunnel
   interface could be created with a network address set to the registered
   home address, and the care-of address set to the mobile node proxy.
   The home agent should also add to the route table the network
   level addresses of the client being registered (for all protocols).

   Once all of the above steps have been successfully completed, the
   home agent returns a registration response message with the return
   code set to SERVICE_PROVIDED.

   Both the request and response MUST include, as the first extension the
   authentication extension, which contains an MD5 digest of the
   message.

   Note that if the request contained a VPN extension, it MUST be
   returned in the response even if it is not supported locally.  This
   extension is necessary for certain type of network equipment which

Calhoun et. al.                                                   [Page 9]


DRAFT                  Virtual Tunneling Protocol               July 1996


   supports multiple VPNs.

   The mobile node proxy receiving this response must examine the
   return code.  Unless the return code was set to authentication failure,
   the message digest in the response should be compared with a locally
   generated message digest (using the session key).  If the return code
   is set to a value other than [ ], the mobile node proxy may either
   retry the message up to the maximum retry, or attempt a tunnel with an
   alternate home agent (if one is available).

   If the request was sent to register a new remote address on an existing
   tunnel and the response contains a different tunnel identifier than was
   requested, then the mobile node proxy MUST assume that the home agent
   has rebooted and that the old tunnel is no longer valid.

   The mobile node proxy could then create a local tunnel interface with
   the local network address set to the home address; the IP tunnel local
   address set to the care-of address; and the IP tunnel peer address set
   to the home agent IP address.


2.1.1.  Router to Router Tunnel Establishment

   This section will detail the events for tunnel establishment for a
   router to router scenario.

   Figure 1 depicts two branch offices which connect to the main office
   through a public network in a secure fashion.  Both of the branch
   offices have a router which supports VTP, which will establish a tunnel
   to a VTP server (running on a CPE router, for example) at the main
   office.  In this diagram we show a firewall at the main office, which
   must be configured to allow IP datagrams with a protocol ID set to GRE
   and whose destination is set to the VTP Server.

   Both of the routers and the VTP server SHOULD either share a pre-
   configured shared secret, use a public/private key scheme or have
   access to some form of key distribution center.   Since MD5 key
   encoding is an optional extension for this protocol, all
   implementations SHOULD support shared secrets.

   An example scenario of the use of VTP in this case would be when
   there is data which is to be routed to the main office from one of the
   branch offices, the router could examine if there is already a tunnel
   to the VTP server.  If no tunnel is established, a registration request
   is sent and once the response is received all data may be encapsulated
   and sent to the server.



Calhoun et. al.                                                  [Page 10]


DRAFT                  Virtual Tunneling Protocol               July 1996


        Host
         |
   ------+------                        +----------------------+
         |                              |                      |
       Router 1   ----------------------+                      |
     (VTP Client)                       |    Public Network    |
                                        |                      |
                                        |                      |
       Router  2  ----------------------+                      |
     (VTP Client)                       |                      |
                                        +-----------+----------+
                                                    |
                                                    |
                                              ------+------
                                                    |
                                                    |

                                               Firewall Node

                                                    |
                                                    |
                                            --------+---------
                                                    |
                                                 Router 3
                                               (VTP Server)

                Figure 1:  Router to Router VTP connection




2.1.2.  NAS to Gateway Tunnel Establishment

   This section will detail the sequence of events which are necessary for
   a Dial-up router to establish a tunnel with a gateway.  This scenario
   shows the VTP home agent residing within the ISP's network, but this
   is not a limitation of the protocol.  Figure 2 shows an example of
   network which supports VTP.

   The home agent shown has the ability to support multiple VPNs (or
   domains) in a secure fashion (meaning that network resources may
   only be accessed by users if they are within the same VPN).  This
   example also shows a RADIUS Server which holds all of the configuration
   necessary for VTP tunnel establishment and is returns a successful user
   authentication message.  The RADIUS Server also act as a Key
   Distribution Center (KDC) and create a unique session key for each
   user.


Calhoun et. al.                                                  [Page 11]


DRAFT                  Virtual Tunneling Protocol               July 1996


   Note that the user of RADIUS is optional and any authentication
   protocol may be used.  In addition, a KDC is also optional, however
   configuring shared secrets on each VTP device causes interesting
   scalability problems, but using a public/private key could work.

   Upon connect, a PPP client generates a LCP request, which is used for
   Link Control Protocol negotiations. The NAS will respond and the
   peers must agree to a set of options. The NAS will then generate a
   CHAP request to the client (assuming that CHAP was negotiated as the
   authentication protocol), this request will contain a 16 octet
   authentication vector, which will be used later for security purposes.
   The Client will then pass the encrypted user name and password in the
   CHAP response. At this point, the NAS has a copy of the user name
   and password of the client which will be used when sending the
   authentication request to the local RADIUS Server.

         Host
          |
   +-------------+
   |  PSTN/ISDN  |
   |             |
   +------+------+                      +----------------------+
          |                             |                      |
         NAS      ----------------------+                      |
      (VTP Client)                      |    Public Network    |
                                        |                      |
                                        |                      |
                                        |                      |
                                        |                      |
                                        +-+------------------+-+
                                          |                  |
                                          |                  |
                                    ------+------      ------------
                                          |                  |
                                          |                  |

                                       Gateway          CPE Router
                                    (VTP Server)      (VTP unaware)

                  Figure 2: NAS to Gateway VTP Connection


   Note that VTP does not require CHAP and any authentication protocol
   (i.e. PAP, CHAP, EAP) may be used.

   The NAS generates a Radius ACCESS_REQUEST message and forward the
   message to the local Radius Server. In this example, we will assume
   that the Radius Server (known as the Proxy Server) is configured to

Calhoun et. al.                                                  [Page 12]


DRAFT                  Virtual Tunneling Protocol               July 1996


   forward the authentication requests to a remote Radius Server (known
   as the Domain Authentication Server, or DAS).  The local Radius Server
   will then re-compute the password using the Shared Secret which is
   configured between itself and the remote Radius Server, add a proxy
   state attribute and forward the request to the DAS.

   The Remote Radius Server is now responsible for user authentication.
   If successfully authenticated, the attributes configured for the user
   are added  to the ACCESS_ACCEPT packet.  One or more VPN Gateway
   attributes are attached to the packet. This attribute contains an IP
   address, a tunnel refresh value and an encoded representation of a
   temporary session key.  The packet is then returned to the Proxy
   Server.  The Proxy Server will then add VPN specific attributes and
   return the message to the originating NAS.

   Once the NAS receives the ACCESS_ACCEPT message, a CHAP response is
   returned to the PPP Client and NCP negotiations are then initiated.
   Once NCP negotiations are complete, the NAS creates a VPN entry from
   the information which was received in the packet.

   NOTE: The tunnel establishment SHOULD occur after the completion
   of the NCP negotiation phase, but prior to setting the connection to
   the open state, in order to avoid PPP client time-outs.

   At this point, the NAS will send a registration request message to the
   home agent (see figure 2).  Upon receipt of a successful response, the
   NAS sets the PPP to open state.  All packets from the client are
   encapsulated within a GRE header with the Tunnel ID field set to the
   tunnel identifier and sent to the home agent.  Upon receipt of a data
   packet, the authenticity must be validated using the session key.


2.1.3.  Race Condition

   Since the protocol requires that the mobile node proxy must always be
   known (the mobile node proxy is the one who is responsible for
   refreshing the tunnel), there exists a potential race condition problem
   when two nodes send a Registration Request simultaneously.

   If a network device receives a registration request message from
   another node which it already has a pending request for, the request
   with the lowest IP address in the home agent IP Address field MUST
   be discarded.


2.2.  Dynamic Tunnel Refresh

   As explained above, each registration request message contains a field

Calhoun et. al.                                                  [Page 13]


DRAFT                  Virtual Tunneling Protocol               July 1996


   known as the lifetime which is set to the maximum number of seconds
   before the tunnel expires.  Although registering a new client over an
   existing tunnel causes the timer to reset and the new lifetime to be
   observed, it is highly possible that no new clients will attempt to
   register before the tunnel does expire. Therefore there must be a
   mechanism to "refresh" the tunnel, and this is done by using the Tunnel
   Refresh message, which includes the tunnel identifier as well as a new
   lifetime. The home agent must acknowledge the request with a
   response in order for the mobile node proxy to consider the tunnel
   "refreshed".

   It is imperative that the mobile node proxy allow enough time for
   refresh request re-transmissions, otherwise the home agent could
   invalidate the tunnel. Therefore the mobile node proxy should observe
   the following formula in determining when to transmit the first refresh
   request message:

   timer = (current time + lifetime) -
                (MAX retransmissions * seconds between retrans.)

   This formula does raise an interesting problem, which deals with
   selecting the tunnel lifetime.  If the lifetime chosen for a tunnel is
   less than the max retransmission times the seconds between each
   retransmission, this would cause a flurry of refreshes, and possibly a
   very unreliable service.  It is therefore recommended that an
   implementation chooses it's minimum lifetime wisely.

   There exists a timing problem which can occur if the mobile node
   proxy sends out a refresh request followed by a deregistration request
   for the same SPI as that used in the refresh.  If the home agent
   received both packets out of order, it could invalidate the SPI when
   receiving the deregistration request and then fail the refresh's
   authentication since the SPI is no longer valid.  It is therefore
   imperative that when the mobile node proxy receives a refresh response
   indicating that the request failed the authentication that a new
   request be sent with another valid SPI (if there are no valid SPI then
   the request is abandoned). This "retransmission" should not be done
   more often than the maximum retransmission counter.

   Once the maximum number of retransmissions have been unsuccesssful
   (either failed or no response), the interface should be shutdown and
   any dial-up users (in the case of a NAS) should be disconnected.


2.3.  Dynamic Tunnel Shutdown

   A tunnel shutdown could result for many reasons, one being that a dial-
   up user has disconnected with the NAS, another being that a router

Calhoun et. al.                                                  [Page 14]


DRAFT                  Virtual Tunneling Protocol               July 1996


   would shutdown a tunnel due to inactivity or possibly when a
   transaction is complete.

   The mobile node proxy constructing the request, MUST use the SPI
   which is associated with this user.  Upon receipt of the message, the
   home agent will attempt to authenticate the message.  If it fails
   authentication, it will respond with a negative response.  Otherwise it
   will remove each route specified in the header and protocol extensions
   from the network routing tables for the mobile node proxy.

   Next, the peer will check if there are any other mobile node proxy
   which are using the tunnel.  If not, then the GRE interface is deleted
   and the response is sent back to the requester.

   Once the mobile node proxy receives the response, it will attempt to
   authenticate the response.  If the response fails the authentication,
   the request will be abandoned.  Once the maximum number
   re-transmissions have been sent, the mobile node proxy will simply
   destroy the tunnel. If the response was successfully authenticated, it
   will also ensure that there are no other mobile node proxies using the
   tunnel.  If there are none, then the local GRE interface is also
   deleted.

   Tunnel de-registration messages are always sent from the mobile node
   proxy to the home agent. If a home agent detects that it must shutdown
   the interface, it may do so and return an error in the next refresh
   response.


3. Protocol Specification

   The VTP protocol is based on the IP Mobility protocol.  The VTP
   protocol uses a subset of the Mobile IP protocol specification.

   The IP Mobility protocol contains a standard header, and a set of
   extensions.  These extensions contain information which is relevant for
   the operation.  An extension consist of a type field, a length field,
   followed by the data field.  All VTP related extensions are
   encapsulated within a single Mobility extension.  This allows the
   protocol to allocate as many extension numbers as required without
   affecting the relatively small Mobility extension address space
   (8 bits).


3.1.  Registration Request

   This message is sent from the mobile node proxy to the home agent for
   two purposes.  In the first case, the mobile node proxy wishes to

Calhoun et. al.                                                  [Page 15]


DRAFT                  Virtual Tunneling Protocol               July 1996


   establish a new tunnel with the home agent, and the second is where
   the mobile node proxy wishes to register a new remote address with the
   home agent over an existing tunnel.

   The following message format is used:

    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|T|r|            Lifetime           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Home IP Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Home Agent Address                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Care of IP Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Identification                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Identification                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


        Type                    1 (Registration Request)

        S, B, M, V              All set to zero to disable features not
                                required.

        D                       1, The mobile node proxy will itself
                                decapsulate datagrams which are sent to
                                the care-of address.

        G                       1, GRE encapsulation enabled.

        T                       1, Bi-directional tunneling enabled.

        r                       0, Reserved Field

        Lifetime                The number of seconds remaining before the
                                registration is considered expired. A
                                value of 0xffff indicates infinity.

        Home IP Address         For IP over dial-up connections, this
                                value is the IP address of the remote node
                                or the dial-up router.  It is the IPCP
                                assigned IP address for the remote client.

                                For non-IP protocol over dial-up
                                connections, this field is set to zero.

Calhoun et. al.                                                  [Page 16]


DRAFT                  Virtual Tunneling Protocol               July 1996


                                For IP tunneling configurations between
                                two routers which are not dial-up routers,
                                this field is also set to zero.

        Home Agent Address      The IP Address of the home agent.

        Care of Address         The IP Address of the Foreign Agent.

        Identification          The 64-bit identification field consists
                                of two parts.  The most significant four
                                bytes contain a valid timestamp, which is
                                the number of seconds since January 1,
                                1900 (as defined in [NTP]).

                                The least significant four bytes contains
                                a random value.


3.1.1. VTP Extensions

   This extension is used to encapsulate all VTP specific extensions. This
   is done in order to conserve the small extension address space which is
   available in the Mobile IP header. Each sub-extension may all be
   encapsulated within one single VTP extension, or each sub-extension may
   be individually encapsulated with this extension.

   The format of the header is as defined below:

    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     |            Sub-Type           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Length     |     flag      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Type                    65 (VTP Extensions)

        Length                  variable

        Sub-Type                Sub Attribute Number

        Sub-Length              Sub Attribute Length

        Flag                    The flag field contains a set of
                                properties for the following
                                sub-attribute. The following bits have
                                been defined:


Calhoun, et. al.                                                 [Page 17]


DRAFT                  Virtual Tunneling Protocol               July 1996


                                VTP_MANDATORY_SUPPORT           0x01
                                    If this bit is set, the attribute
                                    MUST be supported by the peer. If this
                                    attribute cannot be supported, an
                                    error code must be returned.


3.1.1.1.  Tunnel-Identifier Extension

   This extension is REQUIRED for tunnel establishment requests and all
   further requests to register a new user to an existing tunnel. This
   extension SHOULD be the first extension following the protocol header.

    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     |            Sub-Type           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sub-Length   |     flag      |       Tunnel Identifier       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Tunnel Identifier       |         Interface Flags       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Interface Flags         |      System Name (opt) ...    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


        Sub-Type                1 (VTP Tunnel-Identifier Extension)

        Sub-Length              variable

        Flag                    Bit 1 MUST be set (mandatory support)

        Tunnel ID               The Tunnel Identifier contains the GRE
                                session ID. This identifier is used
                                within each GRE header to indicate the
                                session. The Tunnel ID is divided into two
                                parts; the least significant two bytes
                                contains the Foreign Agent session
                                identifier and the most significant two
                                bytes are the Home Agent's session ID.

                                When requesting a new session, the mobile
                                node proxy should insert an unused integer
                                in the least significant two bytes, set
                                the most significant to zero. Upon
                                successful registration, the peer will
                                insert an unused two byte value in the
                                most significant two bytes.


Calhoun et. al.                                                  [Page 18]


DRAFT                  Virtual Tunneling Protocol               July 1996


                                In the case of a NAS which wishes to
                                register a new client within an existing
                                tunnel, the full tunnel identification is
                                inserted in this field.

        Interface Flags         The Interface Flags field contains all
                                attributes for the tunnel. The initiator
                                may set as many attributes for the
                                interface as required, however the
                                response from the peer will contain the
                                attributes which the peer is able to
                                service at this time.

                                It is possible to change the properties of
                                a tunnel while the tunnel is active. This
                                is done when a new user is registered on
                                an existing tunnel. However a property
                                CANNOT be removed from a tunnel, only
                                added.

                                The following flags have been reserved:

                                VTP_IF_COMPRESSION              0x0001
                                    If this bit is enabled, compression of
                                    user data is bi-directionally enabled.
                                    Once compression has been negotiated,
                                    all data sent through the tunnel must
                                    be compressed. This property is per
                                    tunnel, not per user.

                                VTP_IF_AUTHENTICITY             0x0002
                                    If this bit is enabled, each GRE
                                    header contains a 4 octet MD5 hash of
                                    the packet.  This enables
                                    authentication of each data packet. It
                                    is also possible to use the AH header
                                    to authenticate each packet. If this
                                    is done, it is not necessary to set
                                    this bit.

        System Name             This optional 64 octet field contain a
                                string representation of either the user
                                name which was used during the login
                                process which initiated the tunnel
                                establishment or the device system name
                                (if available). This is used for command
                                line display purposes only.


Calhoun et. al.                                                  [Page 19]


DRAFT                  Virtual Tunneling Protocol               July 1996


3.1.1.2.  IP-Protocol Extension

   This extension is OPTIONAL and must be present only if the client being
   registered supports IP. This extension may be sent to register a new
   client on an existing tunnel even if the initial tunnel establishment
   request did not register IP support. This extension can be repeated
   multiple times in the case that several IP addresses are to be
   registered.  In this case, a conventional router or dial-up router
   is serving multiple IP 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |            Sub-Type           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sub-Length   |     flag      |      IP Network Address       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  IP Network Address (cont.)   |        IP Subnet Mask         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     IP Subnet Mask (cont.)    |        Interface Flags        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



        Sub-Type                10 (IP-Protocol Extension)

        Sub-Length              10

        Flag                    Bit 1 MUST be set (mandatory support)

        IP Network Address      This field contains the IP Network address
                                of each of the subnetworks the remote
                                client is serving.  This allows the home
                                agent to add a network route upon
                                successful registration without the need
                                of a routing protocol.

                                This obviously only works if the address
                                space on the network side is contiguous,
                                otherwise a routing protocol is required.

                                For a dial-up user (non-router), this
                                field SHOULD be set to zero.

        IP Subnet Mask          This field contains the Subnet mask of the
                                IP Network address above.



Calhoun et. al.                                                  [Page 20]


DRAFT                  Virtual Tunneling Protocol               July 1996


        Interface Flags         The Interface Flags field contains all
                                attributes for the IP protocol over the
                                tunnel. The tunnel initiator may set all
                                of the bits which it can support. The
                                response from the tunnel terminator
                                determines the interface properties which
                                will be used over the tunnel. It is
                                therefore possible to set a preference
                                on either ends of the tunnel.

                                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.

                                The following flags have been reserved:

                                VTP_IF_RIP_ROUTING              0x0001
                                    If this bit is enabled, RIP will be
                                    used as a routing protocol over the
                                    tunnel.

                                VTP_IF_OSPF_ROUTING             0x0002
                                    If this bit is enabled, OSPF will be
                                    used as a routing protocol over the
                                    tunnel.


3.1.1.3.  IPX-Protocol Extension

   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:











Calhoun et. al.                                                  [Page 21]


DRAFT                  Virtual Tunneling Protocol               July 1996


    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     |            Sub-Type           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sub-Length   |     flag      |       IPX Network Number      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  IPX Network Number (cont.)   |        IPX Node Number        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     IPX Node Number (cont.)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Interface Flags         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Sub-Type                11 (IPX Protocol Extension)

        Sub-Length              12

        Flag                    Bit 1 MUST be set (mandatory support)

        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.

        Interface Flags         The Interface Flags field contains all
                                attributes for the IPX protocol over the
                                tunnel. The tunnel initiator may set all
                                of the bits which it can support. The
                                response from the tunnel terminator
                                determines the interface properties which
                                will be used over the tunnel. It is
                                therefore possible to set a preference on
                                either ends of the tunnel.

                                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.

                                The following flags have been reserved:

                                VTP_IF_RIP_ROUTING              0x0001
                                    If this bit is enabled, IPX RIP will
                                    be used as a routing protocol over
                                    the tunnel.

Calhoun et. al.                                                  [Page 22]


DRAFT                  Virtual Tunneling Protocol               July 1996


                                VTP_IF_NLSP_ROUTING             0x0002
                                    If this bit is enabled, NLSP will be
                                    used as a routing protocol over the
                                    tunnel.

                                VTP_IF_IPXWAN_2                 0x0004
                                    If this bit is enabled, IPXWAN version
                                    2 will be used over the tunnel
                                    interface.


3.1.1.4.  Virtual-Private-Networking Extension

   The Virtual Networking Extension MAY be present in the Registration
   Request if the Mobile Node support the concept of VPN. The
   Registration MUST include this extension (although the name field may
   be removed).

    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     |            Sub-Type           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sub-Length   |     flag      |         VPN Identifier        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         VPN Identifier        |            VPN Name           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          VPN Name (64)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Sub-Type                9 (Virtual-Private-Networking Extension)

        Sub-Length              variable

        Flag                    Bit 1 MUST be set (mandatory support)

        VPN ID                  The VPN Identifier is a numerical
                                representation of the Domain. This
                                customer identifier is assigned by the
                                service provider and must be globally
                                unique within the network. This value may
                                be returned by the authentication server.

                                Although many implementations will not
                                make use of this extension, a registration
                                response MUST include this extension if
                                one was present in the corresponding
                                request.

        VPN Name                This optional field contains the ASCII
                                representation of the VPN identifier,
                                which MAY be the name of the customer

Calhoun et. al.                                                  [Page 23]


DRAFT                  Virtual Tunneling Protocol               July 1996


                                (e.g. ABC Corp.).


3.1.1.5.  Dynamic-Connection Extension

   The Dynamic Connection Extension MAY be present in the Registration
   Request if the circuit from the home agent to the CPE router is not
   permanent. The information contained in this extension should be
   sufficient in order for the home agent to establish a link with the
   CPE device.

    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     |            Sub-Type           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sub-Length   |     flag      |           Link Type           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Address                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Sub-Type                7 (Dynamic-Connection Extension)

        Sub-Length              variable

        Flag                    Bit 1 MUST be set (mandatory support)

        Link Type               The Link Type field contains a
                                numerical representation of the underlying
                                link to use in order to connect to the CPE
                                device. The following have already been
                                defined:

                                VTP_FR_SVC                      0x0001
                                    When set, the address refers to a
                                    Frame Relay Switched Virtual Circuit.

                                VTP_ATM_SVC                     0x0002
                                    When set, the address refers to an ATM
                                    Switched Virtual Circuit.

                                VTP_X25_SVC                     0x0003
                                    When set, the address refers to a X.25
                                    Switched Virtual Circuit.

        Address                 A link layer address which the home agent
                                must use in order to connect to the CPE
                                router. The length of the address is
                                determined by the length of the attribute

Calhoun et. al.                                                  [Page 24]


DRAFT                  Virtual Tunneling Protocol               July 1996


                                (less the link type field).


3.1.1.6.  Session-Key Extension

   The Session Key Extension MUST be present in the request. This
   extension contains the tunnel's session key which will be used for
   message autentication as well as encyption (if used).

    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     |            Sub-Type           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sub-Length   |     flag      |       Encryption Type         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Encoded Session Key                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Encoded Session Key                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Encoded Session Key                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Encoded Session Key                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Vector                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Vector                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Vector                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Vector                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Sub-Type                8 (Session-Key Extension)

        Sub-Length              Variable

        Flag                    Bit 1 MUST be set (mandatory support)

        Encryption Type         The Encryption Type field is used in order
                                to inform the tunnel terminator the
                                encryption technique which was used in
                                order to encrypt the session key.

                                The default value, which MUST be supported
                                by all implementations is MD5 (type 0x0001).

                                The following flags have been reserved:


Calhoun et. al.                                                  [Page 25]


DRAFT                  Virtual Tunneling Protocol               July 1996


                                VTP_ENC_MD5                     0x0001
                                    If this bit is enabled, MD5 was used
                                    as the encryption technique. In this
                                    case, the Encoded Session Key
                                    contains an MD5 hash of the following:

                                    MD5(Vector|Shared Secret|Session Key)

                                    Where the vector is a 16 octet random
                                    value which was used by the session
                                    key encryptor to add randomness to the
                                    encoded value.

                                    The Shared Secret is the shared secret
                                    which is common between the peers
                                    (note it is possible that both peers
                                    do not shared a common secret, see
                                    section 9 for more information).


                                VTP_ENC_DES                     0x0002
                                    This this bit is set, DES was used as
                                    the encryption technique.

                                    A Registration Response with an error
                                    of ERR_ENCRYPT_NOT_SUPPORTED informs
                                    the tunnel initiator that it must
                                    attempt an alternative encryption
                                    technique, or use the default value.

        Encoded Session Key     This field contains a new encoded random
                                16 octet value. The size of the encoded
                                session key is determined by the extension
                                length field (less the 16 octet vector
                                size for MD5 encoding). This value is only
                                valid for the duration of the tunnel (and
                                even shorter if session key renegotiation
                                is done during the tunnel refresh
                                process).

                                The Mobile-Home Authentication extensions
                                contains an SPI, which must be saved and
                                is used in order to reference this session
                                key.

        Vector                  This field contains a 16 octet random
                                value which was used in encrypting the
                                session key. This field is only present

Calhoun et. al.                                                  [Page 26]


DRAFT                  Virtual Tunneling Protocol               July 1996


                                when the encryption type is set to MD5.


3.1.2. Mobile-Home Authentication Extension

   This extension is used as described in the IP Mobility specification.
   This extension MUST be added after the VTP extension in all tunnel
   management messages.

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


        Type                    32

        Length                  4 plus the number of bytes in the
                                Authenticator.

        SPI                     Security Parameter Index.  Contains a
                                pseudo-random value which must be
                                retained by the peer in order to use
                                the session key which was negotiated in
                                any future refresh and deregistration
                                messages.

        Authenticator           Contains a MD5 representation of the whole
                                Tunnel Registration header up to and
                                including this extension's length field.
                                The value is computed from default
                                authentication algorithm a keyed-MD5
                                hash of the following:

                                MD5( Session Key | Packet | Session Key )

                                Where the packet is the whole Mobile IP
                                packet up to and including the length field.
                                The Session Key is a 16 octet randomized
                                value.


3.2.  Registration Response

   Upon receipt of the Registration Request from a mobile node proxy, the
   home agent will register the HOME IP Address for the VPN.

Calhoun et. al.                                                  [Page 27]


DRAFT                  Virtual Tunneling Protocol               July 1996


   The response from the home agent will be in the following format:

    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 IP Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Home Agent IP Address                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Care of IP Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Identification                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Identification                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



        Type                    3 (Registration Response)

        Code                    One of the following:
                                0   - Service will be provided

                                128 - reason unspecified
                                129 - administratively prohibited
                                130 - insufficient resources
                                131 - mobile node proxy failed
                                      authentication
                                133 - registration identification mismatch
                                134 - poorly formed request
                                135 - too many simutaneous mobility
                                      bindings
                                140 - The VPN has not been configured
                                141 - The IP Address already exists
                                142 - The IPX Address already exists
                                143 - Network Outage
                                144 - Encryption type not supported

        Lifetime                The number of seconds remaining before
                                the registration is considered expired. A
                                value of all ones indicates infinity.

        Home IP Address         For routers, this value is the IP address
                                of the router.

                                For Dial-up Routers, this is the IPCP
                                assigned IP address.

Calhoun et. al.                                                  [Page 28]


DRAFT                  Virtual Tunneling Protocol               July 1996


                                If the mobile node proxy does not support
                                IP, this value is set to zero.

        Home Agent IP Address   IP Address of the home agent, copied from
                                the pending Registration Request.

        Care of Address         The IP Address of the tunnel end located
                                in the NAS or router.

        Identification          The identification field consists of two
                                parts. The most significant four bytes
                                contain a valid timestamp, which is the
                                number of seconds since January 1, 1900
                                (as defined by the NTP protocol).

                                The least significant four bytes MUST
                                contain the same value which was set in
                                the request. This is used in order to
                                simplify matching the request and the



                                response.

        The following extensions will be added to the message:


3.2.1.  VTP Extensions

   This extension is used to encapsulate all VTP specific extensions. This
   is done in order to conserve the small extension address space which is
   available in the Mobile IP header. Each sub-extension may all be
   encapsulated within one single VTP extension, or each sub-extension may
   be individually encapsulated with this extension.

   The format of the header is as defined below:

    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     |            Sub-Type           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Length     |     flag      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Type                    65 (VTP Extensions)

        Length                  variable


Calhoun et. al.                                                  [Page 29]


DRAFT                  Virtual Tunneling Protocol               July 1996


        Sub-Type                Sub Attribute Number

        Sub-Length              Sub Attribute Length

        Flag                    The flag field contains a set of
                                properties for the following
                                sub-attribute. The following bits have
                                been defined:

                                VTP_MANDATORY_SUPPORT           0x01
                                    If this bit is set, the attribute
                                    MUST be supported by the peer. If
                                    this attribute cannot be supported,
                                    an error code must be returned.


3.2.1.1.  Tunnel-Identifier Extension

   This extension is REQUIRED for tunnel establishment requests and all
   further requests to register a new user to an existing tunnel. This
   extension SHOULD be the first extension following the protocol header.

    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     |            Sub-Type           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sub-Length   |     flag      |       Tunnel Identifier       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Tunnel Identifier       |         Interface Flags       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Interface Flags         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Sub-Type                1 (VTP Tunnel-Identifier Extension)

        Sub-Length              14

        Flag                    Bit 1 MUST be set (mandatory support)

        Tunnel ID               The Tunnel Identifier contains the GRE
                                session ID. This identifier is used within
                                each GRE header to indicate the session.
                                The Tunnel ID contains two session
                                identifiers; the least significant two
                                bytes contains the initiator's session
                                identifier and the most significant two
                                bytes are the remote peer's session ID.


Calhoun et. al.                                                  [Page 30]


DRAFT                  Virtual Tunneling Protocol               July 1996


                                When responding to a new Tunnel
                                Registration Request, the peer inserts an
                                unused integer within the most significant
                                two bytes.

                                If the initiator inserted a full tunnel
                                identifier, which is no longer valid (e.g.
                                the device has rebooted), it is necessary
                                to insert a new value in the most
                                significant two bytes.

        Interface Flags         The Interface Flags field contains all
                                attributes for the tunnel. The returned
                                values will dictate to the peer what
                                attributes to set for the tunnel. If a
                                specific attribute cannot be supported, it
                                should not be returned in the response,
                                which the peer must consider as disabled
                                for the tunnel. The response cannot
                                contain flags which were not initially
                                requested.


3.2.1.2.  IP-Protocol Extension

   This extension MUST be present if the Registration Request included
   this extension. The absence of this extension, when expected, informs
   the tunnel initiator that the protocol is not supported by the home
   agent. 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |            Sub-Type           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sub-Length   |     flag      |      IP Network Address       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   IP Network Address (cont.)  |        IP Subnet Mask         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     IP Subnet Mask (cont.)    |        Interface Flags        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Sub-Type                10 (IP-Protocol Extension)

        Sub-Length              10

        Flag                    Bit 1 MUST be set (mandatory support)



Calhoun et. al.                                                  [Page 31]


DRAFT                  Virtual Tunneling Protocol               July 1996


        IP Network Address      Set to the value which was in the
                                Registration Request.

        IP Subnet Mask          Set to the value which was in the
                                Registration Request.

        Interface Flags         The Interface Flags field contains the
                                flags which the Home Agent is able to
                                support. The home agent should not set
                                more than one bit which is considered
                                mutually exclusive (i.e. RIP and OSPF).

                                The home agent may not enable a bit which
                                was not present in the Registration
                                Request.


3.2.1.3.  IPX-Protocol Extension

   This extension MUST be present if the Registration Request included
   this extension. The absence of this extension, when expected, informs
   the tunnel initiator that the protocol is not supported by the home
   agent. 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |            Sub-Type           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sub-Length   |     flag      |       IPX Network Number      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  IPX Network Number (cont.)   |        IPX Node Number        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     IPX Node Number (cont.)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Interface Flags         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Sub-Type                11 (IPX-Protocol Extension)

        Sub-Length              12

        Flag                    Bit 1 MUST be set (mandatory support)

        IPX Network             Set to the value which was in the
                                Registration Request.

        IPX Node Number         Set to the value which was in the
                                Registration Request.

Calhoun et. al.                                                  [Page 32]


DRAFT                  Virtual Tunneling Protocol               July 1996


        Interface Flags         The Interface Flags field contains the
                                flags which the Home Agent is able to
                                support. The home agent should not set
                                more than one bit which is considered
                                mutually exclusive (i.e. RIP and NLSP).

                                The home agent may not enable a bit which
                                was not present in the Registration
                                Request.


3.2.1.4.  Virtual-Private-Networking Extension

   The Virtual Private Networking Extension MUST be present if such an
   extension was present in the Registration Request.

    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     |            Sub-Type           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sub-Length   |     flag      |         VPN Identifier        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         VPN Identifier        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Sub-Type                9 (Virtual-Private-Networking Extension)

        Sub-Length              4

        Flag                    Bit 1 MUST be set (mandatory support)

        VPN ID                  The VPN Identifier MUST contain the value
                                which was reported in the Registration
                                Request.


3.2.2.  Mobile-Home Authentication Extension

   This extension is used as described in the IP Mobility specification.
   This extension MUST be added after the VTP extensions in all tunnel
   management messages.








Calhoun et. al.                                                  [Page 33]


DRAFT                  Virtual Tunneling Protocol               July 1996


   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |             SPI               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              SPI              |      Authentication Value     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Authentication Value                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Authentication Value                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Authentication Value                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Authentication Value      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Type                    32 (Mobile-Home Authentication Extension)

        Length                  20

        SPI                     Security Parameter Index. Contains a
                                pseudo-random value which must be retained
                                by the peer in order to use the session
                                key which was negotiated in any future
                                refresh and deregistration messages.

        Authentication Value    Contains a MD5 representation of the whole
                                Tunnel Registration packet up to and
                                including this extensions length field.
                                The value is a MD5 hash of the following:

                                MD5( Session Key | Packet | Session Key )

                                Where the packet is the whole Mobile IP
                                packet up to and including the length
                                field. The Session Key is a 16 octet
                                randomized value.


3.3.  Refresh Request

   The Refresh Request messages is sent from the mobile node proxy to the
   home agent. This message is sent from the mobile node proxy to the home
   agent in order to "refresh" the tunnel and ensure that it does not
   expire.

   Note that although the layer 3 protocols do not require the Home Agent
   to send a refresh request to the Mobile Node for any reason, there may
   exist other extensions which do require this feature. For this reason,

Calhoun et. al.                                                  [Page 34]


DRAFT                  Virtual Tunneling Protocol               July 1996


   it is possible for a Home Agent to initiate a refresh request.

   The following message format is used:

    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|F|M|G|V|T|r|            Lifetime           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Home IP Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Home Agent IP Address                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Care of IP Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Identification                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Identification                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Type                    2 (Refresh Request)

        S, B, M, V              All set to zero to disable features not
                                required.

        D                       1, The mobile node proxy will itself
                                decapsulate datagrams which are sent to
                                the care-of address.

        G                       1, GRE encapsulation enabled.

        T                       1, Bi-directional tunneling enabled.

        r                       0, Reserved Field

        Lifetime                Contains a value indicating the number of
                                seconds before the tunnel expires.

        Home IP Address         Set to zero.

        Home Agent IP Address   IP Address of the home agent IP Address

        Care of Address         The IP Address of the tunnel end located
                                in the NAS.

        Identification          The identification field consists of two
                                parts. The most significant four bytes
                                contain a valid timestamp, which is the
                                number of seconds since January 1, 1900

Calhoun et. al.                                                  [Page 35]


DRAFT                  Virtual Tunneling Protocol               July 1996


                                (as defined by the NTP protocol). The
                                least significant four bytes contain a
                                random value.

   The following extensions will be added to the message:


3.3.1.  VTP Extensions

   This extension is used to encapsulate all VTP specific extensions. This
   is done in order to conserve the small extension address space which is
   available in the Mobile IP header. Each sub-extension may all be
   encapsulated within one single VTP extension, or each sub-extension may
   be individually encapsulated with this extension.

   The format of the header is as defined below:

    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     |            Sub-Type           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Length     |     flag      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Type                    65 (VTP Extensions)

        Length                  variable

        Sub-Type                Sub Attribute Number

        Sub-Length              Sub Attribute Length

        Flag                    The flag field contains a set of
                                properties for the following
                                sub-attribute. The following bits have
                                been defined:

                                VTP_MANDATORY_SUPPORT           0x01
                                    If this bit is set, the attribute MUST
                                    be supported by the peer. If this
                                    attribute cannot be supported, an
                                    error code must be returned.







Calhoun et. al.                                                  [Page 36]


DRAFT                  Virtual Tunneling Protocol               July 1996


3.3.1.1.  Tunnel-Identifier Extension

   This extension is REQUIRED for tunnel establishment requests and all
   further requests for a new client to use an existing tunnel. This
   extension SHOULD be the first extension following the protocol header.

    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     |            Sub-Type           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sub-Length   |     flag      |       Tunnel Identifier       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Tunnel Identifier       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Sub-Type                1 (VTP Tunnel-Identifier Extension)

        Sub-Length              4

        Flag                    Bit 1 MUST be set (mandatory support)

        Tunnel ID               The Tunnel Identifier contains the GRE
                                session ID. This identifier is used within
                                each GRE header to indicate the session.
                                The Tunnel ID contains two session
                                identifiers; the least significant two
                                bytes contains the tunnel initiator's
                                session identifier and the most
                                significant two bytes are the peer's
                                session ID.


3.3.1.2.  Virtual-Private-Networking Extension

   The Virtual Private Networking Extension MUST be present if such an
   extension was present in the Registration Request.

    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     |            Sub-Type           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sub-Length   |     flag      |         VPN Identifier        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         VPN Identifier        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Sub-Type                9 (Virtual-Private-Networking Extension)


Calhoun et. al.                                                  [Page 37]


DRAFT                  Virtual Tunneling Protocol               July 1996

        Sub-Length              4

        Flag                    Bit 1 MUST be set (mandatory support)

        VPN ID                  The VPN Identifier MUST be set to the
                                same value as the one which was reported
                                in the original Registration Request.


3.3.1.3.  Session-Key Extension

   The Session Key Extension is optional during the tunnel refresh
   process. It is used if the mobile node proxy wishes to negotiate a
   new session key with the home agent.

    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     |            Sub-Type           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sub-Length   |     flag      |       Encryption Type         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Encoded Session Key                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Encoded Session Key                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Encoded Session Key                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Encoded Session Key                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Vector                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Vector                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Vector                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Vector                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Sub-Type                8 (Session-Key Extension)

        Sub-Length              Variable

        Flag                    Bit 1 MUST be set (mandatory support)

        Encryption Type         The Encryption Type field is used in order
                                to inform the tunnel terminator the
                                encryption technique which was used in
                                order to encrypt the session key.


Calhoun et. al.                                                  [Page 38]


DRAFT                  Virtual Tunneling Protocol               July 1996


                                The default value, which MUST be supported
                                by all implementations is MD5 (type 0x0001).

                                The following flags have been reserved:

                                VTP_ENC_MD5                     0x0001
                                    If this bit is enabled, MD5 was used
                                    as the encryption technique. In this
                                    case, the Encoded Session Key
                                    contains an MD5 hash of the following:

                                    MD5(Vector|Shared Secret|Session Key)

                                    Where the vector is a 16 octet random
                                    value which was used by the session
                                    key encryptor to add randomness to the
                                    encoded value.

                                    The Old Session Key is the session
                                    which is still valid between both
                                    peers. It is recommended that the
                                    peers remember the Old Session Key
                                    for a short period in order to deal
                                    with out of order packets which may
                                    have been authenticated or encrypted
                                    using the Old Session Key.


                                VTP_ENC_DES                     0x0002
                                    This this bit is set, DES was used as
                                    the encryption technique.

                                    A Registration Response with an error
                                    of ERR_ENCRYPT_NOT_SUPPORTED informs
                                    the tunnel initiator that it must
                                    attempt an alternative encryption
                                    technique, or use the default value.

        Encoded Session Key     This field contains a new encoded random
                                16 octet value. The size of the encoded
                                session key is determined by the extension
                                length field (less the 16 octet vector
                                size for MD5 encoding). This value is only
                                valid for the duration of the tunnel (and
                                even shorter if session key renegotiation
                                is done during the tunnel refresh
                                process).


Calhoun et. al.                                                  [Page 39]


DRAFT                  Virtual Tunneling Protocol               July 1996


                                The Mobile-Home Authentication extensions
                                contains an SPI, which must be saved and
                                is used in order to reference this session
                                key.

        Vector                  This field contains a 16 octet random
                                value which was used in encrypting the
                                session key. This field is only present
                                when the encryption type is set to MD5.


3.3.2.  Mobile-Home Authentication Extension

   This extension is used as described in the IP Mobility specification.
   This extension MUST be added after the VTP extensions in all tunnel
   management messages.

   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |             SPI               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              SPI              |      Authentication Value     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Authentication Value                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Authentication Value                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Authentication Value                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Authentication Value      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Type                    32 (Mobile-Home Authentication Extension)

        Length                  20

        SPI                     Security Parameter Index. Contains a
                                pseudo-random value which must be retained
                                by the peer in order to use the session
                                key which was negotiated in any future
                                refresh and deregistration messages.

        Authentication Value    Contains a MD5 representation of the whole
                                Tunnel Registration packet up to and
                                including this extensions length field.
                                The value is a MD5 hash of the following:

                                MD5( Session Key | Packet | Session Key )

Calhoun et. al.                                                  [Page 40]


DRAFT                  Virtual Tunneling Protocol               July 1996


                                Where the packet is the whole Mobile IP
                                packet up to and including the length
                                field. The Session Key is a 16 octet
                                randomized value.


3.4.  Refresh Response

   The response from the home agent will be in the following format:

    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 IP Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Home Agent IP Address                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Care of IP Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Identification                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Identification                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Type                    4 (Refresh Response)

        Code                    One of the following:
                                0   - Service will be provided

                                128 - reason unspecified
                                129 - administratively prohibited
                                130 - insufficient resources
                                131 - mobile node proxy failed
                                      authentication
                                133 - registration identification mismatch
                                134 - poorly formed request
                                135 - too many simutaneous mobility
                                      bindings
                                140 - The VPN has not been configured
                                141 - The IP Address already exists
                                142 - The IPX Address already exists
                                143 - Network Outage
                                144 - Encryption type not supported

        Lifetime                The number of seconds before the Gateway
                                will consider the tunnel expired, unless
                                a refresh or new tunnel Registration

Calhoun et. al.                                                  [Page 41]


DRAFT                  Virtual Tunneling Protocol               July 1996


                                Request is received.

        Home IP Address         Set to zero.

        Home Agent IP Address   IP Address of the home agent, copied from
                                the pending Refresh Request.

        Identification          The identification field consists of two
                                parts. The most significant four bytes
                                contain a valid timestamp, which is the
                                number of seconds since January 1, 1900
                                (as defined by the NTP protocol).

   The least significant four bytes MUST contain the same value which was
   set in the request. This is used in order to simplify  matching the
   request and the response.

   The following extension will be added to the message:


3.4.1.  VTP Extensions

   This extension is used to encapsulate all VTP specific extensions. This
   is done in order to conserve the small extension address space which
   is available in the Mobile IP header. Each sub-extension may all be
   encapsulated within one single VTP extension, or each sub-extension
   may be individually encapsulated with this extension.

   The format of the header is as defined below:

    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     |            Sub-Type           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Length     |     flag      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Type                    65 (VTP Extensions)

        Length                  variable

        Sub-Type                Sub Attribute Number

        Sub-Length              Sub Attribute Length

        Flag                    The flag field contains a set of
                                properties for the following sub-attribute.


Calhoun et. al.                                                  [Page 42]


DRAFT                  Virtual Tunneling Protocol               July 1996


                                The following bits have been defined:

                                VTP_MANDATORY_SUPPORT           0x01
                                If this bit is set, the attribute MUST be
                                supported by the peer. If this attribute
                                cannot be supported, an error code must
                                be returned.


3.4.1.1.  Tunnel-Identifier Extension

   This extension is REQUIRED for tunnel refresh messages. This extension
   SHOULD be the first extension following the protocol header.

    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     |            Sub-Type           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sub-Length   |     flag      |       Tunnel Identifier       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Tunnel Identifier       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Sub-Type                1 (VTP Tunnel-Identifier Extension)

        Sub-Length              4

        Flag                    Bit 1 MUST be set (mandatory support)

        Tunnel ID               The Tunnel Identifier contains the GRE
                                session ID. This identifier is used within
                                each GRE header to indicate the session.
                                The Tunnel ID contains two session
                                identifiers; the least significant two
                                bytes contains the tunnel initiator's
                                session identifier and the most
                                significant two bytes are the peer's
                                session ID.


3.4.1.2.  Virtual-Private-Networking Extension

   The Virtual Private Networking Extension MUST be present if such an
   extension was present in the Refresh Request.





Calhoun et. al.                                                  [Page 43]


DRAFT                  Virtual Tunneling Protocol               July 1996


    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     |            Sub-Type           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sub-Length   |     flag      |         VPN Identifier        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         VPN Identifier        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Sub-Type                9 (Virtual-Private-Networking Extension)

        Sub-Length              4

        Flag                    Bit 1 MUST be set (mandatory support)

        VPN ID                  The VPN Identifier MUST be set to the same
                                value as the one which was reported in the
                                original Registration Request.


3.4.2.  Mobile-Home Authentication Extension

   This extension is used as described in the IP Mobility specification.
   This extension MUST be added as the first extension in all
   tunnel management messages.

   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |             SPI               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              SPI              |      Authentication Value     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Authentication Value                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Authentication Value                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Authentication Value                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Authentication Value      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Type                    32 (Mobile-Home Authentication Extension)

        Length                  20

        SPI                     Security Parameter Index. Contains the
                                Security association value which was
                                used during the session key management

Calhoun et. al.                                                  [Page 44]


DRAFT                  Virtual Tunneling Protocol               July 1996


                                for the key used in creating the
                                Authentication value for this message.

        Authentication Value    Contains a MD5 representation of the whole
                                Tunnel Registration packet up to and
                                including this extensions length field.
                                The value is a MD5 hash of the following:

                                MD5( Session Key | Packet | Session Key )

                                Where the packet is the whole Mobile IP
                                packet up to and including the length
                                field. The Session Key is a 16 octet
                                randomized value.


3.5.  Deregistration Request

   The Deregistration Request messages is sent from the mobile node proxy
   to the home agent. This message is sent to the home agent in order to
   shutdown the tunnel. For a NAS this is done when the PPP connection
   is terminated. For routers, this may be done when the connection has
   been idle for a specified amount of time.

   Note that although the layer 3 protocols do not require the Home Agent
   to send a Deregistration request to the Mobile Node for any reason,
   there may exist other extensions which do require this feature. For
   this reason, it is possible for a Home Agent to initiate a refresh
   request. The following message format is used:

   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|F|M|G|V|T|r|            Lifetime           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Home IP Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Home Agent IP Address                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Care of IP Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Identification                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Identification                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Type                    1 (Deregistration Request)



Calhoun et. al.                                                  [Page 45]


DRAFT                  Virtual Tunneling Protocol               July 1996


        S, B, M, V              All set to zero to disable features not
                                required.

        D                       1, The mobile node proxy will itself
                                decapsulate datagrams which are sent to
                                the care-of address.

        G                       1, GRE encapsulation enabled.

        T                       1, Bi-directional tunneling enabled.

        r                       0, Reserved Field

        Lifetime                Contains a value of zero to indicate a
                                deregistration.

        Home IP Address         For routers, this value is the IP address
                                of the router.

                                For Dial-up Routers, this is the IPCP
                                assigned IP address.

                                If the mobile node proxy does not support
                                IP, this value is set to zero.

        Home Agent IP Address   IP Address of the home agent IP Address

        Care of Address         The IP Address of the tunnel initiator
                                (Foreign Agent).

        Identification          The identification field consists of two
                                parts. The most significant four bytes
                                contain a valid timestamp, which is the
                                number of seconds since January 1, 1900
                                (as defined by the NTP protocol). The
                                least significant four bytes contain a
                                random value.

The following extensions will be added to the message:


3.5.1.  VTP Extensions

   This extension is used to encapsulate all VTP specific extensions. This
   is done in order to conserve the small extension address space which
   is available in the Mobile IP header. Each sub-extension may all be
   encapsulated within one single VTP extension, or each sub-extension
   may be individually encapsulated with this extension.

Calhoun et. al.                                                  [Page 46]


DRAFT                  Virtual Tunneling Protocol               July 1996


   The format of the header is as defined below:

    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     |            Sub-Type           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Length     |     flag      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Type                    65 (VTP Extensions)

        Length                  variable

        Sub-Type                Sub Attribute Number

        Sub-Length              Sub Attribute Length

        Flag                    The flag field contains a set of
                                properties for the following sub-attribute.
                                The following bits have been defined:

                                VTP_MANDATORY_SUPPORT           0x01
                                If this bit is set, the attribute MUST be
                                supported by the peer. If this attribute
                                cannot be supported, an error code must
                                be returned.


3.5.1.1.  Tunnel-Identifier Extension

   This extension is REQUIRED for tunnel establishment requests and all
   further requests for a new client to use an existing tunnel. This
   extension SHOULD be the first extension following the protocol
   header.

    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     |            Sub-Type           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sub-Length   |     flag      |       Tunnel Identifier       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Tunnel Identifier       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Sub-Type                1 (VTP Tunnel-Identifier Extension)

        Sub-Length              10


Calhoun et. al.                                                  [Page 47]


DRAFT                  Virtual Tunneling Protocol               July 1996


        Flag                    Bit 1 MUST be set (mandatory support)

        Tunnel ID               The Tunnel Identifier contains the GRE
                                session ID. This identifier is used within
                                each GRE header to indicate the session.
                                The Tunnel ID contains two session
                                identifiers; the least significant two
                                bytes contains the tunnel initiator's
                                session identifier and the most
                                significant two bytes are the peer's
                                session ID.


3.5.1.2.  IP-Protocol Extension

   This extension MUST be present if the Registration Request included
   this extension. The presence of this extension informs the home agent
   that this remote IP address no longer exists.  Thus, this IP address
   MUST be removed from the binding table in the home agent.  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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |            Sub-Type           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sub-Length   |     flag      |      IP Network Address       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   IP Network Address (cont.)  |        IP Subnet Mask         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     IP Subnet Mask (cont.)    |        Interface Flags        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Sub-Type                10 (IP-Protocol Extension)

        Sub-Length              10

        Flag                    Bit 1 MUST be set (mandatory support)

        IP Network Address      Set to the value which was in the
                                Registration Request.

        IP Subnet Mask          Set to the value which was in the
                                Registration Request.

        Interface Flags         Set to zero (0).




Calhoun et. al.                                                  [Page 48]


DRAFT                  Virtual Tunneling Protocol               July 1996


3.5.1.3.  IPX-Protocol Extension

   This extension MUST be present if the Registration Request included
   this extension. The presence of this extension informs the home agent
   that this remote IP address no longer exists.  Thus, this IP address
   MUST be removed from the binding table in the home agent.  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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |            Sub-Type           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sub-Length   |     flag      |       IPX Network Number      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  IPX Network Number (cont.)   |        IPX Node Number        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     IPX Node Number (cont.)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Interface Flags         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Sub-Type                11 (IPX-Protocol Extension)

        Sub-Length              12

        Flag                    Bit 1 MUST be set (mandatory support)

        IPX Network             Set to the value which was in the
                                Registration Request.

        IPX Node Number         Set to the value which was in the
                                Registration Request.

        Interface Flags         Set to zero (0).


3.5.1.4.  Virtual-Private-Networking Extension

   The Virtual Private Networking Extension MUST be present if such an
   extension was present in the Registration Request.

    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     |            Sub-Type           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sub-Length   |     flag      |         VPN Identifier        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         VPN Identifier        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Calhoun et. al.                                                  [Page 49]


DRAFT                  Virtual Tunneling Protocol               July 1996


        Sub-Type                9 (Virtual-Private-Networking Extension)

        Sub-Length              4

        Flag                    Bit 1 MUST be set (mandatory support)

        VPN ID                  The VPN Identifier MUST contain the value
                                which was reported in the Registration
                                Request.


3.5.2.  Mobile-Home Authentication Extension

   This extension is used as described in the IP Mobility specification.
   This extension MUST be added after the VTP extensions in all tunnel
   management messages.

   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |             SPI               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              SPI              |      Authentication Value     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Authentication Value                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Authentication Value                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Authentication Value                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Authentication Value      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Type                    32 (Mobile-Home Authentication Extension)

        Length                  20

        SPI                     Security Parameter Index. Contains the
                                Security association value which was used
                                during the session key management for the
                                key used in creating the Authentication
                                value for this message.

        Authentication Value    Contains a MD5 representation of the whole
                                Tunnel Registration packet up to and
                                including this extensions length field.
                                The value is a MD5 hash of the following:

                                MD5( Session Key | Packet | Session Key )

Calhoun et. al.                                                  [Page 50]


DRAFT                  Virtual Tunneling Protocol               July 1996


                                Where the packet is the whole Mobile IP
                                packet up to and including the length
                                field. The Session Key is a 16 octet
                                randomized value.


3.6.  Deregistration Response

   The response from the home agent will be in the following format:

    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 IP Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Home Agent IP Address                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Care of IP Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Identification                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Identification                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Type                    3 (Deregistration Response)

        Code                    One of the following:
                                0   - Service will be provided

                                128 - reason unspecified
                                129 - administratively prohibited
                                130 - insufficient resources
                                131 - mobile node proxy failed
                                      authentication
                                133 - dereg. identification mismatch
                                134 - poorly formed request
                                140 - The VPN has not been configured
                                141 - The IP Address already exists
                                142 - The IPX Address already exists
                                143 - Network Outage

        Lifetime                0

        Home IP Address         IPCP assigned IP address, copied from the
                                pending Deregistration Request.

        Home Agent IP Address   IP Address of the home agent, copied from

Calhoun et. al.                                                  [Page 51]


DRAFT                  Virtual Tunneling Protocol               July 1996


                                the pending Deregistration Request.

        Identification          The identification field consists of two
                                parts. The most significant four bytes
                                contain a valid timestamp, which is the
                                number of seconds since January 1, 1900
                                (as defined by the NTP protocol).

                                The least significant four bytes MUST
                                contain the same value which was set in
                                the request. This is used in order to
                                simplify matching the request and the
                                response.

The following extension will be added to the message:

3.6.1.  Mobile-Home Authentication Extension

   This extension is used as described in the IP Mobility specification.
   This extension MUST be added as the first extension in all
   tunnel management messages.

   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |             SPI               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              SPI              |      Authentication Value     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Authentication Value                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Authentication Value                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Authentication Value                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Authentication Value      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Type                    32 (Mobile-Home Authentication Extension)

        Length                  20

        SPI                     Security Parameter Index. Contains the
                                Security association value which was used
                                during the session key management for the
                                key used in creating the Authentication
                                value for this message.



Calhoun et. al.                                                  [Page 52]


DRAFT                  Virtual Tunneling Protocol               July 1996


        Authentication Value    Contains a MD5 representation of the whole
                                Tunnel Registration packet up to and
                                including this extensions length field.
                                The value is a MD5 hash of the following:

                                MD5( Packet | Session Key )

                                Where the packet is the whole Mobile IP
                                packet up to and including the length
                                field. The Session Key is a 16 octet
                                randomized value.


4.2.  Data Encapsulation


   Once a "tunnel" has been established via a success Registration
   Request, all data is encapsulated within a GRE header.

   This section defines the encapsulation header which is required for the
   VTP and L2TP 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |C|R|K|S|s|Recur|A|T|L|Flg| Ver |        Protocol Type          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          CheckSum (Opt)       |          Offset(Opt)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Key (Opt)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Sequence Number (Opt)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Tunnel Identifier                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


        C                       Checksum Present. Set to zero (0).

        R                       Routing Present. Set to zero (0).

        K                       Key Present.  Set to zero (0).  Set to
                                (1) if the GRE header is to be
                                authenticated and contains the Key field.

        S                       Sequence Number Present. Set to zero (0).



Calhoun et. al.                                                  [Page 53]


DRAFT                  Virtual Tunneling Protocol               July 1996


        s                       Strict Source Route Present. Set to
                                zero (0).

        A                       Acknowledgment sequence number present.
                                Set to zero (0).

        T                       Tunnel Identifier. Set to one (1).

        L                       L2TP Tunnel Information. Set to zero (0).

        Recur                   Recursion control. set to zero (0).

        Flg (Flags)             Must be set to zero.

        Ver                     Must contain 0.

        Protocol Type           Contains the Assigned Protocol ID
                                (see assigned numbers RFC).

        Key                     Key field is zero if each data packet is
                                not authenticated.

        Tunnel Identifier       Contains the Tunnel Identifier which was
                                negotiated during the Registration
                                process. Present if the 'T' bit is set.

                                This field is used in order to identify
                                which tunnel the data belongs to.

   Note that an encapsulated packet which contains an invalid tunnel
   identifier in the Tunnel ID field MUST be dropped.


4.  Radius Support

   In order for NAS' to support the VTP protocol, a minimum amount of
   configuration is required for tunnel management. It is desirable to
   allow the configuration to exist on a separate server in order to
   minimize deployment configuration issues. For this reason, the
   following RADIUS attributes have been defined.

4.1.  VPN ID

   The VPN ID is returned by the Radius Server in order for the NAS to
   identify a VPN. The following packet format extension is added to the
   ACCESS_ACCEPT packet.



Calhoun et. al.                                                  [Page 54]


DRAFT                  Virtual Tunneling Protocol               July 1996


   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    |        Organization ID        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Organization ID(cont.)     |          Indicator            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Indicator (cont.)        |        VPN Identifier         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        VPN Identifier         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Type                    26 (Vendor Specific)

        Length                  14

        Organization ID         429 for US Robotics
                                430 for Bay Networks

        Indicator               0x9006 (VPN-ID)

        VPN Identifier          4 byte VPN Identifier


4.2.  VPN Name

   The VPN Name is returned by the Radius Server in order for the NAS
   to identify a VPN Name. The presence of this attribute is optional and
   is used primarily for the command line display. The following packet
   format extension is added to the ACCESS_ACCEPT packet.

   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    |        Organization ID        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Organization ID(cont.)     |          Indicator            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Indicator (cont.)        |           VPN Name..          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Type                    26 (Vendor Specific)

        Length                  Variable

        Organization ID         429 for US Robotics
                                430 for Bay Networks

        Indicator               0x9007 (VPN-Name)


Calhoun et. al.                                                  [Page 55]


DRAFT                  Virtual Tunneling Protocol               July 1996


        VPN Name                Null Terminated String Containing the
                                VPN Name.


4.3.  VPN Gateway

   The VPN Gateway MUST be returned by the Radius Server within the
   ACCESS_ACCEPT messages in order for the NAS to correctly identify
   the home agent associated with the mobile node proxy. Note that more
   than one VPN Gateway attribute may be returned in a single
   ACCESS_ACCEPT. The following packet extension will be returned:

   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    |        Organization ID        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Organization ID(cont.)     |          Indicator            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Indicator (cont.)        |  Addr Format  | VPN Gateway   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   VPN Gateway                 | Enc Sess. Key |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Encoded Session Key (cont.)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Encoded Session Key (cont.)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Encoded Session Key (cont.)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Encoded Session Key (cont.)          |Tunnel Refresh |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Tunnel Refresh | Desc. Length  |        Description ...        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Type                    26 (Vendor Specific)

        Length                  variable

        Organization ID         429 for US Robotics
                                430 for Bay Networks

        Indicator               0x900A (VPN-Gateway)

        Address Format          Contains a byte which represents the VPN
                                Gateway field's Address format. The
                                following values are currently supported:

                                VTP_ADDRESS_TYPE_IPV4           0x01
                                    The address contains a 32 bit IP

Calhoun et. al.                                                  [Page 56]


DRAFT                  Virtual Tunneling Protocol               July 1996


                                    version 4 address.

                                VTPADDRESS_TYPE_IPV6            0x02
                                    The address contains an IP Version 6
                                    address.

        VPN Gateway             Contains a 4 octet IP Address of the home
                                agent.

        Enc. Session Key        Contains a 16 octet value to be sent to
                                the home agent.

                                This string contains the encoded value of
                                the Session Key.

        Tunnel Refresh          Contains an optional Tunnel Refresh value
                                in seconds.

        Desc. Length            Contains the number of bytes of the
                                description string.

        Description             Contains an ASCII description of the
                                Home Agent (i.e. location information).

4.4.  Session Key Vector

   This attribute is returned by the remote Radius server in the
   Access-Accept packet. It must be present if the VPN Gateway attribute
   is present.  The NAS uses the session key vector attribute to determine
   the Session Key that it shares with the Frame Relay Gateway. The
   following packet extension will be returned:

   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    |        Organization ID        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Organization ID(cont.)     |          Indicator            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Indicator (cont.)        |     Encoded Session Key       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Encoded Session Key (cont.)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Encoded Session Key (cont.)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Encoded Session Key (cont.)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Encoded Session Key (cont.)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Calhoun et. al.                                                  [Page 57]


DRAFT                  Virtual Tunneling Protocol               July 1996


        Type                    26 (Vendor Specific)

        Length                  26

        Organization ID         429 for US Robotics
                                430 for Bay Networks

        Indicator               0x900B (Session Key Vector)

        Enc. Session Key        Contains a 16 octet vector, which contains
                                a four octet, encoded Session Key.


5.  Security Mechanism

   This section will detail the security mechanisms used by for the
   tunneling protocol.


5.1.  Data Authentication

   There exists a problem where a malicious user may spoof encapsulated
   packets to the mobile node proxy or home agent by adding the GRE
   header. In order to minimize this occurrence, it is desirable to add
   a header which contains a Message Integrity Check (MIC). The IP
   Authentication Header is used for this purpose in the following manner:

   +-----------------------------------------------------+
   | IP Header | Auth Header | GRE Header | User Payload |
   +-----------------------------------------------------+

   Note that the use of the data authentication header is optional and is
   outside of the scope of this document.


5.2.  Data Encryption

   In order to provide a true secure tunnel over an unsecure network, it
   is desirable to encrypt the user data. The ESP Header is used for
   this purpose in the following manner:

   +----------------------------------------------------+
   | IP Header | ESP Header | GRE Header | User Payload |
   +----------------------------------------------------+

   Note that the use of the data encryption header is optional and is
   outside of the scope of this document.


Calhoun et. al.                                                  [Page 58]


DRAFT                  Virtual Tunneling Protocol               July 1996


5.3.  Multi-Provider Tunnel Establishment Security

   In order to support multi-provider networks, it must be assumed that
   the NAS and the Gateway exist on different networks. In order to
   support such a scenario, it is required that tunnel establishment ONLY
   occur upon consent of the provider which owns the Gateway.  In this
   case, it is unlikely that both the mobile node proxy and the home agent
   share a common secret, therefore it is necessary for a third party
   server to perform the session key encryption.

                  Service Provider A  |  Service Provider B
                     +----------------+----------------+
                     |                |                |
                     +                |                +
                    /|         Public | Network        |\
                   / |                |                | \
                  /  |                |                |  \
                 /   |                |                |   \
   +------------/+   |                |                |   +\------------+
   |RADIUS Server|   ++---------------+---------------++   |RADIUS Server|
   |             |   /                |                \   |             |
   +------+------+  /                 |                 \  +------+------+
          |        /                  |                  \        |
          |       /                   |                   \       |
          |      /                    |                    \      |
          |     /                     |                     \     |
   +------+----/-+                    |                    +-\----+------+
   |     NAS     |                    |                    | VTP  Server |
   |             |                    |                    |             |
   +------+------+                    |                    +------+------+
          |                           |                           |
    ------+------                     |                     ------+------
          |                                                       |
   +------+------+                                         +------+------+
   |   Joe@ABC   |                                         |ABC's  Router|
   |             |                                         |             |
   +-------------+                                         +------+------+
                                                                  |
                                                                  |
                                                                  |
                                                      ---+--------+-------
                                                         |
                                                         |
                                                  +------+------+
                                                  |    Host     |
                                                  |             |
                                                  +-------------+

                      Figure 3: Multi-Provider Network
Calhoun et. al.                                                  [Page 59]


DRAFT                  Virtual Tunneling Protocol               July 1996


   Figure 3 depicts a scenario with multiple service providers. In this
   example, user Joe@ABC dials into a local service provider to connect to
   his company's corporate backbone. In this example, the home agent which
   serves the corporation is owned by a separate service provider. Note
   that in this example RADIUS is used, but the protocol is not limited to
   RADIUS.

   When the call is received by the NAS, an ACCESS_REQUEST is sent to the
   local RADIUS Server. The RADIUS Server then figures out that the
   authentication request must be forwarded to Service Provider B's RADIUS
   Server.

   If the Remote RADIUS Server successfully authenticates the user, then
   two attributes are attached to the ACCESS_ACCEPT. The server generates
   a random 16 octet value one which will be used as a temporary session
   key for that tunnel (which is only valid for the duration of the
   tunnel). The good formula for generating the random value is known as
   the linear congruential algorithm, where:

        Xn+1 = (A*Xn + C) (mod M), n>=0


        Where:
                Xn = See formula below.
                M  = 248
                A  = 2736731631558
                C  = 138
        And

                X0 = seed(25) 330E16

   Where the most significant 32 bits are set to the seed and the least
   significant 16 bits are set to the constant value. The X0 value is
   plugged into the above formula and the random value returned is in fact
   the first 32 bits of X1.

   The RADIUS Server then encrypts the Session Key using the RAD->RAD
   Shared Secret and adds it to the Session Key Vector Attribute
   (see 5.4). The actual encryption mechanism used is as follow:

        ( md5( CHAP Vector | RAD->RAD SS ) Å  Session Key )

   The Remote RADIUS Server then also encodes the same Session Key using
   the it's common shared secret with the gateway which it will return in
   the Frame Relay Gateway RADIUS attribute. The resulting hash will be
   added to the same attribute (see 7.2.4). The encryption mechanism is:

        ( md5( CHAP Vector | GW->RAD SS ) Å  Session Key )

Calhoun et. al.                                                  [Page 60]


DRAFT                  Virtual Tunneling Protocol               July 1996


   If the RADIUS Server is to return more than one Frame Relay Gateway
   attributes, the above encryption is done for each gateway, using the
   GW->RAD SS which is common between them. Note that the NAS will attempt
   to establish a tunnel with the IP address which is in the first Gateway
   attribute, and will try any other Gateways if more than one attribute
   was returned and the first Gateway did not respond.

   Once the Local RADIUS Server receives the packet, it will check for the
   Session Key Vector attribute. If one is found, knowing RAD->RAD SS, it
   will extract the Session Key from the attribute and re-encrypt the pair
   using the shared secret which is common between itself and the
   requesting NAS. The formula is as follow:

        ( md5( CHAP Vector | NS->RAD SS ) Å Session Key )

   Once the NAS receives the response, it will extract the Session Key
   from the attribute. When the Tunnel Registration Request is formed, the
   RADIUS Identification field and the encrypted session key must be
   inserted in the Registration Extensions of the Registration Request. At
   this point, the NAS will add a Mobile-Home Authentication Extension and
   use the unencrypted Session Key to do the following formula:

        ( md5( RR Packet | Session Key) )

        Where:

                RR Packet       The whole Tunnel Registration Request up
                                to the SPI field of the Mobile-Home
                                Authentication Extension.

   Upon receipt of the Tunnel Registration Request, the Frame Relay
   Gateway, knowing it's common shared secret with it's local RADIUS
   Server (in this case the RADIUS Server in provider B's network),
   extracts the Session Key. Using the Session Key, the Gateway will MD5
   the packet as shown above and ensure that the result is identical to
   the value which is included in the Mobile-Home Authentication
   Extension.

   Note that the Registration Request/Response each contained an SPI
   value in the Mobile-Home Authentication Extension. This value must be
   retained by each peer in order to send a subsequent message (i.e.
   Tunnel Refresh/Deregistration). This allows the use of multiple
   session keys per tunnel, and by using the SPI there is a method to
   inform the peer which session key was used for which message.

   There are two methods of doing this, one where the peers share a
   shared secret (pre-configured in some way), which is used in
   decrypting the shared secret. The alternative, yet more complex,

Calhoun et. al.                                                  [Page 61]


DRAFT                  Virtual Tunneling Protocol               July 1996


   requires an external Key Distribution Center to handle the distribution
   of keys. Due to the uniqueness of this protocol, the KDC required for
   this protocol does not fit with any existing key distribution scheme.
   This approach has the benefit of a much greater secure environment,
   which allows intra service provider tunnels. Note that in both cases,
   the session key generation is only valid for the duration of the
   tunnel. Section 9 covers the security mechanism in more detail.


Acknowledgements

   We would like to thank the following people for their help and support:
   Noor Kamruddin, Sumit Vakil, Peter Pappas, Pat Henkle, Kurtiss Johnson,
   Greg Linn, Nagaraj Arunkumar, Johnathan Zarkower, Wei Hioe, Art
   Muzaffar, Lionel Gibbons, Jun Lopez, Micheal Shapiro, Gary Malkin,
   Paul Raison, Tommy Kwan.

   We would also like to thank the following manufacturers for their
   support in the development of VTP: US Robotics Access Corp, Bay
   Networks Inc., ECI Telematics, 3Com Corp., Novell Corp.


References

[1] C. Huitema, "Routing in the Internet", Prentice Hall,  1995

[2] C. Hedrick, "Routing Information Protocol", RFC-1058, Rutgers
    University, June 1988

[3] C. Perkins, "IP Mobility Support", draft-ietf-mobileip-protocol-13.txt
    November 1995

[4] R. Atkinson, "Security Architecture for the Internet Protocol",
    RFC-1825, August 1995

[5] R. Atkinson, "IP Authentication Header",  RFC-1826, August 1995

[6] R. Atkinson, "IP Encapsulating Security Payload",  RFC-1827,
    August 1995

[7] P. Metzger, "IP Authentication using keyed MD5",  RFC-1828,
    August 1995

[8] P. Karn, "The ESP DES-CBC Transform",  RFC-1829, August 1995





Calhoun et. al.                                                  [Page 62]