idnits 2.17.1 draft-ietf-mobileip-ft-req-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-25) 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 9 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 4. Security Considerations' ) ** 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 abstract seems to contain references ([MoGu96], [Per96b,Per96c], [LGLKKJ96], [RFC1826], [R1], [ChZw95], [R], [R2], [Per96a], [Per96b], [FW1], [Per96c], [McMa96], [FW2], [Leec96], [FW], [LGLK96], [CA9621], [RFCs1825,1826,1827], [Mont96]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 92 has weird spacing: '...irewall prote...' == Line 323 has weird spacing: '...ce many firew...' -- 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 (January 20, 1997) is 9957 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 section? 'Per96a' on line 416 looks like a reference -- Missing reference section? 'Per96b' on line 418 looks like a reference -- Missing reference section? 'Per96c' on line 420 looks like a reference -- Missing reference section? 'CA9621' on line 392 looks like a reference -- Missing reference section? 'Mont96' on line 408 looks like a reference -- Missing reference section? 'ChZw95' on line 396 looks like a reference -- Missing reference section? 'FW' on line 118 looks like a reference -- Missing reference section? 'R2' on line 127 looks like a reference -- Missing reference section? 'R' on line 276 looks like a reference -- Missing reference section? 'FW2' on line 279 looks like a reference -- Missing reference section? 'LGLKKJ96' on line 353 looks like a reference -- Missing reference section? 'MoGu96' on line 412 looks like a reference -- Missing reference section? 'LGLK96' on line 399 looks like a reference -- Missing reference section? 'Leec96' on line 402 looks like a reference -- Missing reference section? 'McMa96' on line 405 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 17 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 January 20, 1997 7 Firewall Traversal for Mobile IP: Goals and Requirements 8 draft-ietf-mobileip-ft-req-00.txt 10 Status of this Memo 12 This document is a submission by the Mobile IP Working Group of the 13 Internet Engineering Task Force (IETF). Comments should be submitted 14 to the mobile-ip@SmallWorks.COM mailing list. 16 Distribution of this memo is unlimited. 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 To learn the current status of any Internet-Draft, please check the 29 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 30 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 This document discusses problems arising out of the use of Mobile IP 37 in a security conscious Internet and presents a list of solution 38 requirements deemed important. These problems may need to be resolved 39 in several stages. A priority order in which these problems should be 40 solved is also proposed. 42 All firewalls are assumed to implement standard mechanisms [RFCs 43 1825,1826,1827] for authentication and encryption proposed by the 44 IPSec working group of the IETF. 46 1. Introduction 48 The IETF Mobile IP protocol [Per96a] allows a mobile node (MN) to 49 continue sending and receiving IP datagrams using a fixed address, 50 its home address, even when it is no longer connected to its home 51 subnet. When a mobile node visits a foreign subnet, it obtains a 52 care-of address on that network and registers that address with its 53 home agent (HA), a special entity residing on its home subnet. The 54 home agent, in turn, intercepts datagrams meant for the mobile node 55 and tunnels them to the registered care-of address. Tunneling refers 56 to the process of enclosing the original datagram, as data, inside 57 another datagram with a new IP header [Per96b, Per96c]. The new 58 header carries the mobile node's care-of address in the destination 59 field. The care-of address may belong to a specially designated node 60 -- the foreign agent (FA) -- or may be a temporary address assigned 61 to one of the interfaces of the mobile node, e.g. through DHCP or 62 PPP. In the latter case, the mobile node is said to have a co-located 63 care-of address. This mode of operation obviates the need for 64 explicit mobility support, in the form of a FA, on the foreign 65 subnet. The recipient of a tunneled packet recovers the original 66 datagram before processing it further. 68 Mobile IP assumes that routing of unicast traffic is based solely on 69 the destination address. Many Internet routers now include other 70 considerations in their forwarding decision, e.g. in an effort to 71 guard against IP-spoofing attacks, source-filtering routers drop 72 datagrams that arrive on an interface inconsistent with their source 73 address [CA9621]. Such a router, if present on the foreign network, 74 will block all datagrams generated by a visiting mobile node carrying 75 its home address as source. A solution to this problem is to use a 76 reverse tunnel directed from the mobile node's care-of address to its 77 home agent [Mont96]. Under this arrangement, datagrams sent from MN 78 to a correspondent node (CN) now carry the care-of address (rather 79 than the home address) as source in the outermost IP header and pass 80 unchallenged through source-filtering routers to the mobile node's 81 home agent. The home agent strips the outer IP header and recovers 82 the original packet. From then on, the packet is forwarded as if the 83 mobile node were on its home subnet. 85 Additionally, many organizations use firewalls to protect their 86 networks from the general Internet. These firewalls impose additional 87 constraints, e.g. they may drop unsolicited datagrams from untrusted 88 external hosts [ChZw95]. Such a policy is enforced by carefully 89 screening the source and destination addresses, as well as ports, on 90 all transport level packets. For TCP packets, the firewall may also 91 monitor the ACK bit. In this situation, a mobile node's registration 92 requests are likely to be dropped by a firewall protecting its home 93 network. Note that source-filtering is not an issue here because 94 registration requests arrive with a topologically correct source 95 address - namely the current care-of address of the mobile node. 97 To complicate matters, organizations often hide the topology of their 98 internal network by using private addresses. These addresses are not 99 advertised to the general Internet. Such addresses include, but are 100 not restricted to, those defined in RFC 1918. The Internet's routing 101 fabric is unable to route packets to these addresses (resulting in 102 ICMP unreachables). To allow connections from the internal network to 103 the general Internet, application relays (also called application 104 gateways or proxies) are used. In a typical configuration, the 105 internal network is separated from the general Internet by a 106 "perimeter network" on which the firewall and proxies are located 107 [ChZw95] (see Figure 1). Hosts on the peripheral network use public 108 addresses, i.e. their addresses are advertised to the general 109 Internet. When a host on the internal network wishes to connect to 110 the Internet, two separate connections are set up: one between the 111 internal host and the proxy and another between the proxy and the 112 outside host. To the external host, the user at the other end appears 113 to be on the proxy host. 115 I 116 N 117 T 118 Firewall w/ [FW] E 119 application +---+ +------[R1]----------- R 120 proxies | | | Exterior/ N 121 | | | Access E 122 +-+-+ | Router T** 123 | | 124 ----+--------+------------+-- 125 | Perimeter Network** 126 Interior/ | 127 Choke [R2] 128 Router | 129 | * = Uses Private Addresses 130 Internal Network* ** = Uses Public Addresses 132 Figure 1: Screened-subnet firewall architecture. 134 The use of private addresses on firewall-protected networks poses an 135 additional challenge. A mobile node belonging to such a network can 136 not use its home address (a private address) to communicate directly 137 with correspondent nodes when it is outside the protected domain as 138 replies from correspondent nodes to the private address are likely to 139 generate a "host unreachable" ICMP message. If, somehow, a reverse 140 tunnel can be established from the mobile node to its home agent, the 141 mobile node can continue using its private home address. Datagrams 142 generated by the mobile node using its home address will appear to 143 emerge from its home network and connections to external hosts will 144 still involve an intermediate proxy. 146 The presence of intermediate firewall(s) disrupts free flow of 147 packets from a mobile node on the outside to its home agent on the 148 inside. Appropriate security mechanisms are required to successfully 149 traverse these firewalls to achieve required connectivity. 151 2. Proposed Solution Framework 153 The firewall traversal problem in its most general form (e.g. 154 multiple firewalls under different administrative controls with 155 limited mutual trust) does not lend itself directly to an easy 156 solution. Therefore, it is reasonable to try solving this problem in 157 several phases starting with the simplest (and still useful) variant 158 described below. 160 Consider Mobile IP operation for a mobile node (e.g. a notebook 161 computer belonging to a corporate employee) when it is moved outside 162 its firewall protected home domain into the general internet (e.g. a 163 university or ISP environment) which imposes no access restrictions 164 other than network ingress filtering. In order to reach it's home 165 subnet, packets from a mobile node may need to traverse Multiple 166 firewalls. However, they all belong to the mobile node's protected 167 domain and their existence and relative placement (with respect to a 168 mobile node's current location) is known apriori. 170 The simplified problem does not address the case when some of the 171 intermediate firewalls belong to administrative domains other than 172 the mobile node's, nor does it address the case when a correspondent 173 node (outside the mobile node's protected domain) is itself protected 174 by a firewall. This latter issue, however, is orthogonal to mobility 175 since the problem is unchanged even when the mobile node is at home. 177 A reasonable aim is to provide a mobile node with the same 178 connectivity (modulo performance penalties) outside its protected 179 network that it enjoys at home. Additionally, it should be possible 180 to encrypt all traffic to/from the mobile node in an effort to 181 preserve the level of privacy that a mobile node enjoys at home. 183 The problem of dynamically discovering intermediate firewalls should 184 be treated separately at a later time (see item (e) in Section 3). 186 3. Issues to Consider 187 This section discusses several important issues that should be 188 considered while solving the firewall traversal problem for Mobile 189 IP. 191 (a) Security processing of registrations requests sent on behalf of 192 (or by) a Mobile node must not depend on its reachability at its home 193 address. A violation of this assumption will create a circular 194 dependency since a Mobile Node's reachability at its home address is 195 at best uncertain until the registration request gets past the 196 firewall. 198 Solutions that involve a separate phase in which the mobile node 199 negotiates access parameters with the firewall should attempt to 200 minimize the number of round-trip delays. 202 (b) Colocating Home Agent and Firewall functionality on the same host 203 considerably simplifies the firewall traversal problem. However, 204 doing so effectively restricts the number of networks with mobility 205 support. For example, in Figure 1, hosts on the perimeter network 206 would enjoy mobility support but none on the internal network. 207 Therefore, a solution must not require Home Agent and Firewall 208 functionality to be colocated. 210 (c) It is possible to configure intermediate firewalls such that UDP 211 packets sent to port 434 of "well known" Home Agents are allowed to 212 pass through without any IPSEC processing. This solves the firewall 213 traversal problem for registration requests but not for reverse 214 tunneled traffic. This approach also involves administrative 215 maintenance of the list of "well known" home agents and assumes that 216 all processes running on port 434 of these hosts are trusted. 217 Ideally, a firewall should decide to let in a packet based solely on 218 its IPSEC characteristics (e.g. is it authenticated, encrypted or 219 both) rather than any higher level information. A solution that does 220 not require Firewalls to understand Mobile IP is preferred. 222 (d) If firewalls are unable to parse Mobile IP registrations, 223 complications arise when the mobile node uses a care-of address 224 belonging to a Foreign Agent (rather than a co-located address). The 225 main problem is that even if the Foreign Agent (FA) implements IPSEC 226 and is able to establish a security association with the Mobile 227 Node's firewall (FW), it can not win the Firewall's trust. A valid 228 authentication header on a packet generated by a FA only tells a FW 229 that the packet was indeed generated by the FA. However, the FW has 230 no way of knowing whether it was generated on behalf of a trusted 231 mobile node. The FA may have generated this packet on its own and the 232 FW may not trust the FA. (Obviously, a mobile node must not divulge 233 the secret it shares with the FW to its FA just so registrations can 234 go through.) 235 Consider the case of a FA relaying a mobile node's (MN) registration 236 request. For this request to pass through FW, it must have an 237 authenticator based on a security association between FW and MN. We 238 could have MN precompute an "IP Authentication Header (AH)" [RFC 239 1826] authenticator which, if inserted by the FA in the relayed 240 datagram, will pass authentication at the firewall. The tricky part 241 here is that the AH authenticator includes the Identifier field of 242 the immediately preceding IP header and there is no easy way for MN 243 to predetermine its value generated by FA for the relayed request. 245 There is a questionable solution. The MN could generate its own 246 Identifier and convey it to the FA with the understanding that the FA 247 must use this value in the IP header of the relayed request. This 248 value, the AH authenticator and the firewall address etc could all be 249 bundled in a new MN to FA registration extension. With this 250 mechanism, the FA need not even be an IPSEC node. For the case we are 251 considering (FA belongs to a trusting university/ISP environment), it 252 is quite likely that none of the mobility agents are capable of IPSEC 253 processing. However, this approach gets more convoluted when a 254 mobile node must separately authenticate itself to multiple firewalls 255 (see item (e) below). 257 In contrast, Mobile nodes operating with a co-located care-of address 258 are a lot simpler to deal with. In this case, requests seen by the 259 firewall are generated directly by a mobile node for which a trusted 260 relationship already exists. 262 Solving the firewall traversal problem for mobile nodes registered 263 through foreign agents may perhaps be postponed to a later phase. 265 (e) When multiple firewalls within the home domain must be traversed, 266 each firewall may require a different level of trust, e.g. a large 267 corporation may have one firewall guarding its connection to the 268 Internet and another guarding the finance department network from the 269 rest of the company (Figure 2). Amongst all the employees that are 270 allowed access through the main firewall, only a small subset may be 271 allowed in through the finance firewall. 273 [FW1]-------------------- INTERNET 274 | 275 | 276 [R] 277 / \ 278 / \ 279 {Engineering} [FW2] 280 | 281 {Finance} 283 Figure 2: Nested firewalls requiring different levels 284 of trust. 286 In this scenario, a mobile node on the outside that wishes to 287 communicate with its home agent in the finance network must be able 288 to explicitly (separately) authenticate itself to each intervening 289 firewall. 291 (f) Many organizations use firewalls along with private addresses. 292 If private addresses are used by the Mobile node's home domain, these 293 addresses must not be exposed to routers on the outside. This may 294 require additional tunneling e.g. a tunnel from the care-of address 295 to at least the (outer most) Firewall may be needed to hide/bury the 296 Home Agent's 'private' address as destination on reverse tunneled 297 traffic. 299 The problem is complicated when routers within the home domain are 300 (by design) kept unaware of external destinations. Analogously, extra 301 tunneling may be needed even on the inside, e.g. in Figure 2, a 302 tunnel may be needed between a home agent on the finance network and 303 (the proxy) FW1 to hide the 'external' care-of destination address on 304 encapsulated packets meant for a mobile node roaming outside. 306 So far we've only considered the problem of exposing addresses as 307 destinations to routers that are unaware of them. To make things 308 worse, routers are likely to disallow unknown addresses even in the 309 source field of the datagrams they forward. For example, internal 310 routers may disallow an external care-of address as source on reverse 311 tunneled traffic. This may necessitate additional tunneling within 312 the protected domain even for incoming packets e.g. an external 313 care-of address may need to be hidden from R (Figure 2) on reverse- 314 tunneled traffic. Similarly, extra tunneling may be required to hide 315 internal addresses (e.g. home agent's) from appearing as source on 316 outgoing packets routed by external routers. 318 Due to the widespread use of private addresses, solutions to the 319 firewall traversal problem must accommodate private addresses. 321 (g) Proposals for dynamic discovery of intervening firewalls must not 322 rely on firewalls generating ICMP "administratively unreachable" 323 messages since many firewalls are designed to hide as much of their 324 presence as possible. 326 According to Chapman and Zwicky [ChZw95, Chap 6, Section titled 327 "Returning ICMP Error Codes"]: 329 "Returning the new 'host administratively unreachable' or the fact 330 that there is a packet filtering system at your site, which you may 331 or may not want to do. These codes may also cause excessive reactions 332 in faulty IP implementations." 334 "If your router returns an ICMP error code for every packet that 335 violates your filtering policy, you're also giving an attacker a way 336 to probe your filtering system. By observing which packets evoke an 337 ICMP error response, attackers can discover what types of packets do 338 and don't violate your policy. You should not give this information 339 away, because it greatly simplifies the attacker's job. The attacker 340 knows that packets that don't get the ICMP error are going somewhere, 341 and can concentrate on those protocols, where you actually have 342 vulnerabilities. You'd rather that the attacker spent plenty of time 343 sending you packets you happily throw away." 345 "All in all, the safest thing to do seems to be to drop packets 346 without returning any ICMP error codes. If your router offers 347 flexibility, it might make sense to configure it to return ICMP error 348 codes to internal systems (which would like to know immediately that 349 something is going to fail, rather than wait for a timeout), but not 350 to external systems ... " 352 (h) The Authenticated Firewall Traversal (AFT) working group of the 353 IETF has developed the SOCKS protocol [LGLKKJ96] as a general 354 mechanism for firewall traversal. The protocol is conceptually a 355 "shim-layer" between the application layer and the transport layer, 356 and as such does not provide network layer gateway services, such as 357 forwarding of ICMP (or even IPinIP) messages. IPinIP messages (from 358 HA to MN) would have to be encapsulated within UDP or TCP in order to 359 use SOCKS. Beside the resulting inefficiency, there are other 360 concerns regarding its appropriateness for the problem at hand 361 [MoGu96]. 363 The SOCKS solution requires that the mobile node -- or another node 364 on its behalf -- establish a TCP session to exchange UDP traffic with 365 each firewall. SOCKS incurs a minimum delay of four round-trips (six 366 with GSS-API) before a client is able to pass data through the 367 firewall. It seems unlikely that this negotiation will be efficient 368 enough to allow a mobile node to change its point of attachment as 369 often as once per second, as specified in [Per96a]. 371 Given the likelihood that most firewalls in the future will be based 372 on IPSEC mechanisms, it is imperative that a solution be based on 373 standard IPSEC protocols, e.g. ISAKMP/Oakley. 375 4. Security Considerations 377 Mobile IP assumes that routing of unicast datagrams is based solely 378 on the destination address. Packet filtering routers and Firewalls 379 include additional considerations in their routing decisions. Special 380 mechanisms are needed to ensure Mobile IP operation in the presence 381 of these and related (e.g. use of private addresses) security 382 measures currently becoming popular on the Internet. 384 Acknowledgments 386 Ideas in this document have benefited from discussions with at least 387 the following people: Gabriel Montenegro, Rich Skrenta and Tsutomo 388 Shimomura. 390 References 392 [CA9621] CERT Advisory CA-96.21, "TCP SYN Flooding and IP 393 Spoofing Attacks", available at ftp://info.cert.org/pub/ 394 cert_advisories/CA-96.21.tcp_syn_flooding. 396 [ChZw95] D. B. Chapman and E. Zwicky, "Building Internet 397 Firewalls", O'Reilly & Associates, Inc., Sept. 1995. 399 [LGLK96] M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas and 400 L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996. 402 [Leec96] M. Leech, "Username/Password Authentication for SOCKS 403 V5", RFC 1929, March 1996. 405 [McMa96] P. McMahon, "GSS-API Authentication Method for SOCKS 406 Version 5", RFC 1961, June 1996. 408 [Mont96] G. Montenegro, "Bi-directional Tunneling for Mobile IP", 409 Draft -- work in progress, 410 Sept. 1996. 412 [MoGu96] G. Montenegro and V. Gupta, "Firewall Support for Mobile 413 IP". Draft , work 414 in progress, Sept. 1996. 416 [Per96a] C. Perkins, "IP Mobility Support", RFC 2002. 418 [Per96b] C. Perkins, "IP Encapsulation within IP", RFC 2003. 420 [Per96c] C. Perkins, "Minimal Encapsulation within IP", RFC 2004. 422 Author's Address 424 Vipul Gupta 425 Sun Microsystems, Inc. 426 2550 Garcia Avenue 427 Mailstop UMPK 15-214 428 Mountain View, CA 94043-1100 430 Tel: (415) 786 3614 431 Fax: (415) 786 6445 433 EMail: vipul.gupta@eng.sun.com 435 Steven M. Glass 436 FTP Software 437 2 High Street 438 North Andover, MA 01949 440 Tel: (508) 685 4000 441 Fax: (508) 684 6105 443 EMail: glass@ftp.com