idnits 2.17.1 draft-montenegro-tsp-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-03-28) 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. == 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 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. ** 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 308: '... MUST share a security association. ...' RFC 2119 keyword, line 310: '...ode itself, they MUST use the Mobile-H...' RFC 2119 keyword, line 357: '...ownstream agent) MUST add some extra i...' RFC 2119 keyword, line 359: '... upstream agent) MUST return this iden...' RFC 2119 keyword, line 366: '...tifier Extension MUST appear before th...' (13 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (August 25, 1997) is 9712 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: Non-RFC (?) normative reference: ref. 'Aziz95' -- Possible downref: Normative reference to a draft: ref. 'Calhoun96' -- Possible downref: Normative reference to a draft: ref. 'GuGl97a' -- Possible downref: Normative reference to a draft: ref. 'GuGl97b' ** Downref: Normative reference to an Informational RFC: RFC 1701 (ref. 'Hanks94') == Outdated reference: A later version (-09) exists of draft-ietf-ipsec-isakmp-08 ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-isakmp (ref. 'ISAKMP') == Outdated reference: A later version (-07) exists of draft-ietf-ipsec-isakmp-oakley-04 ** Downref: Normative reference to an Historic draft: draft-ietf-ipsec-isakmp-oakley (ref. 'ISAOAK') == 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: Non-RFC (?) normative reference: ref. 'MNCRS' == Outdated reference: A later version (-05) exists of draft-ietf-mobileip-tunnel-reverse-04 == Outdated reference: A later version (-03) exists of draft-montenegro-firewall-sup-01 ** Downref: Normative reference to an Informational draft: draft-montenegro-firewall-sup (ref. 'MoGu97') -- Unexpected draft version: The latest known version of draft-ietf-ipsec-oakley is -01, but you're referring to -02. ** Downref: Normative reference to an Informational draft: draft-ietf-ipsec-oakley (ref. 'OAKLEY') ** Obsolete normative reference: RFC 2002 (ref. 'Perkins96a') (Obsoleted by RFC 3220) Summary: 16 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force G. Montenegro 2 INTERNET DRAFT Sun Microsystems, Inc. 3 August 25, 1997 4 Tunnel Set-up Protocol (TSP) 5 draft-montenegro-tsp-00.txt 7 Status of This Memo 9 This document is a submission to the Mobile IP Working Group of the 10 Internet Engineering Task Force (IETF). Comments should be submitted 11 either to the author, or to the mobile-ip@SmallWorks.COM mailing 12 list. 14 Distribution of this memo is unlimited. 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet- Drafts as 24 reference material or to cite them other than as ``work in 25 progress.'' 27 To learn the current status of any Internet-Draft, please check the 28 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 29 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 30 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 31 ftp.isi.edu (US West Coast). 33 Abstract 35 Remote access over the internet and IP mobility are currently being 36 addressed as two separate problems. The L2TP specification is 37 defining a protocol, or rather a tunnel control mechanism to solve 38 the remote access problem. On the other hand, the Mobile IP working 39 group has been solving the mobility problem. Nevertheless, the same 40 solution applies to both problems, namely, tunneling. 42 This document defines a Tunnel Set-up Protocol (TSP) that solves 43 both problems using a common approach. TSP is heavily based on the 44 control messages defined by Mobile IP. 46 Table of Contents 48 1. Introduction ................................................... 3 49 1.1. Motivation ................................................ 3 50 1.2. Terminology ............................................... 4 51 1.3. Related Work .............................................. 4 52 1.4. Design Goals .............................................. 5 53 2. Overview ....................................................... 6 54 2.1. Base Mobile IP ............................................ 6 55 2.2. Chained Registrations ..................................... 6 56 2.3. Surrogate Registrations ................................... 7 57 3. Dynamic Home Address Discovery ................................. 8 58 3.1. Registering over the Internet ............................. 8 59 3.2. Registering within the Corporation ........................ 8 60 4. New Packet Formats ............................................. 8 61 4.1. Mobile Node Identifier Extension .......................... 8 62 4.2. "Invalid Home Address" Error Code ......................... 10 63 5. Protocol Behavior .............................................. 10 64 6. Data Transfer: Tunneling Modes ................................. 11 65 7. Example Scenarios .............................................. 11 66 7.1 TSP as a Mobile Remote Access Solution ..................... 11 67 7.2 Registering Without a Permanent Home Address ............... 13 68 8. Security Considerations ........................................ 16 69 References ........................................................ 16 70 Author and Chair Addresses ........................................ 18 71 1. Introduction 73 1.1. Motivation 75 The Mobile IP protocol has great provisions for dynamic tunnel set 76 up to effect Layer 3 forwarding (IP packet forwarding). The purpose 77 is to dynamically and securely set up an IP packet forwarder (the 78 "home agent" functionality) toward a current point of attachment 79 (the "care-of address") of a roaming system. 81 Notice that if the packet forwarder happens to be the home agent of 82 the device, then we are dealing with Mobile IP. However, there are 83 very good reasons to use the same protocol to establish a packet 84 forwarder at, for example, the border of a private net. This allows 85 a remote device to appear to be within the confines of the private 86 network, albeit at its periphery. Doing so, and using IP security to 87 authenticate and encrypt the data traffic, presents a homogeneous 88 and simple solution to two fundamental problems in the internet: 90 - mobility 92 - secure remote access over the internet. 94 Another characteristic of Mobile IP that plays perfectly in the 95 remote access arena is the foreign agent. Many service providers 96 need exactly this as a point of control for billing purposes. 98 However, there are certain limitations that must be addressed in 99 order to achieve a homogeneous solution to the problems listed 100 above. 102 Current Mobile IP lacks flexibility in how registrations are 103 accomplished in that it assumes that the endpoints of the tunnel are 104 mutually trusting entities that are able to and willing to exchange 105 registration protocol packets. 107 Furthermore, it assumes that the mobile node creates the 108 Registration Request. TSP addresses these issues by allowing the 109 creation of compound tunnels. TSP recognizes that in addition to 110 tunnel endpoints, there may be tunnel intermediate points. 111 Registrations are exchanged only between intermediate points. The 112 result is a composite tunnel with some very desireable security and 113 scalability characteristics: 115 - Different security domains interface at an intermediate point, 116 which provides a clean separation between segments. 118 - Movement beyond a certain intermediate point only implies 119 re-registrations from that point onward. 121 1.2. Terminology 123 This discussion uses terms defined by Mobile IP [Perkins96a]. 124 Additionally, it uses the following terms: 126 Chained Registration 128 A registration in which the home agent and the mobile node do 129 not directly exchange a Registration Request and Reply. 130 Rather, the request/reply is carried out between endoints of 131 tunnel segments. The composition of tunnel segments represents 132 the compound tunnel from home agent to mobile node. 134 Surrogate Registrations 136 These are registrations that are not created by the mobile 137 node. Rather, they are created on its behalf by another entity 138 (a foreign agent). This is not a new concept and is in use in 139 commercial implementations. Nevertheless, with its 140 introduction of chained registrations and compound tunnels, 141 this document allows for registrations that neither originate 142 at the mobile node (i.e. they are surrogate registrations), 143 nor do they terminate at the home agent (i.e. they terminate 144 at an intermediate point at least one tunnel away from the 145 home agent). 147 Upstream Agent 149 The endpoint of a tunnel segment that is closest to the home 150 agent. The last upstream agent is the home agent itself. 152 Downstream Agent 154 The endpoint of a tunnel segment that is closest to the mobile 155 node. The last downstream agent is the mobile node itself. 157 1.3. Related Work 159 VTP (Virtual Tunneling Protocol) [Calhoun96] also uses Mobile IP as 160 a basis for a tunnel set-up protocol. The registrations composed 161 by VTP's "proxy mobile nodes" are essentially surrogate 162 registrations. 164 Chained registrations add the flexibility that the registration 165 request need not end at the home agent, but at an intermediate 166 system (an upstream agent). 168 There has been some work on enabling secure mobile remote access 169 using SKIP [MoGu97]. Subsequently, the Mobile IP Working Group is 170 extending these efforts and defining a solution based on 171 ISAKMP/OAKLEY [GuGl97a, GuGl97b]. However, these documents still 172 assume that the mobile node and the home agent exchange Registration 173 Protocol packets directly. True, they may tunnel or relay them 174 through participating firewalls, but the latter are merely IP 175 Security aware devices, unaware of Mobile IP. TSP allows for 176 firewalls to be Mobile IP aware so they can serve as endpoints of 177 tunnel segments. 179 However, TSP does not require the use compound tunnels, as this is a 180 policy issue. When they are not required, secure remote mobile 181 access may be accomplished along the lines proposed by the documents 182 in the previous paragraph. 184 1.4. Design Goals 186 One of the main objectives in defining TSP is to support Mobile 187 Network Computers [MNCRS]. Given that these devices are meant to be 188 very lightweight and to keep as little state as possible, TSP's 189 design goals are: 191 - Simplicity. 193 TSP only defines the minimum required to support the additional 194 applications and target devices. Surprisingly little needs to 195 be specified in order to adapt Mobile IP to serve as a remote 196 access mechanism based on layer 3 forwarding. 198 - Reusability. 200 Unless otherwise specified, TSP adopts packet formats and 201 protocol behavior as specified by Mobile IP. This results in 202 one protocol that solves mobility and remote access. 204 - Security. 206 Given the nature of remote access, security associations are 207 required of entities exchanging Registration Protocol packets 208 over public sectors of the internet. Privacy of data transfer 209 is also a requirement in these conditions, and is accomplished 210 by using ESP [Kent97a] and AH [Kent97b]. 212 2. Overview 214 2.1. Base Mobile IP 216 Mobile IP [Perkins96a] defines 3 entities: mobile node (MN), foreign 217 agent (FA) and home agent (HA). 219 The idea is that a mobile node is always able to use its permanent 220 IP address ("home address"), even if it is not "home" (the logical 221 location of its IP address). When the mobile node moves to another 222 region of the internet, it's home address is no longer usable, as 223 the routing fabric still delivers packets to its home location. In a 224 manner similar to how one leaves forwarding indications at the post 225 office when out of town, the mobile node engages in a secure 226 "registration" with the home agent. Once this forwarding indicator 227 or "binding" is in place, the home agent intercepts all packets 228 destined for the mobile node and forwards them to the foreign agent 229 currently being visited by the mobile node. In essence, the foreign 230 agent lends the mobile node its topologically correct address 231 ("care-of address"). 233 The home agent forwards packets destined for the mobile node by 234 adding another IP header so the routing fabric sees the home agent's 235 address as source and the care-of address as destination. Once at 236 the care-of address, the original packet meant for the mobile node 237 is recovered and delivered without recourse to regular routing. 238 Notice that the mobile node may possibly acquire the care-of address 239 necessary for tunneling. In this case, there is no separate foreign 240 agent, rather, the mobile node serves as its own tunnel endoint. 242 This "local" delivery from the foreign agent to the mobile node is 243 possible because it does not rely on traditional network layer 244 routing. 246 2.2. Chained Registrations 248 Base Mobile IP assumes that the foreign agent is directly reachable 249 from the home agent. In many situations this is not possible or 250 desirable. For example, if the foreign agent belongs to an ISP, or 251 a wireless carrier, it is not desirable to allow it direct 252 reachability to a system (the HA) that "lives" within the private 253 network. 255 A much more secure configuration is to allow the ISP's system to 256 directly reach only as far as the private network's gateway or 257 firewall. These two systems need to share some mutual trust, 258 particularly if using surrogate registrations. 260 Another separate trust relationship is then built between the 261 gateway or firewall system, and the home agent inside the private 262 network. Notice that by introducing this intermediate system there 263 is a very clean separation between external and internal systems 264 security domains. 266 This configuration is possible because of the use of chained 267 registrations, whereas usual registration requests flow directly 268 from the mobile node to the home agent. 270 2.3. Surrogate Registrations 272 Surrogate registrations are composed on behalf of a given node by 273 another node. Consider the following network: 275 MN@COA ---------------------- GFA ----- HA 277 where the mobile node has acquired a co-located address (COA). 278 Assume that the mobile node is not allowed to exchange packets 279 directly with its home agent within the private network. Instead, it 280 sends a Registration Request to the gateway foreign agent (GFA) as 281 follows: 283 MN@COA, home agent = GFA. 285 The gateway foreign agent is not, of course, the mobile node's home 286 agent. Nevertheless, it has knowledge or can obtain knowledge 287 (perhaps after consulting a RADIUS database) of the mobile node's 288 home agent. It then composes a Registration Request aimed at 289 establishing a tunnel with the home agent: 291 MN@GFA, home agent = HA. 293 From the home agent's point of view, this registration request is 294 almost indistinguishable from what it would have received from the 295 MN directly. Notice that when the mobile node roams within the 296 private network, mobility is probably accomplished without surrogate 297 registrations. Hence, Registration Requests like the above are 298 sometimes sent directly by the mobile node to the home agent. 300 The target system can always tell the identity of the system that 301 composes a Registration Request by the value of the SPI. If the 302 target system is the home agent, a security association is already 303 required by Mobile IP. However, intermediate nodes may set up tunnel 304 segments with other intermediate nodes. 306 Because the SPI is the only way to identify the creator of a 307 Registration, TSP requires that entities setting up tunnel segments 308 MUST share a security association. Since surrogate registrations 309 have exactly the same format as registrations issued by the mobile 310 node itself, they MUST use the Mobile-Home Authentication Extension 311 as dictated by Mobile IP. 313 3. Dynamic Home Address Discovery 315 It is possible for a mobile node to not have a permanently assigned 316 IP address. This is the default operating condition for a Mobile 317 Network Computer. 319 3.1. Registering over the Internet 321 When a Mobile Network Computer tries to register over the internet, 322 it may not have a valid IP address (because it is booting instead of 323 resuming, or because its lease ran out). TSP defines a home address 324 discovery mechanism akin to the home agent discovery mechanism 325 defined by Mobile IP. In both cases, a registration denial carries 326 the necessary information (see Section 5). 328 3.2. Registering within the Corporation 330 In this case, the Mobile Network Computer boots using the Network 331 Computer model of obtaining its operating parameters from a DHCP 332 server. One of the parameters received is the IP address to be 333 used. The Mobile Network Computer must make sure that it receives 334 an IP address valid for roaming as a Mobile IP node, i.e. it must be 335 an address that a home agent is willing to provide forwarding 336 service to [Alex97]. The home agent could also be communicated 337 using DHCP, or it could be discovered using the home agent discovery 338 mechanism in [Perkins96a]. 340 4. New Packet Formats 342 This section specifies packets formats that are different or new 343 as compared to those defined by Mobile IP [Perkins96a] and 344 Reverse Tunneling [Monten97]. 346 4.1. Mobile Node Identifier Extension 348 If the mobile node is using a co-located care-of address, the 349 Registration Reply is delivered directly to it. 351 On the other hand, if the care-of address belongs to a foreign 352 agent, it uses the mobile node's home address and the ID field in 353 the Registration Reply to determine which link-layer address to 354 relay it to. However, if the mobile node is carrying out dynamic 355 home address discovery, then the foreign agent can only rely on the 356 ID field, which is not guaranteed to be unique. The foreign agent 357 (or downstream agent) MUST add some extra information to 358 Registration Requests to uniquely identify the mobile node. The home 359 agent (or upstream agent) MUST return this identifier for the 360 foreign agent to be able to resolve which mobile node it is intended 361 for. 363 The Mobile Node Identifier Extension defined below serves this 364 purpose. 366 The Mobile Node Identifier Extension MUST appear before the 367 TSP-required Foreign-Home Authentication Extension. It SHOULD appear 368 immediately before it. 370 As per section 1.9 of [Perkins96a], the type value of 130 implies 371 that if a node encounters a Mobile Node Identifier Extension in a 372 Registration Request or Reply, it MAY silently ignore it. This 373 implies that home agents that comply with Mobile IP, but are unaware 374 of the TSP extension MAY still be used, as long as the mobile node 375 does not attempt home address discovery. 377 TSP home agents that support Mobile Network Computers MUST 378 understand the Mobile Node Identifier Extension and return it in its 379 replies. The reason is that Mobile Network Computers may attempt to 380 register using a certain home address whose DHCP lease may have 381 expired. Furthermore, two or more Mobile Network Computers may 382 attempt to use the same home address. Without the Mobile Node 383 Identifier Extension the foreign agent (or downstream agent) may be 384 unable to resolve the conflict. 386 0 1 2 3 387 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 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Type | Length | Reserved | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Mobile Node Identifier | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 Type 396 130 398 Length 400 6 402 Reserved 404 0 406 Mobile Node Identifier 408 A pseudo-random number created by the tunnel initiator (e.g. 409 foreign agent) as a unique identifier of the mobile node. 411 NOTE: This is not optimized for the usual case. Should try to do so, 412 perhaps by claiming the last unused bit in the "rsvd" field of 413 the Registration Request to mean "it is ok to assign me a new 414 home address". Only if this bit were on would the Mobile Node 415 Identifier Extension be needed. 417 4.2. "Invalid Home Address" Error Code 419 In order to support dynamic home address discovery, we define a new 420 error code: 422 Service denied by the home agent: 424 140 invalid home address 426 Notice that "invalid" home address includes two cases: 428 1. mobile node requires an address assignment, 430 2. mobile node's lease on its previous address has expired. 432 An "invalid home address" denial carries the assigned home address 433 in the home address field of the registration reply. 435 5. Protocol Behavior 437 Unless otherwise specified, TSP assumes the behavior defined by 438 Mobile IP [Perkins96a]. TSP operates in two different modes: 440 1. When operating within a private network, TSP MAY adopt the 441 same protocol behavior as Mobile IP, that is, there are no 442 surrogate registrations, compound tunnels or home address 443 assignment. 445 2. However, when setting up a compound tunnel, or when a tunnel 446 traverses a public sector of the internet, bi-directional 447 tunnels MUST be used. This MAY be accomplished by using either 448 reverse tunneling [Monten97] or GRE [Hanks94]. In this case, 449 all Registration Requests and Replies MUST include the proper 450 Authentication Extension. Also, dynamic home address discovery 451 while using the services of a separate foreign agent implies 452 the use of the Mobile Node Identifier Extension. 454 [gab: must add more detail] 456 6. Data Transfer: Tunneling Modes 458 The Registration Protocol defined in [Perkins96a] and the extensions 459 specified in this document enable tunnels to be set up in an 460 authenticated fashion. However, there is still the separate matter 461 of sending data through the tunnels. 463 Mobile Network Computers MUST use IP in IP encapsulation 464 [Perkins96b] preferrably using reverse tunneling [Monten97]. Other 465 types of mobile nodes MAY specify GRE [Hanks94]. 467 However, one of the main applications of TSP is remote access. 468 Accordingly, tunnels that traverse public sectors of the internet 469 MUST be protected by using ESP [Kent97a] and AH [Kent97b]. Manual 470 keying MUST be supported. Key management MUST use either SKIP 471 [Aziz95] or ISAKMP/OAKLEY [ISAKMP, OAKLEY, ISAOAK]. The exact 472 mechanism is not determined via Registration Protocol exchanges. 474 Tunnels that traverse private sectors of the network MAY optionally 475 protect their traffic in similar fashion. 477 7. Example Scenarios 479 7.1 TSP as a Mobile Remote Access Solution 481 Chained registrations flow in separate steps which together build 482 one compound tunnel. For example, assuming there is only one 483 intermediate point (or "traversal point"), labelled GFA ("gateway 484 foreign agent"), this is how the chained registration would work: 486 EXAMPLE: TSP for Mobility and Remote Access 488 MN -- FA ---------------------- GFA ----- HA 489 a. The MN sends a registration request to the FA with the 490 following information: 492 name: MN 493 care-of address: FA 494 home agent: GFA 496 b. The FA then forwards this registration to the "home agent", 497 i.e. to GFA. Notice that GFA is not a home agent in the 498 traditional sense, because it's address and MN's do not belong 499 to the same subnet. Also notice that the FA could have 500 composed the above registration on behalf of the MN (the 501 so-called "surrogate registration"). At any rate, whoever 502 composes the registration request must share a secret with 503 GFA, as this is needed to fill correctly the authenticator 504 field of the registration request (not shown above). 506 c. GFA verifies the authentication for this registration and 507 fetches the information contained therein. It notices that it 508 is listed as the home agent for the MN, which is not really 509 true. However, it checks its database, and obtains information 510 that MN's real home agent is HA, with which it can engage in 511 yet another authenticated registration protocol exchange 512 ("chained registration"). 514 GFA sends the following registration to HA: 516 name: MN 517 care-of address: GFA 518 home agent: HA 520 Notice two things: 522 1. This registration is composed by the GFA on behalf of 523 the MN, so it is a surrogate registration. 525 2. If GFA is indeed the home agent for the mobile node at 526 this point Remote Access has been accomplished. 528 d. HA verifies the authentication for this registration and 529 notices that it is indeed valid (it is possible for HA and GFW 530 to use a shared secret different from the one used by HA and 531 MN). It then establishes a "tunnel" (i.e an IP forwarder) of 532 MN's packets to GFA. 534 Once this chained registration is in place, this is how data 535 transfer may occur: 537 a. A correspondent node, CN, sends a packet to the MN with the 538 following IP header: 540 IP source: CN 541 IP destination: MN 543 b. The packet arrives in the vicinity of HA, which intercepts and 544 forwards it to GFA by prepending a new IP header like this: 546 New IP source: HA 547 New IP destination: GFA 549 c. GFA receives the packet, recovers the original packet: 551 IP source: CN 552 IP destination: MN 554 and notices that it has a binding or registration for MN. This 555 prompts GFA to forward the packet, this time with the 556 following new IP header prepended to it: 558 New IP source: GFA 559 New IP destination: FA 561 d. FA obtains the packet, recovers the inner, original packet: 563 IP source: CN 564 IP destination: MN 566 and notices that is has a binding or registration for MN. 567 This time, it just forwards without any additional headers 568 because MN is directly reachable. 570 e. MN receives the packet: 572 IP source: CN 573 IP destination: MN 575 which from the point of view of its applications is exactly 576 the same packet they would have received if MN had been in its 577 office. Thus mobility is transparent. 579 7.2 Registering Without a Permanent Home Address 581 Assume that the mobile node is a Mobile Network Computer, and as 582 such, does not have a permanent home address. If at home, it 583 typically acquires an address via DHCP for use during that session. 584 The notion of session, however, does not necessarily imply a certain 585 time limit. As long as the Mobile Network Computer renews its DHCP 586 lease, it can continue to use the assigned address. If it reboots 587 again, it will need a new address, but this is probably a very rare 588 ocurrence. Instead of rebooting, what is customary is for a Mobile 589 Network Computer to suspend its state and resume it at a later 590 time. At that time, it will attempt to use the same address as it 591 was using when it suspended its state. It's DHCP lease may have 592 expired, or it may even ignore what to use as a home address. At 593 this point, it establishes a presence on the public internet, 594 perhaps by starting a PPP session with an ISP. It needs to obtain a 595 new home address. 597 This is what it knows: 599 *1. the home prefix is known 600 2. HA is known 601 3. secret is known 602 4. care-of address is known 603 *5. care-of address is co-located 605 This is what it wishes to find out: 607 1. MN home address 609 The mobile node issues this Registration Request: 611 IP fields: 612 Source Address = co-located care-of address 613 Destination Address = IP address of home agent 614 Time to Live = 64 615 UDP fields: 616 Source Port = 617 Destination Port = 434 618 Registration Request fields: 619 Type = 1 620 S=0,B=x,D=1,M=x,G=x 621 Lifetime = 1800 (seconds) 622 Home Address = the mobile node's home prefix 623 Home Agent = IP address of mobile node's home agent 624 Care-of Address = co-located care-of address 625 Identification = timestamp 626 Extensions: 627 The Mobile-Home Authentication Extension 629 The home agent sees that the home address field is not completely 630 filled out, obtains a new address within the indicated prefix and 631 returns it to the mobile node using this reply: 633 Upon return: 635 IP fields: 636 Source Address = IP address of home agent 637 Destination Address = co-located care-of address 638 Time to Live = 64 639 UDP fields: 640 Source Port = 641 Destination Port = copied from src port or reg req 642 Registration Reply fields: 643 Type = 3 644 Code = 140 (invalid home address) 645 Lifetime = 1800 (seconds) 646 Home Address = the mobile node's newly assigned home address 647 Home Agent = IP address of mobile node's home agent 648 Identification = timestamp 649 Extensions: 650 The Mobile-Home Authentication Extension 652 Notice that it is possible to discover both the home agent and the 653 mobile node addresses: 655 Now, this is what the Mobile Network Computer knows: 657 *1. the home prefix is known 658 *2. HA prefix is known 659 3. secret is known 660 4. care-of address is known 661 *5. care-of address is co-located 663 And this is what it wishes to find out: 665 1. HA address 666 2. MN home address 668 It issues this Registration Request: 670 Registration Request fields: 671 Type = 1 672 S=0,B=x,D=1,M=x,G=x 673 Lifetime = 1800 (seconds) 674 Home Address = the mobile node's home prefix 675 Home Agent = directed broadcast to HA's prefix 676 Care-of Address = co-located care-of address 677 Identification = timestamp 679 Extensions: 680 The Mobile-Home Authentication Extension 682 An initial reply with code 136 (unknown home agent address) tells 683 the mobile node which home agent to use. Subsequently, the mobile 684 node may discover its own home address. It must first discover the 685 home agent address because the latter must be willing to provide 686 some address allocation services on the mobile node's behalf. 688 We could also use a separate foreign agent: 690 In this case, these are the known quantities: 692 *1. the home prefix is known 693 *2. HA prefix is known 694 3. secret is known 695 4. care-of address is known 697 In this case, the foreign agent uses a Mobile Node Identifier 698 Extension (Section 4.1.2) to determine which mobile node to send 699 replies to. Notice that it is presumed that an foreign agent learn 700 the mobile node MAC address from snooping the Registration Request. 702 8. Security Considerations 704 This document is very heavily based on Mobile IP. Tunnel Set-up 705 Protocol focuses on additional applications, namely, remote access. 706 Because of this, items which may be optional in basic Mobile IP 707 become absolute requirements for TSP. The registration protocol 708 messages MUST always be authenticated. This means that there MUST 709 always be a security association between both endpoints of any given 710 tunnel segment. 712 References 714 [Aziz95] A. Aziz and M. Patterson, Design and Implementation 715 of SKIP, available on-line at 716 http://skip.incog.com/inet-95.ps. A previous version 717 of the paper was presented at INET '95 under the 718 title Simple Key Management for Internet Protocols 719 (SKIP), and appears in the conference proceedings 720 under that title. 722 [Calhoun96] P. Calhoun, E. Wong. Virtual Tunneling Protocol -- 723 work in progress, draft-calhoun-vtp-protocol-00.txt, 724 July 1996. 726 [GuGl97a] V. Gupta and S. Glass, "Firewall traversal for 727 Mobile IP: Goals and Requirements". -- work in 728 progress, draft-ietf-mobileip-ft-req-00.txt> -- work 729 in progress, January 1997. 731 [GuGl97b] V. Gupta and S. Glass, "Firewall traversal for 732 Mobile IP: Guidelines for Firewalls and Mobile IP 733 entities" -- work in progress, 734 draft-ietf-mobileip-firewall-trav-00.txt, March 735 1997. 737 [Hanks94] Hanks, S., Li, R., Farinacci, D., and P. Traina, 738 "Generic Routing Encapsulation (GRE)", RFC 1701, 739 October 1994. 741 [ISAKMP] Maughhan, D., Schertler, M., Schneider, M., and 742 Turner, J., "Internet Security Association and Key 743 Management Protocol (ISAKMP)", 744 draft-ietf-ipsec-isakmp-08.{ps,txt}, July 1997. 746 [ISAOAK] Harkins, D., Carrel, D., "The resolution of ISAKMP 747 with Oakley", draft-ietf-ipsec-isakmp-oakley-04.txt, 748 July 1997. 750 [Kent97a] S. Kent, R. Atkinson. IP Encapsulating Payload -- 751 work in progress, draft-ietf-ipsec-esp-v2-00.txt, 752 July 1997 (obsoletes RFC 1827, August 1995). 754 [Kent97b] S. Kent, R. Atkinson. IP Authentication Header -- 755 work in progress, 756 draft-ietf-ipsec-auth-header-01.txt, July 1997 757 (obsoletes RFC 1826, August 1995). 759 [MNCRS] Mobile Network Computer Reference Specification, 760 June 1997. 761 http://www.internet.ibm.com/computers/networkstation/ 762 os/mncrs.html 764 [Monten97] G. Montenegro, "Reverse Tunneling for Mobile IP" -- 765 work in progress, 766 draft-ietf-mobileip-tunnel-reverse-04.txt, August 767 1997. 769 [MoGu97] G. Montenegro and V. Gupta, "Firewall Support for 770 Mobile IP". -- work in progress, 771 draft-montenegro-firewall-sup-01.txt, July 1997. 773 [OAKLEY] Orman, H., "The Oakley Key Determination Protocol", 774 draft-ietf-ipsec-oakley-02.txt, July 1997. 776 [Perkins96a] C. Perkins, Editor. IP Mobility Support. RFC 777 2002. 779 [Perkins96b] C. Perkins, Editor. IP Encapsulation within IP. RFC 780 2003. 782 [Alex97] S. Alexander, R. Droms. DHCP Options and BOOTP 783 Vendor Extensions. RFC 2132. 785 Author and Chair Addresses 787 Questions about this document may be directed at: 789 Gabriel E. Montenegro 790 Sun Microsystems, Inc. 791 an Antonio Road 792 Mailstop UMPK 15-214 793 Mountain View, California 94303 795 Voice: +1-415-786-6288 796 Fax: +1-415-786-6445 798 E-Mail: gabriel.montenegro@eng.sun.com 800 The working group can be contacted via the current chairs: 802 Jim Solomon 803 Motorola, Inc. 804 1301 E. Algonquin Rd. - Rm 2240 805 Schaumburg, IL 60196 807 Voice: +1-847-576-2753 808 Fax: +1-847-576-3240 809 E-Mail: solomon@comm.mot.com 811 Erik Nordmark 812 Sun Microsystems, Inc. 813 901 San Antonio Road 814 Mailstop UMPK17-202 815 Mountain View, California 94303 817 Voice: +1-415-786-5166 818 E-Mail: erik.nordmark@eng.sun.com