idnits 2.17.1 draft-ietf-mobileip-tunnel-reverse-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-18) 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 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 195: '...sets the 'T' bit MUST support the two ...' RFC 2119 keyword, line 250: '...Tunnel Extension MUST NOT be included ...' RFC 2119 keyword, line 276: '...me agent replies MUST convey if the re...' RFC 2119 keyword, line 295: '...t the home agent MUST deny registratio...' RFC 2119 keyword, line 321: '... [1], and depending on the reply code, MAY try modifying the...' (28 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 217 has weird spacing: '... agents proba...' == Line 317 has weird spacing: '...her the home ...' -- 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 (February 12, 1997) is 9927 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) ** Obsolete normative reference: RFC 2002 (ref. '1') (Obsoleted by RFC 3220) -- Possible downref: Non-RFC (?) normative reference: ref. '3' == Outdated reference: A later version (-11) exists of draft-ietf-mobileip-optim-05 -- Possible downref: Normative reference to a draft: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 1826 (ref. '6') (Obsoleted by RFC 2402) ** Obsolete normative reference: RFC 1827 (ref. '7') (Obsoleted by RFC 2406) == Outdated reference: A later version (-02) exists of draft-ferguson-ingress-filtering-01 Summary: 12 errors (**), 0 flaws (~~), 5 warnings (==), 5 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 February 12, 1997 5 Reverse Tunneling for Mobile IP 6 draft-ietf-mobileip-tunnel-reverse-01.txt 8 Status of This Memo 10 This document is a submission by the Mobile IP Working Group of the 11 Internet Engineering Task Force (IETF). Comments should be submitted 12 to the Working Group mailing list at "mobile-ip@SmallWorks.COM". 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 Mobile IP uses tunneling from the home agent to the mobile node's 36 care-of address, but rarely in the reverse direction. Usually, a 37 mobile node sends its packets through a router on the foreign net, 38 and assumes that routing is independent of source address. When 39 this assumption is not true, it is convenient to establish a 40 topologically correct reverse tunnel from the care-of address to the 41 home agent. 43 This document proposes backwards-compatible extensions to Mobile IP 44 in order to support topologically correct reverse tunnels. This 45 document does not attempt to solve the problems posed by firewalls 46 located between the home agent and the mobile node's care-of 47 address. 49 1. Introduction 51 Section 1.3 of the Mobile IP specification [1] lists the following 52 assumption: 54 It is assumed that IP unicast datagrams are routed based on the 55 destination address in the datagram header (i.e., not by source 56 address). 58 Because of security concerns (e.g. IP spoofing attacks), and in 59 accordance with the IAB [8] and CERT [3] advisories to this effect, 60 routers that break this assumption are increasingly more common. 62 In the presence of such routers, the source and destination IP 63 address in a packet must be topologically correct. The forward 64 tunnel complies with this, as its endpoints (home agent address and 65 care-of address) are properly assigned addresses for their 66 respective locations. On the other hand, the source IP address of a 67 packet transmitted by the mobile node does not correspond to the 68 location from where it emanates. 70 This document discusses topologically correct reverse tunnels. 72 Mobile IP does dictate the use of reverse tunnels in the context of 73 multicast datagram routing and mobile routers. However, the source 74 IP address is set to the mobile node's home address, so these 75 tunnels are not topologically correct. 77 Notice that there are several uses for reverse tunnels regardless of 78 their topological correctness: 80 - Mobile routers: reverse tunnels obviate the need for recursive 81 tunneling [1]. 83 - Multicast: reverse tunnels enable a mobile node away from home 84 to (1) join multicast groups in its home network, and (2) 85 transmit multicast packets such that they emanate from its home 86 network [1]. 88 - The TTL of packets sent by the mobile node (particularly when 89 it addresses other hosts in its home network) may be so low 90 that they may expire before reaching their destination. A 91 reverse tunnel solves the problem as it represents a TTL 92 decrement of one [5]. 94 1.1. Terminology 96 The discussion below uses terms defined in the Mobile IP 97 specification. Additionally, it uses the following terms: 99 Forward Tunnel 101 A tunnel that shuttles packets towards the mobile node. It 102 starts at the home agent, and ends at the mobile node's 103 care-of address. 105 Reverse Tunnel 107 A tunnel that starts at the mobile node's care-of address and 108 terminates at the home agent. 110 Light-weight mobile node 112 A mobile node that relies on a separate foreign agent for 113 tunneling services (i.e. the care-of address belongs to the 114 foreign agent). 116 1.2. Assumptions 118 Mobility is constrained to one IP address space (e.g. the routing 119 fabric between, say, the mobile node and the home agent is not 120 partitioned into a "private" and a "public" network). 122 This document does not attempt to solve the firewall traversal 123 problem. Rather, it assumes one of the following is true: 125 - There are no intervening firewalls along the path of the 126 tunneled packets. 128 - Any intervening firewalls share the security association 129 necessary to process any authentication [6] or encryption [7] 130 headers which may have been added to the tunneled packets. 132 The reverse tunnels considered here are symmetric, that is, they use 133 the same configuration (encapsulation method, IP address endpoints) 134 as the forward tunnel. IP in IP encapsulation [2] is assumed unless 135 stated otherwise. 137 Route optimization [4] introduces forward tunnels initiated at a 138 correspondent host. Since a mobile node cannot know if the 139 correspondent host can decapsulate packets, reverse tunnels in that 140 context are not discussed here. 142 1.3. Justification 144 Why not let the mobile node itself initiate the tunnel to the home 145 agent? This is indeed what it should do if it is already operating 146 with a topologically significant co-located care-of address. 148 However, one of the primary objectives of the Mobile IP 149 specification is to not *require* this mode of operation. 151 The mechanisms outlined in this document are primarily intended for 152 use by mobile nodes that rely on the foreign agent for forward 153 tunnel support. It is desirable to continue supporting these 154 "lightweight" mobile nodes, even in the presence of filtering 155 routers. 157 2. Overview 159 A light-weight mobile node arrives at a foreign net, listens for 160 advertisements and selects a foreign agent that supports reverse 161 tunnels. It requests this service when it registers through the 162 selected foreign agent. At this time, and depending on how the 163 mobile node wishes to deliver packets to the foreign agent, it also 164 requests either the lightweight or the encapsulating style of 165 delivery (section 5). 167 In the lightweight delivery style, the mobile node designates the 168 foreign agent as its default router and proceeds to send packets as 169 usual. The foreign agent intercepts them, and tunnels them to the 170 home agent. 172 In the encapsulating delivery style, the mobile node encapsulates 173 all its outgoing packets to the foreign agent. The foreign agent 174 decapsulates and tunnels again, this time, directly to the home 175 agent. 177 3. New Packet Formats 179 3.1. Agent Advertisements: Mobile Service Extension 180 0 1 2 3 181 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 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Type | Length | Sequence Number | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Lifetime |R|B|H|F|M|G|V|T| reserved | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | zero or more Care-of Addresses | 188 | ... | 190 The only change to the Mobile Service Extension [1] is the 191 additional 'T' bit: 193 T Agent offers reverse tunneling service. 195 A foreign agent that sets the 'T' bit MUST support the two delivery 196 styles currently supported (section 5). 198 Using this information, a mobile node is able to choose a foreign 199 agent that supports reverse tunnels. Notice that if a mobile node 200 does not understand this bit, it simply ignores it. 202 3.2. Registration Request 204 Reverse tunneling support is added directly into the Registration 205 Request by using one of the "rsvd" bits. If a foreign or home agent 206 that does not support reverse tunnels receives a request with the 207 'T' bit set, the Registration Request fails. This results in a 208 registration denial (failure codes are specified in section 3.4). 210 Most home agents would not object to providing reverse tunnel 211 support, because they "SHOULD be able to decapsulate and further 212 deliver packets addressed to themselves, sent by a mobile node" 213 [1]. In the case of topologically correct reverse tunnels, the 214 packets are not sent by the mobile node as distinguished by its home 215 address. Rather, the outermost (encapsulating) IP source address on 216 such datagrams is the care-of address of the mobile node. 217 Nevertheless, home agents probably already support the required 218 decapsulation and further forwarding. 220 0 1 2 3 221 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 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Type |S|B|D|M|G|V|T|-| Lifetime | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Home Address | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Home Agent | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Care-of Address | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Identification | 232 | | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Extensions ... 235 +-+-+-+-+-+-+-+- 237 The only change to the Registration Request packet is the additional 238 'T' bit: 240 T If the 'T' bit is set, the mobile node asks its home 241 agent to accept a reverse tunnel from the care-of 242 address. Lightweight mobile nodes ask the foreign 243 agent to reverse-tunnel its packets. 245 3.3. Reverse Tunnel Extension 247 The Reverse Tunnel Extension is used to further specify reverse 248 tunneling behavior. Currently, it is only possible to request the 249 encapsulating style of delivery, but future behavior may be 250 defined. The Reverse Tunnel Extension MUST NOT be included if the 251 'T' bit is not set in the Registration Request. 253 If this extension is absent, or if no style is explicitly requested, 254 Lightweight Delivery is assumed. Besides the latter, currently only 255 the Encapsulating style is defined (section 5). 257 0 1 2 3 258 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 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Type | Length |E| reserved | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 Type 128 265 Length 2 267 E Encapsulating style of delivery. Encapsulation is done 268 according to what was negotiated for the forward tunnel 269 (i.e., IP in IP is assumed unless specified otherwise). 271 reserved Ignored upon reception. Must be set to zero when 272 transmitting. 274 3.4. New Registration Reply Codes 276 Foreign and home agent replies MUST convey if the reverse tunnel 277 request failed. Four new reply codes are defined. The use of codes 278 74 and 137 is preferred over code 70 for foreign agents and code 134 279 for home agents [1]: 281 Service denied by the foreign agent: 283 74 requested reverse tunnel unavailable 284 75 reverse tunnel is mandatory and 'T' bit not set 286 and 288 Service denied by the home agent: 290 137 requested reverse tunnel unavailable 291 138 reverse tunnel is mandatory and 'T' bit not set 293 Forward and reverse tunnels are symmetric, i.e. both are able to use 294 the same tunneling options negotiated at registration. This implies 295 that the home agent MUST deny registrations if an unsupported 296 tunneling form is requested: 298 139 requested encapsulation unavailable 300 Notice that Mobile IP [1] already defines the analogous failure code 301 72 for use by the foreign agent. 303 4. Changes in Protocol Behavior 305 Reverse tunnels must be handled appropriately by the different 306 mobility entities. Differences in protocol behavior with respect to 307 the Mobile IP specification are: 309 4.1. Mobile Node Considerations 311 In addition to the considerations in [1], a mobile node sets the 'T' 312 bit in its Registration Request to petition a reverse tunnel. It may 313 optionally include a Reverse Tunnel Extension. 315 Possible outcomes are: 317 - Either the home agent or the foreign agent returns a 318 registration denial: 320 a. The mobile node follows the error checking guidelines in 321 [1], and depending on the reply code, MAY try modifying the 322 registration request (for example by eliminating the 323 request for alternate forms of encapsulation), and issuing 324 a new registration. 326 b. Depending on the reply code, the mobile node MAY try 327 zeroing the 'T' bit, eliminating the Reverse Tunnel 328 Extension (if one was present), and issuing a new 329 registration. 331 - The home agent returns a Registration Reply indicating that the 332 service will be provided. 334 In this last case, the mobile node has succeeded in establishing a 335 reverse tunnel between its care-of address and its home agent. If 336 the mobile node is operating with a co-located care-of address, it 337 MUST encapsulate all outgoing data such that the destination address 338 of the outer header is the home agent. Not doing so does not 339 necessarily preclude data transmission, but it defeats the purpose 340 of the reverse tunnel. 342 If the care-of address belongs to a separate foreign agent, the 343 mobile node MUST employ whatever delivery style was requested 344 (lightweight or encapsulated) and proceed as specified in section 345 5. 347 A successful registration reply is an assurance that both the 348 foreign agent and the home agent support whatever alternate forms of 349 encapsulation (other than IP in IP) were requested. Accordingly, the 350 mobile node MAY use them at its discretion. 352 4.2. Foreign Agent Considerations 354 A foreign agent that receives a Registration Request with the 'T' 355 bit set processes the packet as specified in the Mobile IP 356 specification [1], and determines if it can accomodate the forward 357 tunnel request. If it cannot, it returns an appropriate code. In 358 particular, if the foreign agent is unable to support the requested 359 form of encapsulation, code 72 MUST be returned. 361 As a last check, the foreign agent verifies that it can support a 362 reverse tunnel with the same configuration. If it cannot, it MUST 363 return a Registration Reply denying the request. Valid return codes 364 are 74 (requested reverse tunnel unavailable) or 70 (poorly formed 365 request). Code 74 is preferred. 367 Otherwise, the foreign agent must relay the Registration Request to 368 the home agent. 370 Upon receipt of a Registration Reply that satisfies validity checks, 371 it MUST update its visitor list, including indication that this 372 mobile node has been granted a reverse tunnel and the delivery style 373 expected (section 5). 375 While this visitor list entry is in effect, the foreign agent MUST 376 process incoming traffic according to the delivery style, 377 encapsulate it and tunnel it from the care-of address to the home 378 agent's address. 380 4.3. Home Agent Considerations 382 A home agent that receives a Registration Request with the 'T' bit 383 set processes the packet as specified in the Mobile IP specification 384 [1]. and determines if it can accomodate the forward tunnel 385 request. If it cannot, it returns an appropriate code. In 386 particular, if the home agent is unable to support the requested 387 form of encapsulation, code 139 MUST be returned. 389 As a last check, the home agent verifies that it can support a 390 reverse tunnel with the same configuration. 392 If it can, the home agent sends back a Registration Reply with code 393 0 or 1. A registration denial should send back code 137 (requested 394 reverse tunnel unavailable) or 134 (poorly formed Request). Code 395 137 is preferred. 397 After a successful registration, the home agent will receive 398 encapsulated packets addressed to it. For each such packet it MAY 399 search for a mobility binding whose care-of address is the source of 400 the outer header, and whose mobile node address is the source of the 401 inner header. 403 The home agent MUST decapsulate, recover the original packet, and 404 then forward it on behalf of its sender (the mobile node) to the 405 destination address (the correspondent host). 407 5. Mobile Node to Foreign Agent Delivery Styles 409 This section specifies how the mobile node sends its data traffic 410 via the foreign agent. In all cases, the mobile node learns the 411 foreign agent's link-layer address from the link-layer header in the 412 agent advertisement. 414 5.1. Lightweight Delivery Style 416 This delivery mechanism is very simple to implement, and uses small 417 (non-encapsulated) packets on the link between the mobile node and 418 the foreign agent (potentially a very slow link). However, it only 419 supports reverse-tunneling of unicast packets. 421 5.1.1. Packet Processing 423 The mobile node MUST designate the foreign agent as its default 424 router. Not doing so will not guarantee encapsulation of all the 425 mobile node's outgoing traffic, and defeats the purpose of the 426 reverse tunnel. The foreign agent MUST: 428 - detect packets sent by the mobile node, and 430 - modify its forwarding function to re-encapsulate them before 431 forwarding. 433 5.1.2. Packet Header Format and Fields 435 This section shows the format of the packet headers used by the 436 Lightweight Delivery style. 438 Packet format received by the foreign agent (lightweight delivery): 440 Data Link fields: 441 Source Address = mobile node's link-layer address 442 Destination Address = foreign agent's link-layer address 443 IP fields: 444 Source Address = mobile node's home address 445 Destination Address = correspondent host's address 446 Upper Layer Protocol 448 Packet format forwarded by the foreign agent (lightweight delivery): 450 Data Link fields: 451 Source Address = foreign agent's link-layer address 452 Destination Address = next hop router's link-layer address 453 IP fields (encapsulating header): 454 Source Address = foreign agent's address 455 Destination Address = home agent's address 456 Protocol field: 4 (IP in IP) 457 IP fields (original header): 458 Source Address = mobile node's home address 459 Destination Address = correspondent host's address 460 Upper Layer Protocol 462 These fields of the encapsulating header MUST be chosen in 463 accordance with section 3.7.2.2 of Mobile IP [1]: 465 IP Source Address 467 The foreign agent's address on the interface from which the 468 message will be sent. 470 IP Destination Address 472 Copied from the Home Agent field within the Registration 473 Request. 475 IP Protocol Field 477 Default is 4 (IP in IP [2]), but other methods of 478 encapsulation MAY be used as negotiated at registration time. 480 5.2. Encapsulating Delivery Style 482 This mechanism requires that the mobile node implement 483 encapsulation, and explicitly directs packets at the foreign agent 484 by designating it as the destination address in a new outermost 485 header. Mobile nodes that wish to send either broadcast or 486 multicast packets MUST use encapsulating delivery. 488 5.2.1 Packet Processing 490 The foreign agent does not modify its forwarding function. 491 Rather, it receives an encapsulated packet and after verifying that 492 it was sent by the mobile node, it MUST: 494 - recover the inner packet, 496 - re-encapsulate it, and send it to the home agent. 498 If the foreign agent expects encapsulating delivery, it MUST NOT 499 reverse tunnel unencapsulated packets from the mobile node. 501 5.2.2. Packet Header Format and Fields 503 This section shows the format of the packet headers used by the 504 Encapsulating Delivery style. 506 Packet format received by the foreign agent (encapsulated delivery): 508 Data Link fields: 509 Source Address = mobile node's link-layer address 510 Destination Address = foreign agent's link-layer address 511 IP fields (encapsulating header): 512 Source Address = mobile node's home address 513 Destination Address = foreign agent's address 514 Protocol field: 4 (IP in IP) 515 IP fields (original header): 516 Source Address = mobile node's home address 517 Destination Address = correspondent host's address 518 Upper Layer Protocol 520 The fields of the encapsulating IP header MUST be chosen as 521 follows: 523 IP Source Address 525 The mobile node's home address. 527 IP Destination Address 529 The address of the agent as learned from the IP source address 530 of the agent's most recent registration reply. 532 IP Protocol Field 534 Default is 4 (IP in IP [2]), but other methods of 535 encapsulation MAY be used as negotiated at registration time. 537 Packet format forwarded by the foreign agent (encapsulated delivery): 539 Data Link fields: 540 Source Address = foreign agent's link-layer address 541 Destination Address = next hop router's link-layer address 542 IP fields (encapsulating header): 543 Source Address = foreign agent's address 544 Destination Address = home agent's address 545 Protocol field: 4 (IP in IP) 546 IP fields (original header): 547 Source Address = mobile node's home address 548 Destination Address = correspondent host's address 549 Upper Layer Protocol 551 These fields of the encapsulating IP header MUST be chosen in 552 accordance with section 3.7.2.2 of Mobile IP [1]: 554 IP Source Address 556 The foreign agent's address on the interface from which the 557 message will be sent. 559 IP Destination Address 561 Copied from the Home Agent field within the Registration 562 Request. 564 IP Protocol Field 566 Default is 4 (IP in IP [2]), but other methods of 567 encapsulation MAY be used as negotiated at registration time. 569 5.3. Support for Broadcast and Multicast Datagrams 571 If a mobile node is operating with a co-located care-of address, 572 broadcast and multicast datagrams are handled according to Sections 573 4.3 and 4.4 of the Mobile IP specification [1]. Light-weight mobile 574 nodes MAY have their broadcast and multicast datagrams 575 reverse-tunneled by the foreign agent. However, any mobile nodes 576 doing so MUST use of the encapsulating delivery style. 578 This delivers the datagram only to the foreign agent. The latter 579 decapsulates it and then processes it as any other packet from the 580 mobile node, namely, by reverse tunneling it to the home agent. 582 5.4. Selective Reverse Tunneling 584 Packets destined to local resources (e.g. a nearby printer) may be 585 unaffected by ingress filtering. A mobile node with a co-located 586 care-of address MAY optimize delivery of these packets by not 587 reverse tunneling them. On the other hand, a lightweight mobile 588 node MAY use this selective reverse tunneling capability by 589 requesting the encapsulating delivery style, and following these 590 guidelines: 592 Packets meant to be reversed tunneled: 594 Sent using the Lightweight Delivery style. The foreign agent 595 MUST process these packets as regular traffic: they MAY be 596 forwarded but MUST NOT be reverse tunneled to the home agent. 598 Packets NOT meant to be reverse tunneled: 600 Sent using the Encapsulating Delivery style. The foreign agent 601 MUST process these packets as specified in section 5.2: they 602 MUST be reverse tunneled to the home agent. 604 6. Security Considerations 606 The extensions outlined in this document are subject to the security 607 considerations outlined in the Mobile IP specification [1]. 608 Essentialy, creation of both forward and reverse tunnels involves an 609 authentication procedure, which reduces the risk for attack. 611 However, once the tunnel is set up, a malicious user could hijack it 612 to inject packets into the network. Reverse tunnels might exacerbate 613 this problem, because upon reaching the tunnel exit point packets 614 are forwarded beyond the local network. This concern is also present 615 in the Mobile IP specification, as it already dictates the use of 616 reverse tunnels for certain applications. 618 There has been some concern regarding the long-term effectiveness of 619 reverse-tunneling in the presence of ingress filtering. The 620 conjecture is that network administrators will target 621 reverse-tunneled packets (IP in IP encapsulated packets) for 622 filtering. The ingress filtering recommendation spells out why this 623 is not the case [8]: 625 Tracking the source of an attack is simplified when the source is 626 more likely to be "valid." 628 7. Acknowledgements 630 The encapsulating style of delivery was proposed by Charlie Perkins. 632 References 634 [1] C. Perkins. IP Mobility Support. RFC 2002, October 1996. 636 [2] C. Perkins. IP Encapsulation within IP. RFC 2003, October 637 1996. 639 [3] Computer Emergency Response Team (CERT), "IP Spoofing Attacks 640 and Hijacked Terminal Connections", CA-95:01, January 1995. 641 Available via anonymous ftp from info.cert.org in 642 /pub/cert_advisories. 644 [4] D. Johnson and C. Perkins. Route Optimization in Mobile IP -- 645 work in progress, draft-ietf-mobileip-optim-05.txt, November 646 1996. 648 [5] Manuel Rodriguez, private communication, August 1995. 650 [6] R. Atkinson. IP Authentication Header. RFC 1826, August 1995. 652 [7] R. Atkinson. IP Encapsulating Security Payload. RFC 1827, 653 August 1995. 655 [8] P. Ferguson and D. Senie. Network Ingress Filtering: Defending 656 Against IP Source Address Spoofing -- work in progress, 657 draft-ferguson-ingress-filtering-01.txt, February 1996 659 Author's Address 660 Gabriel E. Montenegro 661 Sun Microsystems, Inc. 662 2550 Garcia Avenue 663 Mailstop UMPK 15-214 664 Mountain View, California 94043-1100 666 Tel: (415)786-6288 667 Fax: (415)786-6445 669 gab@eng.sun.com