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 = 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 = 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]