idnits 2.17.1 draft-calhoun-vtp-protocol-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == There are 3 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 284 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 213: '... MUST This word, o...' RFC 2119 keyword, line 217: '... MUST NOT This phrase ...' RFC 2119 keyword, line 220: '... SHOULD This word, o...' RFC 2119 keyword, line 228: '... MAY This word, o...' RFC 2119 keyword, line 231: '...nclude this option MUST be prepared to...' (84 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 90 has weird spacing: '... tunnel inter...' == Line 568 has weird spacing: '...e added to th...' == Line 1913 has weird spacing: '...implify match...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 1996) is 10146 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'NTP' on line 759 == Unused Reference: '1' is defined on line 2853, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 2855, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 2861, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 2864, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 2866, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 2869, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 2872, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Downref: Normative reference to an Historic RFC: RFC 1058 (ref. '2') == Outdated reference: A later version (-17) exists of draft-ietf-mobileip-protocol-13 ** Obsolete normative reference: RFC 1825 (ref. '4') (Obsoleted by RFC 2401) ** Obsolete normative reference: RFC 1826 (ref. '5') (Obsoleted by RFC 2402) ** Obsolete normative reference: RFC 1827 (ref. '6') (Obsoleted by RFC 2406) ** Downref: Normative reference to an Historic RFC: RFC 1828 (ref. '7') Summary: 17 errors (**), 0 flaws (~~), 13 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Pat R. Calhoun 3 Internet Draft US Robotics Access Corp. 4 expires in six months Ellis Wong 5 Bay Networks, Inc. 6 July 1996 8 Virtual Tunneling Protocol (VTP) 9 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 To learn the current status of any Internet-Draft, please check the 24 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 Abstract 31 This document specifies a protocol which allows various Layer 2 and 32 Layer 3 protocols to be tunneled through an IP network. VTP does not 33 specify any change to the protocol to be tunneled. It describes the 34 mechanisms for dynamically establishing and maintaining secure IP 35 tunnels, and carrying multiprotocol data over those tunnels. VTP 36 can be used in the implementation of Virtual Private Networks (VPNs). 38 A client-server architecture is defined in order to decouple functions 39 which exist in the tunnel initiation node and those in the tunnel 40 termination node. This protocol can be implemented in network 41 devices such as network access servers, routers and application servers. 43 VTP specifies a Mobile IP-like message exchange protocol to create 44 and manage IP tunnel sessions dynamically. VTP uses the GRE (Generic 45 Routing Encapsulation) mechanism to encapsulate multi-protocol 46 payload traffic. 48 1. Introduction 50 The Virtual Tunneling Protocol (VTP) is a protocol which enables a 51 service provider to offer Virtual Private Network (VPN) services and 52 dial access services to corporate home networks. The corporate 53 enterprise can subscribe to the service to allow its telecommuters, 54 mobile professionals and users in remote branch offices to connect 55 back to the corporate network, via the service provider's network. 57 In order to provide a true "multiprotocol" VPN technology, it is 58 necessary to perform some form of encapsulation and tunneling in 59 order to mask the private address space being used. This technology 60 must be sufficiently secure in order to protect the network resources 61 from outside attack. 63 There exists some basic form of VPN technology today by some 64 manufacturers, however these are either very static in nature or are 65 proprietary solutions. The intent of this document is to establish a 66 standard, dynamic tunnel establishment scheme which require minimal 67 configuration in order to ease deployment of such products. 69 This protocol allows dynamic tunnel establishment between two 70 network elements over an IP network infrastructure, with extensibility 71 to provide tunnel security. This protocol can be used to construct a 72 corporate VPN by implementing the VTP client functions in a remote 73 office router and the VTP server functions a router in the corporate 74 network. This protocol can also be used to enable dial access to 75 corporate networks via an IP tunnel, through the service provider's 76 infrastructure. To support this capability, the VTP client functions 77 can be implemented in a service provider Network Access Server (NAS) 78 and the VTP server functions can be implemented in a router in a 79 corporate network. In this case, the corporate enterprise can out- 80 source the purchase, installation and management of the remote access 81 equipment, such as the NAS, to service providers for cost savings. 83 The protocol is extensible to support any Layer 2 and Layer 3 protocol 84 to be tunneled over an IP network. The protocol is also flexible by 85 allowing the IP tunnel to be terminated within a customer premise, or 86 within a service provider network. Many corporate enterprises may 87 already have subscribed to service providers for VPN services such as 88 Frame Relay, SMDS, or even ATM. By terminating IP tunnels in a 89 gateway residing within the service provider network, the provider can 90 now offer dial-up IP tunnel interworking with other existing VPN 91 services. With this offering, the corporate enterprise may now obtain 92 remote dial access service from the same provider with no hardware or 93 software change required in the customer premise equipment (CPE). 95 This specification simply details the protocol which is used for 96 tunnel management between two devices. In the case of support for a 97 dial-up PPP connection, user authentication is assumed to be managed 98 by the corporate enterprise, not the service provider. This protocol 99 does not require the use of a specific user authentication protocol. 100 The PPP CHAP and RADIUS protocols are used in examples to 101 facilitate discussion. 103 In case of support for LAN interconnection across the service 104 provider's IP network infrastructure, routers are used in examples to 105 describe the router to router tunneling capability of the protocol. 106 The VTP protocol does not require the use of a specific IP 107 security mechanism. A public/private key management mechanism can 108 be used to provide secure tunneling functionality. 110 1.1. Protocol Goals and Assumptions 112 The VTP protocol only needs to be implemented in a tunnel initiation 113 node and a tunnel termination node. The tunneling functions are 114 transparent to the dial-up hosts or remote office routers, as well as 115 the intermediate systems in the IP backbone. Hence, no change is 116 required in those systems. 118 If the tunnel initiation node is a NAS, then it is responsible for 119 physical interfacing to the PSTN or ISDN. It is also responsible for 120 the logical termination of the PPP or SLIP connection, and the tunnel 121 initiation from an IP network interface. If the tunnel termination 122 node is a router, then it simply consists of one of more LAN 123 interfaces, and at least one IP network interface which the IP tunnel 124 is initiated from. 126 Authentication is provided via PPP CHAP or PAP, or through 127 other dialogs as needed for protocols which do not use authentication 128 (i.e. SLIP). User authentication is managed from the enterprise home 129 network. This specification does not require the use of one specific 130 user authentication protocol (i.e., RADIUS, TACACS+). 132 The VTP protocol also must support enterprises which use private 133 network addresses for corporate virtual private networking. In the 134 case the tunnel initiator is a NAS, the enterprise assigns an address 135 for the dial-up node, which is meaningful to the enterprise home 136 network, during the user authentication process. 138 1.2. Terminology 140 This document frequently uses the following terms: 142 DLCI Data Link Connection Identifier is a unique identifier 143 for a virtual circuit at each Frame Relay interface. 145 PVC Permanent Virtual Circuits are connections which are 146 permanent in nature. 148 SVC Switched Virtual Circuits are connections which are 149 dynamic in nature. 151 Care-of Address 152 The termination point of a tunnel towards a mobile node, 153 for datagrams forwarded to the mobile node while it is 154 away from home. This protocol specifies the use of a 155 "co-located care-of address", which is an externally 156 obtained local address which the mobile node has 157 associated with one of its own network interfaces. 159 Foreign Agent 160 A router on a mobile node's visited network which 161 provides routing relay services to the registered mobile 162 node. The foreign agent decapsulates and delivers 163 datagrams to the mobile node which were tunneled by the 164 mobile node's home agent. 166 For datagrams sent by the a mobile node, the foreign 167 agent may serve as a default router for mobile nodes. 169 Gateway 170 A router which resides within the service provider network. 171 It is connected to multiple VPNs (such as Frame Relay), as 172 well as the IP backbone. The gateway may provide the 173 home agent processing functions. 175 Home Address 176 An address which is assigned to a Mobile Node for an 177 extended period of time. This address is assigned from 178 the home network. 180 Home Agent 181 A router on a mobile node's home network which tunnels 182 datagrams for delivery to the mobile node when it is away 183 from home, and maintains current location information for 184 the mobile node. 186 Home Network 187 The network address domain which the mobile node's home 188 address belongs in. 190 Mobile Node 191 A host or router which changes its point of attachment 192 from one network or subnetwork to another. A mobile node 193 may change its location without changing its IP address. 194 It may continue to communicate with other Internet nodes 195 at any location using its (constant) IP address, assuming 196 link-layer connectivity to a point of attachment is 197 available. The Mobile Node initiates the registration 198 request to its home agent to indicate its current point 199 of network attachment. 201 NAS A Network Access Server is a router which supports 202 dial-up PPP and SLIP users. 204 VPN Virtual Private Networks are logical networks over a 205 physical public network. This logical network forms a 206 private network for an enterprise. 208 1.3. Specification Language 210 In this document, several words are used to signify the requirements 211 of the specification. These words are often capitalized. 213 MUST This word, or the adjective "required", means 214 that the definition is an absolute requirement 215 of the specification. 217 MUST NOT This phrase means that the definition is an 218 absolute prohibition of the specification. 220 SHOULD This word, or the adjective "recommended", 221 means that, in some circumstances, valid 222 reasons may exist to ignore this item, but the 223 full implications must be understood and 224 carefully weighed before choosing a different 225 course. Unexpected results may result 226 otherwise. 228 MAY This word, or the adjective "optional", means 229 that this item is one of an allowed set of 230 alternatives. An implementation which does 231 not include this option MUST be prepared to 232 interoperate with another implementation which 233 does include the option. 235 silently discard The implementation discards the datagram 236 without further processing, and without 238 indicating an error to the sender. The 239 implementation SHOULD provide the capability 240 of logging the error, including the contents 241 of the discarded datagram, and SHOULD record 242 the event in a statistics counter. 244 2. Protocol Overview 246 The basic functionality defined in VTP is derived from the Mobile 247 IP protocol [3]. The Mobile IP specification provides much more 248 functionality than required for this protocol. Thus, only a subset of 249 the specification will be used in this protocol. The Mobile IP 250 specification defined a registration mechanism for creating a one-way 251 tunnel from the home agent to the mobile node, and allows for roaming 252 of the mobile node. VTP uses the registration mechanism to create 253 two-way tunnels and does not support any roaming (as in cellular 254 roaming) capability. The subset which will be implemented will be the 255 Registration Request/Response messages which are used for the Tunnel 256 Establishment, Shutdown and Refresh functions. The VTP protocol also 257 takes the advantage of the extensibility defined as registration 258 extensions in the Mobile IP specification to carry tunnel specific 259 information which are important in establishing secure VPN tunneling. 261 The VTP protocol defines a resource called the Mobile Node Proxy. 262 The mobile node proxy has similar functionality to a mobile node 263 which has a co-located care-of address. However, the mobile node 264 proxy is the device which initiates a two-way IP tunnel by registering 265 to the home agent. The home agent is the device which terminates 266 the two-way tunnel. The mobile node proxy can perform 267 encapsulation of datagrams to be tunneled to its home agent and 268 decapsulation of datagrams tunneled from its home agent. Similarly, 269 the home agent can perform encapsulation of datagrams to be 270 tunneled to a mobile node proxy and decapsulation of datagrams 271 tunneled from a mobile node proxy. 273 For virtual dial-up tunneling support, the mobile node proxy can 274 be implemented in a NAS. The home agent functions can be 275 implemented in a customer CPE router or in a gateway router which 276 resides in the service provider network. The mobile node proxy can 277 initiate a two-way IP tunnel in response to a remote PPP dial-in 278 connection attempt. A dial-up PPP client will be referred to as a 279 dial-up client in this specification, however VTP does inherently 280 support SLIP as well. 282 The mobile node proxy, in a sense, acts as a proxy agent for the dial- 283 up client. This proxy capability will allow dial-up clients to 284 connect to the corporate network via the IP backbone without having to 285 install Mobile IP capable software. The IP address of the NAS then 286 becomes the care-of address for each of these mobile node proxy 287 instances. 289 For router to router tunneling support, the mobile node proxy can be 290 implemented in the router which initiates a tunnel establishment 291 attempt to interconnect remote networks over an IP backbone. The home 292 agent can be implemented in a peer router which terminates the tunnel. 293 In this case, the router which initiates the tunnel has a co-located 294 care-of address. The care-of address is the address of the IP 295 interface which connects to the IP backbone. 297 For both virtual dial-up tunneling and router-to-router tunneling 298 cases, the mobile node proxy and the a home agent can coexist in one 299 element. This will allow the network element to initiate one bi- 300 directional tunnel and to terminate another independently. 302 This protocol defines another resource called the VPN Identifier. This 303 identifier has no significance for router to router tunnel 304 establishment, but is used by devices which support multiple VPNs 305 simultaneously. This numerical representation of the domain allows 306 network devices to protect network resources by allowing only 307 resources from one domain to access other resources within the same 308 domain. The VPN identifier is included in the tunnel manangement 309 messages as a registration extension. 311 This protocol also defines another resource called the Tunnel 312 Identifier. This identifier is also used to distinguish each tunnel 313 from the other. The tunnel identifier allows the each end of the 314 tunnel to associate the tunneled data stream with the appropriate 315 tunnel. The tunnel identifier is included in each of the tunnel 316 management messages as a registration extension. It is also included 317 in the encapsulation header of each tunneled data packet. 319 Tunnel security is performed by authenticating each peer of the tunnel 320 as defined in the Mobile-Home Authentication section of the Mobile IP 321 specification, which is done with the use of session keys. In order 322 to provide a good authentication scheme, a session key must have a 323 short life span, where it is valid only for the duration of a tunnel, 324 and in the case of a long term tunnel it is possible to re-negotiate a 325 new session key. 327 This protocol provides flexibility as far as a session key encryption 328 technique. However, MD5 is the default technique which MUST be 329 supported by all implementations. 331 2.1. Dynamic Tunnel Establishment 333 This section will detail the events which are necessary for tunnel 334 establishment. We will attempt to describe the events of a tunnel 335 establishment, followed by two sections which describe the 336 applicability with a router to router and a NAS to router scenario. 337 A final section detailing how to recover from a race condition. 339 In order to establish a tunnel, it is necessary to send a Registration 340 Request message. The sender (or tunnel initiator) is known as the 341 Mobile Node Proxy. Each registration request message contains a 342 field known as Lifetime. This field contains a value which defines the 343 number of seconds before the tunnel expires. The tunnel initiator is 344 responsible for "refreshing" the tunnel before the peer considers the 345 tunnel expired. 347 When creating a registration request message, the mobile node proxy 348 must know if it is simply registering a new remote client to use an 349 existing tunnel, or if a new tunnel needs to be created for a new 350 remote client. In the case of a new tunnel, the mobile node proxy must 351 set the least significant two bytes of the four-byte field to a locally 352 unique value (unused by the sender). This value may be used locally as 353 an index into a local table. The decision to register a new client 354 using an existing tunnel (multiplexing many remote clients over one 355 tunnel), or to create a new tunnel for each new remote client is 356 implementation specific. 358 If a tunnel already exists and the mobile node proxy wishes to register 359 a new remote address to an existing tunnel, the mobile node proxy 360 must insert the full tunnel identifier into the request. Registering a 361 new remote address on an existing tunnel resets the lifetime for the 362 tunnel (same as the Refresh Request message). The tunnel identifier, 363 is used in all subsequent exchanges in order to identify the tunnel. 365 All protocols which are used by the client must be registered with the 366 home agent. Each network protocol used by the client is indicated in 367 a separate registration extension. 369 If the dial-up PPP station is a network device which requires routing 370 updates (i.e. a router), routing may be required on the tunnel. The 371 tunnel registration mechanism also negotiates a set of attributes for 372 the tunnel itself; including routing, compression and others. 374 An encrypted session key MUST be present in the registration request 375 message, which is used by the home agent (tunnel terminator) in order 376 to verify the authenticity of the message. The message also 377 contains an MD5 message digest as the last extension. 379 Upon receipt of this message, the home agent must decrypt the session 380 key, and use the same key to verify the authenticity of the message by 381 generating an MD5 hash of the message and comparing it with the 382 value in the extension. If the message digest does not compare, a 383 response with the appropriate error code is returned to the mobile node 384 proxy. 386 If the home agent receives an extension which MUST be supported 387 and cannot be supported locally, the home agent MUST respond with 388 the appropriate error code. If an extension is malformed or contains 389 an invalid value, the same processing policy applies in these cases. 391 If the registration request is for a new tunnel, the home agent must 392 insert an unused, locally unique, value into the most significant two 393 bytes of the four-byte tunnel identifier. In the case of a request to 394 register a new address on an existing tunnel, the home agent must 395 verify that the tunnel is active and the tunnel's peer is with the 396 requesting mobile node proxy. 398 If the mobile node proxy is requesting an existing tunnel which does 399 not exist on the home agent (or exists with a different peer), the home 400 agent must insert a new value into the most significant two bytes 401 (this could occur if the home agent had reset for some reason) of the 402 tunnel identifier. 404 If the request is valid and contains all of the required extensions, 405 the home agent will create a dynamic tunnel interface. The tunnel 406 interface could be created with a network address set to the registered 407 home address, and the care-of address set to the mobile node proxy. 408 The home agent should also add to the route table the network 409 level addresses of the client being registered (for all protocols). 411 Once all of the above steps have been successfully completed, the 412 home agent returns a registration response message with the return 413 code set to SERVICE_PROVIDED. 415 Both the request and response MUST include, as the first extension the 416 authentication extension, which contains an MD5 digest of the 417 message. 419 Note that if the request contained a VPN extension, it MUST be 420 returned in the response even if it is not supported locally. This 421 extension is necessary for certain type of network equipment which 422 supports multiple VPNs. 424 The mobile node proxy receiving this response must examine the 425 return code. Unless the return code was set to authentication failure, 426 the message digest in the response should be compared with a locally 427 generated message digest (using the session key). If the return code 428 is set to a value other than [ ], the mobile node proxy may either 429 retry the message up to the maximum retry, or attempt a tunnel with an 430 alternate home agent (if one is available). 432 If the request was sent to register a new remote address on an existing 433 tunnel and the response contains a different tunnel identifier than was 434 requested, then the mobile node proxy MUST assume that the home agent 435 has rebooted and that the old tunnel is no longer valid. 437 The mobile node proxy could then create a local tunnel interface with 438 the local network address set to the home address; the IP tunnel local 439 address set to the care-of address; and the IP tunnel peer address set 440 to the home agent IP address. 442 2.1.1. Router to Router Tunnel Establishment 444 This section will detail the events for tunnel establishment for a 445 router to router scenario. 447 Figure 1 depicts two branch offices which connect to the main office 448 through a public network in a secure fashion. Both of the branch 449 offices have a router which supports VTP, which will establish a tunnel 450 to a VTP server (running on a CPE router, for example) at the main 451 office. In this diagram we show a firewall at the main office, which 452 must be configured to allow IP datagrams with a protocol ID set to GRE 453 and whose destination is set to the VTP Server. 455 Both of the routers and the VTP server SHOULD either share a pre- 456 configured shared secret, use a public/private key scheme or have 457 access to some form of key distribution center. Since MD5 key 458 encoding is an optional extension for this protocol, all 459 implementations SHOULD support shared secrets. 461 An example scenario of the use of VTP in this case would be when 462 there is data which is to be routed to the main office from one of the 463 branch offices, the router could examine if there is already a tunnel 464 to the VTP server. If no tunnel is established, a registration request 465 is sent and once the response is received all data may be encapsulated 466 and sent to the server. 468 Host 469 | 470 ------+------ +----------------------+ 471 | | | 472 Router 1 ----------------------+ | 473 (VTP Client) | Public Network | 474 | | 475 | | 476 Router 2 ----------------------+ | 477 (VTP Client) | | 478 +-----------+----------+ 479 | 480 | 481 ------+------ 482 | 483 | 485 Firewall Node 487 | 488 | 489 --------+--------- 490 | 491 Router 3 492 (VTP Server) 494 Figure 1: Router to Router VTP connection 496 2.1.2. NAS to Gateway Tunnel Establishment 498 This section will detail the sequence of events which are necessary for 499 a Dial-up router to establish a tunnel with a gateway. This scenario 500 shows the VTP home agent residing within the ISP's network, but this 501 is not a limitation of the protocol. Figure 2 shows an example of 502 network which supports VTP. 504 The home agent shown has the ability to support multiple VPNs (or 505 domains) in a secure fashion (meaning that network resources may 506 only be accessed by users if they are within the same VPN). This 507 example also shows a RADIUS Server which holds all of the configuration 508 necessary for VTP tunnel establishment and is returns a successful user 509 authentication message. The RADIUS Server also act as a Key 510 Distribution Center (KDC) and create a unique session key for each 511 user. 513 Note that the user of RADIUS is optional and any authentication 514 protocol may be used. In addition, a KDC is also optional, however 515 configuring shared secrets on each VTP device causes interesting 516 scalability problems, but using a public/private key could work. 518 Upon connect, a PPP client generates a LCP request, which is used for 519 Link Control Protocol negotiations. The NAS will respond and the 520 peers must agree to a set of options. The NAS will then generate a 521 CHAP request to the client (assuming that CHAP was negotiated as the 522 authentication protocol), this request will contain a 16 octet 523 authentication vector, which will be used later for security purposes. 524 The Client will then pass the encrypted user name and password in the 525 CHAP response. At this point, the NAS has a copy of the user name 526 and password of the client which will be used when sending the 527 authentication request to the local RADIUS Server. 529 Host 530 | 531 +-------------+ 532 | PSTN/ISDN | 533 | | 534 +------+------+ +----------------------+ 535 | | | 536 NAS ----------------------+ | 537 (VTP Client) | Public Network | 538 | | 539 | | 540 | | 541 | | 542 +-+------------------+-+ 543 | | 544 | | 545 ------+------ ------------ 546 | | 547 | | 549 Gateway CPE Router 550 (VTP Server) (VTP unaware) 552 Figure 2: NAS to Gateway VTP Connection 554 Note that VTP does not require CHAP and any authentication protocol 555 (i.e. PAP, CHAP, EAP) may be used. 557 The NAS generates a Radius ACCESS_REQUEST message and forward the 558 message to the local Radius Server. In this example, we will assume 559 that the Radius Server (known as the Proxy Server) is configured to 560 forward the authentication requests to a remote Radius Server (known 561 as the Domain Authentication Server, or DAS). The local Radius Server 562 will then re-compute the password using the Shared Secret which is 563 configured between itself and the remote Radius Server, add a proxy 564 state attribute and forward the request to the DAS. 566 The Remote Radius Server is now responsible for user authentication. 567 If successfully authenticated, the attributes configured for the user 568 are added to the ACCESS_ACCEPT packet. One or more VPN Gateway 569 attributes are attached to the packet. This attribute contains an IP 570 address, a tunnel refresh value and an encoded representation of a 571 temporary session key. The packet is then returned to the Proxy 572 Server. The Proxy Server will then add VPN specific attributes and 573 return the message to the originating NAS. 575 Once the NAS receives the ACCESS_ACCEPT message, a CHAP response is 576 returned to the PPP Client and NCP negotiations are then initiated. 577 Once NCP negotiations are complete, the NAS creates a VPN entry from 578 the information which was received in the packet. 580 NOTE: The tunnel establishment SHOULD occur after the completion 581 of the NCP negotiation phase, but prior to setting the connection to 582 the open state, in order to avoid PPP client time-outs. 584 At this point, the NAS will send a registration request message to the 585 home agent (see figure 2). Upon receipt of a successful response, the 586 NAS sets the PPP to open state. All packets from the client are 587 encapsulated within a GRE header with the Tunnel ID field set to the 588 tunnel identifier and sent to the home agent. Upon receipt of a data 589 packet, the authenticity must be validated using the session key. 591 2.1.3. Race Condition 593 Since the protocol requires that the mobile node proxy must always be 594 known (the mobile node proxy is the one who is responsible for 595 refreshing the tunnel), there exists a potential race condition problem 596 when two nodes send a Registration Request simultaneously. 598 If a network device receives a registration request message from 599 another node which it already has a pending request for, the request 600 with the lowest IP address in the home agent IP Address field MUST 601 be discarded. 603 2.2. Dynamic Tunnel Refresh 605 As explained above, each registration request message contains a field 606 known as the lifetime which is set to the maximum number of seconds 607 before the tunnel expires. Although registering a new client over an 608 existing tunnel causes the timer to reset and the new lifetime to be 609 observed, it is highly possible that no new clients will attempt to 610 register before the tunnel does expire. Therefore there must be a 611 mechanism to "refresh" the tunnel, and this is done by using the Tunnel 612 Refresh message, which includes the tunnel identifier as well as a new 613 lifetime. The home agent must acknowledge the request with a 614 response in order for the mobile node proxy to consider the tunnel 615 "refreshed". 617 It is imperative that the mobile node proxy allow enough time for 618 refresh request re-transmissions, otherwise the home agent could 619 invalidate the tunnel. Therefore the mobile node proxy should observe 620 the following formula in determining when to transmit the first refresh 621 request message: 623 timer = (current time + lifetime) - 624 (MAX retransmissions * seconds between retrans.) 626 This formula does raise an interesting problem, which deals with 627 selecting the tunnel lifetime. If the lifetime chosen for a tunnel is 628 less than the max retransmission times the seconds between each 629 retransmission, this would cause a flurry of refreshes, and possibly a 630 very unreliable service. It is therefore recommended that an 631 implementation chooses it's minimum lifetime wisely. 633 There exists a timing problem which can occur if the mobile node 634 proxy sends out a refresh request followed by a deregistration request 635 for the same SPI as that used in the refresh. If the home agent 636 received both packets out of order, it could invalidate the SPI when 637 receiving the deregistration request and then fail the refresh's 638 authentication since the SPI is no longer valid. It is therefore 639 imperative that when the mobile node proxy receives a refresh response 640 indicating that the request failed the authentication that a new 641 request be sent with another valid SPI (if there are no valid SPI then 642 the request is abandoned). This "retransmission" should not be done 643 more often than the maximum retransmission counter. 645 Once the maximum number of retransmissions have been unsuccesssful 646 (either failed or no response), the interface should be shutdown and 647 any dial-up users (in the case of a NAS) should be disconnected. 649 2.3. Dynamic Tunnel Shutdown 651 A tunnel shutdown could result for many reasons, one being that a dial- 652 up user has disconnected with the NAS, another being that a router 653 would shutdown a tunnel due to inactivity or possibly when a 654 transaction is complete. 656 The mobile node proxy constructing the request, MUST use the SPI 657 which is associated with this user. Upon receipt of the message, the 658 home agent will attempt to authenticate the message. If it fails 659 authentication, it will respond with a negative response. Otherwise it 660 will remove each route specified in the header and protocol extensions 661 from the network routing tables for the mobile node proxy. 663 Next, the peer will check if there are any other mobile node proxy 664 which are using the tunnel. If not, then the GRE interface is deleted 665 and the response is sent back to the requester. 667 Once the mobile node proxy receives the response, it will attempt to 668 authenticate the response. If the response fails the authentication, 669 the request will be abandoned. Once the maximum number 670 re-transmissions have been sent, the mobile node proxy will simply 671 destroy the tunnel. If the response was successfully authenticated, it 672 will also ensure that there are no other mobile node proxies using the 673 tunnel. If there are none, then the local GRE interface is also 674 deleted. 676 Tunnel de-registration messages are always sent from the mobile node 677 proxy to the home agent. If a home agent detects that it must shutdown 678 the interface, it may do so and return an error in the next refresh 679 response. 681 3. Protocol Specification 683 The VTP protocol is based on the IP Mobility protocol. The VTP 684 protocol uses a subset of the Mobile IP protocol specification. 686 The IP Mobility protocol contains a standard header, and a set of 687 extensions. These extensions contain information which is relevant for 688 the operation. An extension consist of a type field, a length field, 689 followed by the data field. All VTP related extensions are 690 encapsulated within a single Mobility extension. This allows the 691 protocol to allocate as many extension numbers as required without 692 affecting the relatively small Mobility extension address space 693 (8 bits). 695 3.1. Registration Request 697 This message is sent from the mobile node proxy to the home agent for 698 two purposes. In the first case, the mobile node proxy wishes to 699 establish a new tunnel with the home agent, and the second is where 700 the mobile node proxy wishes to register a new remote address with the 701 home agent over an existing tunnel. 703 The following message format is used: 705 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 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | Type |S|B|D|M|G|V|T|r| Lifetime | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | Home IP Address | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 | Home Agent Address | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 | Care of IP Address | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | Identification | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | Identification | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 Type 1 (Registration Request) 722 S, B, M, V All set to zero to disable features not 723 required. 725 D 1, The mobile node proxy will itself 726 decapsulate datagrams which are sent to 727 the care-of address. 729 G 1, GRE encapsulation enabled. 731 T 1, Bi-directional tunneling enabled. 733 r 0, Reserved Field 735 Lifetime The number of seconds remaining before the 736 registration is considered expired. A 737 value of 0xffff indicates infinity. 739 Home IP Address For IP over dial-up connections, this 740 value is the IP address of the remote node 741 or the dial-up router. It is the IPCP 742 assigned IP address for the remote client. 744 For non-IP protocol over dial-up 745 connections, this field is set to zero. 747 For IP tunneling configurations between 748 two routers which are not dial-up routers, 749 this field is also set to zero. 751 Home Agent Address The IP Address of the home agent. 753 Care of Address The IP Address of the Foreign Agent. 755 Identification The 64-bit identification field consists 756 of two parts. The most significant four 757 bytes contain a valid timestamp, which is 758 the number of seconds since January 1, 759 1900 (as defined in [NTP]). 761 The least significant four bytes contains 762 a random value. 764 3.1.1. VTP Extensions 766 This extension is used to encapsulate all VTP specific extensions. This 767 is done in order to conserve the small extension address space which is 768 available in the Mobile IP header. Each sub-extension may all be 769 encapsulated within one single VTP extension, or each sub-extension may 770 be individually encapsulated with this extension. 772 The format of the header is as defined below: 774 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 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 | Type | Length | Sub-Type | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 | Length | flag | 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 Type 65 (VTP Extensions) 783 Length variable 785 Sub-Type Sub Attribute Number 787 Sub-Length Sub Attribute Length 789 Flag The flag field contains a set of 790 properties for the following 791 sub-attribute. The following bits have 792 been defined: 794 VTP_MANDATORY_SUPPORT 0x01 795 If this bit is set, the attribute 796 MUST be supported by the peer. If this 797 attribute cannot be supported, an 798 error code must be returned. 800 3.1.1.1. Tunnel-Identifier Extension 802 This extension is REQUIRED for tunnel establishment requests and all 803 further requests to register a new user to an existing tunnel. This 804 extension SHOULD be the first extension following the protocol header. 806 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 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 | Type | Length | Sub-Type | 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | Sub-Length | flag | Tunnel Identifier | 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 | Tunnel Identifier | Interface Flags | 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 | Interface Flags | System Name (opt) ... | 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 Sub-Type 1 (VTP Tunnel-Identifier Extension) 819 Sub-Length variable 821 Flag Bit 1 MUST be set (mandatory support) 823 Tunnel ID The Tunnel Identifier contains the GRE 824 session ID. This identifier is used 825 within each GRE header to indicate the 826 session. The Tunnel ID is divided into two 827 parts; the least significant two bytes 828 contains the Foreign Agent session 829 identifier and the most significant two 830 bytes are the Home Agent's session ID. 832 When requesting a new session, the mobile 833 node proxy should insert an unused integer 834 in the least significant two bytes, set 835 the most significant to zero. Upon 836 successful registration, the peer will 837 insert an unused two byte value in the 838 most significant two bytes. 840 In the case of a NAS which wishes to 841 register a new client within an existing 842 tunnel, the full tunnel identification is 843 inserted in this field. 845 Interface Flags The Interface Flags field contains all 846 attributes for the tunnel. The initiator 847 may set as many attributes for the 848 interface as required, however the 849 response from the peer will contain the 850 attributes which the peer is able to 851 service at this time. 853 It is possible to change the properties of 854 a tunnel while the tunnel is active. This 855 is done when a new user is registered on 856 an existing tunnel. However a property 857 CANNOT be removed from a tunnel, only 858 added. 860 The following flags have been reserved: 862 VTP_IF_COMPRESSION 0x0001 863 If this bit is enabled, compression of 864 user data is bi-directionally enabled. 865 Once compression has been negotiated, 866 all data sent through the tunnel must 867 be compressed. This property is per 868 tunnel, not per user. 870 VTP_IF_AUTHENTICITY 0x0002 871 If this bit is enabled, each GRE 872 header contains a 4 octet MD5 hash of 873 the packet. This enables 874 authentication of each data packet. It 875 is also possible to use the AH header 876 to authenticate each packet. If this 877 is done, it is not necessary to set 878 this bit. 880 System Name This optional 64 octet field contain a 881 string representation of either the user 882 name which was used during the login 883 process which initiated the tunnel 884 establishment or the device system name 885 (if available). This is used for command 886 line display purposes only. 888 3.1.1.2. IP-Protocol Extension 890 This extension is OPTIONAL and must be present only if the client being 891 registered supports IP. This extension may be sent to register a new 892 client on an existing tunnel even if the initial tunnel establishment 893 request did not register IP support. This extension can be repeated 894 multiple times in the case that several IP addresses are to be 895 registered. In this case, a conventional router or dial-up router 896 is serving multiple IP addresses in the remote LAN. The format of the 897 extension is: 899 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 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 | Type | Length | Sub-Type | 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 | Sub-Length | flag | IP Network Address | 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 | IP Network Address (cont.) | IP Subnet Mask | 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 | IP Subnet Mask (cont.) | Interface Flags | 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 Sub-Type 10 (IP-Protocol Extension) 912 Sub-Length 10 914 Flag Bit 1 MUST be set (mandatory support) 916 IP Network Address This field contains the IP Network address 917 of each of the subnetworks the remote 918 client is serving. This allows the home 919 agent to add a network route upon 920 successful registration without the need 921 of a routing protocol. 923 This obviously only works if the address 924 space on the network side is contiguous, 925 otherwise a routing protocol is required. 927 For a dial-up user (non-router), this 928 field SHOULD be set to zero. 930 IP Subnet Mask This field contains the Subnet mask of the 931 IP Network address above. 933 Interface Flags The Interface Flags field contains all 934 attributes for the IP protocol over the 935 tunnel. The tunnel initiator may set all 936 of the bits which it can support. The 937 response from the tunnel terminator 938 determines the interface properties which 939 will be used over the tunnel. It is 940 therefore possible to set a preference 941 on either ends of the tunnel. 943 It is possible to enable a routing 944 protocol over an existing tunnel only if 945 one was not already negotiated. It is not 946 possible to disable such a protocol. 948 The following flags have been reserved: 950 VTP_IF_RIP_ROUTING 0x0001 951 If this bit is enabled, RIP will be 952 used as a routing protocol over the 953 tunnel. 955 VTP_IF_OSPF_ROUTING 0x0002 956 If this bit is enabled, OSPF will be 957 used as a routing protocol over the 958 tunnel. 960 3.1.1.3. IPX-Protocol Extension 962 This extension is OPTIONAL and must be present only if the client 963 being registered supports IPX. This extension may be sent to register 964 a new client on an existing tunnel even if the initial tunnel 965 establishment request did not register IPX support. This extension can 966 be repeated multiple times in the case that several IPX addresses are 967 to be registered. In this case, a conventional router or dial-up 968 router is serving multiple IPX addresses in the remote LAN. The format 969 of the extension is: 971 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 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 | Type | Length | Sub-Type | 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 | Sub-Length | flag | IPX Network Number | 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 | IPX Network Number (cont.) | IPX Node Number | 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 | IPX Node Number (cont.) | 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 981 | Interface Flags | 982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 Sub-Type 11 (IPX Protocol Extension) 986 Sub-Length 12 988 Flag Bit 1 MUST be set (mandatory support) 990 IPX Network This field contains the IPX Network number 991 of the remote client (as negotiated by 992 IPXCP for a dial-up user). 994 IPX Node Number This field contains the IPX Node number of 995 the remote client. 997 Interface Flags The Interface Flags field contains all 998 attributes for the IPX protocol over the 999 tunnel. The tunnel initiator may set all 1000 of the bits which it can support. The 1001 response from the tunnel terminator 1002 determines the interface properties which 1003 will be used over the tunnel. It is 1004 therefore possible to set a preference on 1005 either ends of the tunnel. 1007 It is possible to enable a routing 1008 protocol over an existing tunnel only if 1009 one was not already negotiated. It is not 1010 possible to disable such a protocol. 1012 The following flags have been reserved: 1014 VTP_IF_RIP_ROUTING 0x0001 1015 If this bit is enabled, IPX RIP will 1016 be used as a routing protocol over 1017 the tunnel. 1019 VTP_IF_NLSP_ROUTING 0x0002 1020 If this bit is enabled, NLSP will be 1021 used as a routing protocol over the 1022 tunnel. 1024 VTP_IF_IPXWAN_2 0x0004 1025 If this bit is enabled, IPXWAN version 1026 2 will be used over the tunnel 1027 interface. 1029 3.1.1.4. Virtual-Private-Networking Extension 1031 The Virtual Networking Extension MAY be present in the Registration 1032 Request if the Mobile Node support the concept of VPN. The 1033 Registration MUST include this extension (although the name field may 1034 be removed). 1036 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 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 | Type | Length | Sub-Type | 1039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1040 | Sub-Length | flag | VPN Identifier | 1041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 | VPN Identifier | VPN Name | 1043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1044 | VPN Name (64) | 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 Sub-Type 9 (Virtual-Private-Networking Extension) 1049 Sub-Length variable 1051 Flag Bit 1 MUST be set (mandatory support) 1053 VPN ID The VPN Identifier is a numerical 1054 representation of the Domain. This 1055 customer identifier is assigned by the 1056 service provider and must be globally 1057 unique within the network. This value may 1058 be returned by the authentication server. 1060 Although many implementations will not 1061 make use of this extension, a registration 1062 response MUST include this extension if 1063 one was present in the corresponding 1064 request. 1066 VPN Name This optional field contains the ASCII 1067 representation of the VPN identifier, 1068 which MAY be the name of the customer 1069 (e.g. ABC Corp.). 1071 3.1.1.5. Dynamic-Connection Extension 1073 The Dynamic Connection Extension MAY be present in the Registration 1074 Request if the circuit from the home agent to the CPE router is not 1075 permanent. The information contained in this extension should be 1076 sufficient in order for the home agent to establish a link with the 1077 CPE device. 1079 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 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 | Type | Length | Sub-Type | 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 | Sub-Length | flag | Link Type | 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1085 | Address | 1086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1088 Sub-Type 7 (Dynamic-Connection Extension) 1090 Sub-Length variable 1092 Flag Bit 1 MUST be set (mandatory support) 1094 Link Type The Link Type field contains a 1095 numerical representation of the underlying 1096 link to use in order to connect to the CPE 1097 device. The following have already been 1098 defined: 1100 VTP_FR_SVC 0x0001 1101 When set, the address refers to a 1102 Frame Relay Switched Virtual Circuit. 1104 VTP_ATM_SVC 0x0002 1105 When set, the address refers to an ATM 1106 Switched Virtual Circuit. 1108 VTP_X25_SVC 0x0003 1109 When set, the address refers to a X.25 1110 Switched Virtual Circuit. 1112 Address A link layer address which the home agent 1113 must use in order to connect to the CPE 1114 router. The length of the address is 1115 determined by the length of the attribute 1116 (less the link type field). 1118 3.1.1.6. Session-Key Extension 1120 The Session Key Extension MUST be present in the request. This 1121 extension contains the tunnel's session key which will be used for 1122 message autentication as well as encyption (if used). 1124 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 1125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1126 | Type | Length | Sub-Type | 1127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1128 | Sub-Length | flag | Encryption Type | 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 | Encoded Session Key | 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 | Encoded Session Key | 1133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1134 | Encoded Session Key | 1135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1136 | Encoded Session Key | 1137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1138 | Vector | 1139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1140 | Vector | 1141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1142 | Vector | 1143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1144 | Vector | 1145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1147 Sub-Type 8 (Session-Key Extension) 1149 Sub-Length Variable 1151 Flag Bit 1 MUST be set (mandatory support) 1153 Encryption Type The Encryption Type field is used in order 1154 to inform the tunnel terminator the 1155 encryption technique which was used in 1156 order to encrypt the session key. 1158 The default value, which MUST be supported 1159 by all implementations is MD5 (type 0x0001). 1161 The following flags have been reserved: 1163 VTP_ENC_MD5 0x0001 1164 If this bit is enabled, MD5 was used 1165 as the encryption technique. In this 1166 case, the Encoded Session Key 1167 contains an MD5 hash of the following: 1169 MD5(Vector|Shared Secret|Session Key) 1171 Where the vector is a 16 octet random 1172 value which was used by the session 1173 key encryptor to add randomness to the 1174 encoded value. 1176 The Shared Secret is the shared secret 1177 which is common between the peers 1178 (note it is possible that both peers 1179 do not shared a common secret, see 1180 section 9 for more information). 1182 VTP_ENC_DES 0x0002 1183 This this bit is set, DES was used as 1184 the encryption technique. 1186 A Registration Response with an error 1187 of ERR_ENCRYPT_NOT_SUPPORTED informs 1188 the tunnel initiator that it must 1189 attempt an alternative encryption 1190 technique, or use the default value. 1192 Encoded Session Key This field contains a new encoded random 1193 16 octet value. The size of the encoded 1194 session key is determined by the extension 1195 length field (less the 16 octet vector 1196 size for MD5 encoding). This value is only 1197 valid for the duration of the tunnel (and 1198 even shorter if session key renegotiation 1199 is done during the tunnel refresh 1200 process). 1202 The Mobile-Home Authentication extensions 1203 contains an SPI, which must be saved and 1204 is used in order to reference this session 1205 key. 1207 Vector This field contains a 16 octet random 1208 value which was used in encrypting the 1209 session key. This field is only present 1210 when the encryption type is set to MD5. 1212 3.1.2. Mobile-Home Authentication Extension 1214 This extension is used as described in the IP Mobility specification. 1215 This extension MUST be added after the VTP extension in all tunnel 1216 management messages. 1218 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 1219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1220 | Type | Length | SPI | 1221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1222 | SPI | Authenticator... 1223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1225 Type 32 1227 Length 4 plus the number of bytes in the 1228 Authenticator. 1230 SPI Security Parameter Index. Contains a 1231 pseudo-random value which must be 1232 retained by the peer in order to use 1233 the session key which was negotiated in 1234 any future refresh and deregistration 1235 messages. 1237 Authenticator Contains a MD5 representation of the whole 1238 Tunnel Registration header up to and 1239 including this extension's length field. 1240 The value is computed from default 1241 authentication algorithm a keyed-MD5 1242 hash of the following: 1244 MD5( Session Key | Packet | Session Key ) 1246 Where the packet is the whole Mobile IP 1247 packet up to and including the length field. 1248 The Session Key is a 16 octet randomized 1249 value. 1251 3.2. Registration Response 1253 Upon receipt of the Registration Request from a mobile node proxy, the 1254 home agent will register the HOME IP Address for the VPN. 1256 The response from the home agent will be in the following format: 1258 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 1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1260 | Type | Code | Lifetime | 1261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1262 | Home IP Address | 1263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1264 | Home Agent IP Address | 1265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1266 | Care of IP Address | 1267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1268 | Identification | 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1270 | Identification | 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1273 Type 3 (Registration Response) 1275 Code One of the following: 1276 0 - Service will be provided 1278 128 - reason unspecified 1279 129 - administratively prohibited 1280 130 - insufficient resources 1281 131 - mobile node proxy failed 1282 authentication 1283 133 - registration identification mismatch 1284 134 - poorly formed request 1285 135 - too many simutaneous mobility 1286 bindings 1287 140 - The VPN has not been configured 1288 141 - The IP Address already exists 1289 142 - The IPX Address already exists 1290 143 - Network Outage 1291 144 - Encryption type not supported 1293 Lifetime The number of seconds remaining before 1294 the registration is considered expired. A 1295 value of all ones indicates infinity. 1297 Home IP Address For routers, this value is the IP address 1298 of the router. 1300 For Dial-up Routers, this is the IPCP 1301 assigned IP address. 1303 If the mobile node proxy does not support 1304 IP, this value is set to zero. 1306 Home Agent IP Address IP Address of the home agent, copied from 1307 the pending Registration Request. 1309 Care of Address The IP Address of the tunnel end located 1310 in the NAS or router. 1312 Identification The identification field consists of two 1313 parts. The most significant four bytes 1314 contain a valid timestamp, which is the 1315 number of seconds since January 1, 1900 1316 (as defined by the NTP protocol). 1318 The least significant four bytes MUST 1319 contain the same value which was set in 1320 the request. This is used in order to 1321 simplify matching the request and the 1323 response. 1325 The following extensions will be added to the message: 1327 3.2.1. VTP Extensions 1329 This extension is used to encapsulate all VTP specific extensions. This 1330 is done in order to conserve the small extension address space which is 1331 available in the Mobile IP header. Each sub-extension may all be 1332 encapsulated within one single VTP extension, or each sub-extension may 1333 be individually encapsulated with this extension. 1335 The format of the header is as defined below: 1337 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 1338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1339 | Type | Length | Sub-Type | 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1341 | Length | flag | 1342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1344 Type 65 (VTP Extensions) 1346 Length variable 1347 Sub-Type Sub Attribute Number 1349 Sub-Length Sub Attribute Length 1351 Flag The flag field contains a set of 1352 properties for the following 1353 sub-attribute. The following bits have 1354 been defined: 1356 VTP_MANDATORY_SUPPORT 0x01 1357 If this bit is set, the attribute 1358 MUST be supported by the peer. If 1359 this attribute cannot be supported, 1360 an error code must be returned. 1362 3.2.1.1. Tunnel-Identifier Extension 1364 This extension is REQUIRED for tunnel establishment requests and all 1365 further requests to register a new user to an existing tunnel. This 1366 extension SHOULD be the first extension following the protocol header. 1368 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 1369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1370 | Type | Length | Sub-Type | 1371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1372 | Sub-Length | flag | Tunnel Identifier | 1373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1374 | Tunnel Identifier | Interface Flags | 1375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1376 | Interface Flags | 1377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1379 Sub-Type 1 (VTP Tunnel-Identifier Extension) 1381 Sub-Length 14 1383 Flag Bit 1 MUST be set (mandatory support) 1385 Tunnel ID The Tunnel Identifier contains the GRE 1386 session ID. This identifier is used within 1387 each GRE header to indicate the session. 1388 The Tunnel ID contains two session 1389 identifiers; the least significant two 1390 bytes contains the initiator's session 1391 identifier and the most significant two 1392 bytes are the remote peer's session ID. 1394 When responding to a new Tunnel 1395 Registration Request, the peer inserts an 1396 unused integer within the most significant 1397 two bytes. 1399 If the initiator inserted a full tunnel 1400 identifier, which is no longer valid (e.g. 1401 the device has rebooted), it is necessary 1402 to insert a new value in the most 1403 significant two bytes. 1405 Interface Flags The Interface Flags field contains all 1406 attributes for the tunnel. The returned 1407 values will dictate to the peer what 1408 attributes to set for the tunnel. If a 1409 specific attribute cannot be supported, it 1410 should not be returned in the response, 1411 which the peer must consider as disabled 1412 for the tunnel. The response cannot 1413 contain flags which were not initially 1414 requested. 1416 3.2.1.2. IP-Protocol Extension 1418 This extension MUST be present if the Registration Request included 1419 this extension. The absence of this extension, when expected, informs 1420 the tunnel initiator that the protocol is not supported by the home 1421 agent. The format of the extension is: 1423 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 1424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1425 | Type | Length | Sub-Type | 1426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1427 | Sub-Length | flag | IP Network Address | 1428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1429 | IP Network Address (cont.) | IP Subnet Mask | 1430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1431 | IP Subnet Mask (cont.) | Interface Flags | 1432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1434 Sub-Type 10 (IP-Protocol Extension) 1436 Sub-Length 10 1438 Flag Bit 1 MUST be set (mandatory support) 1439 IP Network Address Set to the value which was in the 1440 Registration Request. 1442 IP Subnet Mask Set to the value which was in the 1443 Registration Request. 1445 Interface Flags The Interface Flags field contains the 1446 flags which the Home Agent is able to 1447 support. The home agent should not set 1448 more than one bit which is considered 1449 mutually exclusive (i.e. RIP and OSPF). 1451 The home agent may not enable a bit which 1452 was not present in the Registration 1453 Request. 1455 3.2.1.3. IPX-Protocol Extension 1457 This extension MUST be present if the Registration Request included 1458 this extension. The absence of this extension, when expected, informs 1459 the tunnel initiator that the protocol is not supported by the home 1460 agent. The format of the extension is: 1462 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 1463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1464 | Type | Length | Sub-Type | 1465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1466 | Sub-Length | flag | IPX Network Number | 1467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1468 | IPX Network Number (cont.) | IPX Node Number | 1469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1470 | IPX Node Number (cont.) | 1471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1472 | Interface Flags | 1473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1475 Sub-Type 11 (IPX-Protocol Extension) 1477 Sub-Length 12 1479 Flag Bit 1 MUST be set (mandatory support) 1481 IPX Network Set to the value which was in the 1482 Registration Request. 1484 IPX Node Number Set to the value which was in the 1485 Registration Request. 1487 Interface Flags The Interface Flags field contains the 1488 flags which the Home Agent is able to 1489 support. The home agent should not set 1490 more than one bit which is considered 1491 mutually exclusive (i.e. RIP and NLSP). 1493 The home agent may not enable a bit which 1494 was not present in the Registration 1495 Request. 1497 3.2.1.4. Virtual-Private-Networking Extension 1499 The Virtual Private Networking Extension MUST be present if such an 1500 extension was present in the Registration Request. 1502 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 1503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1504 | Type | Length | Sub-Type | 1505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1506 | Sub-Length | flag | VPN Identifier | 1507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1508 | VPN Identifier | 1509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1511 Sub-Type 9 (Virtual-Private-Networking Extension) 1513 Sub-Length 4 1515 Flag Bit 1 MUST be set (mandatory support) 1517 VPN ID The VPN Identifier MUST contain the value 1518 which was reported in the Registration 1519 Request. 1521 3.2.2. Mobile-Home Authentication Extension 1523 This extension is used as described in the IP Mobility specification. 1524 This extension MUST be added after the VTP extensions in all tunnel 1525 management messages. 1527 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 1528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1529 | Type | Length | SPI | 1530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1531 | SPI | Authentication Value | 1532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1533 | Authentication Value | 1534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1535 | Authentication Value | 1536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1537 | Authentication Value | 1538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1539 | Authentication Value | 1540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1542 Type 32 (Mobile-Home Authentication Extension) 1544 Length 20 1546 SPI Security Parameter Index. Contains a 1547 pseudo-random value which must be retained 1548 by the peer in order to use the session 1549 key which was negotiated in any future 1550 refresh and deregistration messages. 1552 Authentication Value Contains a MD5 representation of the whole 1553 Tunnel Registration packet up to and 1554 including this extensions length field. 1555 The value is a MD5 hash of the following: 1557 MD5( Session Key | Packet | Session Key ) 1559 Where the packet is the whole Mobile IP 1560 packet up to and including the length 1561 field. The Session Key is a 16 octet 1562 randomized value. 1564 3.3. Refresh Request 1566 The Refresh Request messages is sent from the mobile node proxy to the 1567 home agent. This message is sent from the mobile node proxy to the home 1568 agent in order to "refresh" the tunnel and ensure that it does not 1569 expire. 1571 Note that although the layer 3 protocols do not require the Home Agent 1572 to send a refresh request to the Mobile Node for any reason, there may 1573 exist other extensions which do require this feature. For this reason, 1574 it is possible for a Home Agent to initiate a refresh request. 1576 The following message format is used: 1578 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 1579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1580 | Type |S|B|F|M|G|V|T|r| Lifetime | 1581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1582 | Home IP Address | 1583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1584 | Home Agent IP Address | 1585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1586 | Care of IP Address | 1587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1588 | Identification | 1589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1590 | Identification | 1591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1593 Type 2 (Refresh Request) 1595 S, B, M, V All set to zero to disable features not 1596 required. 1598 D 1, The mobile node proxy will itself 1599 decapsulate datagrams which are sent to 1600 the care-of address. 1602 G 1, GRE encapsulation enabled. 1604 T 1, Bi-directional tunneling enabled. 1606 r 0, Reserved Field 1608 Lifetime Contains a value indicating the number of 1609 seconds before the tunnel expires. 1611 Home IP Address Set to zero. 1613 Home Agent IP Address IP Address of the home agent IP Address 1615 Care of Address The IP Address of the tunnel end located 1616 in the NAS. 1618 Identification The identification field consists of two 1619 parts. The most significant four bytes 1620 contain a valid timestamp, which is the 1621 number of seconds since January 1, 1900 1622 (as defined by the NTP protocol). The 1623 least significant four bytes contain a 1624 random value. 1626 The following extensions will be added to the message: 1628 3.3.1. VTP Extensions 1630 This extension is used to encapsulate all VTP specific extensions. This 1631 is done in order to conserve the small extension address space which is 1632 available in the Mobile IP header. Each sub-extension may all be 1633 encapsulated within one single VTP extension, or each sub-extension may 1634 be individually encapsulated with this extension. 1636 The format of the header is as defined below: 1638 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 1639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1640 | Type | Length | Sub-Type | 1641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1642 | Length | flag | 1643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1645 Type 65 (VTP Extensions) 1647 Length variable 1649 Sub-Type Sub Attribute Number 1651 Sub-Length Sub Attribute Length 1653 Flag The flag field contains a set of 1654 properties for the following 1655 sub-attribute. The following bits have 1656 been defined: 1658 VTP_MANDATORY_SUPPORT 0x01 1659 If this bit is set, the attribute MUST 1660 be supported by the peer. If this 1661 attribute cannot be supported, an 1662 error code must be returned. 1664 3.3.1.1. Tunnel-Identifier Extension 1666 This extension is REQUIRED for tunnel establishment requests and all 1667 further requests for a new client to use an existing tunnel. This 1668 extension SHOULD be the first extension following the protocol header. 1670 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 1671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1672 | Type | Length | Sub-Type | 1673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1674 | Sub-Length | flag | Tunnel Identifier | 1675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1676 | Tunnel Identifier | 1677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1679 Sub-Type 1 (VTP Tunnel-Identifier Extension) 1681 Sub-Length 4 1683 Flag Bit 1 MUST be set (mandatory support) 1685 Tunnel ID The Tunnel Identifier contains the GRE 1686 session ID. This identifier is used within 1687 each GRE header to indicate the session. 1688 The Tunnel ID contains two session 1689 identifiers; the least significant two 1690 bytes contains the tunnel initiator's 1691 session identifier and the most 1692 significant two bytes are the peer's 1693 session ID. 1695 3.3.1.2. Virtual-Private-Networking Extension 1697 The Virtual Private Networking Extension MUST be present if such an 1698 extension was present in the Registration Request. 1700 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 1701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1702 | Type | Length | Sub-Type | 1703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1704 | Sub-Length | flag | VPN Identifier | 1705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1706 | VPN Identifier | 1707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1709 Sub-Type 9 (Virtual-Private-Networking Extension) 1710 Sub-Length 4 1712 Flag Bit 1 MUST be set (mandatory support) 1714 VPN ID The VPN Identifier MUST be set to the 1715 same value as the one which was reported 1716 in the original Registration Request. 1718 3.3.1.3. Session-Key Extension 1720 The Session Key Extension is optional during the tunnel refresh 1721 process. It is used if the mobile node proxy wishes to negotiate a 1722 new session key with the home agent. 1724 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 1725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1726 | Type | Length | Sub-Type | 1727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1728 | Sub-Length | flag | Encryption Type | 1729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1730 | Encoded Session Key | 1731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1732 | Encoded Session Key | 1733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1734 | Encoded Session Key | 1735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1736 | Encoded Session Key | 1737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1738 | Vector | 1739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1740 | Vector | 1741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1742 | Vector | 1743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1744 | Vector | 1745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1747 Sub-Type 8 (Session-Key Extension) 1749 Sub-Length Variable 1751 Flag Bit 1 MUST be set (mandatory support) 1753 Encryption Type The Encryption Type field is used in order 1754 to inform the tunnel terminator the 1755 encryption technique which was used in 1756 order to encrypt the session key. 1758 The default value, which MUST be supported 1759 by all implementations is MD5 (type 0x0001). 1761 The following flags have been reserved: 1763 VTP_ENC_MD5 0x0001 1764 If this bit is enabled, MD5 was used 1765 as the encryption technique. In this 1766 case, the Encoded Session Key 1767 contains an MD5 hash of the following: 1769 MD5(Vector|Shared Secret|Session Key) 1771 Where the vector is a 16 octet random 1772 value which was used by the session 1773 key encryptor to add randomness to the 1774 encoded value. 1776 The Old Session Key is the session 1777 which is still valid between both 1778 peers. It is recommended that the 1779 peers remember the Old Session Key 1780 for a short period in order to deal 1781 with out of order packets which may 1782 have been authenticated or encrypted 1783 using the Old Session Key. 1785 VTP_ENC_DES 0x0002 1786 This this bit is set, DES was used as 1787 the encryption technique. 1789 A Registration Response with an error 1790 of ERR_ENCRYPT_NOT_SUPPORTED informs 1791 the tunnel initiator that it must 1792 attempt an alternative encryption 1793 technique, or use the default value. 1795 Encoded Session Key This field contains a new encoded random 1796 16 octet value. The size of the encoded 1797 session key is determined by the extension 1798 length field (less the 16 octet vector 1799 size for MD5 encoding). This value is only 1800 valid for the duration of the tunnel (and 1801 even shorter if session key renegotiation 1802 is done during the tunnel refresh 1803 process). 1805 The Mobile-Home Authentication extensions 1806 contains an SPI, which must be saved and 1807 is used in order to reference this session 1808 key. 1810 Vector This field contains a 16 octet random 1811 value which was used in encrypting the 1812 session key. This field is only present 1813 when the encryption type is set to MD5. 1815 3.3.2. Mobile-Home Authentication Extension 1817 This extension is used as described in the IP Mobility specification. 1818 This extension MUST be added after the VTP extensions in all tunnel 1819 management messages. 1821 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 1822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1823 | Type | Length | SPI | 1824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1825 | SPI | Authentication Value | 1826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1827 | Authentication Value | 1828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1829 | Authentication Value | 1830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1831 | Authentication Value | 1832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1833 | Authentication Value | 1834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1836 Type 32 (Mobile-Home Authentication Extension) 1838 Length 20 1840 SPI Security Parameter Index. Contains a 1841 pseudo-random value which must be retained 1842 by the peer in order to use the session 1843 key which was negotiated in any future 1844 refresh and deregistration messages. 1846 Authentication Value Contains a MD5 representation of the whole 1847 Tunnel Registration packet up to and 1848 including this extensions length field. 1849 The value is a MD5 hash of the following: 1851 MD5( Session Key | Packet | Session Key ) 1852 Where the packet is the whole Mobile IP 1853 packet up to and including the length 1854 field. The Session Key is a 16 octet 1855 randomized value. 1857 3.4. Refresh Response 1859 The response from the home agent will be in the following format: 1861 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 1862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1863 | Type | Code | Lifetime | 1864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1865 | Home IP Address | 1866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1867 | Home Agent IP Address | 1868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1869 | Care of IP Address | 1870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1871 | Identification | 1872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1873 | Identification | 1874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1876 Type 4 (Refresh Response) 1878 Code One of the following: 1879 0 - Service will be provided 1881 128 - reason unspecified 1882 129 - administratively prohibited 1883 130 - insufficient resources 1884 131 - mobile node proxy failed 1885 authentication 1886 133 - registration identification mismatch 1887 134 - poorly formed request 1888 135 - too many simutaneous mobility 1889 bindings 1890 140 - The VPN has not been configured 1891 141 - The IP Address already exists 1892 142 - The IPX Address already exists 1893 143 - Network Outage 1894 144 - Encryption type not supported 1896 Lifetime The number of seconds before the Gateway 1897 will consider the tunnel expired, unless 1898 a refresh or new tunnel Registration 1899 Request is received. 1901 Home IP Address Set to zero. 1903 Home Agent IP Address IP Address of the home agent, copied from 1904 the pending Refresh Request. 1906 Identification The identification field consists of two 1907 parts. The most significant four bytes 1908 contain a valid timestamp, which is the 1909 number of seconds since January 1, 1900 1910 (as defined by the NTP protocol). 1912 The least significant four bytes MUST contain the same value which was 1913 set in the request. This is used in order to simplify matching the 1914 request and the response. 1916 The following extension will be added to the message: 1918 3.4.1. VTP Extensions 1920 This extension is used to encapsulate all VTP specific extensions. This 1921 is done in order to conserve the small extension address space which 1922 is available in the Mobile IP header. Each sub-extension may all be 1923 encapsulated within one single VTP extension, or each sub-extension 1924 may be individually encapsulated with this extension. 1926 The format of the header is as defined below: 1928 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 1929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1930 | Type | Length | Sub-Type | 1931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1932 | Length | flag | 1933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1935 Type 65 (VTP Extensions) 1937 Length variable 1939 Sub-Type Sub Attribute Number 1941 Sub-Length Sub Attribute Length 1943 Flag The flag field contains a set of 1944 properties for the following sub-attribute. 1946 The following bits have been defined: 1948 VTP_MANDATORY_SUPPORT 0x01 1949 If this bit is set, the attribute MUST be 1950 supported by the peer. If this attribute 1951 cannot be supported, an error code must 1952 be returned. 1954 3.4.1.1. Tunnel-Identifier Extension 1956 This extension is REQUIRED for tunnel refresh messages. This extension 1957 SHOULD be the first extension following the protocol header. 1959 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 1960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1961 | Type | Length | Sub-Type | 1962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1963 | Sub-Length | flag | Tunnel Identifier | 1964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1965 | Tunnel Identifier | 1966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1968 Sub-Type 1 (VTP Tunnel-Identifier Extension) 1970 Sub-Length 4 1972 Flag Bit 1 MUST be set (mandatory support) 1974 Tunnel ID The Tunnel Identifier contains the GRE 1975 session ID. This identifier is used within 1976 each GRE header to indicate the session. 1977 The Tunnel ID contains two session 1978 identifiers; the least significant two 1979 bytes contains the tunnel initiator's 1980 session identifier and the most 1981 significant two bytes are the peer's 1982 session ID. 1984 3.4.1.2. Virtual-Private-Networking Extension 1986 The Virtual Private Networking Extension MUST be present if such an 1987 extension was present in the Refresh Request. 1989 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 1990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1991 | Type | Length | Sub-Type | 1992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1993 | Sub-Length | flag | VPN Identifier | 1994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1995 | VPN Identifier | 1996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1998 Sub-Type 9 (Virtual-Private-Networking Extension) 2000 Sub-Length 4 2002 Flag Bit 1 MUST be set (mandatory support) 2004 VPN ID The VPN Identifier MUST be set to the same 2005 value as the one which was reported in the 2006 original Registration Request. 2008 3.4.2. Mobile-Home Authentication Extension 2010 This extension is used as described in the IP Mobility specification. 2011 This extension MUST be added as the first extension in all 2012 tunnel management messages. 2014 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 2015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2016 | Type | Length | SPI | 2017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2018 | SPI | Authentication Value | 2019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2020 | Authentication Value | 2021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2022 | Authentication Value | 2023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2024 | Authentication Value | 2025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2026 | Authentication Value | 2027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2029 Type 32 (Mobile-Home Authentication Extension) 2031 Length 20 2033 SPI Security Parameter Index. Contains the 2034 Security association value which was 2035 used during the session key management 2036 for the key used in creating the 2037 Authentication value for this message. 2039 Authentication Value Contains a MD5 representation of the whole 2040 Tunnel Registration packet up to and 2041 including this extensions length field. 2042 The value is a MD5 hash of the following: 2044 MD5( Session Key | Packet | Session Key ) 2046 Where the packet is the whole Mobile IP 2047 packet up to and including the length 2048 field. The Session Key is a 16 octet 2049 randomized value. 2051 3.5. Deregistration Request 2053 The Deregistration Request messages is sent from the mobile node proxy 2054 to the home agent. This message is sent to the home agent in order to 2055 shutdown the tunnel. For a NAS this is done when the PPP connection 2056 is terminated. For routers, this may be done when the connection has 2057 been idle for a specified amount of time. 2059 Note that although the layer 3 protocols do not require the Home Agent 2060 to send a Deregistration request to the Mobile Node for any reason, 2061 there may exist other extensions which do require this feature. For 2062 this reason, it is possible for a Home Agent to initiate a refresh 2063 request. The following message format is used: 2065 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 2066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2067 | Type |S|B|F|M|G|V|T|r| Lifetime | 2068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2069 | Home IP Address | 2070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2071 | Home Agent IP Address | 2072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2073 | Care of IP Address | 2074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2075 | Identification | 2076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2077 | Identification | 2078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2080 Type 1 (Deregistration Request) 2081 S, B, M, V All set to zero to disable features not 2082 required. 2084 D 1, The mobile node proxy will itself 2085 decapsulate datagrams which are sent to 2086 the care-of address. 2088 G 1, GRE encapsulation enabled. 2090 T 1, Bi-directional tunneling enabled. 2092 r 0, Reserved Field 2094 Lifetime Contains a value of zero to indicate a 2095 deregistration. 2097 Home IP Address For routers, this value is the IP address 2098 of the router. 2100 For Dial-up Routers, this is the IPCP 2101 assigned IP address. 2103 If the mobile node proxy does not support 2104 IP, this value is set to zero. 2106 Home Agent IP Address IP Address of the home agent IP Address 2108 Care of Address The IP Address of the tunnel initiator 2109 (Foreign Agent). 2111 Identification The identification field consists of two 2112 parts. The most significant four bytes 2113 contain a valid timestamp, which is the 2114 number of seconds since January 1, 1900 2115 (as defined by the NTP protocol). The 2116 least significant four bytes contain a 2117 random value. 2119 The following extensions will be added to the message: 2121 3.5.1. VTP Extensions 2123 This extension is used to encapsulate all VTP specific extensions. This 2124 is done in order to conserve the small extension address space which 2125 is available in the Mobile IP header. Each sub-extension may all be 2126 encapsulated within one single VTP extension, or each sub-extension 2127 may be individually encapsulated with this extension. 2129 The format of the header is as defined below: 2131 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 2132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2133 | Type | Length | Sub-Type | 2134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2135 | Length | flag | 2136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2138 Type 65 (VTP Extensions) 2140 Length variable 2142 Sub-Type Sub Attribute Number 2144 Sub-Length Sub Attribute Length 2146 Flag The flag field contains a set of 2147 properties for the following sub-attribute. 2148 The following bits have been defined: 2150 VTP_MANDATORY_SUPPORT 0x01 2151 If this bit is set, the attribute MUST be 2152 supported by the peer. If this attribute 2153 cannot be supported, an error code must 2154 be returned. 2156 3.5.1.1. Tunnel-Identifier Extension 2158 This extension is REQUIRED for tunnel establishment requests and all 2159 further requests for a new client to use an existing tunnel. This 2160 extension SHOULD be the first extension following the protocol 2161 header. 2163 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 2164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2165 | Type | Length | Sub-Type | 2166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2167 | Sub-Length | flag | Tunnel Identifier | 2168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2169 | Tunnel Identifier | 2170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2172 Sub-Type 1 (VTP Tunnel-Identifier Extension) 2174 Sub-Length 10 2175 Flag Bit 1 MUST be set (mandatory support) 2177 Tunnel ID The Tunnel Identifier contains the GRE 2178 session ID. This identifier is used within 2179 each GRE header to indicate the session. 2180 The Tunnel ID contains two session 2181 identifiers; the least significant two 2182 bytes contains the tunnel initiator's 2183 session identifier and the most 2184 significant two bytes are the peer's 2185 session ID. 2187 3.5.1.2. IP-Protocol Extension 2189 This extension MUST be present if the Registration Request included 2190 this extension. The presence of this extension informs the home agent 2191 that this remote IP address no longer exists. Thus, this IP address 2192 MUST be removed from the binding table in the home agent. The format 2193 of the extension is: 2195 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 2196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2197 | Type | Length | Sub-Type | 2198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2199 | Sub-Length | flag | IP Network Address | 2200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2201 | IP Network Address (cont.) | IP Subnet Mask | 2202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2203 | IP Subnet Mask (cont.) | Interface Flags | 2204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2206 Sub-Type 10 (IP-Protocol Extension) 2208 Sub-Length 10 2210 Flag Bit 1 MUST be set (mandatory support) 2212 IP Network Address Set to the value which was in the 2213 Registration Request. 2215 IP Subnet Mask Set to the value which was in the 2216 Registration Request. 2218 Interface Flags Set to zero (0). 2220 3.5.1.3. IPX-Protocol Extension 2222 This extension MUST be present if the Registration Request included 2223 this extension. The presence of this extension informs the home agent 2224 that this remote IP address no longer exists. Thus, this IP address 2225 MUST be removed from the binding table in the home agent. The format 2226 of the extension is: 2228 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 2229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2230 | Type | Length | Sub-Type | 2231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2232 | Sub-Length | flag | IPX Network Number | 2233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2234 | IPX Network Number (cont.) | IPX Node Number | 2235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2236 | IPX Node Number (cont.) | 2237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2238 | Interface Flags | 2239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2241 Sub-Type 11 (IPX-Protocol Extension) 2243 Sub-Length 12 2245 Flag Bit 1 MUST be set (mandatory support) 2247 IPX Network Set to the value which was in the 2248 Registration Request. 2250 IPX Node Number Set to the value which was in the 2251 Registration Request. 2253 Interface Flags Set to zero (0). 2255 3.5.1.4. Virtual-Private-Networking Extension 2257 The Virtual Private Networking Extension MUST be present if such an 2258 extension was present in the Registration Request. 2260 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 2261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2262 | Type | Length | Sub-Type | 2263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2264 | Sub-Length | flag | VPN Identifier | 2265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2266 | VPN Identifier | 2267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2268 Sub-Type 9 (Virtual-Private-Networking Extension) 2270 Sub-Length 4 2272 Flag Bit 1 MUST be set (mandatory support) 2274 VPN ID The VPN Identifier MUST contain the value 2275 which was reported in the Registration 2276 Request. 2278 3.5.2. Mobile-Home Authentication Extension 2280 This extension is used as described in the IP Mobility specification. 2281 This extension MUST be added after the VTP extensions in all tunnel 2282 management messages. 2284 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 2285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2286 | Type | Length | SPI | 2287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2288 | SPI | Authentication Value | 2289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2290 | Authentication Value | 2291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2292 | Authentication Value | 2293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2294 | Authentication Value | 2295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2296 | Authentication Value | 2297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2299 Type 32 (Mobile-Home Authentication Extension) 2301 Length 20 2303 SPI Security Parameter Index. Contains the 2304 Security association value which was used 2305 during the session key management for the 2306 key used in creating the Authentication 2307 value for this message. 2309 Authentication Value Contains a MD5 representation of the whole 2310 Tunnel Registration packet up to and 2311 including this extensions length field. 2312 The value is a MD5 hash of the following: 2314 MD5( Session Key | Packet | Session Key ) 2315 Where the packet is the whole Mobile IP 2316 packet up to and including the length 2317 field. The Session Key is a 16 octet 2318 randomized value. 2320 3.6. Deregistration Response 2322 The response from the home agent will be in the following format: 2324 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 2325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2326 | Type | Code | Lifetime | 2327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2328 | Home IP Address | 2329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2330 | Home Agent IP Address | 2331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2332 | Care of IP Address | 2333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2334 | Identification | 2335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2336 | Identification | 2337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2339 Type 3 (Deregistration Response) 2341 Code One of the following: 2342 0 - Service will be provided 2344 128 - reason unspecified 2345 129 - administratively prohibited 2346 130 - insufficient resources 2347 131 - mobile node proxy failed 2348 authentication 2349 133 - dereg. identification mismatch 2350 134 - poorly formed request 2351 140 - The VPN has not been configured 2352 141 - The IP Address already exists 2353 142 - The IPX Address already exists 2354 143 - Network Outage 2356 Lifetime 0 2358 Home IP Address IPCP assigned IP address, copied from the 2359 pending Deregistration Request. 2361 Home Agent IP Address IP Address of the home agent, copied from 2362 the pending Deregistration Request. 2364 Identification The identification field consists of two 2365 parts. The most significant four bytes 2366 contain a valid timestamp, which is the 2367 number of seconds since January 1, 1900 2368 (as defined by the NTP protocol). 2370 The least significant four bytes MUST 2371 contain the same value which was set in 2372 the request. This is used in order to 2373 simplify matching the request and the 2374 response. 2376 The following extension will be added to the message: 2378 3.6.1. Mobile-Home Authentication Extension 2380 This extension is used as described in the IP Mobility specification. 2381 This extension MUST be added as the first extension in all 2382 tunnel management messages. 2384 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 2385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2386 | Type | Length | SPI | 2387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2388 | SPI | Authentication Value | 2389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2390 | Authentication Value | 2391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2392 | Authentication Value | 2393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2394 | Authentication Value | 2395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2396 | Authentication Value | 2397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2399 Type 32 (Mobile-Home Authentication Extension) 2401 Length 20 2403 SPI Security Parameter Index. Contains the 2404 Security association value which was used 2405 during the session key management for the 2406 key used in creating the Authentication 2407 value for this message. 2409 Authentication Value Contains a MD5 representation of the whole 2410 Tunnel Registration packet up to and 2411 including this extensions length field. 2412 The value is a MD5 hash of the following: 2414 MD5( Packet | Session Key ) 2416 Where the packet is the whole Mobile IP 2417 packet up to and including the length 2418 field. The Session Key is a 16 octet 2419 randomized value. 2421 4.2. Data Encapsulation 2423 Once a "tunnel" has been established via a success Registration 2424 Request, all data is encapsulated within a GRE header. 2426 This section defines the encapsulation header which is required for the 2427 VTP and L2TP extension. 2429 0 1 2 3 2430 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 2431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2432 |C|R|K|S|s|Recur|A|T|L|Flg| Ver | Protocol Type | 2433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2434 | CheckSum (Opt) | Offset(Opt) | 2435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2436 | Key (Opt) | 2437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2438 | Sequence Number (Opt) | 2439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2440 | Tunnel Identifier | 2441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2443 C Checksum Present. Set to zero (0). 2445 R Routing Present. Set to zero (0). 2447 K Key Present. Set to zero (0). Set to 2448 (1) if the GRE header is to be 2449 authenticated and contains the Key field. 2451 S Sequence Number Present. Set to zero (0). 2453 s Strict Source Route Present. Set to 2454 zero (0). 2456 A Acknowledgment sequence number present. 2457 Set to zero (0). 2459 T Tunnel Identifier. Set to one (1). 2461 L L2TP Tunnel Information. Set to zero (0). 2463 Recur Recursion control. set to zero (0). 2465 Flg (Flags) Must be set to zero. 2467 Ver Must contain 0. 2469 Protocol Type Contains the Assigned Protocol ID 2470 (see assigned numbers RFC). 2472 Key Key field is zero if each data packet is 2473 not authenticated. 2475 Tunnel Identifier Contains the Tunnel Identifier which was 2476 negotiated during the Registration 2477 process. Present if the 'T' bit is set. 2479 This field is used in order to identify 2480 which tunnel the data belongs to. 2482 Note that an encapsulated packet which contains an invalid tunnel 2483 identifier in the Tunnel ID field MUST be dropped. 2485 4. Radius Support 2487 In order for NAS' to support the VTP protocol, a minimum amount of 2488 configuration is required for tunnel management. It is desirable to 2489 allow the configuration to exist on a separate server in order to 2490 minimize deployment configuration issues. For this reason, the 2491 following RADIUS attributes have been defined. 2493 4.1. VPN ID 2495 The VPN ID is returned by the Radius Server in order for the NAS to 2496 identify a VPN. The following packet format extension is added to the 2497 ACCESS_ACCEPT packet. 2499 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 2500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2501 | Type | Length | Organization ID | 2502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2503 | Organization ID(cont.) | Indicator | 2504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2505 | Indicator (cont.) | VPN Identifier | 2506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2507 | VPN Identifier | 2508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2510 Type 26 (Vendor Specific) 2512 Length 14 2514 Organization ID 429 for US Robotics 2515 430 for Bay Networks 2517 Indicator 0x9006 (VPN-ID) 2519 VPN Identifier 4 byte VPN Identifier 2521 4.2. VPN Name 2523 The VPN Name is returned by the Radius Server in order for the NAS 2524 to identify a VPN Name. The presence of this attribute is optional and 2525 is used primarily for the command line display. The following packet 2526 format extension is added to the ACCESS_ACCEPT packet. 2528 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 2529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2530 | Type | Length | Organization ID | 2531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2532 | Organization ID(cont.) | Indicator | 2533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2534 | Indicator (cont.) | VPN Name.. | 2535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2537 Type 26 (Vendor Specific) 2539 Length Variable 2541 Organization ID 429 for US Robotics 2542 430 for Bay Networks 2544 Indicator 0x9007 (VPN-Name) 2545 VPN Name Null Terminated String Containing the 2546 VPN Name. 2548 4.3. VPN Gateway 2550 The VPN Gateway MUST be returned by the Radius Server within the 2551 ACCESS_ACCEPT messages in order for the NAS to correctly identify 2552 the home agent associated with the mobile node proxy. Note that more 2553 than one VPN Gateway attribute may be returned in a single 2554 ACCESS_ACCEPT. The following packet extension will be returned: 2556 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 2557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2558 | Type | Length | Organization ID | 2559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2560 | Organization ID(cont.) | Indicator | 2561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2562 | Indicator (cont.) | Addr Format | VPN Gateway | 2563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2564 | VPN Gateway | Enc Sess. Key | 2565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2566 | Encoded Session Key (cont.) | 2567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2568 | Encoded Session Key (cont.) | 2569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2570 | Encoded Session Key (cont.) | 2571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2572 | Encoded Session Key (cont.) |Tunnel Refresh | 2573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2574 |Tunnel Refresh | Desc. Length | Description ... | 2575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2577 Type 26 (Vendor Specific) 2579 Length variable 2581 Organization ID 429 for US Robotics 2582 430 for Bay Networks 2584 Indicator 0x900A (VPN-Gateway) 2586 Address Format Contains a byte which represents the VPN 2587 Gateway field's Address format. The 2588 following values are currently supported: 2590 VTP_ADDRESS_TYPE_IPV4 0x01 2591 The address contains a 32 bit IP 2592 version 4 address. 2594 VTPADDRESS_TYPE_IPV6 0x02 2595 The address contains an IP Version 6 2596 address. 2598 VPN Gateway Contains a 4 octet IP Address of the home 2599 agent. 2601 Enc. Session Key Contains a 16 octet value to be sent to 2602 the home agent. 2604 This string contains the encoded value of 2605 the Session Key. 2607 Tunnel Refresh Contains an optional Tunnel Refresh value 2608 in seconds. 2610 Desc. Length Contains the number of bytes of the 2611 description string. 2613 Description Contains an ASCII description of the 2614 Home Agent (i.e. location information). 2616 4.4. Session Key Vector 2618 This attribute is returned by the remote Radius server in the 2619 Access-Accept packet. It must be present if the VPN Gateway attribute 2620 is present. The NAS uses the session key vector attribute to determine 2621 the Session Key that it shares with the Frame Relay Gateway. The 2622 following packet extension will be returned: 2624 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 2625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2626 | Type | Length | Organization ID | 2627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2628 | Organization ID(cont.) | Indicator | 2629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2630 | Indicator (cont.) | Encoded Session Key | 2631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2632 | Encoded Session Key (cont.) | 2633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2634 | Encoded Session Key (cont.) | 2635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2636 | Encoded Session Key (cont.) | 2637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2638 | Encoded Session Key (cont.) | 2639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2640 Type 26 (Vendor Specific) 2642 Length 26 2644 Organization ID 429 for US Robotics 2645 430 for Bay Networks 2647 Indicator 0x900B (Session Key Vector) 2649 Enc. Session Key Contains a 16 octet vector, which contains 2650 a four octet, encoded Session Key. 2652 5. Security Mechanism 2654 This section will detail the security mechanisms used by for the 2655 tunneling protocol. 2657 5.1. Data Authentication 2659 There exists a problem where a malicious user may spoof encapsulated 2660 packets to the mobile node proxy or home agent by adding the GRE 2661 header. In order to minimize this occurrence, it is desirable to add 2662 a header which contains a Message Integrity Check (MIC). The IP 2663 Authentication Header is used for this purpose in the following manner: 2665 +-----------------------------------------------------+ 2666 | IP Header | Auth Header | GRE Header | User Payload | 2667 +-----------------------------------------------------+ 2669 Note that the use of the data authentication header is optional and is 2670 outside of the scope of this document. 2672 5.2. Data Encryption 2674 In order to provide a true secure tunnel over an unsecure network, it 2675 is desirable to encrypt the user data. The ESP Header is used for 2676 this purpose in the following manner: 2678 +----------------------------------------------------+ 2679 | IP Header | ESP Header | GRE Header | User Payload | 2680 +----------------------------------------------------+ 2682 Note that the use of the data encryption header is optional and is 2683 outside of the scope of this document. 2685 5.3. Multi-Provider Tunnel Establishment Security 2687 In order to support multi-provider networks, it must be assumed that 2688 the NAS and the Gateway exist on different networks. In order to 2689 support such a scenario, it is required that tunnel establishment ONLY 2690 occur upon consent of the provider which owns the Gateway. In this 2691 case, it is unlikely that both the mobile node proxy and the home agent 2692 share a common secret, therefore it is necessary for a third party 2693 server to perform the session key encryption. 2695 Service Provider A | Service Provider B 2696 +----------------+----------------+ 2697 | | | 2698 + | + 2699 /| Public | Network |\ 2700 / | | | \ 2701 / | | | \ 2702 / | | | \ 2703 +------------/+ | | | +\------------+ 2704 |RADIUS Server| ++---------------+---------------++ |RADIUS Server| 2705 | | / | \ | | 2706 +------+------+ / | \ +------+------+ 2707 | / | \ | 2708 | / | \ | 2709 | / | \ | 2710 | / | \ | 2711 +------+----/-+ | +-\----+------+ 2712 | NAS | | | VTP Server | 2713 | | | | | 2714 +------+------+ | +------+------+ 2715 | | | 2716 ------+------ | ------+------ 2717 | | 2718 +------+------+ +------+------+ 2719 | Joe@ABC | |ABC's Router| 2720 | | | | 2721 +-------------+ +------+------+ 2722 | 2723 | 2724 | 2725 ---+--------+------- 2726 | 2727 | 2728 +------+------+ 2729 | Host | 2730 | | 2731 +-------------+ 2733 Figure 3: Multi-Provider Network 2735 Figure 3 depicts a scenario with multiple service providers. In this 2736 example, user Joe@ABC dials into a local service provider to connect to 2737 his company's corporate backbone. In this example, the home agent which 2738 serves the corporation is owned by a separate service provider. Note 2739 that in this example RADIUS is used, but the protocol is not limited to 2740 RADIUS. 2742 When the call is received by the NAS, an ACCESS_REQUEST is sent to the 2743 local RADIUS Server. The RADIUS Server then figures out that the 2744 authentication request must be forwarded to Service Provider B's RADIUS 2745 Server. 2747 If the Remote RADIUS Server successfully authenticates the user, then 2748 two attributes are attached to the ACCESS_ACCEPT. The server generates 2749 a random 16 octet value one which will be used as a temporary session 2750 key for that tunnel (which is only valid for the duration of the 2751 tunnel). The good formula for generating the random value is known as 2752 the linear congruential algorithm, where: 2754 Xn+1 = (A*Xn + C) (mod M), n>=0 2756 Where: 2757 Xn = See formula below. 2758 M = 248 2759 A = 2736731631558 2760 C = 138 2761 And 2763 X0 = seed(25) 330E16 2765 Where the most significant 32 bits are set to the seed and the least 2766 significant 16 bits are set to the constant value. The X0 value is 2767 plugged into the above formula and the random value returned is in fact 2768 the first 32 bits of X1. 2770 The RADIUS Server then encrypts the Session Key using the RAD->RAD 2771 Shared Secret and adds it to the Session Key Vector Attribute 2772 (see 5.4). The actual encryption mechanism used is as follow: 2774 ( md5( CHAP Vector | RAD->RAD SS ) � Session Key ) 2776 The Remote RADIUS Server then also encodes the same Session Key using 2777 the it's common shared secret with the gateway which it will return in 2778 the Frame Relay Gateway RADIUS attribute. The resulting hash will be 2779 added to the same attribute (see 7.2.4). The encryption mechanism is: 2781 ( md5( CHAP Vector | GW->RAD SS ) � Session Key ) 2783 If the RADIUS Server is to return more than one Frame Relay Gateway 2784 attributes, the above encryption is done for each gateway, using the 2785 GW->RAD SS which is common between them. Note that the NAS will attempt 2786 to establish a tunnel with the IP address which is in the first Gateway 2787 attribute, and will try any other Gateways if more than one attribute 2788 was returned and the first Gateway did not respond. 2790 Once the Local RADIUS Server receives the packet, it will check for the 2791 Session Key Vector attribute. If one is found, knowing RAD->RAD SS, it 2792 will extract the Session Key from the attribute and re-encrypt the pair 2793 using the shared secret which is common between itself and the 2794 requesting NAS. The formula is as follow: 2796 ( md5( CHAP Vector | NS->RAD SS ) � Session Key ) 2798 Once the NAS receives the response, it will extract the Session Key 2799 from the attribute. When the Tunnel Registration Request is formed, the 2800 RADIUS Identification field and the encrypted session key must be 2801 inserted in the Registration Extensions of the Registration Request. At 2802 this point, the NAS will add a Mobile-Home Authentication Extension and 2803 use the unencrypted Session Key to do the following formula: 2805 ( md5( RR Packet | Session Key) ) 2807 Where: 2809 RR Packet The whole Tunnel Registration Request up 2810 to the SPI field of the Mobile-Home 2811 Authentication Extension. 2813 Upon receipt of the Tunnel Registration Request, the Frame Relay 2814 Gateway, knowing it's common shared secret with it's local RADIUS 2815 Server (in this case the RADIUS Server in provider B's network), 2816 extracts the Session Key. Using the Session Key, the Gateway will MD5 2817 the packet as shown above and ensure that the result is identical to 2818 the value which is included in the Mobile-Home Authentication 2819 Extension. 2821 Note that the Registration Request/Response each contained an SPI 2822 value in the Mobile-Home Authentication Extension. This value must be 2823 retained by each peer in order to send a subsequent message (i.e. 2824 Tunnel Refresh/Deregistration). This allows the use of multiple 2825 session keys per tunnel, and by using the SPI there is a method to 2826 inform the peer which session key was used for which message. 2828 There are two methods of doing this, one where the peers share a 2829 shared secret (pre-configured in some way), which is used in 2830 decrypting the shared secret. The alternative, yet more complex, 2831 requires an external Key Distribution Center to handle the distribution 2832 of keys. Due to the uniqueness of this protocol, the KDC required for 2833 this protocol does not fit with any existing key distribution scheme. 2834 This approach has the benefit of a much greater secure environment, 2835 which allows intra service provider tunnels. Note that in both cases, 2836 the session key generation is only valid for the duration of the 2837 tunnel. Section 9 covers the security mechanism in more detail. 2839 Acknowledgements 2841 We would like to thank the following people for their help and support: 2842 Noor Kamruddin, Sumit Vakil, Peter Pappas, Pat Henkle, Kurtiss Johnson, 2843 Greg Linn, Nagaraj Arunkumar, Johnathan Zarkower, Wei Hioe, Art 2844 Muzaffar, Lionel Gibbons, Jun Lopez, Micheal Shapiro, Gary Malkin, 2845 Paul Raison, Tommy Kwan. 2847 We would also like to thank the following manufacturers for their 2848 support in the development of VTP: US Robotics Access Corp, Bay 2849 Networks Inc., ECI Telematics, 3Com Corp., Novell Corp. 2851 References 2853 [1] C. Huitema, "Routing in the Internet", Prentice Hall, 1995 2855 [2] C. Hedrick, "Routing Information Protocol", RFC-1058, Rutgers 2856 University, June 1988 2858 [3] C. Perkins, "IP Mobility Support", draft-ietf-mobileip-protocol-13.txt 2859 November 1995 2861 [4] R. Atkinson, "Security Architecture for the Internet Protocol", 2862 RFC-1825, August 1995 2864 [5] R. Atkinson, "IP Authentication Header", RFC-1826, August 1995 2866 [6] R. Atkinson, "IP Encapsulating Security Payload", RFC-1827, 2867 August 1995 2869 [7] P. Metzger, "IP Authentication using keyed MD5", RFC-1828, 2870 August 1995 2872 [8] P. Karn, "The ESP DES-CBC Transform", RFC-1829, August 1995