Internet Engineering Task Force G. Montenegro
INTERNET DRAFT Sun Microsystems, Inc.
August 25, 1997
Tunnel Set-up Protocol (TSP)
draft-montenegro-tsp-00.txt
Status of This Memo
This document is a submission to the Mobile IP Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
either to the author, or to the mobile-ip@SmallWorks.COM mailing
list.
Distribution of this memo is unlimited.
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet- Drafts as
reference material or to cite them other than as ``work in
progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
Remote access over the internet and IP mobility are currently being
addressed as two separate problems. The L2TP specification is
defining a protocol, or rather a tunnel control mechanism to solve
the remote access problem. On the other hand, the Mobile IP working
group has been solving the mobility problem. Nevertheless, the same
solution applies to both problems, namely, tunneling.
This document defines a Tunnel Set-up Protocol (TSP) that solves
both problems using a common approach. TSP is heavily based on the
control messages defined by Mobile IP.
Montenegro Expires February 25, 1998 [Page 1]
INTERNET DRAFT Tunnel Set-up Protocol (TSP) August 1997
Table of Contents
1. Introduction ................................................... 3
1.1. Motivation ................................................ 3
1.2. Terminology ............................................... 4
1.3. Related Work .............................................. 4
1.4. Design Goals .............................................. 5
2. Overview ....................................................... 6
2.1. Base Mobile IP ............................................ 6
2.2. Chained Registrations ..................................... 6
2.3. Surrogate Registrations ................................... 7
3. Dynamic Home Address Discovery ................................. 8
3.1. Registering over the Internet ............................. 8
3.2. Registering within the Corporation ........................ 8
4. New Packet Formats ............................................. 8
4.1. Mobile Node Identifier Extension .......................... 8
4.2. "Invalid Home Address" Error Code ......................... 10
5. Protocol Behavior .............................................. 10
6. Data Transfer: Tunneling Modes ................................. 11
7. Example Scenarios .............................................. 11
7.1 TSP as a Mobile Remote Access Solution ..................... 11
7.2 Registering Without a Permanent Home Address ............... 13
8. Security Considerations ........................................ 16
References ........................................................ 16
Author and Chair Addresses ........................................ 18
Montenegro Expires February 25, 1998 [Page 2]
INTERNET DRAFT Tunnel Set-up Protocol (TSP) August 1997
1. Introduction
1.1. Motivation
The Mobile IP protocol has great provisions for dynamic tunnel set
up to effect Layer 3 forwarding (IP packet forwarding). The purpose
is to dynamically and securely set up an IP packet forwarder (the
"home agent" functionality) toward a current point of attachment
(the "care-of address") of a roaming system.
Notice that if the packet forwarder happens to be the home agent of
the device, then we are dealing with Mobile IP. However, there are
very good reasons to use the same protocol to establish a packet
forwarder at, for example, the border of a private net. This allows
a remote device to appear to be within the confines of the private
network, albeit at its periphery. Doing so, and using IP security to
authenticate and encrypt the data traffic, presents a homogeneous
and simple solution to two fundamental problems in the internet:
- mobility
- secure remote access over the internet.
Another characteristic of Mobile IP that plays perfectly in the
remote access arena is the foreign agent. Many service providers
need exactly this as a point of control for billing purposes.
However, there are certain limitations that must be addressed in
order to achieve a homogeneous solution to the problems listed
above.
Current Mobile IP lacks flexibility in how registrations are
accomplished in that it assumes that the endpoints of the tunnel are
mutually trusting entities that are able to and willing to exchange
registration protocol packets.
Furthermore, it assumes that the mobile node creates the
Registration Request. TSP addresses these issues by allowing the
creation of compound tunnels. TSP recognizes that in addition to
tunnel endpoints, there may be tunnel intermediate points.
Registrations are exchanged only between intermediate points. The
result is a composite tunnel with some very desireable security and
scalability characteristics:
- Different security domains interface at an intermediate point,
which provides a clean separation between segments.
Montenegro Expires February 25, 1998 [Page 3]
INTERNET DRAFT Tunnel Set-up Protocol (TSP) August 1997
- Movement beyond a certain intermediate point only implies
re-registrations from that point onward.
1.2. Terminology
This discussion uses terms defined by Mobile IP [Perkins96a].
Additionally, it uses the following terms:
Chained Registration
A registration in which the home agent and the mobile node do
not directly exchange a Registration Request and Reply.
Rather, the request/reply is carried out between endoints of
tunnel segments. The composition of tunnel segments represents
the compound tunnel from home agent to mobile node.
Surrogate Registrations
These are registrations that are not created by the mobile
node. Rather, they are created on its behalf by another entity
(a foreign agent). This is not a new concept and is in use in
commercial implementations. Nevertheless, with its
introduction of chained registrations and compound tunnels,
this document allows for registrations that neither originate
at the mobile node (i.e. they are surrogate registrations),
nor do they terminate at the home agent (i.e. they terminate
at an intermediate point at least one tunnel away from the
home agent).
Upstream Agent
The endpoint of a tunnel segment that is closest to the home
agent. The last upstream agent is the home agent itself.
Downstream Agent
The endpoint of a tunnel segment that is closest to the mobile
node. The last downstream agent is the mobile node itself.
1.3. Related Work
VTP (Virtual Tunneling Protocol) [Calhoun96] also uses Mobile IP as
a basis for a tunnel set-up protocol. The registrations composed
by VTP's "proxy mobile nodes" are essentially surrogate
registrations.
Montenegro Expires February 25, 1998 [Page 4]
INTERNET DRAFT Tunnel Set-up Protocol (TSP) August 1997
Chained registrations add the flexibility that the registration
request need not end at the home agent, but at an intermediate
system (an upstream agent).
There has been some work on enabling secure mobile remote access
using SKIP [MoGu97]. Subsequently, the Mobile IP Working Group is
extending these efforts and defining a solution based on
ISAKMP/OAKLEY [GuGl97a, GuGl97b]. However, these documents still
assume that the mobile node and the home agent exchange Registration
Protocol packets directly. True, they may tunnel or relay them
through participating firewalls, but the latter are merely IP
Security aware devices, unaware of Mobile IP. TSP allows for
firewalls to be Mobile IP aware so they can serve as endpoints of
tunnel segments.
However, TSP does not require the use compound tunnels, as this is a
policy issue. When they are not required, secure remote mobile
access may be accomplished along the lines proposed by the documents
in the previous paragraph.
1.4. Design Goals
One of the main objectives in defining TSP is to support Mobile
Network Computers [MNCRS]. Given that these devices are meant to be
very lightweight and to keep as little state as possible, TSP's
design goals are:
- Simplicity.
TSP only defines the minimum required to support the additional
applications and target devices. Surprisingly little needs to
be specified in order to adapt Mobile IP to serve as a remote
access mechanism based on layer 3 forwarding.
- Reusability.
Unless otherwise specified, TSP adopts packet formats and
protocol behavior as specified by Mobile IP. This results in
one protocol that solves mobility and remote access.
- Security.
Given the nature of remote access, security associations are
required of entities exchanging Registration Protocol packets
over public sectors of the internet. Privacy of data transfer
is also a requirement in these conditions, and is accomplished
by using ESP [Kent97a] and AH [Kent97b].
Montenegro Expires February 25, 1998 [Page 5]
INTERNET DRAFT Tunnel Set-up Protocol (TSP) August 1997
2. Overview
2.1. Base Mobile IP
Mobile IP [Perkins96a] defines 3 entities: mobile node (MN), foreign
agent (FA) and home agent (HA).
The idea is that a mobile node is always able to use its permanent
IP address ("home address"), even if it is not "home" (the logical
location of its IP address). When the mobile node moves to another
region of the internet, it's home address is no longer usable, as
the routing fabric still delivers packets to its home location. In a
manner similar to how one leaves forwarding indications at the post
office when out of town, the mobile node engages in a secure
"registration" with the home agent. Once this forwarding indicator
or "binding" is in place, the home agent intercepts all packets
destined for the mobile node and forwards them to the foreign agent
currently being visited by the mobile node. In essence, the foreign
agent lends the mobile node its topologically correct address
("care-of address").
The home agent forwards packets destined for the mobile node by
adding another IP header so the routing fabric sees the home agent's
address as source and the care-of address as destination. Once at
the care-of address, the original packet meant for the mobile node
is recovered and delivered without recourse to regular routing.
Notice that the mobile node may possibly acquire the care-of address
necessary for tunneling. In this case, there is no separate foreign
agent, rather, the mobile node serves as its own tunnel endoint.
This "local" delivery from the foreign agent to the mobile node is
possible because it does not rely on traditional network layer
routing.
2.2. Chained Registrations
Base Mobile IP assumes that the foreign agent is directly reachable
from the home agent. In many situations this is not possible or
desirable. For example, if the foreign agent belongs to an ISP, or
a wireless carrier, it is not desirable to allow it direct
reachability to a system (the HA) that "lives" within the private
network.
A much more secure configuration is to allow the ISP's system to
directly reach only as far as the private network's gateway or
firewall. These two systems need to share some mutual trust,
Montenegro Expires February 25, 1998 [Page 6]
INTERNET DRAFT Tunnel Set-up Protocol (TSP) August 1997
particularly if using surrogate registrations.
Another separate trust relationship is then built between the
gateway or firewall system, and the home agent inside the private
network. Notice that by introducing this intermediate system there
is a very clean separation between external and internal systems
security domains.
This configuration is possible because of the use of chained
registrations, whereas usual registration requests flow directly
from the mobile node to the home agent.
2.3. Surrogate Registrations
Surrogate registrations are composed on behalf of a given node by
another node. Consider the following network:
MN@COA ---------------------- GFA ----- HA
where the mobile node has acquired a co-located address (COA).
Assume that the mobile node is not allowed to exchange packets
directly with its home agent within the private network. Instead, it
sends a Registration Request to the gateway foreign agent (GFA) as
follows:
MN@COA, home agent = GFA.
The gateway foreign agent is not, of course, the mobile node's home
agent. Nevertheless, it has knowledge or can obtain knowledge
(perhaps after consulting a RADIUS database) of the mobile node's
home agent. It then composes a Registration Request aimed at
establishing a tunnel with the home agent:
MN@GFA, home agent = HA.
From the home agent's point of view, this registration request is
almost indistinguishable from what it would have received from the
MN directly. Notice that when the mobile node roams within the
private network, mobility is probably accomplished without surrogate
registrations. Hence, Registration Requests like the above are
sometimes sent directly by the mobile node to the home agent.
The target system can always tell the identity of the system that
composes a Registration Request by the value of the SPI. If the
target system is the home agent, a security association is already
required by Mobile IP. However, intermediate nodes may set up tunnel
segments with other intermediate nodes.
Montenegro Expires February 25, 1998 [Page 7]
INTERNET DRAFT Tunnel Set-up Protocol (TSP) August 1997
Because the SPI is the only way to identify the creator of a
Registration, TSP requires that entities setting up tunnel segments
MUST share a security association. Since surrogate registrations
have exactly the same format as registrations issued by the mobile
node itself, they MUST use the Mobile-Home Authentication Extension
as dictated by Mobile IP.
3. Dynamic Home Address Discovery
It is possible for a mobile node to not have a permanently assigned
IP address. This is the default operating condition for a Mobile
Network Computer.
3.1. Registering over the Internet
When a Mobile Network Computer tries to register over the internet,
it may not have a valid IP address (because it is booting instead of
resuming, or because its lease ran out). TSP defines a home address
discovery mechanism akin to the home agent discovery mechanism
defined by Mobile IP. In both cases, a registration denial carries
the necessary information (see Section 5).
3.2. Registering within the Corporation
In this case, the Mobile Network Computer boots using the Network
Computer model of obtaining its operating parameters from a DHCP
server. One of the parameters received is the IP address to be
used. The Mobile Network Computer must make sure that it receives
an IP address valid for roaming as a Mobile IP node, i.e. it must be
an address that a home agent is willing to provide forwarding
service to [Alex97]. The home agent could also be communicated
using DHCP, or it could be discovered using the home agent discovery
mechanism in [Perkins96a].
4. New Packet Formats
This section specifies packets formats that are different or new
as compared to those defined by Mobile IP [Perkins96a] and
Reverse Tunneling [Monten97].
4.1. Mobile Node Identifier Extension
If the mobile node is using a co-located care-of address, the
Montenegro Expires February 25, 1998 [Page 8]
INTERNET DRAFT Tunnel Set-up Protocol (TSP) August 1997
Registration Reply is delivered directly to it.
On the other hand, if the care-of address belongs to a foreign
agent, it uses the mobile node's home address and the ID field in
the Registration Reply to determine which link-layer address to
relay it to. However, if the mobile node is carrying out dynamic
home address discovery, then the foreign agent can only rely on the
ID field, which is not guaranteed to be unique. The foreign agent
(or downstream agent) MUST add some extra information to
Registration Requests to uniquely identify the mobile node. The home
agent (or upstream agent) MUST return this identifier for the
foreign agent to be able to resolve which mobile node it is intended
for.
The Mobile Node Identifier Extension defined below serves this
purpose.
The Mobile Node Identifier Extension MUST appear before the
TSP-required Foreign-Home Authentication Extension. It SHOULD appear
immediately before it.
As per section 1.9 of [Perkins96a], the type value of 130 implies
that if a node encounters a Mobile Node Identifier Extension in a
Registration Request or Reply, it MAY silently ignore it. This
implies that home agents that comply with Mobile IP, but are unaware
of the TSP extension MAY still be used, as long as the mobile node
does not attempt home address discovery.
TSP home agents that support Mobile Network Computers MUST
understand the Mobile Node Identifier Extension and return it in its
replies. The reason is that Mobile Network Computers may attempt to
register using a certain home address whose DHCP lease may have
expired. Furthermore, two or more Mobile Network Computers may
attempt to use the same home address. Without the Mobile Node
Identifier Extension the foreign agent (or downstream agent) may be
unable to resolve the conflict.
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
130
Montenegro Expires February 25, 1998 [Page 9]
INTERNET DRAFT Tunnel Set-up Protocol (TSP) August 1997
Length
6
Reserved
0
Mobile Node Identifier
A pseudo-random number created by the tunnel initiator (e.g.
foreign agent) as a unique identifier of the mobile node.
NOTE: This is not optimized for the usual case. Should try to do so,
perhaps by claiming the last unused bit in the "rsvd" field of
the Registration Request to mean "it is ok to assign me a new
home address". Only if this bit were on would the Mobile Node
Identifier Extension be needed.
4.2. "Invalid Home Address" Error Code
In order to support dynamic home address discovery, we define a new
error code:
Service denied by the home agent:
140 invalid home address
Notice that "invalid" home address includes two cases:
1. mobile node requires an address assignment,
2. mobile node's lease on its previous address has expired.
An "invalid home address" denial carries the assigned home address
in the home address field of the registration reply.
5. Protocol Behavior
Unless otherwise specified, TSP assumes the behavior defined by
Mobile IP [Perkins96a]. TSP operates in two different modes:
1. When operating within a private network, TSP MAY adopt the
same protocol behavior as Mobile IP, that is, there are no
surrogate registrations, compound tunnels or home address
assignment.
Montenegro Expires February 25, 1998 [Page 10]
INTERNET DRAFT Tunnel Set-up Protocol (TSP) August 1997
2. However, when setting up a compound tunnel, or when a tunnel
traverses a public sector of the internet, bi-directional
tunnels MUST be used. This MAY be accomplished by using either
reverse tunneling [Monten97] or GRE [Hanks94]. In this case,
all Registration Requests and Replies MUST include the proper
Authentication Extension. Also, dynamic home address discovery
while using the services of a separate foreign agent implies
the use of the Mobile Node Identifier Extension.
[gab: must add more detail]
6. Data Transfer: Tunneling Modes
The Registration Protocol defined in [Perkins96a] and the extensions
specified in this document enable tunnels to be set up in an
authenticated fashion. However, there is still the separate matter
of sending data through the tunnels.
Mobile Network Computers MUST use IP in IP encapsulation
[Perkins96b] preferrably using reverse tunneling [Monten97]. Other
types of mobile nodes MAY specify GRE [Hanks94].
However, one of the main applications of TSP is remote access.
Accordingly, tunnels that traverse public sectors of the internet
MUST be protected by using ESP [Kent97a] and AH [Kent97b]. Manual
keying MUST be supported. Key management MUST use either SKIP
[Aziz95] or ISAKMP/OAKLEY [ISAKMP, OAKLEY, ISAOAK]. The exact
mechanism is not determined via Registration Protocol exchanges.
Tunnels that traverse private sectors of the network MAY optionally
protect their traffic in similar fashion.
7. Example Scenarios
7.1 TSP as a Mobile Remote Access Solution
Chained registrations flow in separate steps which together build
one compound tunnel. For example, assuming there is only one
intermediate point (or "traversal point"), labelled GFA ("gateway
foreign agent"), this is how the chained registration would work:
EXAMPLE: TSP for Mobility and Remote Access
MN -- FA ---------------------- GFA ----- HA
Montenegro Expires February 25, 1998 [Page 11]
INTERNET DRAFT Tunnel Set-up Protocol (TSP) August 1997
a. The MN sends a registration request to the FA with the
following information:
name: MN
care-of address: FA
home agent: GFA
b. The FA then forwards this registration to the "home agent",
i.e. to GFA. Notice that GFA is not a home agent in the
traditional sense, because it's address and MN's do not belong
to the same subnet. Also notice that the FA could have
composed the above registration on behalf of the MN (the
so-called "surrogate registration"). At any rate, whoever
composes the registration request must share a secret with
GFA, as this is needed to fill correctly the authenticator
field of the registration request (not shown above).
c. GFA verifies the authentication for this registration and
fetches the information contained therein. It notices that it
is listed as the home agent for the MN, which is not really
true. However, it checks its database, and obtains information
that MN's real home agent is HA, with which it can engage in
yet another authenticated registration protocol exchange
("chained registration").
GFA sends the following registration to HA:
name: MN
care-of address: GFA
home agent: HA
Notice two things:
1. This registration is composed by the GFA on behalf of
the MN, so it is a surrogate registration.
2. If GFA is indeed the home agent for the mobile node at
this point Remote Access has been accomplished.
d. HA verifies the authentication for this registration and
notices that it is indeed valid (it is possible for HA and GFW
to use a shared secret different from the one used by HA and
MN). It then establishes a "tunnel" (i.e an IP forwarder) of
MN's packets to GFA.
Once this chained registration is in place, this is how data
transfer may occur:
Montenegro Expires February 25, 1998 [Page 12]
INTERNET DRAFT Tunnel Set-up Protocol (TSP) August 1997
a. A correspondent node, CN, sends a packet to the MN with the
following IP header:
IP source: CN
IP destination: MN
b. The packet arrives in the vicinity of HA, which intercepts and
forwards it to GFA by prepending a new IP header like this:
New IP source: HA
New IP destination: GFA
c. GFA receives the packet, recovers the original packet:
IP source: CN
IP destination: MN
and notices that it has a binding or registration for MN. This
prompts GFA to forward the packet, this time with the
following new IP header prepended to it:
New IP source: GFA
New IP destination: FA
d. FA obtains the packet, recovers the inner, original packet:
IP source: CN
IP destination: MN
and notices that is has a binding or registration for MN.
This time, it just forwards without any additional headers
because MN is directly reachable.
e. MN receives the packet:
IP source: CN
IP destination: MN
which from the point of view of its applications is exactly
the same packet they would have received if MN had been in its
office. Thus mobility is transparent.
7.2 Registering Without a Permanent Home Address
Assume that the mobile node is a Mobile Network Computer, and as
such, does not have a permanent home address. If at home, it
Montenegro Expires February 25, 1998 [Page 13]
INTERNET DRAFT Tunnel Set-up Protocol (TSP) August 1997
typically acquires an address via DHCP for use during that session.
The notion of session, however, does not necessarily imply a certain
time limit. As long as the Mobile Network Computer renews its DHCP
lease, it can continue to use the assigned address. If it reboots
again, it will need a new address, but this is probably a very rare
ocurrence. Instead of rebooting, what is customary is for a Mobile
Network Computer to suspend its state and resume it at a later
time. At that time, it will attempt to use the same address as it
was using when it suspended its state. It's DHCP lease may have
expired, or it may even ignore what to use as a home address. At
this point, it establishes a presence on the public internet,
perhaps by starting a PPP session with an ISP. It needs to obtain a
new home address.
This is what it knows:
*1. the home prefix is known
2. HA is known
3. secret is known
4. care-of address is known
*5. care-of address is co-located
This is what it wishes to find out:
1. MN home address
The mobile node issues this Registration Request:
IP fields:
Source Address = co-located care-of address
Destination Address = IP address of home agent
Time to Live = 64
UDP fields:
Source Port = <any>
Destination Port = 434
Registration Request fields:
Type = 1
S=0,B=x,D=1,M=x,G=x
Lifetime = 1800 (seconds)
Home Address = the mobile node's home prefix
Home Agent = IP address of mobile node's home agent
Care-of Address = co-located care-of address
Identification = timestamp
Extensions:
The Mobile-Home Authentication Extension
The home agent sees that the home address field is not completely
Montenegro Expires February 25, 1998 [Page 14]
INTERNET DRAFT Tunnel Set-up Protocol (TSP) August 1997
filled out, obtains a new address within the indicated prefix and
returns it to the mobile node using this reply:
Upon return:
IP fields:
Source Address = IP address of home agent
Destination Address = co-located care-of address
Time to Live = 64
UDP fields:
Source Port = <any>
Destination Port = copied from src port or reg req
Registration Reply fields:
Type = 3
Code = 140 (invalid home address)
Lifetime = 1800 (seconds)
Home Address = the mobile node's newly assigned home address
Home Agent = IP address of mobile node's home agent
Identification = timestamp
Extensions:
The Mobile-Home Authentication Extension
Notice that it is possible to discover both the home agent and the
mobile node addresses:
Now, this is what the Mobile Network Computer knows:
*1. the home prefix is known
*2. HA prefix is known
3. secret is known
4. care-of address is known
*5. care-of address is co-located
And this is what it wishes to find out:
1. HA address
2. MN home address
It issues this Registration Request:
Registration Request fields:
Type = 1
S=0,B=x,D=1,M=x,G=x
Lifetime = 1800 (seconds)
Home Address = the mobile node's home prefix
Home Agent = directed broadcast to HA's prefix
Care-of Address = co-located care-of address
Identification = timestamp
Montenegro Expires February 25, 1998 [Page 15]
INTERNET DRAFT Tunnel Set-up Protocol (TSP) August 1997
Extensions:
The Mobile-Home Authentication Extension
An initial reply with code 136 (unknown home agent address) tells
the mobile node which home agent to use. Subsequently, the mobile
node may discover its own home address. It must first discover the
home agent address because the latter must be willing to provide
some address allocation services on the mobile node's behalf.
We could also use a separate foreign agent:
In this case, these are the known quantities:
*1. the home prefix is known
*2. HA prefix is known
3. secret is known
4. care-of address is known
In this case, the foreign agent uses a Mobile Node Identifier
Extension (Section 4.1.2) to determine which mobile node to send
replies to. Notice that it is presumed that an foreign agent learn
the mobile node MAC address from snooping the Registration Request.
8. Security Considerations
This document is very heavily based on Mobile IP. Tunnel Set-up
Protocol focuses on additional applications, namely, remote access.
Because of this, items which may be optional in basic Mobile IP
become absolute requirements for TSP. The registration protocol
messages MUST always be authenticated. This means that there MUST
always be a security association between both endpoints of any given
tunnel segment.
References
[Aziz95] A. Aziz and M. Patterson, Design and Implementation
of SKIP, available on-line at
http://skip.incog.com/inet-95.ps. A previous version
of the paper was presented at INET '95 under the
title Simple Key Management for Internet Protocols
(SKIP), and appears in the conference proceedings
under that title.
[Calhoun96] P. Calhoun, E. Wong. Virtual Tunneling Protocol --
work in progress, draft-calhoun-vtp-protocol-00.txt,
Montenegro Expires February 25, 1998 [Page 16]
INTERNET DRAFT Tunnel Set-up Protocol (TSP) August 1997
July 1996.
[GuGl97a] V. Gupta and S. Glass, "Firewall traversal for
Mobile IP: Goals and Requirements". -- work in
progress, draft-ietf-mobileip-ft-req-00.txt> -- work
in progress, January 1997.
[GuGl97b] V. Gupta and S. Glass, "Firewall traversal for
Mobile IP: Guidelines for Firewalls and Mobile IP
entities" -- work in progress,
draft-ietf-mobileip-firewall-trav-00.txt, March
1997.
[Hanks94] Hanks, S., Li, R., Farinacci, D., and P. Traina,
"Generic Routing Encapsulation (GRE)", RFC 1701,
October 1994.
[ISAKMP] Maughhan, D., Schertler, M., Schneider, M., and
Turner, J., "Internet Security Association and Key
Management Protocol (ISAKMP)",
draft-ietf-ipsec-isakmp-08.{ps,txt}, July 1997.
[ISAOAK] Harkins, D., Carrel, D., "The resolution of ISAKMP
with Oakley", draft-ietf-ipsec-isakmp-oakley-04.txt,
July 1997.
[Kent97a] S. Kent, R. Atkinson. IP Encapsulating Payload --
work in progress, draft-ietf-ipsec-esp-v2-00.txt,
July 1997 (obsoletes RFC 1827, August 1995).
[Kent97b] S. Kent, R. Atkinson. IP Authentication Header --
work in progress,
draft-ietf-ipsec-auth-header-01.txt, July 1997
(obsoletes RFC 1826, August 1995).
[MNCRS] Mobile Network Computer Reference Specification,
June 1997.
http://www.internet.ibm.com/computers/networkstation/
os/mncrs.html
[Monten97] G. Montenegro, "Reverse Tunneling for Mobile IP" --
work in progress,
draft-ietf-mobileip-tunnel-reverse-04.txt, August
1997.
[MoGu97] G. Montenegro and V. Gupta, "Firewall Support for
Mobile IP". -- work in progress,
draft-montenegro-firewall-sup-01.txt, July 1997.
Montenegro Expires February 25, 1998 [Page 17]
INTERNET DRAFT Tunnel Set-up Protocol (TSP) August 1997
[OAKLEY] Orman, H., "The Oakley Key Determination Protocol",
draft-ietf-ipsec-oakley-02.txt, July 1997.
[Perkins96a] C. Perkins, Editor. IP Mobility Support. RFC
2002.
[Perkins96b] C. Perkins, Editor. IP Encapsulation within IP. RFC
2003.
[Alex97] S. Alexander, R. Droms. DHCP Options and BOOTP
Vendor Extensions. RFC 2132.
Author and Chair Addresses
Questions about this document may be directed at:
Gabriel E. Montenegro
Sun Microsystems, Inc.
an Antonio Road
Mailstop UMPK 15-214
Mountain View, California 94303
Voice: +1-415-786-6288
Fax: +1-415-786-6445
E-Mail: gabriel.montenegro@eng.sun.com
Montenegro Expires February 25, 1998 [Page 18]
INTERNET DRAFT Tunnel Set-up Protocol (TSP) August 1997
The working group can be contacted via the current chairs:
Jim Solomon
Motorola, Inc.
1301 E. Algonquin Rd. - Rm 2240
Schaumburg, IL 60196
Voice: +1-847-576-2753
Fax: +1-847-576-3240
E-Mail: solomon@comm.mot.com
Erik Nordmark
Sun Microsystems, Inc.
901 San Antonio Road
Mailstop UMPK17-202
Mountain View, California 94303
Voice: +1-415-786-5166
E-Mail: erik.nordmark@eng.sun.com
Montenegro Expires February 25, 1998 [Page 19]