idnits 2.17.1 draft-ietf-mobileip-firewall-trav-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 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 == The page length should not exceed 58 lines per page, but there was 13 longer pages, the longest (page 13) being 72 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages 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 abstract seems to contain references (1826,, [RFCs1825,, [GuGl97], 1827]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 109 has weird spacing: '...irewall prote...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 17, 1997) is 9895 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) == Missing Reference: 'RFCs 1825' is mentioned on line 57, but not defined -- Looks like a reference, but probably isn't: '1826' on line 57 -- Looks like a reference, but probably isn't: '1827' on line 57 == Missing Reference: 'FW' is mentioned on line 135, but not defined == Missing Reference: 'R2' is mentioned on line 144, but not defined == Unused Reference: 'LGLK96' is defined on line 564, but no explicit reference was found in the text == Unused Reference: 'Leec96' is defined on line 567, but no explicit reference was found in the text == Unused Reference: 'McMa96' is defined on line 575, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'CA9621' -- Possible downref: Non-RFC (?) normative reference: ref. 'ChZw95' -- Possible downref: Non-RFC (?) normative reference: ref. 'GuGl97' -- Possible downref: Non-RFC (?) normative reference: ref. 'MSST96' -- Possible downref: Non-RFC (?) normative reference: ref. 'Mont97' -- Possible downref: Non-RFC (?) normative reference: ref. 'MoGu96' -- Possible downref: Non-RFC (?) normative reference: ref. 'Orma96' ** Obsolete normative reference: RFC 2002 (ref. 'Per96a') (Obsoleted by RFC 3220) Summary: 9 errors (**), 0 flaws (~~), 10 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobile IP Working Group V. Gupta 2 INTERNET DRAFT SUN Microsystems 3 S. Glass 4 FTP Software 5 March 17, 1997 7 Firewall Traversal for Mobile IP: Guidelines for Firewalls 8 and Mobile IP entities 9 draft-ietf-mobileip-firewall-trav-00.txt 11 Status of this Memo 13 This document is a submission by the Mobile IP Working Group of the 14 Internet Engineering Task Force (IETF). Comments should be submitted 15 to the mobile-ip@SmallWorks.COM mailing list. 17 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 months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 To learn the current status of any Internet-Draft, please check the 28 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 29 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 Distribution of this memo is unlimited. 35 Abstract 37 The use of network security mechanisms such as ingress filtering, 38 firewall systems and private address spaces can disrupt normal 39 operation of Mobile IP [GuGl97]. This document outlines behavioral 40 guidelines for Mobile Nodes, their Home Agents and intervening 41 Firewalls. Compliance with these guidelines allows secure datagram 42 exchange between a mobile node and its home agent even across 43 firewalls, ingress filtering routers and distinct address spaces. To 44 its correspondent nodes, the mobile node appears to be connected to 45 its home network even while roaming on the general Internet. It 46 enjoys the same connectivity (modulo performance penalities) and, if 47 desired, privacy outside its protected domain as on the inside. 49 The guidelines described here solve a restricted, but still useful, 50 variant of the general firewall traversal problem for Mobile IP. 51 They make the following assumptions: (a) All intervening firewalls 52 belong to the mobile node's protected home domain and their existence 53 and relative placement, with respect to a mobile node's current 54 location, is known a priori. (b) Mobile nodes use co-located care-of 55 addresses (rather than Foreign Agents) when outside their protected 56 home domain. (c) Firewalls implement standard protocols for 57 authentication and encryption [RFCs 1825, 1826, 1827] but need not 58 understand Mobile IP message formats. (d) When private addresses are 59 used inside a Mobile node's home domain, the home agent is able to 60 distinguish between private and public addresses. 62 1. Introduction 64 The IETF Mobile IP protocol [Per96a] allows a mobile node (MN) to 65 continue sending and receiving IP datagrams using a fixed address, 66 its home address, even when it is no longer connected to its home 67 subnet. When a mobile node visits a foreign subnet, it obtains a 68 care-of address on that network and registers that address with its 69 home agent (HA), a special entity residing on its home subnet. The 70 home agent, in turn, intercepts datagrams meant for the mobile node 71 and tunnels them to the registered care-of address. Tunneling refers 72 to the process of enclosing the original datagram, as data, inside 73 another datagram with a new IP header [Per96b, Per96c]. The new 74 header carries the mobile node's care-of address in the destination 75 field. The care-of address may belong to a specially designated node 76 -- the foreign agent (FA) -- or may be a temporary address assigned 77 to one of the interfaces of the mobile node, e.g. through DHCP or 78 PPP. In the latter case, the mobile node is said to have a co-located 79 care-of address. This mode of operation obviates the need for 80 explicit mobility support, in the form of an FA, on the foreign 81 subnet, though local policy may still require a mobile node to 82 register through an FA. The recipient of a tunneled packet recovers 83 the original datagram before processing it further. 85 Mobile IP assumes that routing of unicast traffic is based solely on 86 the destination address. Many Internet routers now include other 87 considerations in their forwarding decision, e.g. in an effort to 88 guard against IP-spoofing attacks, source-filtering routers drop 89 datagrams that arrive on an interface inconsistent with their source 90 address [CA9621]. Such a router, if present on the foreign network, 91 will block all datagrams generated by a visiting mobile node carrying 92 its home address as source. A solution to this problem is to use a 93 reverse tunnel directed from the mobile node's care-of address to its 94 home agent [Mont97]. Under this arrangement, datagrams sent from MN 95 to a correspondent node (CN) now carry the care-of address (rather 96 than the home address) as source in the outermost IP header and pass 97 unchallenged through source-filtering routers to the mobile node's 98 home agent. The home agent strips the outer IP header and recovers 99 the original packet. From then on, the packet is forwarded as if the 100 mobile node were on its home subnet. 102 Additionally, many organizations use firewalls to protect their 103 networks from the general Internet. These firewalls impose additional 104 constraints, e.g. they may drop unsolicited datagrams from untrusted 105 external hosts [ChZw95]. Such a policy is enforced by carefully 106 screening the source and destination addresses, as well as ports, on 107 all transport level packets. For TCP packets, the firewall may also 108 monitor the ACK bit. In this situation, a mobile node's registration 109 requests are likely to be dropped by a firewall protecting its home 110 network. Note that source-filtering is not an issue here because 111 registration requests arrive with a topologically correct source 112 address - namely the current care-of address of the mobile node. 114 To complicate matters, organizations often hide the topology of their 115 internal network by using private addresses. These addresses are not 116 advertised to the general Internet. Such addresses include, but are 117 not restricted to, those defined in RFC 1918. The Internet's routing 118 fabric is unable to route packets to these addresses (resulting in 119 ICMP unreachables). To allow connections from the internal network to 120 the general Internet, application relays (also called application 121 gateways or proxies) are used. In a typical configuration, the 122 internal network is separated from the general Internet by a 123 "perimeter network" on which the firewall and proxies are located 124 [ChZw95] (see Figure 1). Hosts on the peripheral network use public 125 addresses, i.e. their addresses are advertised to the general 126 Internet. When a host on the internal network wishes to connect to 127 the Internet, two separate connections are set up: one between the 128 internal host and the proxy and another between the proxy and the 129 outside host. To the external host, the user at the other end appears 130 to be on the proxy host. 132 I 133 N 134 T 135 Firewall w/ [FW] E 136 application +---+ +------[R1]----------- R 137 proxies | | | Exterior/ N 138 | | | Access E 139 +-+-+ | Router T** 140 | | 141 ----+--------+------------+-- 142 | Perimeter Network** 143 Interior/ | 144 Choke [R2] 145 Router | 146 | * = Uses Private Addresses 147 Internal Network* ** = Uses Public Addresses 149 Figure 1: Screened-subnet firewall architecture. 151 The use of private addresses on firewall-protected networks poses an 152 additional challenge. A mobile node belonging to such a network can 153 not use its home address (a private address) to communicate directly 154 with correspondent nodes when it is outside the protected domain 155 since replies from correspondent nodes to the private address will 156 likely generate a "host unreachable" ICMP message. If, somehow, a 157 reverse tunnel can be established from the mobile node to its home 158 agent, the mobile node can continue using its private home address. 159 Datagrams generated by the mobile node using its home address will 160 appear to emerge from its home network and connections to external 161 hosts will still involve an intermediate proxy. 163 The presence of intermediate firewall(s) disrupts free flow of 164 packets from a mobile node on the outside to its home agent on the 165 inside. In its current form, this draft provides a conceptual 166 framework for achieving the required connectivity by mutual 167 cooperation between mobile nodes, their home agents and intervening 168 firewalls. As proposed IPSEC standards stabilize, later revisions 169 will incorporate greater details, e.g. message formats required to 170 establish dynamic security associations. 172 2. Solution Overview 174 In a security-conscious environment, there are two main obstacles 175 preventing free flow of datagrams between a mobile node and its home 176 agent. Both can be countered as described below: 178 (1) Firewalls: Their main purpose is enforcing controlled access 179 to the internal network. Firewalls can use IPSEC authentication 180 to establish the true identity of a datagram source. Their 181 security policy can be appropriately configured such that 182 packets between an authenticated mobile node and its home 183 agent are allowed to pass. 185 Additionally, IPSEC encryption can be used between the outermost 186 (perimeter) firewall and the mobile node to keep untrusted 187 hosts, outside the protected domain, from prying on a mobile 188 node's traffic. 190 (2) Ingress Filtering/private address spaces: We group these together 191 because both mechanisms are implemented by filtering routers. 192 These routers do not forward any datagram in which either: 193 (i) The source address is inconsistent with the interface that 194 the datagram arrives on, i.e. the source is topologically 195 incorrect. Note that an unknown source addresses can be 196 thought of as always being topologically incorrect. 198 (ii) The destination address is unknown. 200 These routers can be countered by using (possibly multiple levels 201 of) tunneling such that on the outermost IP header both the 202 source and destination addresses are known to the router and 203 the source address is topologically correct. 205 There are only two kinds of datagrams that need to pass back and 206 forth through these obstacles: 208 (a) Datagrams directed from a mobile node to its home agent which 209 include registration requests and reverse tunneled traffic. 210 In either case, the (outermost) IP header contains the mobile 211 node's care-of address (COA) as source and the home agent's 212 address (HA) as destination. 214 HA MN 215 (Inside) (Outside) 216 <------------- 217 +--------+--------+--------------+ 218 | s=COA | UDP | Registration | 219 | d=HA | header | request | 220 +--------+--------+--------------+ 222 +-------+----------------+-------------+ 223 | s=COA | s=MN home addr | Upper layer | 224 | d=HA | d=CN | protocol | 225 +-------+----------------+-------------+ 227 For the rest of this article we represent both of these as 228 follows and refer to it as an "inbound" packet. 230 <-------- 231 +-------+---------+ 232 | s=COA | MIP | s: IP source 233 | d=HA | payload | d: IP destination 234 +-------+---------+ 236 Figure 1: Inbound packet 238 (b) Datagrams directed from a home agent to a mobile node which 239 include registration replies and (forward) tunneled traffic. 240 In either case, the (outermost) IP header contains the home 241 agent's address as source and the mobile node's care-of address 242 as destination. 244 HA MN 245 (Inside) (Outside) 247 -------------> 248 +--------------+--------+-------+ 249 | Registration | UDP | s=HA | 250 | reply | header | d=COA | 251 +--------------+--------+-------+ 253 +-------------+----------------+-------+ 254 | Upper layer | s=CN | s=HA | 255 | protocol | d=MN home addr | d=COA | 256 +-------------+----------------+-------+ 258 For the rest of this article we represent both of these as 259 follows and refer to it as an "outbound" packet. 260 --------> 261 +---------+-------+ 262 | MIP | s=HA | 263 | payload | d=COA | 264 +---------+-------+ 266 Figure 2: Outbound packet 268 2.1 Assumptions 270 Our solution is based on the following assumptions: 272 (a) A mobile node can deduce its current location and the sequence 273 of firewalls that must be traversed to reach the home agent. The 274 exact mechanism for doing so is unspecified and will primarily 275 be decided by the local (home) security policy. It may be based 276 on manual pre-configuration, user input or a separate dynamic 277 firewall-discovery protocol. Such a discovery protocol is beyond 278 the scope of this document. For the rest of this article we label 279 the intervening firewalls FW1, FW2, ..FWn. Here, FW1 is the 280 perimeter firewall guarding the home domain from the Internet. 282 Protected Domain | Internet 283 (Inside) | (Outside) 284 | 285 HA | MN 286 | | 287 ---+---[FWn]-- ... --[FW2]--[FW1]--[R']-- ... --[R]--+-- 288 Home 289 network | 290 | 291 | 293 Figure 3: Security framework addressed by this document. 295 (b) All firewalls are IPSEC-aware and able to establish security 296 associations between themselves. 298 (c) FW1 is the only firewall whose address is advertised on the 299 general Internet, i.e. routers such as R and R' can route 300 packets to FW1 but are not aware of the addresses used 301 internally by FW2, ... FWn. In contrast, routers on the inside 302 are able to route packets for FW1 through FWn but are unaware 303 of any addresses used on the outside Internet. 305 (d) Any number of routers may exist between the MN (outside the 306 home domain), and HA (inside the home domain), any or all of 307 which implement source filtering, i.e. they drop packets on 308 which the source address is either unknown or inconsistent 309 with the interface on which the datagram is received. All 310 routers drop packets meant for unknown destinations. 312 (e) The Mobile Node is IPSEC aware and can acquire an appropriate 313 security association with each firewall such that packets 314 authenticated with that association are allowed to pass through. 315 This acquisition may either be based on manual configuration or 316 a key management and distribution protocol [MSST96, Orma96]. 318 (f) When MN is outside the protected domain, there are no firewalls 319 between it and FW1. 321 (g) Nodes within the protected domain trust each other, so, for 322 example, there is no need to encrypt a mobile node's traffic 323 on network links inside the protected domain. Note that 324 procedures defined in this document do not preclude end-to-end 325 or other forms of such encryption, should they be required by 326 an organization's security policy. 328 (h) A home agent belonging to the protected domain is able to 329 distinguish between addresses belonging to the protected domain 330 and those on the outside. Manual configuration is one option 331 (e.g. one could supply a list of "internal addresses" and all 332 others will be treated as "external). It is also possible to 333 introduce a new MN-HA extension in registration requests that 334 identifies the care-of address as being "external". This 335 essentially transfers the burden of identification from the HA 336 to the MN which may be justified since the latter can consult 337 the user if needed. 339 Note that assumptions (c) and (d) represent additional constraints 340 accommodated by our solution rather than solution requirements. 342 3. Inbound Datagram Processing 344 On realizing that it is outside its protected domain, a mobile node 345 first establishes a security association with the perimeter firewall. 346 IPSEC compliant key management protocols must allow separation 347 between an entity's true identity and its current IP address. This 348 distinction is crucial for a mobile node when it must send a packet 349 with its current care-of address past a firewall. If necessary, this 350 exchange may have to be repeated for each of the other firewalls in 351 sequence. To send an "inbound" packet to its home agent, the mobile 352 node prepends a tunnel mode authentication header for each firewall 353 starting with FWn. In addition, transport mode encryption may 354 (optionally) be inserted before prepending the authentication header 355 corresponding to FW1. If both authentication and encryption are 356 desired between the mobile node and FW1, the mobile node may choose a 357 single ESP transform that accommodates both. 359 <---------- 361 +-------+---------+-------+-----+...+------+-----+-------+---------+ 362 | s=COA | AH1+ESP | s=COA | AH2 | |s=COA | AHn | s=COA | MIP | 363 | d=FW1 | or ESP' | d=FW2 | | |d=FWn | | d=HA | payload | 364 +-------+---------+-------+-----+...+------+-----+-------+---------+ 366 Figure 4: An "inbound" packet as it leaves the mobile node. 368 The security policy on each firewall should be configured to 369 processes packets as follows: 371 (a) Look for an authentication header in the datagram (drop packet 372 if there isn't one) and look up the security association 373 referenced by the included Security Parameter Index [RFC1825, 374 1826]. 376 (b) Verify the authenticator (drop packet if authentication fails). 378 (c) Decrypt packet if ESP is present to recover a new datagram. 379 Note that steps (b) and (c) may need to be performed multiple 380 times if there are nested security headers for the same 381 destination. This process will eventually yield a datagram to 382 be forwarded beyond this firewall. 384 (d) If the last exposed datagram is likely to be dropped by filtering 385 routers before reaching its destination (e.g. because the source 386 address is unknown), then tunnel the packet of item (c) to the 387 next destination. Either a tunnel-mode IP Authentication Header 388 or plain IPinIP may be used since both are able to hide the 389 unknown source address (COA) from internal routers. 391 Actions (a)-(c) do not place any additional burden on IPSEC compliant 392 hosts. Action (d) is required only if the protected domain uses 393 private addresses and internal routers are configured to drop packets 394 in which the source or destination address is unknown or the source 395 is inconsistent with the interface on which the packet arrives. Even 396 so, action (d) may not be required at all firewalls, e.g. FWn can 397 skip this step if there are no filtering routers between FWn and HA. 399 As a result of these actions, the "inbound" datagram datagram looks 400 as follows as it travels towards the home agent. 402 <---------- 403 +-------+-----+-------+-----+- .. -+------+-----+-------+---------+ 404 | s=FW1 | AH' | s=COA | AH2 | |s=COA | AHn | s=COA | MIP | 405 | d=FW2 | | d=FW2 | | |d=FWn | | d=HA | payload | 406 +-------+-----+-------+-----+- .. -+------+-----+-------+---------+ 408 Figure 5: "Inbound" packet on its way from FW1 to FW2. 410 <---------- 411 +-------+------+-------+-----+- .. -+------+-----+-------+---------+ 412 | s=FW2 | AH'' | s=COA | AH3 | |s=COA | AHn | s=COA | MIP | 413 | d=FW3 | | d=FW3 | | |d=FWn | | d=HA | payload | 414 +-------+------+-------+-----+- .. -+------+-----+-------+---------+ 416 Figure 6: "Inbound" packet on its way from FW2 to FW3. 418 <---------- 419 +-------+----+-------+---------+ 420 | s=FWn | AH | s=COA | MIP | 421 | d=HA | | d=HA | payload | 422 +-------+----+-------+---------+ 424 Figure 7: "Inbound" packet on its way from FWn to HA. 426 The home agent recovers the original "inbound" packet (Figure 1) and 427 processes it as under normal Mobile IP (in the presence of reverse 428 tunneling [Mont97]). Note that depending on the kind of tunneling 429 used in step (d) and the placement of filtering routers, HA may need 430 to be IPSEC aware. 432 4. Outbound Datagram Processing 434 Since hosts inside the protected domain are trusted, non-perimeter 435 firewalls like FW2, ..., FWn may be configured to allow outgoing 436 packets to pass without any authentication. In this situation, 437 outbound datagram processing is quite simple. 439 The home agent creates an outbound packet as part of normal Mobile IP 440 operation. If the destination is recognized as being outside the 441 protected domain, the packet is explicitly directed at the perimeter 442 firewall FW1 either by using IPinIP tunneling or a tunnel mode 443 Authentication header. The former requires that FW1 be able to 444 decapsulate IPinIP datagrams while the latter requires HA to be IPSEC 445 aware. The resulting packet is shown in Figure 8. 447 ----------> 448 +---------+-------+-----+-------+ 449 | MIP | s=HA | AH' | s=HA | 450 | payload | d=COA | | d=FW1 | 451 +---------+-------+-----+-------+ 453 Figure 8: Outbound packet as it leaves HA (the authentication 454 header may not be needed). 456 Once this packet reaches the perimeter firewall FW1 successfully, the 457 original "outbound" datagram is recovered (either after IPSEC 458 processing or IPinIP decapsulation). 460 The security policy on FW1 must be configured as follows: If a 461 packet is to be forwarded to a destination for which a security 462 association exists, appropriate IPSEC headers must be added before 463 forwarding. 465 As a result of this policy, the "outbound" packet looks as shown in 466 Figure 9 as it leaves FW1 for the mobile node. 468 ----------> 469 +---------+-------+-----+----+-------+ 470 | MIP | s=HA | ESP | AH | s=FW1 | 471 | payload | d=COA | | | d=COA | 472 +---------+-------+-----+----+-------+ 474 Figure 9: "Outbound" packet on its way from FW1 to MN. 476 Intermediate routers such as R' and R'' see a topologically correct 477 source address and a routable (known) destination address. Once the 478 packet reaches the mobile node, the original "outbound" datagram is 479 recovered after IPSEC processing and processed as with normal Mobile 480 IP. 482 If FW2, ... FWn require source authentication even on outgoing 483 packets the process by which the outbound datagram reaches FW1 is no 484 longer as simple. In this situation the overall processing is similar 485 to that described for inbound datagrams but in the reverse direction. 487 ----------> 488 +---------+-------+-----+-------+-----+-------+- .. -+-----+-------+ 489 | MIP | s=HA | AH1 | s=HA | AH2 | s=HA | | AHn | s=HA | 490 | payload | d=COA | | d=FW1 | | d=FW2 | | | d=FWn | 491 +---------+-------+-----+-------+-----+-------+- .. -+-----+-------+ 493 Figure 10: An "outbound" packet as it leaves HA. 495 +---------+-------+-----+-------+-----+-------+ 496 | MIP | s=HA | AH1 | s=HA | AH2 | s=HA | 497 | payload | d=COA | | d=FW1 | | d=FW2 | 498 +---------+-------+-----+-------+-----+-------+ 500 Figure 11: An "outbound" packet on its way from FW3 to FW2. 502 +---------+-------+-----+-------+ 503 | MIP | s=HA | AH1 | s=HA | 504 | payload | d=COA | | d=FW1 | 505 +---------+-------+-----+-------+ 507 Figure 12: An "outbound" packet on its way from FW2 to FW1. 509 Note that intermediate firewalls do not need to prepend additional 510 headers before forwarding an outbound packet because already the 511 outermost source and destination are known to internal routers and 512 the source is topologically correct. 514 5. Closing Remarks 516 The mechanism outlined here allows Mobile IP operation even when a 517 mobile node roams outside its firewall-protected domain. This 518 functionality is achieved at the cost of introducing sub-optimal 519 "quadrangle" routing and additional header overhead. The amount of 520 header overhead depends on the number of intervening firewalls. In 521 most cases just a single firewall must be traversed. Preliminary 522 experiments on a SKIP-based implementation [MoGu96] suggest that the 523 performance penalty due to IPSEC processing and additional headers on 524 sustained throughput is roughly ten percent. Bursty traffic rates can 525 show significant variance because the use of Mobile IP and IPSEC 526 tunnels delays Path MTU discovery. Several packets may need to be 527 sent before the sender's path MTU estimate becomes small enough to 528 account for all intermediate tunnels, e.g. one ftp transfer of a 0.5 529 MB file attained a transfer rate of 7KB/s but after the path MTU had 530 been cached at the sender, the same file was transferred at a rate of 531 270 KB/s. 533 6. Security Considerations 535 This entire document discusses security considerations for mobile 536 nodes. Using the procedure outlined in this document, datagrams 537 between a mobile node and its home agent can pass freely through 538 firewalls protecting its home domain. In this situation, the mobile 539 node acts as an extension of the security perimeter surrounding its 540 home domain and must, therefore, share in the responsibility of 541 protecting it from outsiders. In the absence of user-specific 542 keying information, someone who steals the mobile node may also 543 gain access to the home network. 545 Acknowledgments 547 This document builds upon ideas previously introduced in [MoGu96] and 548 discussions at the "Secure firewall Traversal for Mobile IP" special 549 meeting held during the 37th IETF meeting. 551 References 553 [CA9621] CERT Advisory CA-96.21, "TCP SYN Flooding and IP 554 Spoofing Attacks", available at ftp://info.cert.org/pub/ 555 cert_advisories/CA-96.21.tcp_syn_flooding. 557 [ChZw95] D. B. Chapman and E. Zwicky, "Building Internet 558 Firewalls", O'Reilly & Associates, Inc., Sept. 1995. 560 [GuGl97] V. Gupta and S. Glass, "Firewall traversal for Mobile IP: 561 Goals and Requirements". Draft -- work in progress, January 1997. 564 [LGLK96] M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas and 565 L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996. 567 [Leec96] M. Leech, "Username/Password Authentication for SOCKS 568 V5", RFC 1929, March 1996. 570 [MSST96] D. Maughan, M. Schertler, M. Schneider and J. Turner, 571 "Internet Security Association and Key Management Protocol 572 (ISAKMP)", version 7, Draft -- work in progress. 575 [McMa96] P. McMahon, "GSS-API Authentication Method for SOCKS 576 Version 5", RFC 1961, June 1996. 578 [Mont97] G. Montenegro, "Bi-directional Tunneling for Mobile IP", 579 Draft -- work 580 in progress, Feb. 1997. 582 [MoGu96] G. Montenegro and V. Gupta, "Firewall Support for Mobile 583 IP". Draft , work 584 in progress, Sept. 1996. 586 [Orma96] H. Orman, "The Oakley Key Determination Protocol", 587 version 1, Draft -- work 588 in progress. 590 [Per96a] C. Perkins, "IP Mobility Support", RFC 2002. 592 [Per96b] C. Perkins, "IP Encapsulation within IP", RFC 2003. 594 [Per96c] C. Perkins, "Minimal Encapsulation within IP", RFC 2004. 596 Author's Address 598 Vipul Gupta 599 Sun Microsystems, Inc. 600 2550 Garcia Avenue 601 Mailstop UMPK 15-214 602 Mountain View, CA 94043-1100 604 Tel: (415) 786 3614 605 Fax: (415) 786 6445 607 EMail: vipul.gupta@eng.sun.com 609 Steven M. Glass 610 FTP Software 611 2 High Street 612 North Andover, MA 01949 614 Tel: (508) 685 4000 615 Fax: (508) 684 6105 617 EMail: glass@ftp.com