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]