idnits 2.17.1 draft-ietf-mobileip-calhoun-tep-01.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-19) 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 385 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 521 instances of too long lines in the document, the longest one being 1 character 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 277: '...ng foreign agent MAY use procedures th...' RFC 2119 keyword, line 280: '...e. Alternatively, the mobile node MAY...' RFC 2119 keyword, line 286: '...bile node. This MAY happen as a resul...' RFC 2119 keyword, line 447: '...he foreign agent MUST insert a locally...' RFC 2119 keyword, line 451: '...r extension, it MUST insert a locally...' (53 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 13 has weird spacing: '... Group of t...' == Line 19 has weird spacing: '...ocument is a...' == Line 20 has weird spacing: '...cuments of t...' == Line 21 has weird spacing: '... groups may ...' == Line 25 has weird spacing: '... and may b...' == (380 more instances...) -- 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 (March 1998) is 9532 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) -- Possible downref: Normative reference to a draft: ref. '1' ** Downref: Normative reference to an Informational RFC: RFC 1701 (ref. '3') -- Possible downref: Normative reference to a draft: ref. '4' -- Possible downref: Normative reference to a draft: ref. '5' -- Possible downref: Normative reference to a draft: ref. '6' == Outdated reference: A later version (-11) exists of draft-ietf-mobileip-optim-07 -- Possible downref: Normative reference to a draft: ref. '8' ** Obsolete normative reference: RFC 2002 (ref. '9') (Obsoleted by RFC 3220) ** Obsolete normative reference: RFC 1700 (ref. '10') (Obsoleted by RFC 3232) -- Possible downref: Non-RFC (?) normative reference: ref. '11' == Outdated reference: A later version (-05) exists of draft-ietf-ipsec-esp-v2-00 == Outdated reference: A later version (-06) exists of draft-ietf-ipsec-auth-header-01 -- Possible downref: Normative reference to a draft: ref. '15' -- Possible downref: Non-RFC (?) normative reference: ref. '16' == Outdated reference: A later version (-03) exists of draft-ietf-mobileip-regkey-00 -- Possible downref: Normative reference to a draft: ref. '17' == Outdated reference: A later version (-12) exists of draft-ietf-roamops-nai-10 ** Obsolete normative reference: RFC 1826 (ref. '19') (Obsoleted by RFC 2402) ** Obsolete normative reference: RFC 1827 (ref. '20') (Obsoleted by RFC 2406) == Outdated reference: A later version (-07) exists of draft-ietf-ipsec-isakmp-oakley-06 ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-isakmp-oakley (ref. '21') -- Possible downref: Non-RFC (?) normative reference: ref. '22' Summary: 18 errors (**), 0 flaws (~~), 12 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile IP Working Group Pat Calhoun 3 INTERNET DRAFT Gabriel Montenegro 4 Category: Standards Track Charles Perkins 5 Title: draft-ietf-mobileip-calhoun-tep-01.txt Sun Microsystems, Inc. 6 Date: March 1998 8 Tunnel Establishment Protocol 9 draft-ietf-mobileip-calhoun-tep-01.txt 11 Status of this Memo 13 This document is a submission by the Mobile IP Working Group of the 14 Internet Engineering Task Force (IETF). Comments should be submitted 15 to the mobile-ip@SmallWorks.COM mailing list. 17 Distribution of this memo is unlimited. 19 This document is an Internet-Draft. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet- Drafts as reference 27 material or to cite them other than as ``work in progress.'' 29 To learn the current status of any Internet-Draft, please check the 30 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 31 Directories on ftp.is.co.za (Africa), nic.nordu.net (North Europe), 32 ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim), 33 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 35 Abstract 37 A general tunnel establishment protocol (TEP) is defined to handle 38 multi-protocol tunneling as well as multilevel domains guarded by 39 tunnel agents which may be thought of as security gateways, or 40 alternatively as modified foreign agents defined by with Mobile IP. 41 Mobile IP provides the model for TEP; the registration messages in RFC 42 2002 establish a tunnel between the home agent and the foreign agent. 44 1. Introduction 46 Tunnels are needed for a variety of reasons in the Internet. Two 47 nodes may wish to communicate by using protocol data units (PDUs) for 48 protocols other than IP that are not easily routed over the Internet 49 infrastructure. Such PDUs can, however, be transmitted over the 50 Internet encapsulated within IP. For remote access, one might wish to 51 set up a secure tunnel between a current point of attachment and a 52 enterprise network. Mobile IP (RFC 2002) [9] requires the creation of 53 a tunnel so that the home agent can transmit IP datagrams to the care- 54 of address of the mobile node. All of these separate needs share a 55 common need for tunnel establishment and management, which can be 56 fulfilled by enhancements of the tunnel establishment procedures 57 specified in RFC 2002 [9], and the tunnel management procedures 58 specified in RFC 2003 [7]. This document specifies those 59 enhancements. 61 Currently, Mobile IP lacks flexibility in how registrations are 62 accomplished in that it assumes that the endpoints of the tunnel are 63 mutually trusting entities that are able to and willing to exchange 64 registration protocol packets. 66 Furthermore, it assumes that the mobile node creates the Registration 67 Request. TEP addresses these issues by allowing the creation of 68 compound tunnels. TEP recognizes that in addition to tunnel endpoints, 69 there may be tunnel intermediate points. Registrations are exchanged 70 only between intermediate points. The result is a composite tunnel 71 with some very desireable security and scalability characteristics: 73 - Different security domains interface at an intermediate point, 74 which provides a clean separation between segments. 76 - Movement beyond a certain intermediate point only implies 77 re-registrations from that point onward. 79 This document draws on several previous documents -- notably 80 "Integrated Mobility Extension" [4], "Virtual Tunneling Protocol 81 (VTP)" [1], and "Tunnel Set-up Protocol" [5]. 83 1.1. Terminology 85 This document uses the following terms: 87 Binding 89 An association between a mobile node's address and the IP 90 address of a Tunnel Agent nearer to the mobile node. 92 Chained Registration 93 A registration in which the home agent and the mobile node do 94 not directly exchange a Registration Request and Reply. 95 Rather, the request/reply is carried out between endpoints of 96 tunnel segments. The composition of tunnel segments represents 97 the compound tunnel from home agent to mobile node. 99 Downstream Agent 101 The endpoint of a tunnel segment that is closer to the mobile 102 node. The last downstream agent may be the mobile node itself 103 or its foreign agent. 105 Home Agent 107 The tunnel agent which terminates the tunnel, and which 108 encapsulates datagrams to be sent to the mobile node. 110 Mobile Node 112 The node on whose behalf the tunnel is established. 114 SPI 116 Acronym for "Security Parameters Index". The combination of a 117 destination address, and an SPI uniquely identifies a security 118 association. The SPI is carried Registration Requests and 119 Replies to enable the receiving system to select the SA under 120 which a received packet will be processed. An SPI has only 121 local significance, as defined by the creator of the SA 122 (usually the receiver of the packet carrying the SPI); thus an 123 SPI is generally viewed as an opaque bit string. However, the 124 creator of an SA may choose to interpret the bits in an SPI to 125 facilitate local processing. 127 Surrogate Agent 129 A tunnel agent establishing a tunnel on behalf of a mobile node 130 which does not take any active role in the establishment 131 process. 133 Surrogate Registrations 135 These are registrations that are not created by the mobile 136 node. Rather, they are created on its behalf by another entity 137 (a foreign agent). This is not a new concept and is in use in 138 commercial implementations. Nevertheless, with its introduction 139 of chained registrations and compound tunnels, this document 140 allows for registrations that neither originate at the mobile 141 node (i.e. they start off as surrogate registrations), nor do 142 they terminate at the home agent (i.e. they terminate at an 143 intermediate point at least one tunnel away from the home 144 agent). 146 Targeted Tunnel Agent 148 The ultimate intended recipient for a Tunnel Establishment 149 Request. 151 Tunnel Agent 153 An agent which can perform encapsulation and decapsulation 155 Tunnel Requestor 157 Either a mobile node, or a surrogate agent acting on its 158 behalf. 160 Upstream Agent 162 The endpoint of a tunnel segment that is closer to the home 163 agent. The last upstream agent is the home agent itself. 165 Notice that in this document, the term "mobile node" is used to help 166 understanding. There is no protocol dependence upon the fact that the 167 node is mobile, but we so far have not been very successful in finding 168 suitable terminology. The previous term we had used in this document 169 was "PDU receiver". Similarly, what was previously called the 170 "encapsulator" is now called a home agent. Finally, what was 171 previously called the "decapsulator" is now called the "foreign 172 agent", and is a tunnel agent capable of forwarding decapsulated PDUs 173 from the home agent to the mobile node. 175 1.2. Design Goals 177 One of the main objectives in defining TEP is to support Mobile 178 Network Computers [11]. Given that these devices are meant to be very 179 lightweight and to keep as little state as possible, TEP's design 180 goals are: 182 - Simplicity. 184 TEP only defines the minimum required to support the additional 185 applications and target devices. Surprisingly little needs to 186 be specified in order to adapt Mobile IP to serve as a remote 187 access mechanism based on layer 3 forwarding. 189 - Reusability. 191 Unless otherwise specified, TEP adopts packet formats and 192 protocol behavior as specified by Mobile IP. This results in 193 one protocol that solves mobility and remote access. 195 - Security. 197 Given the nature of remote access, security associations are 198 required of entities exchanging Registration Protocol packets 199 over public sectors of the internet. Privacy and authentication 200 of data transfer is also a requirement in these conditions, and 201 is accomplished by using ESP [12] and optionally using AH [13]. 203 2. Overview of tunnel establishment 205 Mobile IP [9] is a tunnel between the home agent and the foreign 206 agent, on behalf of a mobile node. 208 In the Tunnel Establishment Protocol (TEP), the protocol methods used 209 by Mobile IP are modified to work between arbitrary nodes. When a 210 tunnel is established, the upstream agent (called the home agent) then 211 transmits PDUs to the tunnel endpoint (called the foreign agent) 212 according to the tunnel establishment parameters. Generally, the 213 tunnel establishment parameters include a network address of the node 214 for which the tunnel is being established, called the mobile node. 215 The foreign agent may then use any of a variety of methods, to further 216 transmit the decapsulated PDU so that it can be received by the mobile 217 node (one mechanism which is defined in this document). If the mobile 218 node is the same node as the foreign agent, then no further network 219 operations are needed to deliver the PDU. 221 When the home agent obtains a PDU that needs to be transmitted to the 222 mobile node, the home agent consults a table to determine the 223 appropriate tunnel endpoint for that mobile node. In the case of 224 mobile IP, the table is indexed by the mobile node's IP address. This 225 document specifies ways to allow the table to be indexed by other 226 network-layer addresses. Additionally, each table entry will contain 227 other necessary parameters associated with the tunnel as part of the 228 establishment process. The act of creating or updating the table 229 entry which contains all of the parameters associated to the tunnel is 230 called tunnel establishment, or just establishment. Note that a 231 binding is the equivalent of a row (entry) in the table. 233 The procedures in this document deal with the actions of four separate 234 TEP entities, as outlined above, called the home agent, the foreign 235 agent, the gateway foreign agent, and the mobile node. For simplicity, 236 it is assumed that all home agents can also perform decapsulation and 237 vice versa. A tunnel agent is thus a node that can perform the 238 functions of either the home agent or the (gateway) foreign agent, and 239 tunnels are said to be established between two tunnel agents. The 240 foreign agent and mobile node may be the same node. 242 This document does not specify means by which a mobile node discovers 243 a suitable tunnel endpoint (foreign agent) which can be used for the 244 tunnel establishment. An example of one such method, by which a 245 mobile node (receiving IP data units) discovers a tunnel endpoint 246 called a care-of address, is specified as part of the Mobile IP 247 protocol, and consists of a straightforward modification of the Mobile 248 Service Extension to the ICMP Router Discovery protocol [2], as 249 specified in Mobile IP [9]. This extension will soon be specified in a 250 companion document. 252 This document assumes that each tunnel endpoint will be equipped with 253 an IP address. If the establishment completes successfully, the 254 foreign agent becomes one endpoint of a GRE tunnel [3]. The other 255 endpoint is the home agent. Once the tunnel is established, it 256 provides IP (network layer) connectivity between the two tunnel 257 agents. The tunnel appears to be a virtual point-to-point link, and 258 encapsulated PDUs traverse the tunnel as if it were a single link. 260 This document defines new extensions which are used with the existing 261 Mobile IP message types as defined in [9]. 263 Tunnel establishment requires authentication. The tunnel 264 establishment messages use some of the authentication extensions 265 defined by [17]. This security association between receiver and home 266 agent may require additional security mechanisms such as encryption 267 which are not part of the tunnel establishment, but which affect the 268 format of the encapsulated datagrams which flow through the tunnel. 269 Intermediate nodes which are involved with the tunnel establishment 270 may additionally impose their own authentication and privacy 271 requirements. Such nodes follow the dictates of their security 272 associations with the other nodes with which they communicate in the 273 course of managing the established tunnel, but the security 274 associations or the use of them are established by policy which is 275 external to TEP. 277 A requesting foreign agent MAY use procedures that are not specified 278 in this document to obtain all tunnel establishment parameters, 279 including authentication information for the mobile node, for use in 280 the Registration Request message. Alternatively, the mobile node MAY 281 (as is the case with mobile IP) transmit a Registration Request 282 message to a prospective tunnel endpoint to enable that node to 283 transact a tunnel establishment with some home agent. 285 TEP specifies that the downstream agent issue the Registration Request 286 message as surrogate for the mobile node. This MAY happen as a result 287 of protocol operations transacted between the foreign agent and the 288 mobile node. The downstream agent could, on the other hand, be 289 configured by any convenient means to have all the necessary tunnel 290 establishment parameters needed to issue a request message on behalf 291 of the mobile node. TEP makes no restriction on the methods by which 292 the foreign agent discovers the establishment parameters. 294 2.1. Chained Registrations 296 Base Mobile IP assumes that the foreign agent is directly reachable 297 from the home agent. In many situations this is not possible or 298 desirable. For example, if the foreign agent belongs to an ISP, or a 299 wireless carrier, it is not desirable to allow it direct reachability 300 to a system (the HA) that "lives" within the private network. 302 A much more secure configuration is to allow the ISP's system to 303 directly reach only as far as the private network's gateway or 304 firewall. These two systems need to share some mutual trust, 305 particularly if using surrogate registrations. 307 Another separate trust relationship is then built between the gateway 308 or firewall system, and the home agent inside the private network. 309 Notice that by introducing this intermediate system there is a very 310 clean separation between external and internal systems security 311 domains. 313 This configuration is possible because of the use of chained 314 registrations, whereas usual registration requests flow directly from 315 the mobile node to the home agent [15]. 317 2.2. Surrogate Registrations 319 Surrogate registrations are composed on behalf of a given node by 320 another node. Consider the following network: 322 MN@COA ---------------------- GFA ----- HA 324 where the mobile node has acquired a co-located address (COA). Assume 325 that the mobile node is not allowed to exchange packets directly with 326 its home agent within the private network. Instead, it sends a 327 Registration Request to the gateway foreign agent (GFA) as follows: 329 MN@COA, home agent = GFA. 331 The gateway foreign agent is not, of course, the mobile node's home 332 agent. Nevertheless, it has knowledge or can obtain knowledge (perhaps 333 after consulting a RADIUS database) of the mobile node's home agent. 334 It then composes a Registration Request aimed at establishing a tunnel 335 with the home agent: 337 MN@GFA, home agent = HA. 339 From the home agent's point of view, this registration request is 340 almost indistinguishable from what it would have received from the MN 341 directly. Notice that when the mobile node roams within the private 342 network, mobility is probably accomplished without surrogate 343 registrations. Hence, Registration Requests like the above are 344 sometimes sent directly by the mobile node to the home agent. 346 2.3. Regionalized Tunnel Management 348 The use of Hierarchical Foreign Agent Extension as defined in [6] 349 provides TEP with a method to support mobile nodes accessing their 350 private home networks from a private foreign network. 352 +------------------------------------+ 353 | Private Foreign Network | 354 | +------+ +------+ +-------+ | 355 | | MN |---| FA |------| PFA | | 356 | +------+ +------+ +---+---+ | 357 | | | 358 +------------------------------|-----+ 359 +-------|--------+ 360 | | | 361 | Public Network | 362 | | | 363 +-------|--------+ 364 | 365 +------------------------------|-----+ 366 | Private Home Network | | 367 | +------+ +---+---+ | 368 | | HA |------| PHA | | 369 | +------+ +-------+ | 370 | | 371 +------------------------------------+ 373 The above diagram provides an example of a mobile node that belongs to 374 a private network (NET 10) and temporarily visiting a foreign private 375 network (NET 10). 377 In this example the mobile node receives an advertisement from the FA 378 with the PFA's public IP address. The mobile node issues a 379 Registration Request to the FA with the home agent set to the PHA's 380 public address, which in turn adds a Hierarchical Foreign Agent 381 Extension indicating its address and forwards the request to the PFA. 383 The PFA keeps track of the mobile node's current point of attachement 384 as indicated in the hierarchical foreign agent extension and removes 385 the extension. The request is then forwarded to the PHA. 387 The PHA performs a lookup either locally or through the use of an 388 external AAA Policy Server in order to determine the mobile node's 389 true home agent. Once found, the PHA adds a hierarchical foreign agent 390 extension to the request and forwards the request to the HA. 392 The HA is now aware that the mobile node is reachable through the PHA 393 and will reply back directly to the PHA. The PHA will forward the 394 reply back to the PFA, which will in turn forward the request to the 395 FA. The FA then uses the MN's link layer address in order to forward 396 the reply to it. 398 3. Dynamic Home Address Discovery 400 It is possible for a mobile node to not have a permanently assigned IP 401 address. This is the default operating condition for a Mobile Network 402 Computer. 404 3.1. Registering over the Internet 406 When a Mobile Network Computer tries to register over the internet, it 407 may not have a valid IP address (because it is booting instead of 408 resuming, or because its lease ran out). TEP defines a home address 409 discovery mechanism akin to the home agent discovery mechanism defined 410 by Mobile IP. In both cases, a registration denial carries the 411 necessary information (see Section 6). 413 3.2. Registering within the Corporation 415 In this case, the Mobile Network Computer boots using the Network 416 Computer model of obtaining its operating parameters from a DHCP 417 server. One of the parameters received is the IP address to be used. 418 The Mobile Network Computer must make sure that it receives an IP 419 address valid for roaming as a Mobile IP node, i.e. it must be an 420 address that a home agent is willing to provide forwarding service to 421 [14]. The home agent could also be communicated using DHCP, or it 422 could be discovered using the home agent discovery mechanism in [9]. 424 4. Payload Encapsulation 426 There are two methods which may be used to encapsulate TEP payloads. 427 IP in IP encapsulation [7] can be used to encapsulate an IP packet. 428 However, TEP also adds multi-protocol support which can only be 429 handled by encapsulating with GRE [3]. The encapsulation mechanism is 430 negotiated during Mobility Registration and cannot be changed while a 431 binding is active. 433 4.1 Multi-Protocol Support and IP-only Foreign Agents 435 There are two methods for foreign agents to support multi-protocol 436 mobile nodes. One is to support all of the protocols requested and 437 "route" multi-protocol packets based on the innermost destination 438 address. 440 However, it is envisioned that not all foreign agents will support 441 protocols other than IP. Therefore in order for an IP only foreign 442 agent to support multi-protocol, it is necessary to support the Tunnel 443 Identifier extension. 445 When a foreign agent receives a Registration Request from a mobile 446 node, the foreign agent adds the Tunnel Identifier extension to the 447 request. The foreign agent MUST insert a locally unique value within 448 the most significant 16 bits of the Tunnel ID. 450 When a home agent responds successfully to a Registration Request that 451 included the Tunnel Identifier extension, it MUST insert a locally 452 unique within the least significant 16 bits of the field. 454 When the home agent receives a packet destined for the mobile node, it 455 MUST include the negotiated Tunnel ID within the KEY field of the GRE 456 header. Similarly, when the foreign Agent receives a packet from the 457 mobile node it MUST include the Tunnel ID within the KEY field of the 458 GRE header. 460 If a Registration Request is sent to re-register an existing tunnel 461 (which is presumably about to expire) it is recommended that the 462 foreign agent includes the negotiated Tunnel ID in the Tunnel 463 Identifier extension. 465 5. Security Model 467 TEP uses the Key Registration mechanisms as defined in [17]. 468 Specifically when a mobile node wishes to establish a tunnel, it 469 includes the Foreign Agent Key Request extension within the 470 Registration Request. Upon receipt the home agent includes a Foreign 471 Agent Key Reply Extension and a Home-Mobile Key Reply Extension in the 472 Registration Reply. 474 5.1. SPI Usage 476 According to [9] and [19, 20] a given security association is indexed 477 by the SPI (a 32-bit number), the destination address and the security 478 protocol (for example AH, ESP or Mobility Security Associations). 480 The first 256 SPI values are assigned by IANA, and the rest MUST be 481 unique at the destination. There are several ways to assign the non- 482 reserved SPIs: 484 - the SPI is the result of some previous and fixed agreement 485 between both parties, 487 - the SPI is the result of a security association establishment 488 procedure (for example [21] or assignment by a key-distribution 489 center). 491 Even if an SPI value has not been determined by either of the above 492 procedures, secure communication may still be possible. In this case, 493 the SPI value MUST be set to 0 [22]. This typically implies that the 494 security association is being negotiated in-line using information 495 found elsewhere within the datagram. This is similar to SKIP's in-line 496 keying, although in this case the SPI value of 1 has been assigned by 497 IANA [22]. 499 Once this secure exchange is over, a non-reserved SPI MUST be assigned 500 and used in subsequent messages. 502 6. Registration Request 504 A Registration Request message is sent by the mobile node towards the 505 foreign agent which forwards the request to the home agent. 507 Unless otherwise specified by the 'G' bit, the requestor expects to 508 receive PDUs encapsulated within an IP header. When the 'G' bit is 509 set, the PDU is to be encapsulated within GRE, which can further be 510 encapsulated within IP. 512 Since TEP requires reverse tunnels, the Registration Request MUST have 513 the reverse tunnel 'T' bit set [16]. 515 The Registration Request MUST include an authentication extension 516 appropriate to the targeted tunnel agent. The format of the 517 authentication extension is identical to one of the extensions defined 518 in the base Mobile IP specification, either a Mobile-Home 519 Authentication Extension, or a Mobile-Foreign Authentication 520 Extension. In the case of the Mobile-Foreign Authentication Extension 521 the mobile node MAY use the SPI and Mobility Security Association set 522 up when it obtained a session key (say, using Route Optimization 523 extension numbers 104 and 105 [8]), from a previous Tunnel Parameters 524 Extension it transacted with its home agent and all intervening 525 foreign agents at that time. 527 The relative order in which different extensions, when present, MUST 528 be placed is defined in [9]. 530 7. Registration Reply 532 A tunnel agent returns a Registration Reply message to a tunnel 533 requestor which has sent a Registration Request (Section 6) message 534 The Registration Reply message contains the necessary codes to inform 535 the tunnel requestor about the status of its Request, along with the 536 lifetime granted by the targeted agent. 538 When the foreign agent receives a successful Registration Reply, it 539 updates its binding for the mobile node and forwards the reply to the 540 mobile node. 542 The multi-protocol network address(es) of the mobile node MUST be 543 included in multi-protocol extension(s) within the Registration Reply 544 as they appeared in the Registration Request. Unless specifically 545 superseded in this document, all processing of Registration Replies by 546 tunnel agents is specified to be the same as the processing by tunnel 547 agents in the base mobile-IP draft specification [9]. This includes 548 determining the validity of the Registration Request, and selecting 549 the appropriate status code (from among those listed below) for the 550 reply. The IP fields and UDP fields are chosen just as with the 551 Registration Reply message in the base mobile-IP specification. 553 The following value is available for use within the Code field in 554 addition to the values defined in [9] and in the most recent "Assigned 555 Numbers" [10]: 557 140 invalid home address 559 Notice that the "invalid" home address (140) error may occur in two 560 cases: 562 1. mobile node requires an address assignment, 564 2. mobile node's lease on its previous address has expired. 566 An "invalid home address" denial carries the assigned home address in 567 the home address field of the registration reply. 569 8. Multi-Protocol Extension 571 This specification defines the Multi-Protocol Extension, which is 572 found in Registration Request and Reply messages. This extension is 573 denoted by the value of 128 in the extension field. 575 0 1 2 3 576 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 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | Type | Length | EtherType | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | Sub-Length |M| reserved | Data ... 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 is encoded in the following Type-Length-Value format: 585 Type 587 TDB 589 Length 591 Indicates the length (in octets) of the data field within this 592 Extension. The length does NOT include the Type and Length 593 octets. 595 EtherType 597 The EtherType indicates which network layer protocol address is 598 included in the Data field, and thus the particular type of 599 tunnel to be registered with the home agent. 601 Sub-Length 603 The length of the data following the reserved field 605 M(andatory) 607 When the Mandatory bit is set, the Home Agent MUST support the 608 requested extension in order to return a successful reply. 610 Data 612 Data in the particular format, specified in subsequent 613 sections, needed for the establishment of tunnel appropriate 614 for the Addr Family. 616 Each Addr Family defines a protocol and address format. The values 617 for the Addr Family are compatible with those defined by GRE [3]. The 618 contents of the Data field depend on the particular network layer. 619 For each value of the Addr Family, the format of the Data field is to 620 be outlined in a subsequent Section. 622 8.1. IPX 623 An IPX address is either 6 or 10 octets. If the target is an IPX 624 host, the extension MUST supply its 6 octet IEEE 802 address. If the 625 target is an IPX router, the extension MUST supply both its network 626 number and node number (its IEEE 802 address). 628 This extension is OPTIONAL and must be present only if the client 629 being registered supports IPX. This extension may be sent to register 630 a new client on an existing tunnel even if the initial tunnel 631 establishment request did not register IPX support. 633 Many instances of this extension may be present in a registration 634 request in the case that several IPX addresses are to be registered. 635 In this case, a conventional router or dial-up router is serving 636 multiple IPX addresses in the remote LAN. The format of the extension 637 is: 639 0 1 2 3 640 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 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | Type | Length | EtherType | 643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | Sub-Length |M| reserved | IPX Network Number | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 | IPX Network Number (cont.) | IPX Node Number | 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | IPX Node Number (cont.) | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 |Routing Support| 651 +-+-+-+-+-+-+-+-+ 653 EtherType 655 8137h (IPX) 657 Sub-Length 659 12 (the length of the Data field) 661 M(andatory) 663 The Mandatory bit MUST be set 665 reserved 667 MUST be zero 669 IPX Network 671 This field contains the IPX Network number of the remote client 672 (as negotiated by IPXCP for a dial-up user). 674 IPX Node Number 676 This field contains the IPX Node number of the remote client. 678 IPX Routing Flag 680 It is possible to enable a routing protocol over an existing 681 tunnel only if one was not already negotiated. The following 682 routing protocols may be used over the tunnel by setting the 683 following values: 685 IPX_RIP 0x0001 687 NLSP 0x0002 689 IPXWAN_2 0x0004 691 8.2. AppleTalk Address Extension 693 An AppleTalk address is three octets. If the target does not yet have 694 an AppleTalk address, the tunnel endpoint should use the address 0.0 695 (three octets of all zeros). 697 0 1 2 3 698 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 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | Type | Length | EtherType | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | Sub-Length |M|Z| reserved | Appletalk Network | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | Node number | Zone | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 EtherType 709 809Bh (Ethertalk - Appletalk) 711 Sub-Length 713 5 or 7 (the length of the Data field) 715 M(andatory) 717 The Mandatory bit MUST be set 719 Z(one) 721 If set, the Zone field is present 723 Appletalk Network 725 Two octets for the Appletalk network number 727 Node number 729 One octet for the Appletalk node number 731 Zone 733 If present, an unsigned integer indicating the Zone in which 734 the Appletalk Address is located. 736 8.3. Vines Address Extension 738 A Vines address is either 6 or 10 octets. If the target is a Vines 739 host, it MUST supply its 6 octet Vines address (normally an IEEE 802 740 address). If the target is a Vines router, it MUST supply both its 741 Vines address and the subnet number. 743 0 1 2 3 744 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 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | Type | Length | EtherType | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | Sub-Length |M| reserved | Vines Node Number ... | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | ... Vines Node Number, continued. | 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 | Vines subnet Number | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 EtherType 757 0BADh (Vines) 759 Sub-Length 761 12 (the length of the Data field) 763 M(andatory) 765 The Mandatory bit MUST be set 767 reserved 769 MUST be zero 771 Vines Node Number 773 This field contains the Vines Node number of the remote client. 775 Vines Network 777 This field contains the Vines Network number of the remote 778 client. 780 8.4. CLNP Address Extension 782 CLNP uses NSAPs as its addresses, which are of variable length. If the 783 target knows its NET (NSAP with an NSEL of 0), it MUST Include its NET 784 in the extension. Targets which do not know their NET May specify a 785 zero length address. 787 0 1 2 3 788 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 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | Type | Length | EtherType | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | Sub-Length |M| reserved | NSAP ... 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 EtherType 797 00FEh (OSI) 799 Sub-Length 801 12 (the length of the Data field) 803 M(andatory) 805 The Mandatory bit MUST be set 807 reserved 809 MUST be zero 811 NSAP 813 Network address for use by NSAP 815 9. Tunnel Establishment Protocol Extensions 817 This section contains several optional TEP extensions which MAY be 818 used during the registration process. 820 9.1. Client-Identifier Extension 822 The Client-Identifier Extension contains the user or hosts name in the 823 format defined in [18] and serves two purposes. First and foremost, 824 this extension MAY be used by intermediate foreign agents in order to 825 identify a user's domain for authentication, authorization and 826 accounting purposes. 828 When a foreign agent receives a TEP request, it can form an 829 Authentication/ Authorization request and forward the request to its 830 AAA Server to see if the local policy authorizes the mobile node to 831 use the services requested. Simply using an IP address is problematic 832 since it does not necessarily identify the user's domain. 834 The Client-Identifier Extension is also used if the mobile node is 835 requesting dynamic home address discovery. In this case since the home 836 address is set to zero (0) the foreign agent can only rely on the ID 837 field, which is not guaranteed to be unique across multiple mobile 838 nodes. The Client-Identifier does provide sufficient information for 839 the foreign agent (or downstream agent) to uniquely identify the 840 mobile node. The home agent (or upstream agent) MUST return this 841 identifier in the Registration Reply for the foreign agent to be able 842 to resolve which mobile node it is intended for. 844 The Client-Identifier Extension defined below serves this purpose. 846 The Client-Identifier Extension MUST appear before the TEP-required 847 Foreign-Home Authentication Extension. It SHOULD appear immediately 848 before it. 850 As per section 1.9 of [9], the type value of TDB implies that if a 851 node encounters a Client-Identifier Extension in a Registration 852 Request or Reply, it MAY silently ignore it. This implies that home 853 agents that comply with Mobile IP, but are unaware of the TEP 854 extension MAY still be used, as long as the mobile node does not 855 attempt home address discovery. 857 TEP home agents that support Mobile Network Computers MUST understand 858 the Client-Identifier Extension and return it in its replies. The 859 reason is that Mobile Network Computers may attempt to register using 860 a certain home address whose DHCP lease may have expired. 861 Furthermore, two or more Mobile Network Computers may attempt to use 862 the same home address. Without the Client-Identifier Extension the 863 foreign agent (or downstream agent) may be unable to resolve the 864 conflict. 866 0 1 2 3 867 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 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 | Type | Length | Reserved | 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 | Client-Identifier... 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 Type 876 TDB 878 Length 880 8 882 Reserved 884 0 886 Client-Identifier 888 Contains the Client's username or host name in the format 889 defined in [18]. 891 9.2. VPN Identifier Extension 893 The VPN Identifier Extension has no significance when the Home Agent 894 belongs to the MN's home network. However there are current services 895 already deployed which allow service providers to own the HA and share 896 it among many customers. 898 There are some obvious security considerations since the service 899 providers want to ensure that these customers cannot access each 900 other's networks through the shared HA. 902 The VPN Identifier allows the shared HA to know which domain a mobile 903 node belongs to, and furthermore only permits routing of the mobile 904 node's packet to routes which are tagged with the same VPN Identifier. 906 Implementation details of how a shared HA can handle routes for 907 multiple domains is outside the scope of this specification. 909 The optional VPN Identifier extension MAY be present in a Registration 910 Request. If present the VPN Identifier MUST be returned in the 911 Registration Reply (even if not used by the HA). 913 0 1 2 3 914 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 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 | Type | Length | Reserved | 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | VPN Identifier | 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 | VPN Name... 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 Type 925 TDB 927 Length 929 >8 931 Reserved 933 0 935 VPN Identifier 937 The VPN Identifier is a numerical representation of a domain. 938 This identifier is assigned by the service provider and must be 939 unique within the mobile network. 941 It is common for a foreign agent to retrieve this value from an 942 authentication service such as RADIUS. 944 VPN Name 946 This optional field contains the ASCII representation of the 947 VPN identifier (i.e. ABC.COM). The length of the field is 948 computed using the length (less the size of the VPN Identifier 949 field). 951 9.3. Dynamic-Connection Extension 953 The Dynamic Connection Extension is used when a service provider 954 provides a Gateway Foreign Agent or a Home Agent within its network 955 and the link to the customer network is over a WAN. 957 The information contained in this extension should be sufficient in 958 order for the GFA or HA to communicate or establish a link with the 959 CPE device. 961 0 1 2 3 962 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 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 964 | Type | Length | Reserved | 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 | Link Type | Address... 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 Type 971 TDB 973 Length 975 >8 977 Reserved 979 0 981 Link Type 983 The Link Type field contains a numerical representation of the 984 underlying link to use in order to connect to the CPE device. 985 The following have already been defined: 987 VTP_FR_PVC 0x0001 988 When set, the address refers to a Frame Relay Permanent 989 Virtual Circuit. 991 VTP_FR_SVC 0x0002 992 When set, the address refers to a Frame Relay Switched 993 Virtual Circuit. 995 VTP_ATM_PVC 0x0003 996 When set, the address refers to an ATM Permanent Virtual 997 Circuit. 999 VTP_ATM_SVC 0x0004 1000 When set, the address refers to an ATM Switched Virtual 1001 Circuit. 1003 VTP_X25_PVC 0x0005 1004 When set, the address refers to a X.25 Permanent Virtual 1005 Circuit. 1007 VTP_X25_SVC 0x0006 1008 When set, the address refers to a X.25 Switched Virtual 1009 Circuit. 1011 Address 1013 A link layer address that the GFA or HA uses in order to 1014 communicate or establish a link with the CPE device. The length 1015 of the address field is determined by the length field (less 1016 the size of the reserved and link type field). 1018 9.4. Tunnel-Identifier Extension 1020 The optional Tunnel Identifier MAY be added in a Registration Request 1021 by the foreign agent. This extension MUST NOT be used if IP-in-IP 1022 encapsulation is requested. 1024 The Tunnel Identifier added by the foreign agent MUST include a 1025 locally unique value in the most significant 16 bits. The home agent 1026 MUST include a locally unique value within the least significant 16 1027 bits. 1029 0 1 2 3 1030 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 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1032 | Type | Length | Reserved | 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 | VPN Identifier | 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 | Tunnel Identifier | 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 Type 1040 TDB 1042 Length 1044 >8 1046 Reserved 1048 0 1050 Tunnel ID 1052 The Tunnel Identifier contains the GRE session ID. This 1053 identifier is used within each GRE header to indicate the 1054 session associated with with the payload. 1056 10. Hierarchical Foreign Agent Extension 1058 One or more Hierarchical Foreign Agent Extension MAY be present in a 1059 Registration Request or Reply. If more than one Hierarchical Foreign 1060 Agent Extension is present, the order of these extensions MUST be 1061 maintained through the hierarchy. 1063 When replying with a Registration Reply, the Home Agent MUST ensure 1064 that the order of the Hierarchical Foreign Agent extensions are 1065 reversed. (PRC?!?) 1067 If the hierarchical Foreign Agent Extension is present in the Request, 1068 Each foreign agent MUST check to make sure that its address is 1069 Included in the list of tunnel agents. If not, it rejects the Request 1070 with a status code of 70. 1072 Otherwise, the foreign agent makes note of the address of the next 1073 lower-level tunnel agent, for future association with the mobile 1074 node's network address. 1076 0 1 2 3 1077 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 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 | Type | Length | Reserved | 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 | Next Level Care-of Address | 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 Type 1085 TDB 1087 Length 1089 6 1091 Reserved 1093 0 1095 Foreign Agent Address 1097 The IP Address of the next Foreign Agent in the hierarchy. 1099 11. Mobile Node Considerations 1101 The tunnel requestor MAY also include at least one multi-protocol 1102 extension as well as Tunnel establishment extensions. Only one such 1103 extension MAY be included per additional network layer protocol. Note 1104 that a tunnel requestor may change which ethertypes are to be used by 1105 establishing a tunnel with different ethertype extensions in its 1106 establishment packets. 1108 If the mobile node receives a successful Reply message containing an 1109 Tunnel Establishment extension, the mobile node should immediately 1110 establish a GRE tunnel with the home agent as the other endpoint of 1111 the tunnel. Then, all data packets at the mobile node with a next hop 1112 of the home agent will be tunneled to the home agent using GRE over IP 1113 as the transport mechanism. This includes IP packets. Once the 1114 packet reaches the home agent, the outer header (IP) and GRE header 1115 are stripped and the packet is submitted for local processing, as 1116 appropriate for the particular network layer protocol. 1118 12. Foreign Agent Considerations 1120 The foreign agent MUST copy the Tunnel Establishment extension from 1121 the Mobile Request to the Establishment Request without modifying it 1122 in any way. The foreign agent MUST NOT reject a Mobile Request due to 1123 the presence or contents of any well formed Tunnel Establishment or 1124 multi-protocol extensions. 1126 Foreign Agents that support IP only wishing to provide multi-protocol 1127 support MUST support the Tunnel Identifier extension. 1129 13. Home Agent Considerations 1131 The home agent MAY reject an Registration Request based on the 1132 contents of an multi-protocol or any other Tunnel Establishment 1133 extensions. If the home agent accepts a Registration Request with an 1134 multi-protocol extension, it MUST provide connectivity to the mobile 1135 node for the network layer protocol described in the multi-protocol 1136 extension. Further, the multi-protocol extensions MUST be copied into 1137 the Reply message. 1139 If the home agent accepts a Registration Request with an Integrated 1140 Mobility extension, the request MUST also have a Local Care-Of Address 1141 extension. The home agent MUST use the Local Care-Of Address as the 1142 tunnel endpoint and MUST establish a GRE tunnel to the Local Care-Of 1143 Address. 1145 Once the GRE tunnel is established, a PDU arriving at the home agent 1146 for the mobile node will be tunneled to the receiver using GRE over IP 1147 as the transport mechanism. Note that this includes IP packets. Once 1148 the packet reaches the mobile node, the outer header (IP) and GRE 1149 header are stripped and the packet is submitted for local processing, 1150 as appropriate for the particular network layer protocol. 1152 14. Security 1154 Tunnel establishment follows the design philosophy of the Mobile IP 1155 specification to provide accceptable authentication of the 1156 establishment process. This document does not discuss confidentiality 1157 of user data. 1159 Note that tunnel establishment often has the effect of controlling and 1160 possibly redirecting data streams to new points of attachment for the 1161 mobile node. Thus, failure to provide sufficient authentication of 1162 Registration Request messages can have the effect of allowing 1163 malicious disruption of traffic which is supposed to be received by 1164 the mobile node. Even failure to properly authenticate Registration 1165 Reply messages could have the effect of masking control or data errors 1166 in the establishment process. 1168 15. Acknowledgements Acks anyone??? (PRC) 1170 16. References 1172 [1] Pat R. Calhoun and Ellis Won. Virtual Tunneling Protocol 1173 (VTP). draft-calhoun-vtp-protocol-00.txt, July 1996. (work in 1174 progress). 1176 [2] Stephen E. Deering, Editor. ICMP Router Discovery Messages. 1177 RFC 1256, September 1991. 1179 [3] Stan Hanks, Tony Li, Dino Farinacci, and Paul Traina. Generic 1180 Routing Encapsulation (GRE). RFC 1701, October 1994. 1182 [4] T. Li and Y. Rekhter. Integrated Mobility Extension. 1183 draft-ietf-mobileip-integrated-00.txt, March 1994. (work in 1184 progress). 1186 [5] G. Montenegro. Tunnel Set-up Protocol (TSP). 1187 draft-montenegro-tsp-00.txt, August 1997. (work in progress). 1189 [6] C. Perkins. Mobile-IP Local Registration with Hierarchical 1190 Foreign Agents. draft-perkins-mobileip-hierfa-00.txt, February 1191 1996. (work in progress). 1193 [7] Charles Perkins. IP Encapsulation within IP. RFC 2003, May 1194 1996. 1196 [8] Charles E. Perkins and David B. Johnson. Route Optimization in 1197 Mobile-IP. draft-ietf-mobileip-optim-07.txt, November 1997. 1198 (work in progress). 1200 [9] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 1201 1996. 1203 [10] Joyce K. Reynolds and Jon Postel. Assigned Numbers. RFC 1700, 1204 October 1994. 1206 [11] Mobile Network Computer Reference Specification, June 1997. 1207 http://www.internet.ibm.com/computers/networkstation/os/mncrs.html 1209 [12] S. Kent, R. Atkinson. IP Encapsulating Payload -- work in 1210 progress, draft-ietf-ipsec-esp-v2-00.txt, July 1997 1211 (obsoletes RFC 1827, August 1995). 1213 [13] S. Kent, R. Atkinson. IP Authentication Header -- work in 1214 progress, draft-ietf-ipsec-auth-header-01.txt, July 1997 1215 (obsoletes RFC 1826, August 1995). 1217 [14] S. Alexander, R. Droms. DHCP Options and BOOTP Vendor Extensions. 1218 RFC 2132. 1220 [15] V Gupta, S. Glass. Firewall Traversal for Mobile IP: Guidelines 1221 for Firewalls and Mobile IP entities. 1222 draft-ietf-mobileip-firewall-trav-00.txt, March 1997. (work in 1223 progress). 1225 [16] G. Montenegro. Reverse Tunneling for Mobile IP. 1227 draft-ietf-mobileip-tunnel-reverse-05.txt, January 1998. 1228 (work in progress). 1230 [17] C. Perkins, D. Johnson. Registration Keys for Route Optimization. 1231 draft-ietf-mobileip-regkey-00.txt. November 1997. (work in 1232 progress). 1234 [18] B. Aboba, M. Beadles. Network Address Identifier. 1235 draft-ietf-roamops-nai-10.txt, February 1998. (work in progress). 1237 [19] Atkinson, R., "IP Authentication Header", RFC 1826, Naval 1238 Research Laboratory, August 1995. 1240 [20] Atkinson, R., "IP Encapsulating Security Payload (ESP)", 1241 RFC 1827, Naval Research Laboratory, August 1995. 1243 [21] Harkins, D., Carrel, D., The Internet Key Exchange (IKE), 1244 February 1998, Internet-draft 1245 draft-ietf-ipsec-isakmp-oakley-06.txt (work in progress). 1247 [22] Assigned numbers for Security Parameters Index. Available at: 1248 http://www.isi.edu/in-notes/iana/assignments/spi-numbers 1250 17. Chairs' Addresses 1252 The working group can be contacted via the current chairs: 1254 Jim Solomon 1255 Motorola, Inc. 1256 1301 E. Algonquin Road 1257 Schaumburg, IL 60196 1258 USA 1260 Voice: +1-847-576-2753 1261 Fax: +1-847-576-3240 1262 E-Mail: solomon@comm.mot.com 1264 Erik Nordmark 1265 Sun Microsystems, Inc. 1266 901 San Antonio Road 1267 Mailstop UMPK17-202 1268 Mountain View, California 94303 1270 Phone: +1 650 786-5166 1271 Fax: +1 650 786-5896 1272 E-Mail: erik.nordmark@eng.sun.com 1274 17. Author's Address 1276 Questions about this memo can be directed to: 1278 Pat R. Calhoun 1279 Technology Development 1280 Sun Microsystems, Inc. 1281 15 Network Circle 1282 Menlo Park, California, 94025 1283 USA 1285 Phone: 1-847-548-9587 1286 Fax: 1-650-786-6445 1287 E-mail: pcalhoun@toast.net 1289 Gabriel E. Montenegro 1290 Technology Development 1291 Sun Microsystems, Inc. 1292 15 Network Circle 1293 Menlo Park, California, 94025 1294 USA 1296 Phone: 1-650-786-6288 1297 Fax: 1-650-786-6445 1298 E-mail: Gabriel.Montenegro@Eng.Sun.Com 1300 Charles E. Perkins 1301 Technology Development 1302 Sun Microsystems, Inc. 1303 15 Network Circle 1304 Menlo Park, California, 94025 1305 USA 1307 Phone: 1-650-786-6464 1308 Fax: 1-650-786-6445 1309 E-mail: Charles.Perkins@Eng.Sun.Com 1311 Appendix A. Example of an IPX Mobile Node 1313 A Mobile Node which desired IPX connectivity in addition to IP 1314 connectivity would include an extension of the form: 1316 0x?? 0x06 0x81 0x37 0x00 0x00 0x0c 0x01 0x0e 0x36 0x00 0x00 1318 This indicates an extension of TDB [0x??] (Tunnel Establishment), a 1319 data length of 6 octets, an ethertype value of 0x8137 (IPX), and an 1320 IEEE 802 address of 00:00:0c:01:03:36. The final two octets of 0x00 1321 are sent so that the extension terminates on a four- octet boundary, 1322 in accordance with the IP Mobility RFC. 1324 Appendix B. TEP as a Mobile Remote Access Solution 1326 Chained registrations flow in separate steps which together build one 1327 compound tunnel. For example, assuming there is only one intermediate 1328 point (or "traversal point"), labelled GFA ("gateway foreign agent"), 1329 this is how the chained registration would work: 1331 EXAMPLE: TEP for Mobility and Remote Access 1333 MN -- FA ---------------------- GFA ----- HA 1335 A. The MN sends a registration request to the FA with the following 1336 information: 1338 name: MN 1339 care-of address: FA 1340 home agent: GFA 1342 B. The FA then forwards this registration to the "home agent", i.e. 1343 to GFA. Notice that GFA is not a home agent in the traditional 1344 sense, because it's address and MN's do not belong to the same 1345 subnet. Also notice that the FA could have composed the above 1346 registration on behalf of the MN (the so-called "surrogate 1347 registration"). At any rate, whoever composes the registration 1348 request must share a secret with GFA, as this is needed to fill 1349 correctly the authenticator field of the registration request (not 1350 shown above). 1352 C. GFA verifies the authentication for this registration and 1353 fetches the information contained therein. It notices that it is 1354 listed as the home agent for the MN, which is not really true. 1355 However, it checks its database, and obtains information that MN's 1356 real home agent is HA, with which it can engage in yet another 1357 authenticated registration protocol exchange ("chained 1358 registration"). 1360 GFA sends the following registration to HA: 1362 name: MN 1363 care-of address: GFA 1364 home agent: HA 1366 Notice two things: 1368 1. This registration is composed by the GFA on behalf of the MN, 1369 so it is a surrogate registration. 1371 2. If GFA is indeed the home agent for the mobile node at this 1372 point Remote Access has been accomplished. 1374 D. HA verifies the authentication for this registration and notices 1375 that it is indeed valid (it is possible for HA and GFW to use a 1376 shared secret different from the one used by HA and MN). It then 1377 establishes a "tunnel" (i.e an IP forwarder) of MN's packets to 1378 GFA. 1380 Once this chained registration is in place, this is how data transfer 1381 may occur: 1383 A. A correspondent node, CN, sends a packet to the MN with the 1384 following IP header: 1386 IP source: CN 1387 IP destination: MN 1389 B. The packet arrives in the vicinity of HA, which intercepts and 1390 forwards it to GFA by prepending a new IP header like this: 1392 New IP source: HA 1393 New IP destination: GFA 1395 C. GFA receives the packet, recovers the original packet: 1397 IP source: CN 1398 IP destination: MN 1400 and notices that it has a binding or registration for MN. This 1401 prompts GFA to forward the packet, this time with the following new 1402 IP header prepended to it: 1404 New IP source: GFA 1405 New IP destination: FA 1407 D. FA obtains the packet, recovers the inner, original packet: 1409 IP source: CN 1410 IP destination: MN 1412 and notices that is has a binding or registration for MN. This 1413 time, it just forwards without any additional headers because MN is 1414 directly reachable. 1416 E. MN receives the packet: 1418 IP source: CN 1419 IP destination: MN 1421 which from the point of view of its applications is exactly the 1422 same packet they would have received if MN had been in its office. 1423 Thus mobility is transparent. 1425 Appendix C. Registering Without a Permanent Home Address 1427 Assume that the mobile node is a Mobile Network Computer, and as such, 1428 does not have a permanent home address. If at home, it typically 1429 acquires an address via DHCP for use during that session. The notion 1430 of session, however, does not necessarily imply a certain time limit. 1431 As long as the Mobile Network Computer renews its DHCP lease, it can 1432 continue to use the assigned address. If it reboots again, it will 1433 need a new address, but this is probably a very rare ocurrence. 1434 Instead of rebooting, what is customary is for a Mobile Network 1435 Computer to suspend its state and resume it at a later time. At that 1436 time, it will attempt to use the same address as it was using when it 1437 suspended its state. It's DHCP lease may have expired, or it may even 1438 ignore what to use as a home address. At this point, it establishes a 1439 presence on the public internet, perhaps by starting a PPP session 1440 with an ISP. It needs to obtain a new home address. 1442 This is what it knows: 1444 *1. the home prefix is known 1445 2. HA is known 1446 3. secret is known 1447 4. care-of address is known 1448 *5. care-of address is co-located 1450 This is what it wishes to find out: 1452 1. MN home address 1454 The mobile node issues this Registration Request: 1456 IP fields: 1457 Source Address = co-located care-of address 1458 Destination Address = IP address of home agent 1459 Time to Live = 64 1460 UDP fields: 1461 Source Port = 1462 Destination Port = 434 1463 Registration Request fields: 1464 Type = 1 1465 S=0,B=x,D=1,M=x,G=x 1466 Lifetime = 1800 (seconds) 1467 Home Address = the mobile node's home prefix 1468 Home Agent = IP address of mobile node's home agent 1469 Care-of Address = co-located care-of address 1470 Identification = timestamp 1471 Extensions: 1472 The Mobile-Home Authentication Extension 1474 The home agent sees that the home address field is not completely 1475 filled out, obtains a new address within the indicated prefix and 1476 returns it to the mobile node using this reply: 1478 Upon return: 1480 IP fields: 1481 Source Address = IP address of home agent 1482 Destination Address = co-located care-of address 1483 Time to Live = 64 1484 UDP fields: 1485 Source Port = Destination Port = copied from src port or 1486 reg req 1487 Registration Reply fields: 1488 Type = 3 1489 Code = 140 (invalid home address) 1490 Lifetime = 1800 (seconds) 1491 Home Address = the mobile node's newly assigned home address 1492 Home Agent = IP address of mobile node's home agent 1493 Identification = timestamp 1494 Extensions: 1495 The Mobile-Home Authentication Extension 1497 Notice that it is possible to discover both the home agent and the 1498 mobile node addresses: 1500 Now, this is what the Mobile Network Computer knows: 1502 *1. the home prefix is known 1503 *2. HA prefix is known 1504 3. secret is known 1505 4. care-of address is known 1506 *5. care-of address is co-located 1508 And this is what it wishes to find out: 1510 1. HA address 1511 2. MN home address 1513 It issues this Registration Request: 1515 Registration Request fields:.in 9 1516 Type = 1 1517 S=0,B=x,D=1,M=x,G=x 1518 Lifetime = 1800 (seconds) 1519 Home Address = the mobile node's home prefix 1520 Home Agent = directed broadcast to HA's prefix 1521 Care-of Address = co-located care-of address 1522 Identification = timestamp 1523 Extensions: 1524 The Mobile-Home Authentication Extension 1526 An initial reply with code 136 (unknown home agent address) tells the 1527 mobile node which home agent to use. Subsequently, the mobile node may 1528 discover its own home address. It must first discover the home agent 1529 address because the latter must be willing to provide some address 1530 allocation services on the mobile node's behalf. 1532 We could also use a separate foreign agent: 1534 In this case, these are the known quantities: 1536 *1. the home prefix is known 1537 *2. HA prefix is known 1538 3. secret is known 1539 4. care-of address is known 1541 In this case, the foreign agent uses a Mobile Node Cookie Extension 1542 (Section 9.5.) to determine which mobile node to send replies to. 1543 Notice that it is presumed that an foreign agent learn the mobile node 1544 MAC address from snooping the Registration Request.