Pat R. Calhoun Internet Draft US Robotics Access Corp. expires in six months Ellis Wong Bay Networks, Inc. July 1996 Virtual Tunneling Protocol (VTP) Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document specifies a protocol which allows various Layer 2 and Layer 3 protocols to be tunneled through an IP network. VTP does not specify any change to the protocol to be tunneled. It describes the mechanisms for dynamically establishing and maintaining secure IP tunnels, and carrying multiprotocol data over those tunnels. VTP can be used in the implementation of Virtual Private Networks (VPNs). A client-server architecture is defined in order to decouple functions which exist in the tunnel initiation node and those in the tunnel termination node. This protocol can be implemented in network devices such as network access servers, routers and application servers. VTP specifies a Mobile IP-like message exchange protocol to create and manage IP tunnel sessions dynamically. VTP uses the GRE (Generic Routing Encapsulation) mechanism to encapsulate multi-protocol payload traffic. Calhoun et. al. [Page 1] DRAFT Virtual Tunneling Protocol July 1996 1. Introduction The Virtual Tunneling Protocol (VTP) is a protocol which enables a service provider to offer Virtual Private Network (VPN) services and dial access services to corporate home networks. The corporate enterprise can subscribe to the service to allow its telecommuters, mobile professionals and users in remote branch offices to connect back to the corporate network, via the service provider's network. In order to provide a true "multiprotocol" VPN technology, it is necessary to perform some form of encapsulation and tunneling in order to mask the private address space being used. This technology must be sufficiently secure in order to protect the network resources from outside attack. There exists some basic form of VPN technology today by some manufacturers, however these are either very static in nature or are proprietary solutions. The intent of this document is to establish a standard, dynamic tunnel establishment scheme which require minimal configuration in order to ease deployment of such products. This protocol allows dynamic tunnel establishment between two network elements over an IP network infrastructure, with extensibility to provide tunnel security. This protocol can be used to construct a corporate VPN by implementing the VTP client functions in a remote office router and the VTP server functions a router in the corporate network. This protocol can also be used to enable dial access to corporate networks via an IP tunnel, through the service provider's infrastructure. To support this capability, the VTP client functions can be implemented in a service provider Network Access Server (NAS) and the VTP server functions can be implemented in a router in a corporate network. In this case, the corporate enterprise can out- source the purchase, installation and management of the remote access equipment, such as the NAS, to service providers for cost savings. The protocol is extensible to support any Layer 2 and Layer 3 protocol to be tunneled over an IP network. The protocol is also flexible by allowing the IP tunnel to be terminated within a customer premise, or within a service provider network. Many corporate enterprises may already have subscribed to service providers for VPN services such as Frame Relay, SMDS, or even ATM. By terminating IP tunnels in a gateway residing within the service provider network, the provider can now offer dial-up IP tunnel interworking with other existing VPN services. With this offering, the corporate enterprise may now obtain remote dial access service from the same provider with no hardware or software change required in the customer premise equipment (CPE). This specification simply details the protocol which is used for Calhoun et. al. [Page 2] DRAFT Virtual Tunneling Protocol July 1996 tunnel management between two devices. In the case of support for a dial-up PPP connection, user authentication is assumed to be managed by the corporate enterprise, not the service provider. This protocol does not require the use of a specific user authentication protocol. The PPP CHAP and RADIUS protocols are used in examples to facilitate discussion. In case of support for LAN interconnection across the service provider's IP network infrastructure, routers are used in examples to describe the router to router tunneling capability of the protocol. The VTP protocol does not require the use of a specific IP security mechanism. A public/private key management mechanism can be used to provide secure tunneling functionality. 1.1. Protocol Goals and Assumptions The VTP protocol only needs to be implemented in a tunnel initiation node and a tunnel termination node. The tunneling functions are transparent to the dial-up hosts or remote office routers, as well as the intermediate systems in the IP backbone. Hence, no change is required in those systems. If the tunnel initiation node is a NAS, then it is responsible for physical interfacing to the PSTN or ISDN. It is also responsible for the logical termination of the PPP or SLIP connection, and the tunnel initiation from an IP network interface. If the tunnel termination node is a router, then it simply consists of one of more LAN interfaces, and at least one IP network interface which the IP tunnel is initiated from. Authentication is provided via PPP CHAP or PAP, or through other dialogs as needed for protocols which do not use authentication (i.e. SLIP). User authentication is managed from the enterprise home network. This specification does not require the use of one specific user authentication protocol (i.e., RADIUS, TACACS+). The VTP protocol also must support enterprises which use private network addresses for corporate virtual private networking. In the case the tunnel initiator is a NAS, the enterprise assigns an address for the dial-up node, which is meaningful to the enterprise home network, during the user authentication process. Calhoun et. al. [Page 3] DRAFT Virtual Tunneling Protocol July 1996 1.2. Terminology This document frequently uses the following terms: DLCI Data Link Connection Identifier is a unique identifier for a virtual circuit at each Frame Relay interface. PVC Permanent Virtual Circuits are connections which are permanent in nature. SVC Switched Virtual Circuits are connections which are dynamic in nature. Care-of Address The termination point of a tunnel towards a mobile node, for datagrams forwarded to the mobile node while it is away from home. This protocol specifies the use of a "co-located care-of address", which is an externally obtained local address which the mobile node has associated with one of its own network interfaces. Foreign Agent A router on a mobile node's visited network which provides routing relay services to the registered mobile node. The foreign agent decapsulates and delivers datagrams to the mobile node which were tunneled by the mobile node's home agent. For datagrams sent by the a mobile node, the foreign agent may serve as a default router for mobile nodes. Gateway A router which resides within the service provider network. It is connected to multiple VPNs (such as Frame Relay), as well as the IP backbone. The gateway may provide the home agent processing functions. Home Address An address which is assigned to a Mobile Node for an extended period of time. This address is assigned from the home network. Home Agent A router on a mobile node's home network which tunnels datagrams for delivery to the mobile node when it is away from home, and maintains current location information for the mobile node. Calhoun et. al. [Page 4] DRAFT Virtual Tunneling Protocol July 1996 Home Network The network address domain which the mobile node's home address belongs in. Mobile Node A host or router which changes its point of attachment from one network or subnetwork to another. A mobile node may change its location without changing its IP address. It may continue to communicate with other Internet nodes at any location using its (constant) IP address, assuming link-layer connectivity to a point of attachment is available. The Mobile Node initiates the registration request to its home agent to indicate its current point of network attachment. NAS A Network Access Server is a router which supports dial-up PPP and SLIP users. VPN Virtual Private Networks are logical networks over a physical public network. This logical network forms a private network for an enterprise. 1.3. Specification Language In this document, several words are used to signify the requirements of the specification. These words are often capitalized. MUST This word, or the adjective "required", means that the definition is an absolute requirement of the specification. MUST NOT This phrase means that the definition is an absolute prohibition of the specification. SHOULD This word, or the adjective "recommended", means that, in some circumstances, valid reasons may exist to ignore this item, but the full implications must be understood and carefully weighed before choosing a different course. Unexpected results may result otherwise. MAY This word, or the adjective "optional", means that this item is one of an allowed set of alternatives. An implementation which does not include this option MUST be prepared to interoperate with another implementation which Calhoun et. al. [Page 5] DRAFT Virtual Tunneling Protocol July 1996 does include the option. silently discard The implementation discards the datagram without further processing, and without indicating an error to the sender. The implementation SHOULD provide the capability of logging the error, including the contents of the discarded datagram, and SHOULD record the event in a statistics counter. 2. Protocol Overview The basic functionality defined in VTP is derived from the Mobile IP protocol [3]. The Mobile IP specification provides much more functionality than required for this protocol. Thus, only a subset of the specification will be used in this protocol. The Mobile IP specification defined a registration mechanism for creating a one-way tunnel from the home agent to the mobile node, and allows for roaming of the mobile node. VTP uses the registration mechanism to create two-way tunnels and does not support any roaming (as in cellular roaming) capability. The subset which will be implemented will be the Registration Request/Response messages which are used for the Tunnel Establishment, Shutdown and Refresh functions. The VTP protocol also takes the advantage of the extensibility defined as registration extensions in the Mobile IP specification to carry tunnel specific information which are important in establishing secure VPN tunneling. The VTP protocol defines a resource called the Mobile Node Proxy. The mobile node proxy has similar functionality to a mobile node which has a co-located care-of address. However, the mobile node proxy is the device which initiates a two-way IP tunnel by registering to the home agent. The home agent is the device which terminates the two-way tunnel. The mobile node proxy can perform encapsulation of datagrams to be tunneled to its home agent and decapsulation of datagrams tunneled from its home agent. Similarly, the home agent can perform encapsulation of datagrams to be tunneled to a mobile node proxy and decapsulation of datagrams tunneled from a mobile node proxy. For virtual dial-up tunneling support, the mobile node proxy can be implemented in a NAS. The home agent functions can be implemented in a customer CPE router or in a gateway router which resides in the service provider network. The mobile node proxy can initiate a two-way IP tunnel in response to a remote PPP dial-in Calhoun et. al. [Page 6] DRAFT Virtual Tunneling Protocol July 1996 connection attempt. A dial-up PPP client will be referred to as a dial-up client in this specification, however VTP does inherently support SLIP as well. The mobile node proxy, in a sense, acts as a proxy agent for the dial- up client. This proxy capability will allow dial-up clients to connect to the corporate network via the IP backbone without having to install Mobile IP capable software. The IP address of the NAS then becomes the care-of address for each of these mobile node proxy instances. For router to router tunneling support, the mobile node proxy can be implemented in the router which initiates a tunnel establishment attempt to interconnect remote networks over an IP backbone. The home agent can be implemented in a peer router which terminates the tunnel. In this case, the router which initiates the tunnel has a co-located care-of address. The care-of address is the address of the IP interface which connects to the IP backbone. For both virtual dial-up tunneling and router-to-router tunneling cases, the mobile node proxy and the a home agent can coexist in one element. This will allow the network element to initiate one bi- directional tunnel and to terminate another independently. This protocol defines another resource called the VPN Identifier. This identifier has no significance for router to router tunnel establishment, but is used by devices which support multiple VPNs simultaneously. This numerical representation of the domain allows network devices to protect network resources by allowing only resources from one domain to access other resources within the same domain. The VPN identifier is included in the tunnel manangement messages as a registration extension. This protocol also defines another resource called the Tunnel Identifier. This identifier is also used to distinguish each tunnel from the other. The tunnel identifier allows the each end of the tunnel to associate the tunneled data stream with the appropriate tunnel. The tunnel identifier is included in each of the tunnel management messages as a registration extension. It is also included in the encapsulation header of each tunneled data packet. Tunnel security is performed by authenticating each peer of the tunnel as defined in the Mobile-Home Authentication section of the Mobile IP specification, which is done with the use of session keys. In order to provide a good authentication scheme, a session key must have a short life span, where it is valid only for the duration of a tunnel, and in the case of a long term tunnel it is possible to re-negotiate a new session key. Calhoun et. al. [Page 7] DRAFT Virtual Tunneling Protocol July 1996 This protocol provides flexibility as far as a session key encryption technique. However, MD5 is the default technique which MUST be supported by all implementations. 2.1. Dynamic Tunnel Establishment This section will detail the events which are necessary for tunnel establishment. We will attempt to describe the events of a tunnel establishment, followed by two sections which describe the applicability with a router to router and a NAS to router scenario. A final section detailing how to recover from a race condition. In order to establish a tunnel, it is necessary to send a Registration Request message. The sender (or tunnel initiator) is known as the Mobile Node Proxy. Each registration request message contains a field known as Lifetime. This field contains a value which defines the number of seconds before the tunnel expires. The tunnel initiator is responsible for "refreshing" the tunnel before the peer considers the tunnel expired. When creating a registration request message, the mobile node proxy must know if it is simply registering a new remote client to use an existing tunnel, or if a new tunnel needs to be created for a new remote client. In the case of a new tunnel, the mobile node proxy must set the least significant two bytes of the four-byte field to a locally unique value (unused by the sender). This value may be used locally as an index into a local table. The decision to register a new client using an existing tunnel (multiplexing many remote clients over one tunnel), or to create a new tunnel for each new remote client is implementation specific. If a tunnel already exists and the mobile node proxy wishes to register a new remote address to an existing tunnel, the mobile node proxy must insert the full tunnel identifier into the request. Registering a new remote address on an existing tunnel resets the lifetime for the tunnel (same as the Refresh Request message). The tunnel identifier, is used in all subsequent exchanges in order to identify the tunnel. All protocols which are used by the client must be registered with the home agent. Each network protocol used by the client is indicated in a separate registration extension. If the dial-up PPP station is a network device which requires routing updates (i.e. a router), routing may be required on the tunnel. The tunnel registration mechanism also negotiates a set of attributes for the tunnel itself; including routing, compression and others. Calhoun et. al. [Page 8] DRAFT Virtual Tunneling Protocol July 1996 An encrypted session key MUST be present in the registration request message, which is used by the home agent (tunnel terminator) in order to verify the authenticity of the message. The message also contains an MD5 message digest as the last extension. Upon receipt of this message, the home agent must decrypt the session key, and use the same key to verify the authenticity of the message by generating an MD5 hash of the message and comparing it with the value in the extension. If the message digest does not compare, a response with the appropriate error code is returned to the mobile node proxy. If the home agent receives an extension which MUST be supported and cannot be supported locally, the home agent MUST respond with the appropriate error code. If an extension is malformed or contains an invalid value, the same processing policy applies in these cases. If the registration request is for a new tunnel, the home agent must insert an unused, locally unique, value into the most significant two bytes of the four-byte tunnel identifier. In the case of a request to register a new address on an existing tunnel, the home agent must verify that the tunnel is active and the tunnel's peer is with the requesting mobile node proxy. If the mobile node proxy is requesting an existing tunnel which does not exist on the home agent (or exists with a different peer), the home agent must insert a new value into the most significant two bytes (this could occur if the home agent had reset for some reason) of the tunnel identifier. If the request is valid and contains all of the required extensions, the home agent will create a dynamic tunnel interface. The tunnel interface could be created with a network address set to the registered home address, and the care-of address set to the mobile node proxy. The home agent should also add to the route table the network level addresses of the client being registered (for all protocols). Once all of the above steps have been successfully completed, the home agent returns a registration response message with the return code set to SERVICE_PROVIDED. Both the request and response MUST include, as the first extension the authentication extension, which contains an MD5 digest of the message. Note that if the request contained a VPN extension, it MUST be returned in the response even if it is not supported locally. This extension is necessary for certain type of network equipment which Calhoun et. al. [Page 9] DRAFT Virtual Tunneling Protocol July 1996 supports multiple VPNs. The mobile node proxy receiving this response must examine the return code. Unless the return code was set to authentication failure, the message digest in the response should be compared with a locally generated message digest (using the session key). If the return code is set to a value other than [ ], the mobile node proxy may either retry the message up to the maximum retry, or attempt a tunnel with an alternate home agent (if one is available). If the request was sent to register a new remote address on an existing tunnel and the response contains a different tunnel identifier than was requested, then the mobile node proxy MUST assume that the home agent has rebooted and that the old tunnel is no longer valid. The mobile node proxy could then create a local tunnel interface with the local network address set to the home address; the IP tunnel local address set to the care-of address; and the IP tunnel peer address set to the home agent IP address. 2.1.1. Router to Router Tunnel Establishment This section will detail the events for tunnel establishment for a router to router scenario. Figure 1 depicts two branch offices which connect to the main office through a public network in a secure fashion. Both of the branch offices have a router which supports VTP, which will establish a tunnel to a VTP server (running on a CPE router, for example) at the main office. In this diagram we show a firewall at the main office, which must be configured to allow IP datagrams with a protocol ID set to GRE and whose destination is set to the VTP Server. Both of the routers and the VTP server SHOULD either share a pre- configured shared secret, use a public/private key scheme or have access to some form of key distribution center. Since MD5 key encoding is an optional extension for this protocol, all implementations SHOULD support shared secrets. An example scenario of the use of VTP in this case would be when there is data which is to be routed to the main office from one of the branch offices, the router could examine if there is already a tunnel to the VTP server. If no tunnel is established, a registration request is sent and once the response is received all data may be encapsulated and sent to the server. Calhoun et. al. [Page 10] DRAFT Virtual Tunneling Protocol July 1996 Host | ------+------ +----------------------+ | | | Router 1 ----------------------+ | (VTP Client) | Public Network | | | | | Router 2 ----------------------+ | (VTP Client) | | +-----------+----------+ | | ------+------ | | Firewall Node | | --------+--------- | Router 3 (VTP Server) Figure 1: Router to Router VTP connection 2.1.2. NAS to Gateway Tunnel Establishment This section will detail the sequence of events which are necessary for a Dial-up router to establish a tunnel with a gateway. This scenario shows the VTP home agent residing within the ISP's network, but this is not a limitation of the protocol. Figure 2 shows an example of network which supports VTP. The home agent shown has the ability to support multiple VPNs (or domains) in a secure fashion (meaning that network resources may only be accessed by users if they are within the same VPN). This example also shows a RADIUS Server which holds all of the configuration necessary for VTP tunnel establishment and is returns a successful user authentication message. The RADIUS Server also act as a Key Distribution Center (KDC) and create a unique session key for each user. Calhoun et. al. [Page 11] DRAFT Virtual Tunneling Protocol July 1996 Note that the user of RADIUS is optional and any authentication protocol may be used. In addition, a KDC is also optional, however configuring shared secrets on each VTP device causes interesting scalability problems, but using a public/private key could work. Upon connect, a PPP client generates a LCP request, which is used for Link Control Protocol negotiations. The NAS will respond and the peers must agree to a set of options. The NAS will then generate a CHAP request to the client (assuming that CHAP was negotiated as the authentication protocol), this request will contain a 16 octet authentication vector, which will be used later for security purposes. The Client will then pass the encrypted user name and password in the CHAP response. At this point, the NAS has a copy of the user name and password of the client which will be used when sending the authentication request to the local RADIUS Server. Host | +-------------+ | PSTN/ISDN | | | +------+------+ +----------------------+ | | | NAS ----------------------+ | (VTP Client) | Public Network | | | | | | | | | +-+------------------+-+ | | | | ------+------ ------------ | | | | Gateway CPE Router (VTP Server) (VTP unaware) Figure 2: NAS to Gateway VTP Connection Note that VTP does not require CHAP and any authentication protocol (i.e. PAP, CHAP, EAP) may be used. The NAS generates a Radius ACCESS_REQUEST message and forward the message to the local Radius Server. In this example, we will assume that the Radius Server (known as the Proxy Server) is configured to Calhoun et. al. [Page 12] DRAFT Virtual Tunneling Protocol July 1996 forward the authentication requests to a remote Radius Server (known as the Domain Authentication Server, or DAS). The local Radius Server will then re-compute the password using the Shared Secret which is configured between itself and the remote Radius Server, add a proxy state attribute and forward the request to the DAS. The Remote Radius Server is now responsible for user authentication. If successfully authenticated, the attributes configured for the user are added to the ACCESS_ACCEPT packet. One or more VPN Gateway attributes are attached to the packet. This attribute contains an IP address, a tunnel refresh value and an encoded representation of a temporary session key. The packet is then returned to the Proxy Server. The Proxy Server will then add VPN specific attributes and return the message to the originating NAS. Once the NAS receives the ACCESS_ACCEPT message, a CHAP response is returned to the PPP Client and NCP negotiations are then initiated. Once NCP negotiations are complete, the NAS creates a VPN entry from the information which was received in the packet. NOTE: The tunnel establishment SHOULD occur after the completion of the NCP negotiation phase, but prior to setting the connection to the open state, in order to avoid PPP client time-outs. At this point, the NAS will send a registration request message to the home agent (see figure 2). Upon receipt of a successful response, the NAS sets the PPP to open state. All packets from the client are encapsulated within a GRE header with the Tunnel ID field set to the tunnel identifier and sent to the home agent. Upon receipt of a data packet, the authenticity must be validated using the session key. 2.1.3. Race Condition Since the protocol requires that the mobile node proxy must always be known (the mobile node proxy is the one who is responsible for refreshing the tunnel), there exists a potential race condition problem when two nodes send a Registration Request simultaneously. If a network device receives a registration request message from another node which it already has a pending request for, the request with the lowest IP address in the home agent IP Address field MUST be discarded. 2.2. Dynamic Tunnel Refresh As explained above, each registration request message contains a field Calhoun et. al. [Page 13] DRAFT Virtual Tunneling Protocol July 1996 known as the lifetime which is set to the maximum number of seconds before the tunnel expires. Although registering a new client over an existing tunnel causes the timer to reset and the new lifetime to be observed, it is highly possible that no new clients will attempt to register before the tunnel does expire. Therefore there must be a mechanism to "refresh" the tunnel, and this is done by using the Tunnel Refresh message, which includes the tunnel identifier as well as a new lifetime. The home agent must acknowledge the request with a response in order for the mobile node proxy to consider the tunnel "refreshed". It is imperative that the mobile node proxy allow enough time for refresh request re-transmissions, otherwise the home agent could invalidate the tunnel. Therefore the mobile node proxy should observe the following formula in determining when to transmit the first refresh request message: timer = (current time + lifetime) - (MAX retransmissions * seconds between retrans.) This formula does raise an interesting problem, which deals with selecting the tunnel lifetime. If the lifetime chosen for a tunnel is less than the max retransmission times the seconds between each retransmission, this would cause a flurry of refreshes, and possibly a very unreliable service. It is therefore recommended that an implementation chooses it's minimum lifetime wisely. There exists a timing problem which can occur if the mobile node proxy sends out a refresh request followed by a deregistration request for the same SPI as that used in the refresh. If the home agent received both packets out of order, it could invalidate the SPI when receiving the deregistration request and then fail the refresh's authentication since the SPI is no longer valid. It is therefore imperative that when the mobile node proxy receives a refresh response indicating that the request failed the authentication that a new request be sent with another valid SPI (if there are no valid SPI then the request is abandoned). This "retransmission" should not be done more often than the maximum retransmission counter. Once the maximum number of retransmissions have been unsuccesssful (either failed or no response), the interface should be shutdown and any dial-up users (in the case of a NAS) should be disconnected. 2.3. Dynamic Tunnel Shutdown A tunnel shutdown could result for many reasons, one being that a dial- up user has disconnected with the NAS, another being that a router Calhoun et. al. [Page 14] DRAFT Virtual Tunneling Protocol July 1996 would shutdown a tunnel due to inactivity or possibly when a transaction is complete. The mobile node proxy constructing the request, MUST use the SPI which is associated with this user. Upon receipt of the message, the home agent will attempt to authenticate the message. If it fails authentication, it will respond with a negative response. Otherwise it will remove each route specified in the header and protocol extensions from the network routing tables for the mobile node proxy. Next, the peer will check if there are any other mobile node proxy which are using the tunnel. If not, then the GRE interface is deleted and the response is sent back to the requester. Once the mobile node proxy receives the response, it will attempt to authenticate the response. If the response fails the authentication, the request will be abandoned. Once the maximum number re-transmissions have been sent, the mobile node proxy will simply destroy the tunnel. If the response was successfully authenticated, it will also ensure that there are no other mobile node proxies using the tunnel. If there are none, then the local GRE interface is also deleted. Tunnel de-registration messages are always sent from the mobile node proxy to the home agent. If a home agent detects that it must shutdown the interface, it may do so and return an error in the next refresh response. 3. Protocol Specification The VTP protocol is based on the IP Mobility protocol. The VTP protocol uses a subset of the Mobile IP protocol specification. The IP Mobility protocol contains a standard header, and a set of extensions. These extensions contain information which is relevant for the operation. An extension consist of a type field, a length field, followed by the data field. All VTP related extensions are encapsulated within a single Mobility extension. This allows the protocol to allocate as many extension numbers as required without affecting the relatively small Mobility extension address space (8 bits). 3.1. Registration Request This message is sent from the mobile node proxy to the home agent for two purposes. In the first case, the mobile node proxy wishes to Calhoun et. al. [Page 15] DRAFT Virtual Tunneling Protocol July 1996 establish a new tunnel with the home agent, and the second is where the mobile node proxy wishes to register a new remote address with the home agent over an existing tunnel. The following message format is used: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |S|B|D|M|G|V|T|r| Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care of IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 1 (Registration Request) S, B, M, V All set to zero to disable features not required. D 1, The mobile node proxy will itself decapsulate datagrams which are sent to the care-of address. G 1, GRE encapsulation enabled. T 1, Bi-directional tunneling enabled. r 0, Reserved Field Lifetime The number of seconds remaining before the registration is considered expired. A value of 0xffff indicates infinity. Home IP Address For IP over dial-up connections, this value is the IP address of the remote node or the dial-up router. It is the IPCP assigned IP address for the remote client. For non-IP protocol over dial-up connections, this field is set to zero. Calhoun et. al. [Page 16] DRAFT Virtual Tunneling Protocol July 1996 For IP tunneling configurations between two routers which are not dial-up routers, this field is also set to zero. Home Agent Address The IP Address of the home agent. Care of Address The IP Address of the Foreign Agent. Identification The 64-bit identification field consists of two parts. The most significant four bytes contain a valid timestamp, which is the number of seconds since January 1, 1900 (as defined in [NTP]). The least significant four bytes contains a random value. 3.1.1. VTP Extensions This extension is used to encapsulate all VTP specific extensions. This is done in order to conserve the small extension address space which is available in the Mobile IP header. Each sub-extension may all be encapsulated within one single VTP extension, or each sub-extension may be individually encapsulated with this extension. The format of the header is as defined below: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | flag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 65 (VTP Extensions) Length variable Sub-Type Sub Attribute Number Sub-Length Sub Attribute Length Flag The flag field contains a set of properties for the following sub-attribute. The following bits have been defined: Calhoun, et. al. [Page 17] DRAFT Virtual Tunneling Protocol July 1996 VTP_MANDATORY_SUPPORT 0x01 If this bit is set, the attribute MUST be supported by the peer. If this attribute cannot be supported, an error code must be returned. 3.1.1.1. Tunnel-Identifier Extension This extension is REQUIRED for tunnel establishment requests and all further requests to register a new user to an existing tunnel. This extension SHOULD be the first extension following the protocol header. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Length | flag | Tunnel Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel Identifier | Interface Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Flags | System Name (opt) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-Type 1 (VTP Tunnel-Identifier Extension) Sub-Length variable Flag Bit 1 MUST be set (mandatory support) Tunnel ID The Tunnel Identifier contains the GRE session ID. This identifier is used within each GRE header to indicate the session. The Tunnel ID is divided into two parts; the least significant two bytes contains the Foreign Agent session identifier and the most significant two bytes are the Home Agent's session ID. When requesting a new session, the mobile node proxy should insert an unused integer in the least significant two bytes, set the most significant to zero. Upon successful registration, the peer will insert an unused two byte value in the most significant two bytes. Calhoun et. al. [Page 18] DRAFT Virtual Tunneling Protocol July 1996 In the case of a NAS which wishes to register a new client within an existing tunnel, the full tunnel identification is inserted in this field. Interface Flags The Interface Flags field contains all attributes for the tunnel. The initiator may set as many attributes for the interface as required, however the response from the peer will contain the attributes which the peer is able to service at this time. It is possible to change the properties of a tunnel while the tunnel is active. This is done when a new user is registered on an existing tunnel. However a property CANNOT be removed from a tunnel, only added. The following flags have been reserved: VTP_IF_COMPRESSION 0x0001 If this bit is enabled, compression of user data is bi-directionally enabled. Once compression has been negotiated, all data sent through the tunnel must be compressed. This property is per tunnel, not per user. VTP_IF_AUTHENTICITY 0x0002 If this bit is enabled, each GRE header contains a 4 octet MD5 hash of the packet. This enables authentication of each data packet. It is also possible to use the AH header to authenticate each packet. If this is done, it is not necessary to set this bit. System Name This optional 64 octet field contain a string representation of either the user name which was used during the login process which initiated the tunnel establishment or the device system name (if available). This is used for command line display purposes only. Calhoun et. al. [Page 19] DRAFT Virtual Tunneling Protocol July 1996 3.1.1.2. IP-Protocol Extension This extension is OPTIONAL and must be present only if the client being registered supports IP. This extension may be sent to register a new client on an existing tunnel even if the initial tunnel establishment request did not register IP support. This extension can be repeated multiple times in the case that several IP addresses are to be registered. In this case, a conventional router or dial-up router is serving multiple IP addresses in the remote LAN. The format of the extension is: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Length | flag | IP Network Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Network Address (cont.) | IP Subnet Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Subnet Mask (cont.) | Interface Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-Type 10 (IP-Protocol Extension) Sub-Length 10 Flag Bit 1 MUST be set (mandatory support) IP Network Address This field contains the IP Network address of each of the subnetworks the remote client is serving. This allows the home agent to add a network route upon successful registration without the need of a routing protocol. This obviously only works if the address space on the network side is contiguous, otherwise a routing protocol is required. For a dial-up user (non-router), this field SHOULD be set to zero. IP Subnet Mask This field contains the Subnet mask of the IP Network address above. Calhoun et. al. [Page 20] DRAFT Virtual Tunneling Protocol July 1996 Interface Flags The Interface Flags field contains all attributes for the IP protocol over the tunnel. The tunnel initiator may set all of the bits which it can support. The response from the tunnel terminator determines the interface properties which will be used over the tunnel. It is therefore possible to set a preference on either ends of the tunnel. It is possible to enable a routing protocol over an existing tunnel only if one was not already negotiated. It is not possible to disable such a protocol. The following flags have been reserved: VTP_IF_RIP_ROUTING 0x0001 If this bit is enabled, RIP will be used as a routing protocol over the tunnel. VTP_IF_OSPF_ROUTING 0x0002 If this bit is enabled, OSPF will be used as a routing protocol over the tunnel. 3.1.1.3. IPX-Protocol Extension This extension is OPTIONAL and must be present only if the client being registered supports IPX. This extension may be sent to register a new client on an existing tunnel even if the initial tunnel establishment request did not register IPX support. This extension can be repeated multiple times in the case that several IPX addresses are to be registered. In this case, a conventional router or dial-up router is serving multiple IPX addresses in the remote LAN. The format of the extension is: Calhoun et. al. [Page 21] DRAFT Virtual Tunneling Protocol July 1996 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Length | flag | IPX Network Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPX Network Number (cont.) | IPX Node Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPX Node Number (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-Type 11 (IPX Protocol Extension) Sub-Length 12 Flag Bit 1 MUST be set (mandatory support) IPX Network This field contains the IPX Network number of the remote client (as negotiated by IPXCP for a dial-up user). IPX Node Number This field contains the IPX Node number of the remote client. Interface Flags The Interface Flags field contains all attributes for the IPX protocol over the tunnel. The tunnel initiator may set all of the bits which it can support. The response from the tunnel terminator determines the interface properties which will be used over the tunnel. It is therefore possible to set a preference on either ends of the tunnel. It is possible to enable a routing protocol over an existing tunnel only if one was not already negotiated. It is not possible to disable such a protocol. The following flags have been reserved: VTP_IF_RIP_ROUTING 0x0001 If this bit is enabled, IPX RIP will be used as a routing protocol over the tunnel. Calhoun et. al. [Page 22] DRAFT Virtual Tunneling Protocol July 1996 VTP_IF_NLSP_ROUTING 0x0002 If this bit is enabled, NLSP will be used as a routing protocol over the tunnel. VTP_IF_IPXWAN_2 0x0004 If this bit is enabled, IPXWAN version 2 will be used over the tunnel interface. 3.1.1.4. Virtual-Private-Networking Extension The Virtual Networking Extension MAY be present in the Registration Request if the Mobile Node support the concept of VPN. The Registration MUST include this extension (although the name field may be removed). 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Length | flag | VPN Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VPN Identifier | VPN Name | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VPN Name (64) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-Type 9 (Virtual-Private-Networking Extension) Sub-Length variable Flag Bit 1 MUST be set (mandatory support) VPN ID The VPN Identifier is a numerical representation of the Domain. This customer identifier is assigned by the service provider and must be globally unique within the network. This value may be returned by the authentication server. Although many implementations will not make use of this extension, a registration response MUST include this extension if one was present in the corresponding request. VPN Name This optional field contains the ASCII representation of the VPN identifier, which MAY be the name of the customer Calhoun et. al. [Page 23] DRAFT Virtual Tunneling Protocol July 1996 (e.g. ABC Corp.). 3.1.1.5. Dynamic-Connection Extension The Dynamic Connection Extension MAY be present in the Registration Request if the circuit from the home agent to the CPE router is not permanent. The information contained in this extension should be sufficient in order for the home agent to establish a link with the CPE device. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Length | flag | Link Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-Type 7 (Dynamic-Connection Extension) Sub-Length variable Flag Bit 1 MUST be set (mandatory support) Link Type The Link Type field contains a numerical representation of the underlying link to use in order to connect to the CPE device. The following have already been defined: VTP_FR_SVC 0x0001 When set, the address refers to a Frame Relay Switched Virtual Circuit. VTP_ATM_SVC 0x0002 When set, the address refers to an ATM Switched Virtual Circuit. VTP_X25_SVC 0x0003 When set, the address refers to a X.25 Switched Virtual Circuit. Address A link layer address which the home agent must use in order to connect to the CPE router. The length of the address is determined by the length of the attribute Calhoun et. al. [Page 24] DRAFT Virtual Tunneling Protocol July 1996 (less the link type field). 3.1.1.6. Session-Key Extension The Session Key Extension MUST be present in the request. This extension contains the tunnel's session key which will be used for message autentication as well as encyption (if used). 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Length | flag | Encryption Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded Session Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded Session Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded Session Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded Session Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vector | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vector | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vector | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vector | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-Type 8 (Session-Key Extension) Sub-Length Variable Flag Bit 1 MUST be set (mandatory support) Encryption Type The Encryption Type field is used in order to inform the tunnel terminator the encryption technique which was used in order to encrypt the session key. The default value, which MUST be supported by all implementations is MD5 (type 0x0001). The following flags have been reserved: Calhoun et. al. [Page 25] DRAFT Virtual Tunneling Protocol July 1996 VTP_ENC_MD5 0x0001 If this bit is enabled, MD5 was used as the encryption technique. In this case, the Encoded Session Key contains an MD5 hash of the following: MD5(Vector|Shared Secret|Session Key) Where the vector is a 16 octet random value which was used by the session key encryptor to add randomness to the encoded value. The Shared Secret is the shared secret which is common between the peers (note it is possible that both peers do not shared a common secret, see section 9 for more information). VTP_ENC_DES 0x0002 This this bit is set, DES was used as the encryption technique. A Registration Response with an error of ERR_ENCRYPT_NOT_SUPPORTED informs the tunnel initiator that it must attempt an alternative encryption technique, or use the default value. Encoded Session Key This field contains a new encoded random 16 octet value. The size of the encoded session key is determined by the extension length field (less the 16 octet vector size for MD5 encoding). This value is only valid for the duration of the tunnel (and even shorter if session key renegotiation is done during the tunnel refresh process). The Mobile-Home Authentication extensions contains an SPI, which must be saved and is used in order to reference this session key. Vector This field contains a 16 octet random value which was used in encrypting the session key. This field is only present Calhoun et. al. [Page 26] DRAFT Virtual Tunneling Protocol July 1996 when the encryption type is set to MD5. 3.1.2. Mobile-Home Authentication Extension This extension is used as described in the IP Mobility specification. This extension MUST be added after the VTP extension in all tunnel management messages. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | Authenticator... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 32 Length 4 plus the number of bytes in the Authenticator. SPI Security Parameter Index. Contains a pseudo-random value which must be retained by the peer in order to use the session key which was negotiated in any future refresh and deregistration messages. Authenticator Contains a MD5 representation of the whole Tunnel Registration header up to and including this extension's length field. The value is computed from default authentication algorithm a keyed-MD5 hash of the following: MD5( Session Key | Packet | Session Key ) Where the packet is the whole Mobile IP packet up to and including the length field. The Session Key is a 16 octet randomized value. 3.2. Registration Response Upon receipt of the Registration Request from a mobile node proxy, the home agent will register the HOME IP Address for the VPN. Calhoun et. al. [Page 27] DRAFT Virtual Tunneling Protocol July 1996 The response from the home agent will be in the following format: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care of IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 3 (Registration Response) Code One of the following: 0 - Service will be provided 128 - reason unspecified 129 - administratively prohibited 130 - insufficient resources 131 - mobile node proxy failed authentication 133 - registration identification mismatch 134 - poorly formed request 135 - too many simutaneous mobility bindings 140 - The VPN has not been configured 141 - The IP Address already exists 142 - The IPX Address already exists 143 - Network Outage 144 - Encryption type not supported Lifetime The number of seconds remaining before the registration is considered expired. A value of all ones indicates infinity. Home IP Address For routers, this value is the IP address of the router. For Dial-up Routers, this is the IPCP assigned IP address. Calhoun et. al. [Page 28] DRAFT Virtual Tunneling Protocol July 1996 If the mobile node proxy does not support IP, this value is set to zero. Home Agent IP Address IP Address of the home agent, copied from the pending Registration Request. Care of Address The IP Address of the tunnel end located in the NAS or router. Identification The identification field consists of two parts. The most significant four bytes contain a valid timestamp, which is the number of seconds since January 1, 1900 (as defined by the NTP protocol). The least significant four bytes MUST contain the same value which was set in the request. This is used in order to simplify matching the request and the response. The following extensions will be added to the message: 3.2.1. VTP Extensions This extension is used to encapsulate all VTP specific extensions. This is done in order to conserve the small extension address space which is available in the Mobile IP header. Each sub-extension may all be encapsulated within one single VTP extension, or each sub-extension may be individually encapsulated with this extension. The format of the header is as defined below: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | flag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 65 (VTP Extensions) Length variable Calhoun et. al. [Page 29] DRAFT Virtual Tunneling Protocol July 1996 Sub-Type Sub Attribute Number Sub-Length Sub Attribute Length Flag The flag field contains a set of properties for the following sub-attribute. The following bits have been defined: VTP_MANDATORY_SUPPORT 0x01 If this bit is set, the attribute MUST be supported by the peer. If this attribute cannot be supported, an error code must be returned. 3.2.1.1. Tunnel-Identifier Extension This extension is REQUIRED for tunnel establishment requests and all further requests to register a new user to an existing tunnel. This extension SHOULD be the first extension following the protocol header. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Length | flag | Tunnel Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel Identifier | Interface Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-Type 1 (VTP Tunnel-Identifier Extension) Sub-Length 14 Flag Bit 1 MUST be set (mandatory support) Tunnel ID The Tunnel Identifier contains the GRE session ID. This identifier is used within each GRE header to indicate the session. The Tunnel ID contains two session identifiers; the least significant two bytes contains the initiator's session identifier and the most significant two bytes are the remote peer's session ID. Calhoun et. al. [Page 30] DRAFT Virtual Tunneling Protocol July 1996 When responding to a new Tunnel Registration Request, the peer inserts an unused integer within the most significant two bytes. If the initiator inserted a full tunnel identifier, which is no longer valid (e.g. the device has rebooted), it is necessary to insert a new value in the most significant two bytes. Interface Flags The Interface Flags field contains all attributes for the tunnel. The returned values will dictate to the peer what attributes to set for the tunnel. If a specific attribute cannot be supported, it should not be returned in the response, which the peer must consider as disabled for the tunnel. The response cannot contain flags which were not initially requested. 3.2.1.2. IP-Protocol Extension This extension MUST be present if the Registration Request included this extension. The absence of this extension, when expected, informs the tunnel initiator that the protocol is not supported by the home agent. The format of the extension is: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Length | flag | IP Network Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Network Address (cont.) | IP Subnet Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Subnet Mask (cont.) | Interface Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-Type 10 (IP-Protocol Extension) Sub-Length 10 Flag Bit 1 MUST be set (mandatory support) Calhoun et. al. [Page 31] DRAFT Virtual Tunneling Protocol July 1996 IP Network Address Set to the value which was in the Registration Request. IP Subnet Mask Set to the value which was in the Registration Request. Interface Flags The Interface Flags field contains the flags which the Home Agent is able to support. The home agent should not set more than one bit which is considered mutually exclusive (i.e. RIP and OSPF). The home agent may not enable a bit which was not present in the Registration Request. 3.2.1.3. IPX-Protocol Extension This extension MUST be present if the Registration Request included this extension. The absence of this extension, when expected, informs the tunnel initiator that the protocol is not supported by the home agent. The format of the extension is: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Length | flag | IPX Network Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPX Network Number (cont.) | IPX Node Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPX Node Number (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-Type 11 (IPX-Protocol Extension) Sub-Length 12 Flag Bit 1 MUST be set (mandatory support) IPX Network Set to the value which was in the Registration Request. IPX Node Number Set to the value which was in the Registration Request. Calhoun et. al. [Page 32] DRAFT Virtual Tunneling Protocol July 1996 Interface Flags The Interface Flags field contains the flags which the Home Agent is able to support. The home agent should not set more than one bit which is considered mutually exclusive (i.e. RIP and NLSP). The home agent may not enable a bit which was not present in the Registration Request. 3.2.1.4. Virtual-Private-Networking Extension The Virtual Private Networking Extension MUST be present if such an extension was present in the Registration Request. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Length | flag | VPN Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VPN Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-Type 9 (Virtual-Private-Networking Extension) Sub-Length 4 Flag Bit 1 MUST be set (mandatory support) VPN ID The VPN Identifier MUST contain the value which was reported in the Registration Request. 3.2.2. Mobile-Home Authentication Extension This extension is used as described in the IP Mobility specification. This extension MUST be added after the VTP extensions in all tunnel management messages. Calhoun et. al. [Page 33] DRAFT Virtual Tunneling Protocol July 1996 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | Authentication Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 32 (Mobile-Home Authentication Extension) Length 20 SPI Security Parameter Index. Contains a pseudo-random value which must be retained by the peer in order to use the session key which was negotiated in any future refresh and deregistration messages. Authentication Value Contains a MD5 representation of the whole Tunnel Registration packet up to and including this extensions length field. The value is a MD5 hash of the following: MD5( Session Key | Packet | Session Key ) Where the packet is the whole Mobile IP packet up to and including the length field. The Session Key is a 16 octet randomized value. 3.3. Refresh Request The Refresh Request messages is sent from the mobile node proxy to the home agent. This message is sent from the mobile node proxy to the home agent in order to "refresh" the tunnel and ensure that it does not expire. Note that although the layer 3 protocols do not require the Home Agent to send a refresh request to the Mobile Node for any reason, there may exist other extensions which do require this feature. For this reason, Calhoun et. al. [Page 34] DRAFT Virtual Tunneling Protocol July 1996 it is possible for a Home Agent to initiate a refresh request. The following message format is used: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |S|B|F|M|G|V|T|r| Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care of IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 2 (Refresh Request) S, B, M, V All set to zero to disable features not required. D 1, The mobile node proxy will itself decapsulate datagrams which are sent to the care-of address. G 1, GRE encapsulation enabled. T 1, Bi-directional tunneling enabled. r 0, Reserved Field Lifetime Contains a value indicating the number of seconds before the tunnel expires. Home IP Address Set to zero. Home Agent IP Address IP Address of the home agent IP Address Care of Address The IP Address of the tunnel end located in the NAS. Identification The identification field consists of two parts. The most significant four bytes contain a valid timestamp, which is the number of seconds since January 1, 1900 Calhoun et. al. [Page 35] DRAFT Virtual Tunneling Protocol July 1996 (as defined by the NTP protocol). The least significant four bytes contain a random value. The following extensions will be added to the message: 3.3.1. VTP Extensions This extension is used to encapsulate all VTP specific extensions. This is done in order to conserve the small extension address space which is available in the Mobile IP header. Each sub-extension may all be encapsulated within one single VTP extension, or each sub-extension may be individually encapsulated with this extension. The format of the header is as defined below: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | flag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 65 (VTP Extensions) Length variable Sub-Type Sub Attribute Number Sub-Length Sub Attribute Length Flag The flag field contains a set of properties for the following sub-attribute. The following bits have been defined: VTP_MANDATORY_SUPPORT 0x01 If this bit is set, the attribute MUST be supported by the peer. If this attribute cannot be supported, an error code must be returned. Calhoun et. al. [Page 36] DRAFT Virtual Tunneling Protocol July 1996 3.3.1.1. Tunnel-Identifier Extension This extension is REQUIRED for tunnel establishment requests and all further requests for a new client to use an existing tunnel. This extension SHOULD be the first extension following the protocol header. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Length | flag | Tunnel Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-Type 1 (VTP Tunnel-Identifier Extension) Sub-Length 4 Flag Bit 1 MUST be set (mandatory support) Tunnel ID The Tunnel Identifier contains the GRE session ID. This identifier is used within each GRE header to indicate the session. The Tunnel ID contains two session identifiers; the least significant two bytes contains the tunnel initiator's session identifier and the most significant two bytes are the peer's session ID. 3.3.1.2. Virtual-Private-Networking Extension The Virtual Private Networking Extension MUST be present if such an extension was present in the Registration Request. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Length | flag | VPN Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VPN Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-Type 9 (Virtual-Private-Networking Extension) Calhoun et. al. [Page 37] DRAFT Virtual Tunneling Protocol July 1996 Sub-Length 4 Flag Bit 1 MUST be set (mandatory support) VPN ID The VPN Identifier MUST be set to the same value as the one which was reported in the original Registration Request. 3.3.1.3. Session-Key Extension The Session Key Extension is optional during the tunnel refresh process. It is used if the mobile node proxy wishes to negotiate a new session key with the home agent. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Length | flag | Encryption Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded Session Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded Session Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded Session Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded Session Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vector | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vector | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vector | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vector | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-Type 8 (Session-Key Extension) Sub-Length Variable Flag Bit 1 MUST be set (mandatory support) Encryption Type The Encryption Type field is used in order to inform the tunnel terminator the encryption technique which was used in order to encrypt the session key. Calhoun et. al. [Page 38] DRAFT Virtual Tunneling Protocol July 1996 The default value, which MUST be supported by all implementations is MD5 (type 0x0001). The following flags have been reserved: VTP_ENC_MD5 0x0001 If this bit is enabled, MD5 was used as the encryption technique. In this case, the Encoded Session Key contains an MD5 hash of the following: MD5(Vector|Shared Secret|Session Key) Where the vector is a 16 octet random value which was used by the session key encryptor to add randomness to the encoded value. The Old Session Key is the session which is still valid between both peers. It is recommended that the peers remember the Old Session Key for a short period in order to deal with out of order packets which may have been authenticated or encrypted using the Old Session Key. VTP_ENC_DES 0x0002 This this bit is set, DES was used as the encryption technique. A Registration Response with an error of ERR_ENCRYPT_NOT_SUPPORTED informs the tunnel initiator that it must attempt an alternative encryption technique, or use the default value. Encoded Session Key This field contains a new encoded random 16 octet value. The size of the encoded session key is determined by the extension length field (less the 16 octet vector size for MD5 encoding). This value is only valid for the duration of the tunnel (and even shorter if session key renegotiation is done during the tunnel refresh process). Calhoun et. al. [Page 39] DRAFT Virtual Tunneling Protocol July 1996 The Mobile-Home Authentication extensions contains an SPI, which must be saved and is used in order to reference this session key. Vector This field contains a 16 octet random value which was used in encrypting the session key. This field is only present when the encryption type is set to MD5. 3.3.2. Mobile-Home Authentication Extension This extension is used as described in the IP Mobility specification. This extension MUST be added after the VTP extensions in all tunnel management messages. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | Authentication Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 32 (Mobile-Home Authentication Extension) Length 20 SPI Security Parameter Index. Contains a pseudo-random value which must be retained by the peer in order to use the session key which was negotiated in any future refresh and deregistration messages. Authentication Value Contains a MD5 representation of the whole Tunnel Registration packet up to and including this extensions length field. The value is a MD5 hash of the following: MD5( Session Key | Packet | Session Key ) Calhoun et. al. [Page 40] DRAFT Virtual Tunneling Protocol July 1996 Where the packet is the whole Mobile IP packet up to and including the length field. The Session Key is a 16 octet randomized value. 3.4. Refresh Response The response from the home agent will be in the following format: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care of IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 4 (Refresh Response) Code One of the following: 0 - Service will be provided 128 - reason unspecified 129 - administratively prohibited 130 - insufficient resources 131 - mobile node proxy failed authentication 133 - registration identification mismatch 134 - poorly formed request 135 - too many simutaneous mobility bindings 140 - The VPN has not been configured 141 - The IP Address already exists 142 - The IPX Address already exists 143 - Network Outage 144 - Encryption type not supported Lifetime The number of seconds before the Gateway will consider the tunnel expired, unless a refresh or new tunnel Registration Calhoun et. al. [Page 41] DRAFT Virtual Tunneling Protocol July 1996 Request is received. Home IP Address Set to zero. Home Agent IP Address IP Address of the home agent, copied from the pending Refresh Request. Identification The identification field consists of two parts. The most significant four bytes contain a valid timestamp, which is the number of seconds since January 1, 1900 (as defined by the NTP protocol). The least significant four bytes MUST contain the same value which was set in the request. This is used in order to simplify matching the request and the response. The following extension will be added to the message: 3.4.1. VTP Extensions This extension is used to encapsulate all VTP specific extensions. This is done in order to conserve the small extension address space which is available in the Mobile IP header. Each sub-extension may all be encapsulated within one single VTP extension, or each sub-extension may be individually encapsulated with this extension. The format of the header is as defined below: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | flag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 65 (VTP Extensions) Length variable Sub-Type Sub Attribute Number Sub-Length Sub Attribute Length Flag The flag field contains a set of properties for the following sub-attribute. Calhoun et. al. [Page 42] DRAFT Virtual Tunneling Protocol July 1996 The following bits have been defined: VTP_MANDATORY_SUPPORT 0x01 If this bit is set, the attribute MUST be supported by the peer. If this attribute cannot be supported, an error code must be returned. 3.4.1.1. Tunnel-Identifier Extension This extension is REQUIRED for tunnel refresh messages. This extension SHOULD be the first extension following the protocol header. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Length | flag | Tunnel Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-Type 1 (VTP Tunnel-Identifier Extension) Sub-Length 4 Flag Bit 1 MUST be set (mandatory support) Tunnel ID The Tunnel Identifier contains the GRE session ID. This identifier is used within each GRE header to indicate the session. The Tunnel ID contains two session identifiers; the least significant two bytes contains the tunnel initiator's session identifier and the most significant two bytes are the peer's session ID. 3.4.1.2. Virtual-Private-Networking Extension The Virtual Private Networking Extension MUST be present if such an extension was present in the Refresh Request. Calhoun et. al. [Page 43] DRAFT Virtual Tunneling Protocol July 1996 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Length | flag | VPN Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VPN Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-Type 9 (Virtual-Private-Networking Extension) Sub-Length 4 Flag Bit 1 MUST be set (mandatory support) VPN ID The VPN Identifier MUST be set to the same value as the one which was reported in the original Registration Request. 3.4.2. Mobile-Home Authentication Extension This extension is used as described in the IP Mobility specification. This extension MUST be added as the first extension in all tunnel management messages. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | Authentication Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 32 (Mobile-Home Authentication Extension) Length 20 SPI Security Parameter Index. Contains the Security association value which was used during the session key management Calhoun et. al. [Page 44] DRAFT Virtual Tunneling Protocol July 1996 for the key used in creating the Authentication value for this message. Authentication Value Contains a MD5 representation of the whole Tunnel Registration packet up to and including this extensions length field. The value is a MD5 hash of the following: MD5( Session Key | Packet | Session Key ) Where the packet is the whole Mobile IP packet up to and including the length field. The Session Key is a 16 octet randomized value. 3.5. Deregistration Request The Deregistration Request messages is sent from the mobile node proxy to the home agent. This message is sent to the home agent in order to shutdown the tunnel. For a NAS this is done when the PPP connection is terminated. For routers, this may be done when the connection has been idle for a specified amount of time. Note that although the layer 3 protocols do not require the Home Agent to send a Deregistration request to the Mobile Node for any reason, there may exist other extensions which do require this feature. For this reason, it is possible for a Home Agent to initiate a refresh request. The following message format is used: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |S|B|F|M|G|V|T|r| Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care of IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 1 (Deregistration Request) Calhoun et. al. [Page 45] DRAFT Virtual Tunneling Protocol July 1996 S, B, M, V All set to zero to disable features not required. D 1, The mobile node proxy will itself decapsulate datagrams which are sent to the care-of address. G 1, GRE encapsulation enabled. T 1, Bi-directional tunneling enabled. r 0, Reserved Field Lifetime Contains a value of zero to indicate a deregistration. Home IP Address For routers, this value is the IP address of the router. For Dial-up Routers, this is the IPCP assigned IP address. If the mobile node proxy does not support IP, this value is set to zero. Home Agent IP Address IP Address of the home agent IP Address Care of Address The IP Address of the tunnel initiator (Foreign Agent). Identification The identification field consists of two parts. The most significant four bytes contain a valid timestamp, which is the number of seconds since January 1, 1900 (as defined by the NTP protocol). The least significant four bytes contain a random value. The following extensions will be added to the message: 3.5.1. VTP Extensions This extension is used to encapsulate all VTP specific extensions. This is done in order to conserve the small extension address space which is available in the Mobile IP header. Each sub-extension may all be encapsulated within one single VTP extension, or each sub-extension may be individually encapsulated with this extension. Calhoun et. al. [Page 46] DRAFT Virtual Tunneling Protocol July 1996 The format of the header is as defined below: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | flag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 65 (VTP Extensions) Length variable Sub-Type Sub Attribute Number Sub-Length Sub Attribute Length Flag The flag field contains a set of properties for the following sub-attribute. The following bits have been defined: VTP_MANDATORY_SUPPORT 0x01 If this bit is set, the attribute MUST be supported by the peer. If this attribute cannot be supported, an error code must be returned. 3.5.1.1. Tunnel-Identifier Extension This extension is REQUIRED for tunnel establishment requests and all further requests for a new client to use an existing tunnel. This extension SHOULD be the first extension following the protocol header. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Length | flag | Tunnel Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-Type 1 (VTP Tunnel-Identifier Extension) Sub-Length 10 Calhoun et. al. [Page 47] DRAFT Virtual Tunneling Protocol July 1996 Flag Bit 1 MUST be set (mandatory support) Tunnel ID The Tunnel Identifier contains the GRE session ID. This identifier is used within each GRE header to indicate the session. The Tunnel ID contains two session identifiers; the least significant two bytes contains the tunnel initiator's session identifier and the most significant two bytes are the peer's session ID. 3.5.1.2. IP-Protocol Extension This extension MUST be present if the Registration Request included this extension. The presence of this extension informs the home agent that this remote IP address no longer exists. Thus, this IP address MUST be removed from the binding table in the home agent. The format of the extension is: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Length | flag | IP Network Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Network Address (cont.) | IP Subnet Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Subnet Mask (cont.) | Interface Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-Type 10 (IP-Protocol Extension) Sub-Length 10 Flag Bit 1 MUST be set (mandatory support) IP Network Address Set to the value which was in the Registration Request. IP Subnet Mask Set to the value which was in the Registration Request. Interface Flags Set to zero (0). Calhoun et. al. [Page 48] DRAFT Virtual Tunneling Protocol July 1996 3.5.1.3. IPX-Protocol Extension This extension MUST be present if the Registration Request included this extension. The presence of this extension informs the home agent that this remote IP address no longer exists. Thus, this IP address MUST be removed from the binding table in the home agent. The format of the extension is: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Length | flag | IPX Network Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPX Network Number (cont.) | IPX Node Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPX Node Number (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sub-Type 11 (IPX-Protocol Extension) Sub-Length 12 Flag Bit 1 MUST be set (mandatory support) IPX Network Set to the value which was in the Registration Request. IPX Node Number Set to the value which was in the Registration Request. Interface Flags Set to zero (0). 3.5.1.4. Virtual-Private-Networking Extension The Virtual Private Networking Extension MUST be present if such an extension was present in the Registration Request. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Length | flag | VPN Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VPN Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Calhoun et. al. [Page 49] DRAFT Virtual Tunneling Protocol July 1996 Sub-Type 9 (Virtual-Private-Networking Extension) Sub-Length 4 Flag Bit 1 MUST be set (mandatory support) VPN ID The VPN Identifier MUST contain the value which was reported in the Registration Request. 3.5.2. Mobile-Home Authentication Extension This extension is used as described in the IP Mobility specification. This extension MUST be added after the VTP extensions in all tunnel management messages. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | Authentication Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 32 (Mobile-Home Authentication Extension) Length 20 SPI Security Parameter Index. Contains the Security association value which was used during the session key management for the key used in creating the Authentication value for this message. Authentication Value Contains a MD5 representation of the whole Tunnel Registration packet up to and including this extensions length field. The value is a MD5 hash of the following: MD5( Session Key | Packet | Session Key ) Calhoun et. al. [Page 50] DRAFT Virtual Tunneling Protocol July 1996 Where the packet is the whole Mobile IP packet up to and including the length field. The Session Key is a 16 octet randomized value. 3.6. Deregistration Response The response from the home agent will be in the following format: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care of IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 3 (Deregistration Response) Code One of the following: 0 - Service will be provided 128 - reason unspecified 129 - administratively prohibited 130 - insufficient resources 131 - mobile node proxy failed authentication 133 - dereg. identification mismatch 134 - poorly formed request 140 - The VPN has not been configured 141 - The IP Address already exists 142 - The IPX Address already exists 143 - Network Outage Lifetime 0 Home IP Address IPCP assigned IP address, copied from the pending Deregistration Request. Home Agent IP Address IP Address of the home agent, copied from Calhoun et. al. [Page 51] DRAFT Virtual Tunneling Protocol July 1996 the pending Deregistration Request. Identification The identification field consists of two parts. The most significant four bytes contain a valid timestamp, which is the number of seconds since January 1, 1900 (as defined by the NTP protocol). The least significant four bytes MUST contain the same value which was set in the request. This is used in order to simplify matching the request and the response. The following extension will be added to the message: 3.6.1. Mobile-Home Authentication Extension This extension is used as described in the IP Mobility specification. This extension MUST be added as the first extension in all tunnel management messages. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | Authentication Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 32 (Mobile-Home Authentication Extension) Length 20 SPI Security Parameter Index. Contains the Security association value which was used during the session key management for the key used in creating the Authentication value for this message. Calhoun et. al. [Page 52] DRAFT Virtual Tunneling Protocol July 1996 Authentication Value Contains a MD5 representation of the whole Tunnel Registration packet up to and including this extensions length field. The value is a MD5 hash of the following: MD5( Packet | Session Key ) Where the packet is the whole Mobile IP packet up to and including the length field. The Session Key is a 16 octet randomized value. 4.2. Data Encapsulation Once a "tunnel" has been established via a success Registration Request, all data is encapsulated within a GRE header. This section defines the encapsulation header which is required for the VTP and L2TP extension. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C|R|K|S|s|Recur|A|T|L|Flg| Ver | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CheckSum (Opt) | Offset(Opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key (Opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number (Opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C Checksum Present. Set to zero (0). R Routing Present. Set to zero (0). K Key Present. Set to zero (0). Set to (1) if the GRE header is to be authenticated and contains the Key field. S Sequence Number Present. Set to zero (0). Calhoun et. al. [Page 53] DRAFT Virtual Tunneling Protocol July 1996 s Strict Source Route Present. Set to zero (0). A Acknowledgment sequence number present. Set to zero (0). T Tunnel Identifier. Set to one (1). L L2TP Tunnel Information. Set to zero (0). Recur Recursion control. set to zero (0). Flg (Flags) Must be set to zero. Ver Must contain 0. Protocol Type Contains the Assigned Protocol ID (see assigned numbers RFC). Key Key field is zero if each data packet is not authenticated. Tunnel Identifier Contains the Tunnel Identifier which was negotiated during the Registration process. Present if the 'T' bit is set. This field is used in order to identify which tunnel the data belongs to. Note that an encapsulated packet which contains an invalid tunnel identifier in the Tunnel ID field MUST be dropped. 4. Radius Support In order for NAS' to support the VTP protocol, a minimum amount of configuration is required for tunnel management. It is desirable to allow the configuration to exist on a separate server in order to minimize deployment configuration issues. For this reason, the following RADIUS attributes have been defined. 4.1. VPN ID The VPN ID is returned by the Radius Server in order for the NAS to identify a VPN. The following packet format extension is added to the ACCESS_ACCEPT packet. Calhoun et. al. [Page 54] DRAFT Virtual Tunneling Protocol July 1996 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Organization ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Organization ID(cont.) | Indicator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Indicator (cont.) | VPN Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VPN Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 26 (Vendor Specific) Length 14 Organization ID 429 for US Robotics 430 for Bay Networks Indicator 0x9006 (VPN-ID) VPN Identifier 4 byte VPN Identifier 4.2. VPN Name The VPN Name is returned by the Radius Server in order for the NAS to identify a VPN Name. The presence of this attribute is optional and is used primarily for the command line display. The following packet format extension is added to the ACCESS_ACCEPT packet. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Organization ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Organization ID(cont.) | Indicator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Indicator (cont.) | VPN Name.. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 26 (Vendor Specific) Length Variable Organization ID 429 for US Robotics 430 for Bay Networks Indicator 0x9007 (VPN-Name) Calhoun et. al. [Page 55] DRAFT Virtual Tunneling Protocol July 1996 VPN Name Null Terminated String Containing the VPN Name. 4.3. VPN Gateway The VPN Gateway MUST be returned by the Radius Server within the ACCESS_ACCEPT messages in order for the NAS to correctly identify the home agent associated with the mobile node proxy. Note that more than one VPN Gateway attribute may be returned in a single ACCESS_ACCEPT. The following packet extension will be returned: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Organization ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Organization ID(cont.) | Indicator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Indicator (cont.) | Addr Format | VPN Gateway | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VPN Gateway | Enc Sess. Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded Session Key (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded Session Key (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded Session Key (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded Session Key (cont.) |Tunnel Refresh | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Tunnel Refresh | Desc. Length | Description ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 26 (Vendor Specific) Length variable Organization ID 429 for US Robotics 430 for Bay Networks Indicator 0x900A (VPN-Gateway) Address Format Contains a byte which represents the VPN Gateway field's Address format. The following values are currently supported: VTP_ADDRESS_TYPE_IPV4 0x01 The address contains a 32 bit IP Calhoun et. al. [Page 56] DRAFT Virtual Tunneling Protocol July 1996 version 4 address. VTPADDRESS_TYPE_IPV6 0x02 The address contains an IP Version 6 address. VPN Gateway Contains a 4 octet IP Address of the home agent. Enc. Session Key Contains a 16 octet value to be sent to the home agent. This string contains the encoded value of the Session Key. Tunnel Refresh Contains an optional Tunnel Refresh value in seconds. Desc. Length Contains the number of bytes of the description string. Description Contains an ASCII description of the Home Agent (i.e. location information). 4.4. Session Key Vector This attribute is returned by the remote Radius server in the Access-Accept packet. It must be present if the VPN Gateway attribute is present. The NAS uses the session key vector attribute to determine the Session Key that it shares with the Frame Relay Gateway. The following packet extension will be returned: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Organization ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Organization ID(cont.) | Indicator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Indicator (cont.) | Encoded Session Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded Session Key (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded Session Key (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded Session Key (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encoded Session Key (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Calhoun et. al. [Page 57] DRAFT Virtual Tunneling Protocol July 1996 Type 26 (Vendor Specific) Length 26 Organization ID 429 for US Robotics 430 for Bay Networks Indicator 0x900B (Session Key Vector) Enc. Session Key Contains a 16 octet vector, which contains a four octet, encoded Session Key. 5. Security Mechanism This section will detail the security mechanisms used by for the tunneling protocol. 5.1. Data Authentication There exists a problem where a malicious user may spoof encapsulated packets to the mobile node proxy or home agent by adding the GRE header. In order to minimize this occurrence, it is desirable to add a header which contains a Message Integrity Check (MIC). The IP Authentication Header is used for this purpose in the following manner: +-----------------------------------------------------+ | IP Header | Auth Header | GRE Header | User Payload | +-----------------------------------------------------+ Note that the use of the data authentication header is optional and is outside of the scope of this document. 5.2. Data Encryption In order to provide a true secure tunnel over an unsecure network, it is desirable to encrypt the user data. The ESP Header is used for this purpose in the following manner: +----------------------------------------------------+ | IP Header | ESP Header | GRE Header | User Payload | +----------------------------------------------------+ Note that the use of the data encryption header is optional and is outside of the scope of this document. Calhoun et. al. [Page 58] DRAFT Virtual Tunneling Protocol July 1996 5.3. Multi-Provider Tunnel Establishment Security In order to support multi-provider networks, it must be assumed that the NAS and the Gateway exist on different networks. In order to support such a scenario, it is required that tunnel establishment ONLY occur upon consent of the provider which owns the Gateway. In this case, it is unlikely that both the mobile node proxy and the home agent share a common secret, therefore it is necessary for a third party server to perform the session key encryption. Service Provider A | Service Provider B +----------------+----------------+ | | | + | + /| Public | Network |\ / | | | \ / | | | \ / | | | \ +------------/+ | | | +\------------+ |RADIUS Server| ++---------------+---------------++ |RADIUS Server| | | / | \ | | +------+------+ / | \ +------+------+ | / | \ | | / | \ | | / | \ | | / | \ | +------+----/-+ | +-\----+------+ | NAS | | | VTP Server | | | | | | +------+------+ | +------+------+ | | | ------+------ | ------+------ | | +------+------+ +------+------+ | Joe@ABC | |ABC's Router| | | | | +-------------+ +------+------+ | | | ---+--------+------- | | +------+------+ | Host | | | +-------------+ Figure 3: Multi-Provider Network Calhoun et. al. [Page 59] DRAFT Virtual Tunneling Protocol July 1996 Figure 3 depicts a scenario with multiple service providers. In this example, user Joe@ABC dials into a local service provider to connect to his company's corporate backbone. In this example, the home agent which serves the corporation is owned by a separate service provider. Note that in this example RADIUS is used, but the protocol is not limited to RADIUS. When the call is received by the NAS, an ACCESS_REQUEST is sent to the local RADIUS Server. The RADIUS Server then figures out that the authentication request must be forwarded to Service Provider B's RADIUS Server. If the Remote RADIUS Server successfully authenticates the user, then two attributes are attached to the ACCESS_ACCEPT. The server generates a random 16 octet value one which will be used as a temporary session key for that tunnel (which is only valid for the duration of the tunnel). The good formula for generating the random value is known as the linear congruential algorithm, where: Xn+1 = (A*Xn + C) (mod M), n>=0 Where: Xn = See formula below. M = 248 A = 2736731631558 C = 138 And X0 = seed(25) 330E16 Where the most significant 32 bits are set to the seed and the least significant 16 bits are set to the constant value. The X0 value is plugged into the above formula and the random value returned is in fact the first 32 bits of X1. The RADIUS Server then encrypts the Session Key using the RAD->RAD Shared Secret and adds it to the Session Key Vector Attribute (see 5.4). The actual encryption mechanism used is as follow: ( md5( CHAP Vector | RAD->RAD SS ) Å Session Key ) The Remote RADIUS Server then also encodes the same Session Key using the it's common shared secret with the gateway which it will return in the Frame Relay Gateway RADIUS attribute. The resulting hash will be added to the same attribute (see 7.2.4). The encryption mechanism is: ( md5( CHAP Vector | GW->RAD SS ) Å Session Key ) Calhoun et. al. [Page 60] DRAFT Virtual Tunneling Protocol July 1996 If the RADIUS Server is to return more than one Frame Relay Gateway attributes, the above encryption is done for each gateway, using the GW->RAD SS which is common between them. Note that the NAS will attempt to establish a tunnel with the IP address which is in the first Gateway attribute, and will try any other Gateways if more than one attribute was returned and the first Gateway did not respond. Once the Local RADIUS Server receives the packet, it will check for the Session Key Vector attribute. If one is found, knowing RAD->RAD SS, it will extract the Session Key from the attribute and re-encrypt the pair using the shared secret which is common between itself and the requesting NAS. The formula is as follow: ( md5( CHAP Vector | NS->RAD SS ) Å Session Key ) Once the NAS receives the response, it will extract the Session Key from the attribute. When the Tunnel Registration Request is formed, the RADIUS Identification field and the encrypted session key must be inserted in the Registration Extensions of the Registration Request. At this point, the NAS will add a Mobile-Home Authentication Extension and use the unencrypted Session Key to do the following formula: ( md5( RR Packet | Session Key) ) Where: RR Packet The whole Tunnel Registration Request up to the SPI field of the Mobile-Home Authentication Extension. Upon receipt of the Tunnel Registration Request, the Frame Relay Gateway, knowing it's common shared secret with it's local RADIUS Server (in this case the RADIUS Server in provider B's network), extracts the Session Key. Using the Session Key, the Gateway will MD5 the packet as shown above and ensure that the result is identical to the value which is included in the Mobile-Home Authentication Extension. Note that the Registration Request/Response each contained an SPI value in the Mobile-Home Authentication Extension. This value must be retained by each peer in order to send a subsequent message (i.e. Tunnel Refresh/Deregistration). This allows the use of multiple session keys per tunnel, and by using the SPI there is a method to inform the peer which session key was used for which message. There are two methods of doing this, one where the peers share a shared secret (pre-configured in some way), which is used in decrypting the shared secret. The alternative, yet more complex, Calhoun et. al. [Page 61] DRAFT Virtual Tunneling Protocol July 1996 requires an external Key Distribution Center to handle the distribution of keys. Due to the uniqueness of this protocol, the KDC required for this protocol does not fit with any existing key distribution scheme. This approach has the benefit of a much greater secure environment, which allows intra service provider tunnels. Note that in both cases, the session key generation is only valid for the duration of the tunnel. Section 9 covers the security mechanism in more detail. Acknowledgements We would like to thank the following people for their help and support: Noor Kamruddin, Sumit Vakil, Peter Pappas, Pat Henkle, Kurtiss Johnson, Greg Linn, Nagaraj Arunkumar, Johnathan Zarkower, Wei Hioe, Art Muzaffar, Lionel Gibbons, Jun Lopez, Micheal Shapiro, Gary Malkin, Paul Raison, Tommy Kwan. We would also like to thank the following manufacturers for their support in the development of VTP: US Robotics Access Corp, Bay Networks Inc., ECI Telematics, 3Com Corp., Novell Corp. References [1] C. Huitema, "Routing in the Internet", Prentice Hall, 1995 [2] C. Hedrick, "Routing Information Protocol", RFC-1058, Rutgers University, June 1988 [3] C. Perkins, "IP Mobility Support", draft-ietf-mobileip-protocol-13.txt November 1995 [4] R. Atkinson, "Security Architecture for the Internet Protocol", RFC-1825, August 1995 [5] R. Atkinson, "IP Authentication Header", RFC-1826, August 1995 [6] R. Atkinson, "IP Encapsulating Security Payload", RFC-1827, August 1995 [7] P. Metzger, "IP Authentication using keyed MD5", RFC-1828, August 1995 [8] P. Karn, "The ESP DES-CBC Transform", RFC-1829, August 1995 Calhoun et. al. [Page 62]