Internet Engineering Task Force P. Calhoun
INTERNET DRAFT 3Com
Mobile IP Working Group C. Perkins
Sun Microsystems
21 November 1997
Tunnel Establishment Protocol
draft-ietf-mobileip-calhoun-tep-00.txt
Status of This Memo
This document is a submission by the Mobile IP Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
to the mobile-ip@SmallWorks.COM mailing list.
Distribution of this memo is unlimited.
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (North
Europe), ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim),
ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
Abstract
A general tunnel establishment protocol (TEP) is defined to handle
multiprotocol tunneling as well as multilevel domains guarded by
tunnel agents which may be thought of as security gateways, or
alternatively as modified foreign agents as used with Mobile IP.
Mobile IP provides the model for TEP; the registration messages in
RFC 2002 establish a tunnel between the home agent and the foreign
agent. TEP extends Mobile IP's model for tunnel establishment to
allow multiple tunnel agents between the beginning and the end of the
tunnel, but assumes the same end-to-end trust model.
Calhoun, Perkins Expires 21 May 1998 [Page i]
Internet Draft Tunnel Establishment Protocol 21 November 1997
1. Introduction
Tunnels are needed for a variety of reasons in the Internet. Two
nodes may wish to communicate by using protocol data units (PDUs) for
protocols other than IP that are not easily routed over the Internet
infrastructure. Such PDUs can, however, be transmitted over the
Internet after encapsulation within IP. For remote access, one might
wish to set up a secure tunnel between a current point of attachment
and a enterprise network. Mobile IP (RFC 2002) [9] requires the
creation of a tunnel so that the home agent can transmit IP datagrams
to the care-of address of the mobile node. All of these separate
needs share a common need for tunnel establishment and management,
which can be fulfilled by enhancements of the tunnel establishment
procedures specified in RFC 2002 [9], and the tunnel management
procedures specified in RFC 2003 [7]. This document specifies those
enhancements.
Several previous documents have been drawn on for creating of
this document -- notably "Integrated Mobility Extension" [4],
"Hierarchical Foreign Agents" [6], "Virtual Tunneling Protocol
(VTP)" [1], and "Tunnel Set-up Protocol" [5].
1.1. Terminology
This document frequently uses the following terms:
binding An association between a mobile node's address and a the
IP address of a Tunnel Agent nearer to the mobile node.
home agent The tunnel agent which initially establishes a tunnel,
and which initially encapsulates datagrams to be sent to
the mobile node.
surrogate Agent A tunnel agent establishing a tunnel on behalf of
a mobile node which does not take any active role in the
establishment process.
Targeted Tunnel Agent
The ultimate intended recipient for a Tunnel
Establishment Request.
Tunnel Agent
An agent which can perform encapsulation and
decapsulation
Tunnel Requestor
Either a mobile node, or a surrogate agent acting on its
behalf.
Calhoun, Perkins Expires 21 May 1998 [Page 1]
Internet Draft Tunnel Establishment Protocol 21 November 1997
Mobile Node
The node on whose behalf the tunnel is established.
Notice that in this document, the term "mobile node" is used to help
understanding. There is no protocol dependence upon the fact that
the node is mobile, but we so far have not been very successful in
finding suitable terminology. The previous term we had used in this
document was "PDU receiver". Similarly, what was previously called
the "encapsulator" is now called a home agent. Finally, what was
previously called the "decapsulator" is now called the "foreign
agent", and is a tunnel agent capable of performing decapsulation on
behalf of a mobile node for PDUs received through the tunnel from the
home agent.
2. Overview of tunnel establishment
Mobile IP [9] allows the registration (on behalf of some target
node) of a tunnel endpoint with a remote encapsulating agent --
namely, in the case of mobile IP, a home agent. Almost all of the
Mobile IP registration procedure can be modeled as way to establish a
tunnel between the home agent and the foreign agent, on behalf of a
mobile node. The tunnel is then expected to be used for the specific
purposes required by Mobile IP.
In the Tunnel Establishment Protocol (TEP), the protocol methods used
by Mobile IP are modified to work between arbitrary nodes. When
a tunnel is established, the encapsulating agent (called the home
agent) then transmits PDUs to the tunnel endpoint (called the foreign
agent) according to the tunnel establishment parameters. Generally,
the tunnel establishment parameters will include a network address
of the node for which the the tunnel is being established, called
the mobile node. The foreign agent may then use any of a variety
of methods, not specified in this document, to further transmit the
decapsulated PDU so that it can be received by the mobile node.
If the mobile node is the same node as the foreign agent, then no
further network operations are needed to effect delivery of the PDU.
When the home agent obtains a PDU which needs to be transmitted to
the mobile node, the home agent consults a table to determine the
appropriate tunnel endpoint for that mobile node. In the case of
mobile IP, the table is indexed by the mobile node's IP address, and
the mobile node is the mobile node; this document specifies ways to
allow the table to be indexed by other network-layer addresses. Each
table entry will contain, besides the address of the tunnel endpoint,
other necessary tunnel parameters associated with the tunnel as part
of the tunnel establishment process. The act of creating or updating
the table entry which contains all of the parameters associated to
the tunnel is called tunnel establishment, or just establishment.
Calhoun, Perkins Expires 21 May 1998 [Page 2]
Internet Draft Tunnel Establishment Protocol 21 November 1997
The procedures in this document deal with the actions of three
separate network entities, as outlined above, called the home agent,
the foreign agent, and the mobile node. For simplicity, it is
assumed that all home agents can also perform decapsulation and vice
versa. A tunnel agent is thus a node that can perform the functions
of either the home agent or the foreign agent, and tunnels are said
to be established between two tunnel agents. The foreign agent and
mobile node may be the same node.
This document does not specify means by which a mobile node discovers
a suitable tunnel endpoint (foreign agent) which can be used for
the tunnel establishment. An example of one such method, by which
a mobile node (receiving IP data units) discovers a tunnel endpoint
called a care-of address, is specified as part of the Mobile IP
protocol. One method suitable for use with TEP is a straightforward
modification of the Mobile Service Extension to the ICMP Router
Discovery protocol [2], as specified in Mobile IP [9]. This
extension will soon be specified in a companion document.
This document assumes that each tunnel endpoint will be equipped
with an IP address. If the establishment completes successfully,
the foreign agent becomes one endpoint of a GRE tunnel [3]. The
other endpoint is the home agent. Once the tunnel is established,
it provides IP (network layer) connectivity between the two tunnel
agents. The tunnel appears to be a virtual point-to-point link, and
encapsulated PDUs traverse the tunnel as if it were a single link.
Tunnel establishment is transacted between the foreign agent and
the home agent by establishment messages transmitted on port 454.
These messages have new message type numbers so that they are
easily distinguished from existing mobile IP message types, but the
format of the new tunnel establishment messages is a straightforward
modification to the format of the existing messages, and is analogous
to the Regional Registration messages defined earlier in the
Hierarchical Foreign Agents proposal [6]. The tunnel establishment
messages accept new extensions, which are defined in this document.
Tunnel establishment requires authentication. The tunnel
establishment messages use the same Authentication extensions defined
by the base mobile IP specification [9]. Even though the tunnel
establishment message is transmitted by the foreign agent to the home
agent, the authentication often relies on a security association
between the mobile node and the home agent. This security
association between receiver and home agent may require additional
security mechanisms such as encryption which are not part of the
tunnel establishment, but which affect the format of the encapsulated
datagrams which flow through the tunnel. Intermediate nodes which
are involved with the tunnel establishment may additionally impose
their own authentication and privacy requirements. Such nodes
Calhoun, Perkins Expires 21 May 1998 [Page 3]
Internet Draft Tunnel Establishment Protocol 21 November 1997
follow the dictates of their security associations with the other
nodes that they communicate with in the course of managing the
established tunnel, but the security associations or the use of them
are established by policy which is external to TEP.
A requesting foreign agent MAY use procedures which are not specified
in this document to obtain all tunnel establishment parameters,
including authentication information for the mobile node, for use
in the Tunnel Establishment Request message. Alternatively, the
mobile node MAY (as is the case with mobile IP) transmit a Tunnel
Establishment Request message to a prospective tunnel endpoint to
enable that node to transact a tunnel establishment with some home
agent.
TEP specifies that the decapsulating node issue the Tunnel
Establishment Request message on behalf of the mobile node. This
MAY happen as a result of protocol operations transacted between the
foreign agent and the mobile node. The decapsulating tunnel agent
could, on the other hand, be configured by any convenient means to
have all the necessary tunnel establishment parameters needed to
issue a request message on behalf of the mobile node. TEP makes no
restriction on the methods by which the foreign agent discovers the
establishment parameters.
Note that in some cases it would be beneficial to enable a sender of
the PDUs to establish the tunnel on behalf of the receiver. While
TEP is likely to solve that problem, the exact operation of the
protocol is not yet specified in that case.
Calhoun, Perkins Expires 21 May 1998 [Page 4]
Internet Draft Tunnel Establishment Protocol 21 November 1997
2.1. Example hierachy
+---------------+
| |
| H A |
| |
+---------------+
|
|
|
/ \
/ \
/ \
/ -----------\
/ \
/ \
+---------------+ +---------------+
| | | |
| F A | | F A |
| | | |
+---------------+ +---------------+
|
|
|
/ \
/ \
/ \
/ --------\
/ \
/ \
+---------------+ +---------------+
| | | |
| F A | | F A |
| | | |
+---------------+ +---------------+
|
|
|
|
+---------------+
| |
| M N |
| |
Calhoun, Perkins Expires 21 May 1998 [Page 5]
Internet Draft Tunnel Establishment Protocol 21 November 1997
+---------------+
This example shows a two-level hierarchy of foreign agents
(decapsulating agents) between the mobile node and its home agent.
Although TEP is general enough for many more levels of hierarchy, it
is likely that two levels of hierarchy will satisfy the needs of many
network administrators.
3. Regionalized Tunnel Management
TEP is designed to allow establishment of tunnels suitable for
transmission of PDUs through multiple levels of security regions,
in the same manner indicated for use with Hierarchical Foreign
Agents [6]. Each security region is assumed to be accessible (from
either the inside or the outside) by a tunnel agent, which is perhaps
made known as part of an extension to Router Advertisements in
the region. Further discussion of such advertisements is outside
the scope of this specification, but some points are developed in
appendix A.
One approach to this problem is to allow Tunnel Establishment
Requests to be sent to a regional tunnel agent that tracks the mobile
node's regional movements but does not forward each establishment
Request all the way back to the home agent. If the regional tunnel
agent is the tunnel endpoint for PDUs encapsulated by the home
agent, then the regional tunnel agent can make further arrangements
for delivery of the PDU. In this document, we further enhance this
regional handling by effectively allowing subregions of regions and
so on, and structuring the foreign agents which manage each region in
a hierarchy.
As each new Tunnel Establishment Request travels up the hierarchy,
it includes all the tunnel agent addresses up to and including the
Targeted Tunnel Agent. Put briefly, the Target Tunnel Agent address
is that of the nearest "regional foreign agent" that has previously
established a tunnel on behalf of the mobile node.
Conceptually, the mobile node, or a foreign agent acting on its
behalf, attempts to minimize the amount of tracking required to
maintain its traffic flow. This amounts to identifying the smallest
region for which the mobile node has not travesed any regional
boundary. That amounts to finding the closest ancestor to the
foreign agent matching the first tunnel agent in the hierarchy, which
was also an ancestor of the mobile node when a tunnel was established
for it. The mobile node may do this as outlined below.
Calhoun, Perkins Expires 21 May 1998 [Page 6]
Internet Draft Tunnel Establishment Protocol 21 November 1997
All of these considerations are equally true a decapsulating agent is
initiating tunnel establishment operations on behalf of the mobile
node. The protocol by which the decapsulating agent discovers the
need for the tunnel establishment also needs to take into account the
discovery of the previous hierarchy serving the mobile node in order
for the regionalization operations to be effective.
The foreign agent nearest the mobile node is the first foreign agent
to find out that a tunnel establishment is needed. This foreign
agent relays the Tunnel Establishment Request to next-higher level of
the hierarchy and thus along towards the target of the Registration
Request, just as if the target foreign agent (call it the targeted
tunnel agent) were the home agent. If the targeted tunnel agent (or
the home agent) receives Tunnel Establishment Request, it returns a
Tunnel Establishment Reply.
The processing of the Tunnel Establishment Request and Registration
Reply requires further refinement compared to the registration
processing in the base mobile-IP specification. When a tunnel agent
receives the Request from the mobile node, it must pass the Request
along to its next nearest ancestor in the hierarchy along the way
to the agent listed as the home agent. In this way, each foreign
agent in the hierarchy between the mobile node and the home agent
will be able to maintain a binding for the mobile node. Similarly,
Tunnel Establishment Replies are passed down from one level of the
hierarchy to the next along the way to the mobile node, so that each
foreign agent can determine the status of the corresponding Tunnel
Establishment Request and create the appropriate binding for the
mobile node. Note that each foreign agent's binding will be for the
tunnel agent's address at the next lower level of the hierarchy.
3.1. Security
Note that home agent can be considered a "universal root" for
all such hierarchies of foreign agents as described above. In
fact, the home agent's address is an ancestor of every other agent
address, and the mobile node is guaranteed of never straying from the
boundaries of the "region" defined by the home agent's agent address.
There is a clear threat to the mobile node posed by illicit Tunnel
Establishment Requests, and thus the same need for authenticating
each Tunnel Establishment Request. The mobile node and the home
agent currently share keys which are configured by means outside the
scope of the TEP protocol specification. The problem is analogous to
the requirement in the Route Optimization [8] protocol specification,
for a mobile node's current foreign agent to obtain a session key
with the mobile node for as long as the mobile node is known to the
decapsulating agent.
Calhoun, Perkins Expires 21 May 1998 [Page 7]
Internet Draft Tunnel Establishment Protocol 21 November 1997
As outlined in this document, when a mobile node registers with
its home agent, it sends a Tunnel Establishment Request to all the
foreign agents in the hierarchy between the home agent and the mobile
node. When the top-level tunnel agent address is provided to its
home agent, the mobile node acquires a session key, (say, using one
of the extensions specified for Route Optimization [8]). Suppose
that each foreign agent in the hierarchy shares the same session key
that the home agent sent to the foreign agent at the top level of the
hierarchy.
Any modification to the tunnel establishment parameters (by or on
behalf of the mobile node) may require re-establishment of the
tunnel with some (or all) of the foreign agents in the hierarchy.
Changing the receivers point of attachment can, however, often be
handled without causing any change to the home agent's binding for
the mobile node. Since each foreign agent between the mobile node's
previous agent address and the home agent shares the same session
key, when the mobile re-registers an intermediate agent address with
an unchanged agent address immediately above it in the hierarchy, the
mobile node already shares a session key with the agent address which
didn't change. To effect the reattachment, then, the mobile node
just has to send the session key along with its establishment through
the changed parts of the hierarchy, until the re-establishment occurs
at the lowest-level agent address which has not changed and which is
handled by a foreign agent which shares the same session key with the
mobile node.
Since each Tunnel Establishment Request is passed to every foreign
agent between the mobile node and the "closest" foreign agent that
didn't change, when the Tunnel Establishment Reply comes back, the
targeted tunnel agent processing the Request can encode the session
key for each new foreign agent which will handle the Reply.
3.2. Forwarding Datagrams to the mobile node
At each level of the hierarchy, the tunnel agent at that level has a
binding for the mobile node. The mobile node's binding shows that
it is served by the tunnel agent at the next lower level of the
hierarchy.
Thus, a PDU arriving at the top of the hierarchy from the home agent
will (figuratively speaking) be decapsulated and re-encapsulated with
a new tunnel endpoint, viz. the tunnel agent at the next lower level
of the hierarchy. This decapsulation and re-encapsulation occurs at
each level of the hierarchy, until the PDU reaches the last foreign
agent which is either the mobile node itself (in case of a co-located
agent address) or a foreign agent that can deliver the decapsulated
PDU to the mobile node with no further TEP handling.
Calhoun, Perkins Expires 21 May 1998 [Page 8]
Internet Draft Tunnel Establishment Protocol 21 November 1997
Note that the actual decapsulation need not occur at each step of
the hierarchy. Instead, the foreign agent at that level can merely
change the source and destination IP addresses of the encapsulating
IP header.
4. Tunnel Establishment Request
A Tunnel Establishment Request message is sent to all of the
hierarchical tunnel agents between the mobile node and its home
agent.
Each tunnel agent receiving the Request relays it to the next
higher-level agent address in the hierarchy. For each pending Tunnel
Establishment Request, in addition to the information stored for the
processing of Tunnel Establishment Requests as required by the base
specification, each foreign agent stores the agent address of the
next-lower foreign agent in the hierarchy. This address is available
in the Request message, as shown below.
The UDP fields also are the same as in the base draft specification.
IP fields:
Source Address Typically the interface address from which
the message is sent.
Destination Address Typically that of the tunnel agent at the
next higher level of the hierarchy of tunnel
agents.
The UDP header is followed by the fields shown below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |G| rsv | count | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Targeted Tunnel Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Agent Addresses ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
Calhoun, Perkins Expires 21 May 1998 [Page 9]
Internet Draft Tunnel Establishment Protocol 21 November 1997
+-+-+-+-+-+-+-+-
All fields not listed here are defined just as in the base mobile-IP
document.
Type 8 (Tunnel Establishment Request)
G The requester expects to receive PDUs tunneled
using GRE [3].
rsv sent as zero, ignored on reception
count The number of Agent Addresses included in the
message, not including the Targeted Tunnel
Agent.
Lifetime The number of seconds before the Tunnel
Establishment must be considered expired by
all tunnel agents receiving the Establishment
message.
Targeted Tunnel Agent The IP address of the targeted tunnel agent,
which is the lowest-level tunnel agent which is
present in the mobile node's current hierarchy
of decapsulating agents.
Tunnel Agents The tunnel agents serving the mobile node for
which the tunnel is to be established.
Extensions The fixed portion of the Tunnel Establishment
Request is followed by one or more Extensions
which are applicable to Tunnel Establishment
Requests.
Unless otherwise specified by the 'G' bit, the requestor expects to
receive PDUs encapsulated within an IP header. When the 'G' bit is
set, the PDU is to be encapsulated within GRE, which can further be
encapsulated within IP.
TODO: specify encapsulation with PPTP... L2TP?
The Tunnel Establishment Request MUST include an authentication
extension appropriate to the targeted tunnel agent. The format of
the authentication extension is identical to one of the extensions
defined in the base Mobile IP specification, either a Mobile-Home
Authentication Extension, or a Mobile-Foreign Authentication
Extension. In the case of the Mobile-Foreign Authentication
Extension the mobile node MAY use the SPI and Mobility Security
Association set up when it obtained a session key (say, using Route
Optimization extension numbers 104 and 105 [8]), from a previous
Tunnel Parameters Extension it transacted with its home agent and all
Calinterveninghforeignoagentsuatnthat,time.Perkins Expires 21 May
1998 [Page 10]
Internet Draft Tunnel Establishment Protocol 21 November 1997
The same rules apply to the Tunnel Establishment Request as apply to
the Mobile IP Registration Request, regarding the relative order in
which different extensions, when present, MUST be placed in a the
establishment message.
Each foreign agent which receives a Tunnel Establishment Request
compares its IP address to the target tunnel agent listed in the
request. If they are the same, the foreign agent determines whether
or not to accept the request, and returns a Tunnel Establishment
Reply with the appropriate status code, as specified in 5.
Otherwise, the foreign agent delivers the Tunnel Establishment
Request to the next-higher agent in the hierarchy. The session-key
extension selected by the mobile node is processed appropriately at
each level of the hierarchy, if necessary. All foreign agents in the
hierarchy between the mobile node and the home agents can share the
same session key.
Each foreign agent MUST check to make sure that its address is
included in the list of tunnel agent addresses within the Request.
If not, it rejects the request with status code 70.
Otherwise, the foreign agent makes note of the address of the next
lower-level tunnel agent, for future association with the mobile
node's network address.
5. Tunnel Establishment Reply
A tunnel agent returns a Tunnel Establishment Reply message to a
tunnel requestor which has sent a Tunnel Establishment Request
(Section 4) message, and to the foreign agent at each intermediate
level of the hierarchy between itself and the tunnel requestor. Each
foreign agent above the mobile node in the hierarchy will receive
the Tunnel Establishment Reply from the tunnel agent at the next
higher level of the hierarchy. The Tunnel Establishment Reply
message contains the necessary codes to inform the tunnel requestor
about the status of its Request, along with the lifetime granted by
the targeted agent, which MUST NOT be great enough to last longer
than time at which the binding at the home agent would expire, as
determined by the original lifetime granted by the mobile node's
home agent in the last Tunnel Establishment Request (or Tunnel
Establishment Request) approved by the home agent.
When the foreign agent receives a successful Tunnel Establishment
Reply, it updates its binding for the mobile node, using the
next-lower tunnel agent in the hierarchy as the foreign agent for the
mobile node.
Calhoun, Perkins Expires 21 May 1998 [Page 11]
Internet Draft Tunnel Establishment Protocol 21 November 1997
The foreign agent MUST NOT modify the Lifetime selected by the mobile
node in the Tunnel Establishment Request, since the Lifetime is
covered by an Authentication Extension. The targeted tunnel agent
MUST NOT increase the Lifetime selected by the mobile node in the
Tunnel Establishment Request, since doing so could increase it beyond
the maximum Registration Lifetime allowed by the foreign agent. If
the Lifetime received in the Tunnel Establishment Reply is greater
than that in the Tunnel Establishment Request, the Lifetime in the
Request MUST be used. When the Lifetime received in the Tunnel
Establishment Reply is less than that in the Tunnel Establishment
Request, the Lifetime in the Reply MUST be used.
The network address of the mobile node MUST be specified
in an extension to the Tunnel Establishment Reply. Unless
specifically superseded in this document, all processing of Tunnel
Establishment Replies by tunnel agents is specified to be the same
as the processing by tunnel agents in the base mobile-IP draft
specification [9]. This includes determining the validity of the
Tunnel Establishment Request, and selecting the appropriate status
code (from among those listed below) for the reply. The IP fields
and UDP fields are chosen just as with the Registration Reply message
in the base mobile-IP specification.
The UDP header is followed by the fields shown below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Home Agent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
Calhoun, Perkins Expires 21 May 1998 [Page 12]
Internet Draft Tunnel Establishment Protocol 21 November 1997
+-+-+-+-+-+-+-+-
Type 9 (Tunnel Establishment Reply)
Code A value indicating the result of the Tunnel
Establishment Request. See below for a list of
currently defined Code values.
Home Agent The IP address of the mobile node's home agent.
Identification A 64-bit number used for matching Tunnel
Establishment Requests with Registration Replies,
and for protecting against replay attacks of
establishment messages. The value is based
on the Identification field from the Tunnel
Establishment Request message from the mobile
node, and on the style of replay protection used
in the security context between the mobile node
and its home agent (defined by the mobility
security association between them, and SPI value
in the Mobile-Home Authentication Extension).
See Section 6.
Extensions The fixed portion of the Tunnel Establishment
Reply is followed by one or more Extensions. An
authentication extension MUST be included in all
Establishment Replies returned by the tunnel
agent.
The following values are available for use within the Code field.
Establishment successful:
0 establishment accepted
Establishment rejected:
64 reason unspecified
65 administratively prohibited
66 insufficient resources
67 mobile node failed authentication
68 tunnel agent failed authentication
69 requested Lifetime too long
70 poorly formed Request
71 poorly formed Reply
72 requested encapsulation unavailable
80 network unreachable (ICMP error received)
81 tunnel agent host unreachable (ICMP error received)
82 tunnel agent port unreachable (ICMP error received)
88 tunnel agent unreachable (other ICMP error received)
133 Identification mismatch
136 unknown tunnel agent address
CalUp-to-datehvaluesoofuthenCode,fieldPareespecifiedrinktheimostnrecents
Expires 21 May 1998 [Page 13]
"Assigned Numbers" [10].
Internet Draft Tunnel Establishment Protocol 21 November 1997
Each foreign agent receiving a successful Tunnel Establishment Reply
from the foreign agent immediately above it in the foreign agent
hierarchy MUST replace any Identification stored and associated with
the mobile node, with the fresh Identification in the received Reply
message.
6. Replay Protection
The Identification field is used to let the targeted tunnel agent
verify that a establishment message has been freshly generated by
the mobile node, not replayed by an attacker from some previous
establishment. All mobile nodes and tunnel agents using Tunnel
Establishment messages MUST implement timestamp-based replay
protection.
The style of replay protection in effect between a mobile node and
its tunnel agents is part of the mobile security association. A
mobile node and its tunnel agent MUST agree on which method of replay
protection will be used. The interpretation of the Identification
field depends on the method of replay protection as described in the
subsequent subsections.
Replay protection must be provided by mobile nodes using the
timestamp procedures specified in this document. The Identification
in a new Tunnel Establishment Request MUST NOT be the same as in an
immediately preceding Request, and SHOULD NOT repeat while the same
security context is being used between the mobile node and the home
agent. Retransmission as in the base mobile-IP specification [9] is
allowed.
7. Tunnel Parameters Extension
This specification defines the Tunnel Parameters Extension, which
is found in Tunnel Registration Request and Reply messages. This
extension is denoted by the value of 128 in the extension field.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Addr Family | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
Calhoun, Perkins Expires 21 May 1998 [Page 14]
Internet Draft Tunnel Establishment Protocol 21 November 1997
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
is encoded in the following Type-Length-Value format:
Type Indicates the particular type of Extension.
Length Indicates the length (in octets) of the data field within
this Extension. The length does NOT include the Type and
Length octets.
reserved sent as zero, ignored on reception
Addr Family The Addr Family indicates which network layer protocol
address is included in the Data field, and thus the
particular type of tunnel to be registered with the home
agent.
Data Data in the particular format, specified in subsequent
sections, needed for the establishment of tunnel
appropriate for the Addr Family.
Each Addr Family defines a protocol and address format. The values
for the Addr Family are compatible with those defined by GRE [3].
The contents of the Data field depend on the particular network
layer. For each value of the Addr Family, the format of the Data
field is to be outlined in a subsequent Section.
Current values for the tunnel type are as follows:
Message Type Abbreviation Function Value
Calhoun, Perkins Expires 21 May 1998 [Page 15]
Internet Draft Tunnel Establishment Protocol 21 November 1997
7.1. IPX (Addr Family 11)
An IPX address is either 6 or 10 octets. If the target is an IPX
host, the extension MUST supply its 6 octet IEEE 802 address. If the
target is an IPX router, the extension MUST supply both its network
number and node number (its IEEE 802 address). This extension is
OPTIONAL and must be present only if the client being registered
supports IPX. This extension may be sent to register a new client
on an existing tunnel even if the initial tunnel establishment
request did not register IPX support. This extension can be repeated
multiple times in the case that several IPX addresses are to be
registered. In this case, a conventional router or dial-up router is
serving multiple IPX addresses in the remote LAN. The format of the
extension is:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Length |1| reserved | IPX Network Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPX Network Number (cont.) | IPX Node Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPX Node Number (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sub-Length 12 (the length of the Data field)
Flag Bit 1 MUST be set
reserved MUST be zero
IPX Network This field contains the IPX Network number of
the remote client (as negotiated by IPXCP for a
dial-up user).
IPX Node Number This field contains the IPX Node number of the
remote client.
It is possible to enable a routing protocol over an existing tunnel
only if one was not already negotiated. It is not possible to
disable such a protocol.
Calhoun, Perkins Expires 21 May 1998 [Page 16]
Internet Draft Tunnel Establishment Protocol 21 November 1997
The following routing protocols may be used over the tunnel by
setting the indicated values into the Interface Flags field:
IPX_RIP 0x0001
NLSP 0x0002
IPXWAN_2 0x0004
7.2. AppleTalk Address Extension
An AppleTalk address is three octets. If the target does not yet
have an AppleTalk address, the tunnel endpoint should use the address
0.0 (three octets of all zeros).
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Length |M|Z| reserved | Appletalk Network |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node number | Zone |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sub-Length 5 or 7 (the length of the Data field)
M Mandatory
Z If set, the Zone field is present
Appletalk Network Two octets for the Appletalk network number
Node number One octet for the Appletalk node number
Zone If present, an unsigned integer indicating
the Zone in which the Appletalk Address is
located.
7.3. Vines Address Extension
A Vines address is either 6 or 10 octets. If the target is a Vines
host, it MUST supply its 6 octet Vines address (normally an IEEE 802
address). If the target is a Vines router, it MUST supply both its
Vines address and the subnet number.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Length |1| reserved | Vines Node Number ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Calhoun, Perkins Expires 21 May 1998 [Page 17]
Internet Draft Tunnel Establishment Protocol 21 November
1997
| ... Vines Node Number, continued. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vines subnet Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sub-Length 12 (the length of the Data field)
Flag Bit 1 MUST be set
reserved MUST be zero
Vines Node Number This field contains the Vines Node number of the remote
client.
Vines Network This field contains the Vines Network number of the remote
client.
7.4. CLNP Address Extension
CLNP uses NSAPs as its addresses, which are of variable length.
If
the target knows its NET (NSAP with an NSEL of 0), it MUST
include
its NET in the extension. Targets which do not know their NET
may
specify a zero length address.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Length |1| reserved | NSAP ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sub-Length 12 (the length of the Data field)
Flag Bit 1 MUST be set
reserved MUST be zero
NSAP Network address for use by NSAP
7.5. Example
A Mobile Node which desired IPX connectivity in addition to IP
connectivity would include an extension of the form:
0x80 0x06 0x81 0x37 0x00 0x00 0x0c 0x01 0x0e 0x36 0x00 0x00
Calhoun, Perkins Expires 21 May 1998 [Page
18]
Internet Draft Tunnel Establishment Protocol 21 November 1997
This indicates an extension of 128 [0x80] (Tunnel Establishment), a
data length of 6 octets, a network layer protocol value of 0x8137
(IPX), and an IEEE 802 address of 00:00:0c:01:03:36. The final two
octets of 0x00 are sent so that the extension terminates on a four-
octet boundary, in accordance with the IP Mobility RFC.
8. Mobile Node Considerations
The tunnel requestor MUST also include the Tunnel Parameters
extension one or more times. Only one such extension MAY be included
per additional network layer protocol. Note that a tunnel requestor
may change which address families are to be used by establishing a
tunnel with different Address Family fields in its establishment
packets.
If the mobile node receives a successful Reply message containing an
Tunnel Establishment extension, the mobile node should immediately
establish a GRE tunnel with the home agent as the other endpoint of
the tunnel. Then, all data packets at the mobile node with a next
hop of the home agent will be tunneled to the home agent using GRE
over IP as the transport mechanism. This includes IP packets. Once
the packet reaches the home agent, the outer header (IP) and GRE
header are stripped and the packet is submitted for local processing,
as appropriate for the particular network layer protocol.
9. Foreign Agent Considerations
The foreign agent MUST copy the Tunnel Establishment extension from
the Mobile Request to the Establishment Request without modifying it
in any way. The foreign agent MUST NOT reject a Mobile Request due
to the presence or contents of any well formed Tunnel Establishment
extension.
10. Home Agent Considerations
The home agent MAY reject an Establishment Request based on the
contents of an Tunnel Establishment extension. If the home agent
accepts a Establishment Request with an Tunnel Establishment
extension, it MUST provide connectivity to the mobile node for
the network layer protocol described in the Tunnel Establishment
extension. Further, the Tunnel Establishment extensions MUST be
copied into the Reply message.
Calhoun, Perkins Expires 21 May 1998 [Page 19]
Internet Draft Tunnel Establishment Protocol 21 November 1997
If the home agent accepts a Establishment Request with an Integrated
Mobility extension, the request MUST also have a Local Care-Of
Address extension. The home agent MUST use the Local Care-Of Address
as the tunnel endpoint and MUST establish a GRE tunnel to the Local
Care-Of Address.
Once the GRE tunnel is established, a PDU arriving at the home agent
for the mobile node will be tunneled to the receiver using GRE over
IP as the transport mechanism. Note that this includes IP packets.
Once the packet reaches the mobile node, the outer header (IP)
and GRE header are stripped and the packet is submitted for local
processing, as appropriate for the particular network layer protocol.
11. Security
Tunnel establishment follows the design philosophy of the
Mobile IP specification to provide accceptable authentication
of the establishment process. This document does not discuss
confidentiality of user data.
Note that tunnel establishment often has the effect of controlling
and possibly redirecting data streams to new points of attachment for
the mobile node. Thus, failure to provide sufficient authentication
of Tunnel Registration Request messages can have the effect of
allowing malicious disruption of traffic which is supposed to be
received by the mobile node. Even failure to properly authenticate
Tunnel Registration Reply messages could have the effect of masking
control or data errors in the establishment process.
12. Acknowledgements
Calhoun, Perkins Expires 21 May 1998 [Page 20]
Internet Draft Tunnel Establishment Protocol 21 November 1997
A. Hierarchical Tunnel Agent advertisement
Since an extension to Router Advertisements could contain multiple
tunnel agent addresses, a natural implementation of the hierarchy
presents itself. Each foreign agent simply includes its ancestors in
the tree of regional foreign agents in the list of agent addresses
in the Agent Advertisement. In order to maintain compatibility with
mobile nodes that do not implement any processing for the foreign
agent hierarchy, each foreign agent must advertise its own agent
address first in the list.
References
[1] Pat R. Calhoun and Ellis Won. Virtual Tunneling Protocol
(VTP). draft-calhoun-vtp-protocol-00.txt, July 1996. (work in
progress).
[2] Stephen E. Deering, Editor. ICMP Router Discovery Messages.
RFC 1256, September 1991.
[3] Stan Hanks, Tony Li, Dino Farinacci, and Paul Traina. Generic
Routing Encapsulation (GRE). RFC 1701, October 1994.
[4] T. Li and Y. Rekhter. Integrated Mobility Extension.
draft-ietf-mobileip-integrated-00.txt, March 1994. (work in
progress).
[5] G. Montenegro. Tunnel Set-up Protocol (TSP).
draft-montenegro-tsp-00.txt,
August 1997. (work in progress).
[6] C. Perkins. Mobile-IP Local Registration with Hierarchical
Foreign Agents. draft-perkins-mobileip-hierfa-00.txt, February
1996. (work in progress).
[7] Charles Perkins. IP Encapsulation within IP. RFC 2003, May
1996.
[8] Charles E. Perkins and David B. Johnson. Route Optimization in
Mobile-IP. draft-ietf-mobileip-optim-07.txt, November 1997.
(work in progress).
[9] C. Perkins, Editor. IP Mobility Support. RFC 2002, October
1996.
[10] Joyce K. Reynolds and Jon Postel. Assigned Numbers. RFC 1700,
October 1994.
Calhoun, Perkins Expires 21 May 1998 [Page 21]
Internet Draft Tunnel Establishment Protocol 21 November 1997
Chairs' Addresses
The working group can be contacted via the current chairs:
Jim Solomon
Motorola, Inc.
1301 E. Algonquin Road
Schaumburg, IL 60196
USA
Phone: +1-847-576-2753
E-mail: solomon@comm.mot.com
Erik Nordmark
Sun Microsystems, Inc.
901 San Antonio Road
Palo Alto, California 94303
USA
Phone: +1 650 786-5166
Fax: +1 650 786-5896
E-mail: nordmark@sun.com
Author's Address
Questions about this memo can be directed to:
Pat Calhoun Charles E. Perkins
Routing Consulting Engineering Technology Development
3com Sun Microcomputer Company
Mount Prospect, IL 60056 901 San Antonio Rd.
Palo Alto, California 94303
Phone: 1-847-342-6898 1-415-786-6464
Fax: 1-847-342-6785 1-415-786-6445
E-mail: pcalhoun@usr.com charles.perkins@Sun.COM
Calhoun, Perkins Expires 21 May 1998 [Page 22]
