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]