idnits 2.17.1 draft-ietf-mobileip-tunnel-reverse-03.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-26) 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. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** 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 230: '...sets the 'T' bit MUST support the two ...' RFC 2119 keyword, line 284: '... Style Extension MAY be included by th...' RFC 2119 keyword, line 287: '...he foreign agent MUST consume this ext...' RFC 2119 keyword, line 290: '... mobile node MUST include the Encaps...' RFC 2119 keyword, line 294: '...lating Extension MUST NOT be included ...' (95 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 253 has weird spacing: '... agents proba...' -- 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 10, 1997) is 9756 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-06 -- 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) Summary: 13 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Montenegro, Editor 3 INTERNET DRAFT Sun Microsystems, Inc. 4 August 10, 1997 6 Reverse Tunneling for Mobile IP 7 draft-ietf-mobileip-tunnel-reverse-03.txt 9 Status of This Memo 11 This document is a submission by the Mobile IP Working Group of the 12 Internet Engineering Task Force (IETF). Comments should be submitted 13 to the Working Group mailing list at "mobile-ip@SmallWorks.COM". 15 Distribution of this memo is unlimited. 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working groups. Note that other groups may also distribute 20 working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet- Drafts as 25 reference material or to cite them other than as ``work in 26 progress.'' 28 To learn the current status of any Internet-Draft, please check the 29 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 30 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 31 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 32 ftp.isi.edu (US West Coast). 34 Abstract 36 Mobile IP uses tunneling from the home agent to the mobile node's 37 care-of address, but rarely in the reverse direction. Usually, a 38 mobile node sends its packets through a router on the foreign 39 network, and assumes that routing is independent of source address. 40 When this assumption is not true, it is convenient to establish a 41 topologically correct reverse tunnel from the care-of address to the 42 home agent. 44 This document proposes backwards-compatible extensions to Mobile IP 45 in order to support topologically correct reverse tunnels. This 46 document does not attempt to solve the problems posed by firewalls 47 located between the home agent and the mobile node's care-of 48 address. 50 Table of Contents 52 1. Introduction ................................................... 3 53 1.1. Terminology .................................................. 4 54 1.2. Assumptions .................................................. 4 55 1.3. Justification ................................................ 4 56 2. Overview ....................................................... 5 57 3. New Packet Formats ............................................. 5 58 3.1. Mobility Agent Advertisement Extension ....................... 5 59 3.2. Registration Request ......................................... 6 60 3.3. Encapsulating Delivery Style Extension ....................... 7 61 3.4. Cookie Extensions ............................................ 8 62 3.4.1 Mobile-Foreign Cookie Extension ............................. 8 63 3.4.2 Foreign-Home Cookie Extension ............................... 10 64 3.5. New Registration Reply Codes ................................. 11 65 4. Changes in Protocol Behavior ................................... 12 66 4.1. Mobile Node Considerations ................................... 12 67 4.1.1. Sending Registration Requests to the Foreign Agent ......... 12 68 4.1.2. Receiving Registration Replies from the Foreign Agent ...... 13 69 4.2. Foreign Agent Considerations ................................. 14 70 4.2.1. Receiving Registration Requests from the Mobile Node ....... 14 71 4.2.2. Relaying Registration Requests to the Home Agent ........... 15 72 4.3. Home Agent Considerations .................................... 16 73 4.3.1. Receiving Registration Requests from the Foreign Agent ..... 16 74 4.3.2. Sending Registration Replies to the Foreign Agent .......... 17 75 5. Mobile Node to Foreign Agent Delivery Styles ................... 18 76 5.1. Direct Delivery Style ........................................ 18 77 5.1.1. Packet Processing .......................................... 18 78 5.1.2. Packet Header Format and Fields ............................ 18 79 5.2. Encapsulating Delivery Style ................................. 19 80 5.2.1 Packet Processing ........................................... 20 81 5.2.2. Packet Header Format and Fields ............................ 20 82 5.3. Support for Broadcast and Multicast Datagrams ................ 21 83 5.4. Selective Reverse Tunneling .................................. 22 84 6. Security Considerations ........................................ 22 85 6.1. Reverse-tunnel Hijacking and Denial-of-Service Attacks ....... 22 86 6.2. Ingress Filtering ............................................ 23 87 7. Acknowledgements ............................................... 24 88 References ........................................................ 24 89 Editor and Chair Addresses ........................................ 24 90 1. Introduction 92 Section 1.3 of the Mobile IP specification [1] lists the following 93 assumption: 95 It is assumed that IP unicast datagrams are routed based on the 96 destination address in the datagram header (i.e., not by source 97 address). 99 Because of security concerns (e.g. IP spoofing attacks), and in 100 accordance with the IAB [8] and CERT [3] advisories to this effect, 101 routers that break this assumption are increasingly more common. 103 In the presence of such routers, the source and destination IP 104 address in a packet must be topologically correct. The forward 105 tunnel complies with this, as its endpoints (home agent address and 106 care-of address) are properly assigned addresses for their 107 respective locations. On the other hand, the source IP address of a 108 packet transmitted by the mobile node does not correspond to the 109 network prefix from where it emanates. 111 This document discusses topologically correct reverse tunnels. 113 Mobile IP does dictate the use of reverse tunnels in the context of 114 multicast datagram routing and mobile routers. However, the source 115 IP address is set to the mobile node's home address, so these 116 tunnels are not topologically correct. 118 Notice that there are several uses for reverse tunnels regardless of 119 their topological correctness: 121 - Mobile routers: reverse tunnels obviate the need for recursive 122 tunneling [1]. 124 - Multicast: reverse tunnels enable a mobile node away from home 125 to (1) join multicast groups in its home network, and (2) 126 transmit multicast packets such that they emanate from its home 127 network [1]. 129 - The TTL of packets sent by the mobile node (particularly when 130 sends packets to other hosts in its home network) may be so low 131 that they might expire before reaching their destination. A 132 reverse tunnel solves the problem as it represents a TTL 133 decrement of one [5]. 135 1.1. Terminology 137 The discussion below uses terms defined in the Mobile IP 138 specification. Additionally, it uses the following terms: 140 Forward Tunnel 142 A tunnel that shuttles packets towards the mobile node. It 143 starts at the home agent, and ends at the mobile node's 144 care-of address. 146 Reverse Tunnel 148 A tunnel that starts at the mobile node's care-of address and 149 terminates at the home agent. 151 1.2. Assumptions 153 Mobility is constrained to a common IP address space (e.g. the 154 routing fabric between, say, the mobile node and the home agent is 155 not partitioned into a "private" and a "public" network). 157 This document does not attempt to solve the firewall traversal 158 problem. Rather, it assumes one of the following is true: 160 - There are no intervening firewalls along the path of the 161 tunneled packets. 163 - Any intervening firewalls share the security association 164 necessary to process any authentication [6] or encryption [7] 165 headers which may have been added to the tunneled packets. 167 The reverse tunnels considered here are symmetric, that is, they use 168 the same configuration (encapsulation method, IP address endpoints) 169 as the forward tunnel. IP in IP encapsulation [2] is assumed unless 170 stated otherwise. 172 Route optimization [4] introduces forward tunnels initiated at a 173 correspondent host. Since a mobile node may not know if the 174 correspondent host can decapsulate packets, reverse tunnels in that 175 context are not discussed here. 177 1.3. Justification 179 Why not let the mobile node itself initiate the tunnel to the home 180 agent? This is indeed what it should do if it is already operating 181 with a topologically correct co-located care-of address. 183 However, one of the primary objectives of the Mobile IP 184 specification is not to require this mode of operation. 186 The mechanisms outlined in this document are primarily intended for 187 use by mobile nodes that rely on the foreign agent for forward 188 tunnel support. It is desirable to continue supporting these mobile 189 nodes, even in the presence of filtering routers. 191 2. Overview 193 A mobile node arrives at a foreign network, listens for agent 194 advertisements and selects a foreign agent that supports reverse 195 tunnels. It requests this service when it registers through the 196 selected foreign agent. At this time, and depending on how the 197 mobile node wishes to deliver packets to the foreign agent, it also 198 requests either the Direct or the Encapsulating Delivery Style 199 (section 5). 201 In the Direct Delivery Style, the mobile node designates the foreign 202 agent as its default router and proceeds to send packets directly to 203 the foreign agent, i.e., without encapsulation. The foreign agent 204 intercepts them, and tunnels them to the home agent. 206 In the Encapsulating Delivery Style, the mobile node encapsulates 207 all its outgoing packets to the foreign agent. The foreign agent 208 decapsulates and re-tunnels them to the home agent, using the 209 foreign agent's care-of address as the entry-point of this new 210 tunnel. 212 3. New Packet Formats 214 3.1. Mobility Agent Advertisement Extension 215 0 1 2 3 216 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 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Type | Length | Sequence Number | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Lifetime |R|B|H|F|M|G|V|T| reserved | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | zero or more Care-of Addresses | 223 | ... | 225 The only change to the Mobility Agent Advertisement Extension [1] is 226 the additional 'T' bit: 228 T Agent offers reverse tunneling service. 230 A foreign agent that sets the 'T' bit MUST support the two delivery 231 styles currently supported: Direct and Encapsulating Delivery Style 232 (section 5). 234 Using this information, a mobile node is able to choose a foreign 235 agent that supports reverse tunnels. Notice that if a mobile node 236 does not understand this bit, it simply ignores it as per [1]. 238 3.2. Registration Request 240 Reverse tunneling support is added directly into the Registration 241 Request by using one of the "rsvd" bits. If a foreign or home agent 242 that does not support reverse tunnels receives a request with the 243 'T' bit set, the Registration Request fails. This results in a 244 registration denial (failure codes are specified in section 3.5). 246 Most home agents would not object to providing reverse tunnel 247 support, because they "SHOULD be able to decapsulate and further 248 deliver packets addressed to themselves, sent by a mobile node" 249 [1]. In the case of topologically correct reverse tunnels, the 250 packets are not sent by the mobile node as distinguished by its home 251 address. Rather, the outermost (encapsulating) IP source address on 252 such datagrams is the care-of address of the mobile node. 253 Nevertheless, home agents probably already support the required 254 decapsulation and further forwarding. 256 0 1 2 3 257 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 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Type |S|B|D|M|G|V|T|-| Lifetime | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Home Address | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Home Agent | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Care-of Address | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Identification | 268 | | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Extensions ... 271 +-+-+-+-+-+-+-+- 273 The only change to the Registration Request packet is the additional 274 'T' bit: 276 T If the 'T' bit is set, the mobile node asks its home 277 agent to accept a reverse tunnel from the care-of 278 address. Mobile nodes using a foreign agent care-of 279 address ask the foreign agent to reverse-tunnel its 280 packets. 282 3.3. Encapsulating Delivery Style Extension 284 The Encapsulating Delivery Style Extension MAY be included by the 285 mobile node in registration requests to further specify reverse 286 tunneling behavior. It is expected to be used only by the foreign 287 agent. Accordingly, the foreign agent MUST consume this extension 288 (i.e. it must not relay it to the home agent or include it in 289 replies to the mobile node). As per Section 3.6.1.3 of [1], the 290 mobile node MUST include the Encapsulating Delivery Style Extension 291 after the Mobile-Home Authentication Extension, and before the 292 Mobile-Foreign Authentication Extension, if present. 294 Encapsulating Extension MUST NOT be included if the 'T' bit is not 295 set in the Registration Request. 297 If this extension is absent, Direct Delivery is assumed. 298 Encapsulation is done according to what was negotiated for the 299 forward tunnel (i.e., IP in IP is assumed unless specified 300 otherwise). For more details on the delivery styles, please refer to 301 section 5. 303 0 1 304 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Type | Length | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 Type 311 128 313 Length 315 0 317 3.4. Cookie Extensions 319 In the absence of mobility security associations, Cookie Extensions 320 are used by mobile nodes, foreign agents and home agents to provide 321 some level of protection against reverse tunnel hijacking and denial 322 of service attacks (see Section 6). Cookies are not needed if the 323 mobile node operates in co-located mode since the two entities 324 involved (mobile node and home agent) MUST have a mobility security 325 association in place [1]. 327 The Mobile-Foreign Cookie Extension is used only between the mobile 328 node and the foreign agent. Similarly, use of the Foreign-Home 329 Cookie Extension is limited to registration traffic between the 330 foreign agent and the home agent. 332 If a Registration Request with the 'T' bit on includes a Cookie 333 Extension, the corresponding successful (code 0) Registration Reply 334 MUST include one as well. 336 3.4.1 Mobile-Foreign Cookie Extension 338 Mobile nodes and foreign agents MAY include a Mobile-Foreign Cookie 339 Extension in Registration Requests and Replies, subject to the 340 conditions detailed in Sections 4.1 and 4.2. 342 The foreign agent MUST consume this extension (i.e. it MUST NOT 343 relay it to the home agent). 345 If the Mobile-Foreign Cookie Extension is present, as per Sections 346 3.6.1.3 and 3.7.3.2 of [1], the mobile node and the foreign agent 347 MUST include it after the Mobile-Home Authentication Extension. 349 For further details about the processing of this extension, at the 350 mobile node and the foreign agent, refer to Sections 4.1 and 4.2, 351 respectively. 353 0 1 2 3 354 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 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Type | Length | Reserved | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Current Cookie | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Previous Cookie | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 Type 365 130 367 Length 369 10 371 Reserved 373 0 375 Current Cookie 377 In Registration Requests, it is a value generated randomly by 378 the mobile node. 380 In Registration Replies, the foreign agent sets it to the value 381 sent by the mobile node as the "Current Cookie" in the 382 corresponding Registration Request. 384 Previous Cookie 386 Set to 0 by the foreign agent in Registration Replies. 388 Set to 0 by the mobile node in initial Registration Requests. 390 In re-registrations, the mobile node sets this field to the 391 "Current Cookie" field of the Mobile-Foreign Cookie Extension 392 in the last successful (code 0) Registration Reply. 394 3.4.2 Foreign-Home Cookie Extension 396 Foreign agents and home agents MAY include a Foreign-Home Cookie 397 Extension in Registration Requests and Replies, subject to the 398 conditions detailed in Sections 4.2 and 4.3. 400 If the Foreign-Home Cookie Extension is present, as per Sections 401 3.7.3.2 and 3.8.3.3 of [1], the foreign agent and the home agent 402 MUST include it after the Mobile-Home Authentication Extension. 404 For further details about the processing of this extension, at the 405 foreign agent and the home agent, refer to Sections 4.2 and 4.3, 406 respectively. 408 0 1 2 3 409 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 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Type | Length | Reserved | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Current Cookie | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Previous Cookie | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 Type 420 131 422 Length 424 10 426 Reserved 428 0 430 Current Cookie 432 In Registration Requests, it is a value generated randomly by 433 the foreign agent. 435 In Registration Replies, the home agent sets it to the value 436 sent by the foreign agent as the "Current Cookie" field of the 437 Foreign-Home Cookie Extension in the corresponding Registration 438 Request. 440 Previous Cookie 441 Set to 0 by the home agent in Registration Replies. 443 Set to 0 by the foreign node in initial Registration Requests. 445 In re-registrations, the foreign agent sets this field to the 446 "Current Cookie" field of the Foreign-Home Cookie Extension in 447 the last Registration Reply. 449 3.5. New Registration Reply Codes 451 Foreign and home agent registration replies MUST convey if the 452 reverse tunnel request failed. These new reply codes are defined: 454 Service denied by the foreign agent: 456 74 requested reverse tunnel unavailable 457 75 reverse tunnel is mandatory and 'T' bit not set 458 76 bad cookie 459 77 bad cookie from home agent 460 78 mobile node too distant 462 and 464 Service denied by the home agent: 466 137 requested reverse tunnel unavailable 467 138 reverse tunnel is mandatory and 'T' bit not set 468 139 requested encapsulation unavailable 469 140 bad cookie 471 In response to a Registration Request with the 'T' bit set, mobile 472 nodes may receive (and MUST accept) code 70 (poorly formed request) 473 from foreign agents and code 134 (poorly formed request) from home 474 agents. However, foreign and home agents that support reverse 475 tunneling MUST use codes 74 and 137, respectively. 477 Absence of the 'T' bit in a Registration Request MAY elicit denials 478 with codes 75 and 138 at the foreign agent and the home agent, 479 respectively. 481 Forward and reverse tunnels are symmetric, i.e. both are able to use 482 the same tunneling options negotiated at registration. This implies 483 that the home agent MUST deny registrations if an unsupported form 484 of tunneling is requested (code 139). Notice that Mobile IP [1] 485 already defines the analogous failure code 72 for use by the foreign 486 agent. 488 In response to a Registration Request with the 'T' bit set, mobile 489 nodes may receive (and MUST accept) codes 76 (bad cookie), 77 (bad 490 cookie from home agent) and 78 (mobile node too distant). from 491 foreign agents. Similarly, foreign agents MUST accept code 140 (bad 492 cookie) from home agents, and then relay it to mobile nodes. These 493 codes are sent as response to the absence of an expected Cookie 494 Extension, or if the values in the fields are unexpected. 496 4. Changes in Protocol Behavior 498 Reverse tunnels must be handled appropriately by the different 499 mobility entities. Differences in protocol behavior with respect to 500 the Mobile IP specification are specified in the subsequent 501 sections. 503 4.1. Mobile Node Considerations 505 This section describes how the mobile node handles registrations 506 that request a reverse tunnel. 508 4.1.1. Sending Registration Requests to the Foreign Agent 510 In addition to the considerations in [1], a mobile node sets the 'T' 511 bit in its Registration Request to petition a reverse tunnel. 513 If registering via a separate foreign agent, it MUST use either one 514 of the following: 516 a. If the mobile node has a security association with the 517 foreign agent, it MUST use it as specified in [1]. 519 b. Otherwise, it MUST append a Mobile-Foreign Cookie Extension 520 to the Registration Request after the Mobile-Home 521 Authentication Extension. The "Current Cookie" field MUST 522 be generated randomly by the mobile node using guidelines 523 similar to those used in generating nonces. 525 If using a Mobile-Foreign Cookie Extension, the mobile node MUST set 526 the TTL field of the IP header to 255. This is meant to limit a 527 denial of service attack introduced by the use of Cookie Extensions 528 (Section 6). 530 The mobile node MAY optionally include an Encapsulating Delivery 531 Style Extension. 533 4.1.2. Receiving Registration Replies from the Foreign Agent 535 If the mobile node included a Mobile-Foreign Cookie Extension in its 536 Registration Request, the Registration Reply MUST also include one. 537 If it doesn't, the mobile node MUST ignore the reply. If such an 538 extension is present, the mobile node MUST verify that the value of 539 the "Current Cookie" field in the reply is equal to that in the 540 request. If it isn't, the mobile node MUST ignore this reply. The 541 mobile node SHOULD treat flag either of these two conditions as 542 security exceptions. 544 Possible valid responses are: 546 - A registration denial issued by either the home agent or the 547 foreign agent: 549 a. The mobile node follows the error checking guidelines in 550 [1], and depending on the reply code, MAY try modifying the 551 registration request (for example by eliminating the 552 request for alternate forms of encapsulation), and issuing 553 a new registration. 555 b. Depending on the reply code, the mobile node MAY try 556 zeroing the 'T' bit, eliminating the Encapsulating Delivery 557 Style Extension (if one was present), and issuing a new 558 registration. 560 c. The foreign agent returns code 76 ("bad cookie"). If 561 reissuing the Registration Request, the mobile node MUST 562 set the "Previous Cookie" to the appropriate value. If the 563 mobile node ignores this value, it can (a) wait for the 564 current binding at the foreign agent to expire, (b) attempt 565 registering using another foreign agent. 567 d. The foreign agent returns codes 77 (bad cookie from home 568 agent) or 78 (mobile node too distant). The mobile node MAY 569 try issuing a new registration via another foreign agent or 570 registering with another home agent. It SHOULD also flag 571 this event as a security exception. 573 e. The foreign agent relays code 140 ("bad cookie") from the 574 home agent. The mobile node MAY try issuing a new 575 registration via another foreign agent. It SHOULD also flag 576 this event as a security exception. 578 - The home agent returns a Registration Reply indicating that the 579 service will be provided. 581 In this last case, the mobile node has succeeded in establishing a 582 reverse tunnel between its care-of address and its home agent. If 583 the mobile node is operating with a co-located care-of address, it 584 MAY encapsulate outgoing data such that the destination address of 585 the outer header is the home agent. This ability to selectively 586 reverse-tunnel packets is discussed further in section 5.4. 588 If the care-of address belongs to a separate foreign agent, the 589 mobile node MUST employ whatever delivery style was requested 590 (Direct or Encapsulating) and proceed as specified in section 5. 592 A successful registration reply is an assurance that both the 593 foreign agent and the home agent support whatever alternate forms of 594 encapsulation (other than IP in IP) were requested. Accordingly, the 595 mobile node MAY use them at its discretion. 597 If a valid Mobile-Foreign Cookie Extension is present in the 598 Registration Reply, the mobile node MUST record the value reported 599 by the foreign agent in the "Current Cookie" field. This value MUST 600 be used to set the "Previous Cookie" field of the Mobile-Foreign 601 Cookie Extension in a subsequent re-registration. Failure to do so 602 will result in a registration denial. Of course, after the 603 registration expires at the foreign agent the mobile node may 604 register with a "Previous Cookie" set to 0. 606 In order to re-register after rebooting, a mobile node MAY choose to 607 record a Registration Reply's "Current Cookie" field in non-volatile 608 storage. Alternatively, it MAY request a sufficiently short lifetime 609 in its registration (e.g. comparable to the time the mobile node 610 takes to reboot). 612 4.2. Foreign Agent Considerations 614 This section describes how the foreign agent handles registrations 615 that request a reverse tunnel. 617 4.2.1. Receiving Registration Requests from the Mobile Node 619 A foreign agent that receives a Registration Request with the 'T' 620 bit set processes the packet as specified in the Mobile IP 621 specification [1], and determines whether it can accomodate the 622 forward tunnel request. If it cannot, it returns an appropriate 623 code. In particular, if the foreign agent is unable to support the 624 requested form of encapsulation it MUST return code 72. 626 The foreign agent MAY reject Registration Requests without the 'T' 627 bit set by denying them with code 75 (reverse tunnel is mandatory 628 and 'T' bit not set). 630 A foreign agent expects a Registration Request with 'T' bit on to be 631 secured by either of these: 633 a. Mobile-Foreign Authentication Extension (preferred), or 635 b. Mobile-Foreign Cookie Extension. 637 If neither of the above is present, the foreign agent MUST reject 638 the registration with code 76 (bad cookie). 640 If the Registration Request includes a Mobile-Foreign Extension, the 641 foreign agent MUST verify that the TTL field of the IP header is set 642 to 255. Otherwise, it MUST reject the registration with code 78 643 (mobile node too distant). The foreign agent MUST record the value 644 of the "Current Cookie" field. This value MUST match the "Previous 645 Cookie" field in subsequent re-registrations issued by the same 646 mobile node. A mismatch MUST result in the foreign agent's denying 647 the registration with code 76 (bad cookie). 649 As a last check, the foreign agent verifies that it can support a 650 reverse tunnel with the same configuration. If it cannot, it MUST 651 return a Registration Reply denying the request with code 74 652 (requested reverse tunnel unavailable). 654 4.2.2. Relaying Registration Requests to the Home Agent 656 Otherwise, the foreign agent MUST relay the Registration Request to 657 the home agent. The foreign agent MUST use either of these: 659 a. Foreign-Home Authentication Extension (preferred), or 661 b. Foreign-Home Cookie Extension. 663 If the foreign agent receives a denial with code 140 (bad cookie) 664 from the home agent, it MUST relay it to the mobile node. 666 If the foreign agent included a Foreign-Home Cookie Extension when 667 it relayed the Registration Request, the Registration Reply MUST 668 also include one. If it doesn't, the foreign agent MUST send a 669 denial to the mobile node with code 77 (bad cookie from home 670 agent). If such an extension is present, the foreign agent MUST 671 verify that the value of the "Current Cookie" field in the reply is 672 equal to that in the request. If it isn't, the foreign agent MUST 673 send a denial to the mobile node with code 77 (bad cookie from home 674 agent). The foreign agent SHOULD flag either of these two 675 conditions as security exceptions. 677 If the reply includes a Foreign-Home Authentication Extension, the 678 foreign agent MUST record the value of the "Current Cookie" field. 679 This value must be used to set the "Previous Cookie" field when 680 relaying a subsequent re-registration from the same mobile node. 682 Upon receipt of a Registration Reply that satisfies validity checks, 683 the foreign agent MUST update its visitor list, including indication 684 that this mobile node has been granted a reverse tunnel and the 685 delivery style expected (section 5). 687 The foreign agent MUST then relay the Registration Reply to the 688 mobile node, including either a Mobile-Foreign Authentication 689 Extension or Mobile-Foreign Cookie Extension, whichever was present 690 in the corresponding Registration Request. In the latter case, the 691 value of the "Current Cookie" MUST be equal to that in the same 692 field of the corresponding request. 694 While this visitor list entry is in effect, the foreign agent MUST 695 process incoming traffic according to the delivery style, 696 encapsulate it and tunnel it from the care-of address to the home 697 agent's address. 699 4.3. Home Agent Considerations 701 This section describes how the home agent handles registrations that 702 request a reverse tunnel. 704 4.3.1. Receiving Registration Requests from the Foreign Agent 706 A home agent that receives a Registration Request with the 'T' bit 707 set processes the packet as specified in the Mobile IP specification 708 [1] and determines whether it can accomodate the forward tunnel 709 request. If it cannot, it returns an appropriate code. In 710 particular, if the home agent is unable to support the requested 711 form of encapsulation it MUST return code 139. 713 The home agent MAY reject registration requests without the 'T' bit 714 set by denying them with code 138 (reverse tunnel is mandatory and 715 'T' bit not set). 717 A home agent expects a Registration Request with 'T' bit on to be 718 secured by either of these: 720 a. Foreign-Home Authentication Extension (preferred), or 722 b. Foreign-Home Cookie Extension. 724 If neither of the above is present, the home agent MUST reject the 725 registration with code 140 (bad cookie). 727 If the Registration Request includes a Foreign-Home Extension, the 728 home agent MUST record the value of the "Current Cookie" field. This 729 value MUST match the "Previous Cookie" field in subsequent 730 re-registrations relayed by the foreign agent on behalf of the same 731 mobile node. A mismatch MUST result in the home agent's denying the 732 registration with code 140 (bad cookie). 734 As a last check, the home agent determines whether it can support a 735 reverse tunnel with the same configuration as the forward tunnel. If 736 it cannot, it MUST send back a registration denial with code 137. 738 Upon receipt of a Registration Reply that satisfies validity checks, 739 the home agent MUST update its mobility bindings list to indicate 740 that this mobile node has been granted a reverse tunnel and the type 741 of encapsulation expected. 743 4.3.2. Sending Registration Replies to the Foreign Agent 745 In response to a valid Registration Request, a home agent MUST issue 746 a Registration Reply to the mobile node, including either a 747 Foreign-Home Authentication Extension or a Foreign-Home Cookie 748 Extension, whichever was present in the corresponding Registration 749 Request. In the latter case, the value of the "Current Cookie" MUST 750 be equal to that in the same field of the corresponding request. 752 After a successful registration, the home agent may receive 753 encapsulated packets addressed to it. For each such packet it MAY 754 search for a mobility binding whose care-of address is the source of 755 the outer header, and whose mobile node address is the source of the 756 inner header. If no such binding is found, or if the packet uses an 757 encapsulation mechanism that was not negotiated at registration the 758 home agent MUST silently discard the packet and SHOULD log the event 759 as a security exception. 761 While the registration is in effect, a home agent MUST process each 762 valid reverse tunneled packet (as determined by checks like the 763 above) by decapsulating it, recovering the original packet, and then 764 forwarding it on behalf of its sender (the mobile node) to the 765 destination address (the correspondent host). 767 5. Mobile Node to Foreign Agent Delivery Styles 769 This section specifies how the mobile node sends its data traffic 770 via the foreign agent. In all cases, the mobile node learns the 771 foreign agent's link-layer address from the link-layer header in the 772 agent advertisement. 774 5.1. Direct Delivery Style 776 This delivery mechanism is very simple to implement at the mobile 777 node, and uses small (non-encapsulated) packets on the link between 778 the mobile node and the foreign agent (potentially a very slow 779 link). However, it only supports reverse-tunneling of unicast 780 packets, and does not allow selective reverse tunneling (section 781 5.4). 783 5.1.1. Packet Processing 785 The mobile node MUST designate the foreign agent as its default 786 router. Not doing so will not guarantee encapsulation of all the 787 mobile node's outgoing traffic, and defeats the purpose of the 788 reverse tunnel. The foreign agent MUST: 790 - detect packets sent by the mobile node, and 792 - modify its forwarding function to encapsulate them before 793 forwarding. 795 5.1.2. Packet Header Format and Fields 797 This section shows the format of the packet headers used by the 798 Direct Delivery style. The formats shown assume IP in IP 799 encapsulation [2]. 801 Packet format received by the foreign agent (Direct Delivery 802 Style): 804 IP fields: 805 Source Address = mobile node's home address 806 Destination Address = correspondent host's address 807 Upper Layer Protocol 809 Packet format forwarded by the foreign agent (Direct Delivery 810 Style): 812 IP fields (encapsulating header): 813 Source Address = foreign agent's care-of address 814 Destination Address = home agent's address 815 Protocol field: 4 (IP in IP) 816 IP fields (original header): 817 Source Address = mobile node's home address 818 Destination Address = correspondent host's address 819 Upper Layer Protocol 821 These fields of the encapsulating header MUST be chosen as follows: 823 IP Source Address 825 Copied from the Care-of Address field within the Registration 826 Request. 828 IP Destination Address 830 Copied from the Home Agent field within the Registration 831 Request. 833 IP Protocol Field 835 Default is 4 (IP in IP [2]), but other methods of 836 encapsulation MAY be used as negotiated at registration time. 838 5.2. Encapsulating Delivery Style 840 This mechanism requires that the mobile node implement 841 encapsulation, and explicitly directs packets at the foreign agent 842 by designating it as the destination address in a new outermost 843 header. Mobile nodes that wish to send either broadcast or 844 multicast packets MUST use the Encapsulating Delivery Style. 846 5.2.1 Packet Processing 848 The foreign agent does not modify its forwarding function. 849 Rather, it receives an encapsulated packet and after verifying that 850 it was sent by the mobile node, it: 852 - decapsulates to recover the inner packet, 854 - re-encapsulates, and sends it to the home agent. 856 If a foreign agent receives an un-encapsulated packet from a mobile 857 node which had explicitly requested the Encapsulated Delivery Style, 858 then the foreign agent MUST NOT reverse tunnel such a packet and 859 rather MUST forward it using standard, IP routing mechanisms. 861 5.2.2. Packet Header Format and Fields 863 This section shows the format of the packet headers used by the 864 Encapsulating Delivery style. The formats shown assume IP in IP 865 encapsulation [2]. 867 Packet format received by the foreign agent (Encapsulating Delivery 868 Style): 870 IP fields (encapsulating header): 871 Source Address = mobile node's home address 872 Destination Address = foreign agent's address 873 Protocol field: 4 (IP in IP) 874 IP fields (original header): 875 Source Address = mobile node's home address 876 Destination Address = correspondent host's address 877 Upper Layer Protocol 879 The fields of the encapsulating IP header MUST be chosen as 880 follows: 882 IP Source Address 884 The mobile node's home address. 886 IP Destination Address 888 The address of the agent as learned from the IP source address 889 of the agent's most recent registration reply. 891 IP Protocol Field 893 Default is 4 (IP in IP [2]), but other methods of 894 encapsulation MAY be used as negotiated at registration time. 896 Packet format forwarded by the foreign agent (Encapsulating Delivery 897 Style): 899 IP fields (encapsulating header): 900 Source Address = foreign agent's care-of address 901 Destination Address = home agent's address 902 Protocol field: 4 (IP in IP) 903 IP fields (original header): 904 Source Address = mobile node's home address 905 Destination Address = correspondent host's address 906 Upper Layer Protocol 908 These fields of the encapsulating IP header MUST be chosen as 909 follows: 911 IP Source Address 913 Copied from the Care-of Address field within the Registration 914 Request. 916 IP Destination Address 918 Copied from the Home Agent field within the Registration 919 Request. 921 IP Protocol Field 923 Default is 4 (IP in IP [2]), but other methods of 924 encapsulation MAY be used as negotiated at registration time. 926 5.3. Support for Broadcast and Multicast Datagrams 928 If a mobile node is operating with a co-located care-of address, 929 broadcast and multicast datagrams are handled according to Sections 930 4.3 and 4.4 of the Mobile IP specification [1]. Mobile nodes using a 931 foreign agent care-of address MAY have their broadcast and multicast 932 datagrams reverse-tunneled by the foreign agent. However, any 933 mobile nodes doing so MUST use the encapsulating delivery style. 935 This delivers the datagram only to the foreign agent. The latter 936 decapsulates it and then processes it as any other packet from the 937 mobile node, namely, by reverse tunneling it to the home agent. 939 5.4. Selective Reverse Tunneling 941 Packets destined to local resources (e.g. a nearby printer) might be 942 unaffected by ingress filtering. A mobile node with a co-located 943 care-of address MAY optimize delivery of these packets by not 944 reverse tunneling them. On the other hand, a mobile node using a 945 foreign agent care-of address MAY use this selective reverse 946 tunneling capability by requesting the Encapsulating Delivery Style, 947 and following these guidelines: 949 Packets NOT meant to be reversed tunneled: 951 Sent using the Direct Delivery style. The foreign agent 952 MUST process these packets as regular traffic: they MAY be 953 forwarded but MUST NOT be reverse tunneled to the home agent. 955 Packets meant to be reverse tunneled: 957 Sent using the Encapsulating Delivery style. The foreign agent 958 MUST process these packets as specified in section 5.2: they 959 MUST be reverse tunneled to the home agent. 961 6. Security Considerations 963 The extensions outlined in this document are subject to the security 964 considerations outlined in the Mobile IP specification [1]. 965 Essentialy, creation of both forward and reverse tunnels involves an 966 authentication procedure, which reduces the risk for attack. 968 6.1. Reverse-tunnel Hijacking and Denial-of-Service Attacks 970 Once the tunnel is set up, a malicious node could hijack it to 971 inject packets into the network. Reverse tunnels might exacerbate 972 this problem, because upon reaching the tunnel exit point packets 973 are forwarded beyond the local network. This concern is also present 974 in the Mobile IP specification, as it already dictates the use of 975 reverse tunnels for certain applications. 977 Unauthenticated exchanges involving the foreign agent allow a 978 malicious node to pose as a valid mobile node and re-direct an 979 existing reverse tunnel to another home agent, perhaps another 980 malicious node. The best way to protect against these attacks is by 981 employing the Mobile-Foreign and Foreign-Home Authentication 982 Extensions defined in [1]. If the necessary mobility security 983 associations are not available, Cookie Extensions (Section 3.4) MUST 984 be used to protect against off-the-path attacks. 986 The Mobile-Foreign Cookie Extension enables a foreign agent to 987 distinguish between a mobile node for which it has a current visitor 988 list entry and an off-the-path attacker. The Foreign-Home Cookie 989 Extension enables a foreign agent to distinguish between the home 990 agent for a mobile node currently in a visitor list entry and an 991 off-the-path attacker. 993 However, cookies are unauthenticated state, and as such, may be used 994 to launch denial-of-service attacks. For example, a malicious node 995 may register via a foreign agent using another malicious node as its 996 home agent. The existence of this visitor list entry at the foreign 997 agent effectively blocks the real mobile node from registering. As 998 a consequence, the mobile node SHOULD cache the cookies in permanent 999 storage, otherwise it will be unable to register in the event of a 1000 reboot as long as it has a valid visitor list entry at the foreign 1001 agent. Alternatively, the mobile node MAY request appropriately 1002 short lifetimes in its Registration Requests. 1004 This document also introduces other mechanisms to reduce the range 1005 and effectiveness of the attacks. Requiring a TTL value of 255 in 1006 the IP headers of Registration Requests received at the foreign 1007 agent prevents malicious nodes more than one hop away from posing as 1008 valid mobile nodes. Additional codes for use in registration denials 1009 make those attacks that do occur easier to track. 1011 6.2. Ingress Filtering 1013 There has been some concern regarding the long-term effectiveness of 1014 reverse-tunneling in the presence of ingress filtering. The 1015 conjecture is that network administrators will target 1016 reverse-tunneled packets (IP in IP encapsulated packets) for 1017 filtering. The ingress filtering recommendation spells out why this 1018 is not the case [8]: 1020 Tracking the source of an attack is simplified when the source is 1021 more likely to be "valid." 1023 7. Acknowledgements 1025 The encapsulating style of delivery was proposed by Charlie 1026 Perkins. Jim Solomon has been instrumental in shaping this document 1027 into its present form. 1029 References 1031 [1] C. Perkins. IP Mobility Support. RFC 2002, October 1996. 1033 [2] C. Perkins. IP Encapsulation within IP. RFC 2003, October 1034 1996. 1036 [3] Computer Emergency Response Team (CERT), "IP Spoofing Attacks 1037 and Hijacked Terminal Connections", CA-95:01, January 1995. 1038 Available via anonymous ftp from info.cert.org in 1039 /pub/cert_advisories. 1041 [4] D. Johnson and C. Perkins. Route Optimization in Mobile IP -- 1042 work in progress, draft-ietf-mobileip-optim-06.txt, July 1997. 1044 [5] Manuel Rodriguez, private communication, August 1995. 1046 [6] R. Atkinson. IP Authentication Header. RFC 1826, August 1995. 1048 [7] R. Atkinson. IP Encapsulating Security Payload. RFC 1827, 1049 August 1995. 1051 [8] P. Ferguson and D. Senie. Network Ingress Filtering: Defending 1052 Against IP Source Address Spoofing -- work in progress, 1053 draft-ferguson-ingress-filtering-02.txt, July 1997. 1055 Editor and Chair Addresses 1056 Questions about this document may be directed at: 1058 Gabriel E. Montenegro 1059 Sun Microsystems, Inc. 1060 an Antonio Road 1061 Mailstop UMPK 15-214 1062 Mountain View, California 94303 1064 Voice: +1-415-786-6288 1065 Fax: +1-415-786-6445 1067 E-Mail: gabriel.montenegro@eng.sun.com 1069 The working group can be contacted via the current chairs: 1071 Jim Solomon 1072 Motorola, Inc. 1073 1301 E. Algonquin Rd. - Rm 2240 1074 Schaumburg, IL 60196 1076 Voice: +1-847-576-2753 1077 Fax: +1-847-576-3240 1078 E-Mail: solomon@comm.mot.com 1080 Erik Nordmark 1081 Sun Microsystems, Inc. 1082 901 San Antonio Road 1083 Mailstop UMPK17-202 1084 Mountain View, California 94303 1086 Voice: +1-415-786-5166 1087 E-Mail: erik.nordmark@eng.sun.com