Internet Info 1997 December

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_j_p / draft-ietf-mobileip-firewall-trav-00.txt < prev next >

Wrap

Text File | 1997-03-27 | 33KB | 848 lines

Mobile IP Working Group V. Gupta INTERNET DRAFT SUN Microsystems S. Glass FTP Software March 17, 1997 Firewall Traversal for Mobile IP: Guidelines for Firewalls and Mobile IP entities draft-ietf-mobileip-firewall-trav-00.txt Status of this Memo This document is a submission by the Mobile IP Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the mobile-ip@SmallWorks.COM mailing list. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. Abstract The use of network security mechanisms such as ingress filtering, firewall systems and private address spaces can disrupt normal operation of Mobile IP [GuGl97]. This document outlines behavioral guidelines for Mobile Nodes, their Home Agents and intervening Firewalls. Compliance with these guidelines allows secure datagram exchange between a mobile node and its home agent even across firewalls, ingress filtering routers and distinct address spaces. To its correspondent nodes, the mobile node appears to be connected to its home network even while roaming on the general Internet. It enjoys the same connectivity (modulo performance penalities) and, if Gupta & Glass Expires September 17, 1997 [Page 1] INTERNET DRAFT Firewall Traversal for Mobile IP March 1997 desired, privacy outside its protected domain as on the inside. The guidelines described here solve a restricted, but still useful, variant of the general firewall traversal problem for Mobile IP. They make the following assumptions: (a) All intervening firewalls belong to the mobile node's protected home domain and their existence and relative placement, with respect to a mobile node's current location, is known a priori. (b) Mobile nodes use co-located care-of addresses (rather than Foreign Agents) when outside their protected home domain. (c) Firewalls implement standard protocols for authentication and encryption [RFCs 1825, 1826, 1827] but need not understand Mobile IP message formats. (d) When private addresses are used inside a Mobile node's home domain, the home agent is able to distinguish between private and public addresses. 1. Introduction The IETF Mobile IP protocol [Per96a] allows a mobile node (MN) to continue sending and receiving IP datagrams using a fixed address, its home address, even when it is no longer connected to its home subnet. When a mobile node visits a foreign subnet, it obtains a care-of address on that network and registers that address with its home agent (HA), a special entity residing on its home subnet. The home agent, in turn, intercepts datagrams meant for the mobile node and tunnels them to the registered care-of address. Tunneling refers to the process of enclosing the original datagram, as data, inside another datagram with a new IP header [Per96b, Per96c]. The new header carries the mobile node's care-of address in the destination field. The care-of address may belong to a specially designated node -- the foreign agent (FA) -- or may be a temporary address assigned to one of the interfaces of the mobile node, e.g. through DHCP or PPP. In the latter case, the mobile node is said to have a co-located care-of address. This mode of operation obviates the need for explicit mobility support, in the form of an FA, on the foreign subnet, though local policy may still require a mobile node to register through an FA. The recipient of a tunneled packet recovers the original datagram before processing it further. Mobile IP assumes that routing of unicast traffic is based solely on the destination address. Many Internet routers now include other considerations in their forwarding decision, e.g. in an effort to guard against IP-spoofing attacks, source-filtering routers drop datagrams that arrive on an interface inconsistent with their source address [CA9621]. Such a router, if present on the foreign network, will block all datagrams generated by a visiting mobile node carrying its home address as source. A solution to this problem is to use a reverse tunnel directed from the mobile node's care-of address to its home agent [Mont97]. Under this arrangement, datagrams sent from MN Gupta & Glass Expires September 17, 1997 [Page 2] INTERNET DRAFT Firewall Traversal for Mobile IP March 1997 to a correspondent node (CN) now carry the care-of address (rather than the home address) as source in the outermost IP header and pass unchallenged through source-filtering routers to the mobile node's home agent. The home agent strips the outer IP header and recovers the original packet. From then on, the packet is forwarded as if the mobile node were on its home subnet. Additionally, many organizations use firewalls to protect their networks from the general Internet. These firewalls impose additional constraints, e.g. they may drop unsolicited datagrams from untrusted external hosts [ChZw95]. Such a policy is enforced by carefully screening the source and destination addresses, as well as ports, on all transport level packets. For TCP packets, the firewall may also monitor the ACK bit. In this situation, a mobile node's registration requests are likely to be dropped by a firewall protecting its home network. Note that source-filtering is not an issue here because registration requests arrive with a topologically correct source address - namely the current care-of address of the mobile node. To complicate matters, organizations often hide the topology of their internal network by using private addresses. These addresses are not advertised to the general Internet. Such addresses include, but are not restricted to, those defined in RFC 1918. The Internet's routing fabric is unable to route packets to these addresses (resulting in ICMP unreachables). To allow connections from the internal network to the general Internet, application relays (also called application gateways or proxies) are used. In a typical configuration, the internal network is separated from the general Internet by a "perimeter network" on which the firewall and proxies are located [ChZw95] (see Figure 1). Hosts on the peripheral network use public addresses, i.e. their addresses are advertised to the general Internet. When a host on the internal network wishes to connect to the Internet, two separate connections are set up: one between the internal host and the proxy and another between the proxy and the outside host. To the external host, the user at the other end appears to be on the proxy host. Gupta & Glass Expires September 17, 1997 [Page 3] INTERNET DRAFT Firewall Traversal for Mobile IP March 1997 I N T Firewall w/ [FW] E application +---+ +------[R1]----------- R proxies | | | Exterior/ N | | | Access E +-+-+ | Router T** | | ----+--------+------------+-- | Perimeter Network** Interior/ | Choke [R2] Router | | * = Uses Private Addresses Internal Network* ** = Uses Public Addresses Figure 1: Screened-subnet firewall architecture. The use of private addresses on firewall-protected networks poses an additional challenge. A mobile node belonging to such a network can not use its home address (a private address) to communicate directly with correspondent nodes when it is outside the protected domain since replies from correspondent nodes to the private address will likely generate a "host unreachable" ICMP message. If, somehow, a reverse tunnel can be established from the mobile node to its home agent, the mobile node can continue using its private home address. Datagrams generated by the mobile node using its home address will appear to emerge from its home network and connections to external hosts will still involve an intermediate proxy. The presence of intermediate firewall(s) disrupts free flow of packets from a mobile node on the outside to its home agent on the inside. In its current form, this draft provides a conceptual framework for achieving the required connectivity by mutual cooperation between mobile nodes, their home agents and intervening firewalls. As proposed IPSEC standards stabilize, later revisions will incorporate greater details, e.g. message formats required to establish dynamic security associations. 2. Solution Overview In a security-conscious environment, there are two main obstacles preventing free flow of datagrams between a mobile node and its home agent. Both can be countered as described below: Gupta & Glass Expires September 17, 1997 [Page 4] INTERNET DRAFT Firewall Traversal for Mobile IP March 1997 (1) Firewalls: Their main purpose is enforcing controlled access to the internal network. Firewalls can use IPSEC authentication to establish the true identity of a datagram source. Their security policy can be appropriately configured such that packets between an authenticated mobile node and its home agent are allowed to pass. Additionally, IPSEC encryption can be used between the outermost (perimeter) firewall and the mobile node to keep untrusted hosts, outside the protected domain, from prying on a mobile node's traffic. (2) Ingress Filtering/private address spaces: We group these together because both mechanisms are implemented by filtering routers. These routers do not forward any datagram in which either: (i) The source address is inconsistent with the interface that the datagram arrives on, i.e. the source is topologically incorrect. Note that an unknown source addresses can be thought of as always being topologically incorrect. (ii) The destination address is unknown. These routers can be countered by using (possibly multiple levels of) tunneling such that on the outermost IP header both the source and destination addresses are known to the router and the source address is topologically correct. There are only two kinds of datagrams that need to pass back and forth through these obstacles: Gupta & Glass Expires September 17, 1997 [Page 5] INTERNET DRAFT Firewall Traversal for Mobile IP March 1997 (a) Datagrams directed from a mobile node to its home agent which include registration requests and reverse tunneled traffic. In either case, the (outermost) IP header contains the mobile node's care-of address (COA) as source and the home agent's address (HA) as destination. HA MN (Inside) (Outside) <------------- +--------+--------+--------------+ | s=COA | UDP | Registration | | d=HA | header | request | +--------+--------+--------------+ +-------+----------------+-------------+ | s=COA | s=MN home addr | Upper layer | | d=HA | d=CN | protocol | +-------+----------------+-------------+ For the rest of this article we represent both of these as follows and refer to it as an "inbound" packet. <-------- +-------+---------+ | s=COA | MIP | s: IP source | d=HA | payload | d: IP destination +-------+---------+ Figure 1: Inbound packet Gupta & Glass Expires September 17, 1997 [Page 6] INTERNET DRAFT Firewall Traversal for Mobile IP March 1997 (b) Datagrams directed from a home agent to a mobile node which include registration replies and (forward) tunneled traffic. In either case, the (outermost) IP header contains the home agent's address as source and the mobile node's care-of address as destination. HA MN (Inside) (Outside) -------------> +--------------+--------+-------+ | Registration | UDP | s=HA | | reply | header | d=COA | +--------------+--------+-------+ +-------------+----------------+-------+ | Upper layer | s=CN | s=HA | | protocol | d=MN home addr | d=COA | +-------------+----------------+-------+ For the rest of this article we represent both of these as follows and refer to it as an "outbound" packet. --------> +---------+-------+ | MIP | s=HA | | payload | d=COA | +---------+-------+ Figure 2: Outbound packet 2.1 Assumptions Our solution is based on the following assumptions: (a) A mobile node can deduce its current location and the sequence of firewalls that must be traversed to reach the home agent. The exact mechanism for doing so is unspecified and will primarily be decided by the local (home) security policy. It may be based on manual pre-configuration, user input or a separate dynamic firewall-discovery protocol. Such a discovery protocol is beyond the scope of this document. For the rest of this article we label the intervening firewalls FW1, FW2, ..FWn. Here, FW1 is the perimeter firewall guarding the home domain from the Internet. Gupta & Glass Expires September 17, 1997 [Page 7] INTERNET DRAFT Firewall Traversal for Mobile IP March 1997 Protected Domain | Internet (Inside) | (Outside) | HA | MN | | ---+---[FWn]-- ... --[FW2]--[FW1]--[R']-- ... --[R]--+-- Home network | | | Figure 3: Security framework addressed by this document. (b) All firewalls are IPSEC-aware and able to establish security associations between themselves. (c) FW1 is the only firewall whose address is advertised on the general Internet, i.e. routers such as R and R' can route packets to FW1 but are not aware of the addresses used internally by FW2, ... FWn. In contrast, routers on the inside are able to route packets for FW1 through FWn but are unaware of any addresses used on the outside Internet. (d) Any number of routers may exist between the MN (outside the home domain), and HA (inside the home domain), any or all of which implement source filtering, i.e. they drop packets on which the source address is either unknown or inconsistent with the interface on which the datagram is received. All routers drop packets meant for unknown destinations. (e) The Mobile Node is IPSEC aware and can acquire an appropriate security association with each firewall such that packets authenticated with that association are allowed to pass through. This acquisition may either be based on manual configuration or a key management and distribution protocol [MSST96, Orma96]. (f) When MN is outside the protected domain, there are no firewalls between it and FW1. (g) Nodes within the protected domain trust each other, so, for example, there is no need to encrypt a mobile node's traffic on network links inside the protected domain. Note that procedures defined in this document do not preclude end-to-end or other forms of such encryption, should they be required by an organization's security policy. (h) A home agent belonging to the protected domain is able to distinguish between addresses belonging to the protected domain Gupta & Glass Expires September 17, 1997 [Page 8] INTERNET DRAFT Firewall Traversal for Mobile IP March 1997 and those on the outside. Manual configuration is one option (e.g. one could supply a list of "internal addresses" and all others will be treated as "external). It is also possible to introduce a new MN-HA extension in registration requests that identifies the care-of address as being "external". This essentially transfers the burden of identification from the HA to the MN which may be justified since the latter can consult the user if needed. Note that assumptions (c) and (d) represent additional constraints accommodated by our solution rather than solution requirements. 3. Inbound Datagram Processing On realizing that it is outside its protected domain, a mobile node first establishes a security association with the perimeter firewall. IPSEC compliant key management protocols must allow separation between an entity's true identity and its current IP address. This distinction is crucial for a mobile node when it must send a packet with its current care-of address past a firewall. If necessary, this exchange may have to be repeated for each of the other firewalls in sequence. To send an "inbound" packet to its home agent, the mobile node prepends a tunnel mode authentication header for each firewall starting with FWn. In addition, transport mode encryption may (optionally) be inserted before prepending the authentication header corresponding to FW1. If both authentication and encryption are desired between the mobile node and FW1, the mobile node may choose a single ESP transform that accommodates both. <---------- +-------+---------+-------+-----+...+------+-----+-------+---------+ | s=COA | AH1+ESP | s=COA | AH2 | |s=COA | AHn | s=COA | MIP | | d=FW1 | or ESP' | d=FW2 | | |d=FWn | | d=HA | payload | +-------+---------+-------+-----+...+------+-----+-------+---------+ Figure 4: An "inbound" packet as it leaves the mobile node. The security policy on each firewall should be configured to processes packets as follows: (a) Look for an authentication header in the datagram (drop packet if there isn't one) and look up the security association referenced by the included Security Parameter Index [RFC1825, 1826]. (b) Verify the authenticator (drop packet if authentication fails). Gupta & Glass Expires September 17, 1997 [Page 9] INTERNET DRAFT Firewall Traversal for Mobile IP March 1997 (c) Decrypt packet if ESP is present to recover a new datagram. Note that steps (b) and (c) may need to be performed multiple times if there are nested security headers for the same destination. This process will eventually yield a datagram to be forwarded beyond this firewall. (d) If the last exposed datagram is likely to be dropped by filtering routers before reaching its destination (e.g. because the source address is unknown), then tunnel the packet of item (c) to the next destination. Either a tunnel-mode IP Authentication Header or plain IPinIP may be used since both are able to hide the unknown source address (COA) from internal routers. Actions (a)-(c) do not place any additional burden on IPSEC compliant hosts. Action (d) is required only if the protected domain uses private addresses and internal routers are configured to drop packets in which the source or destination address is unknown or the source is inconsistent with the interface on which the packet arrives. Even so, action (d) may not be required at all firewalls, e.g. FWn can skip this step if there are no filtering routers between FWn and HA. As a result of these actions, the "inbound" datagram datagram looks as follows as it travels towards the home agent. <---------- +-------+-----+-------+-----+- .. -+------+-----+-------+---------+ | s=FW1 | AH' | s=COA | AH2 | |s=COA | AHn | s=COA | MIP | | d=FW2 | | d=FW2 | | |d=FWn | | d=HA | payload | +-------+-----+-------+-----+- .. -+------+-----+-------+---------+ Figure 5: "Inbound" packet on its way from FW1 to FW2. <---------- +-------+------+-------+-----+- .. -+------+-----+-------+---------+ | s=FW2 | AH'' | s=COA | AH3 | |s=COA | AHn | s=COA | MIP | | d=FW3 | | d=FW3 | | |d=FWn | | d=HA | payload | +-------+------+-------+-----+- .. -+------+-----+-------+---------+ Figure 6: "Inbound" packet on its way from FW2 to FW3. <---------- +-------+----+-------+---------+ | s=FWn | AH | s=COA | MIP | | d=HA | | d=HA | payload | +-------+----+-------+---------+ Figure 7: "Inbound" packet on its way from FWn to HA. Gupta & Glass Expires September 17, 1997 [Page 10] INTERNET DRAFT Firewall Traversal for Mobile IP March 1997 The home agent recovers the original "inbound" packet (Figure 1) and processes it as under normal Mobile IP (in the presence of reverse tunneling [Mont97]). Note that depending on the kind of tunneling used in step (d) and the placement of filtering routers, HA may need to be IPSEC aware. 4. Outbound Datagram Processing Since hosts inside the protected domain are trusted, non-perimeter firewalls like FW2, ..., FWn may be configured to allow outgoing packets to pass without any authentication. In this situation, outbound datagram processing is quite simple. The home agent creates an outbound packet as part of normal Mobile IP operation. If the destination is recognized as being outside the protected domain, the packet is explicitly directed at the perimeter firewall FW1 either by using IPinIP tunneling or a tunnel mode Authentication header. The former requires that FW1 be able to decapsulate IPinIP datagrams while the latter requires HA to be IPSEC aware. The resulting packet is shown in Figure 8. ----------> +---------+-------+-----+-------+ | MIP | s=HA | AH' | s=HA | | payload | d=COA | | d=FW1 | +---------+-------+-----+-------+ Figure 8: Outbound packet as it leaves HA (the authentication header may not be needed). Once this packet reaches the perimeter firewall FW1 successfully, the original "outbound" datagram is recovered (either after IPSEC processing or IPinIP decapsulation). The security policy on FW1 must be configured as follows: If a packet is to be forwarded to a destination for which a security association exists, appropriate IPSEC headers must be added before forwarding. As a result of this policy, the "outbound" packet looks as shown in Figure 9 as it leaves FW1 for the mobile node. Gupta & Glass Expires September 17, 1997 [Page 11] INTERNET DRAFT Firewall Traversal for Mobile IP March 1997 ----------> +---------+-------+-----+----+-------+ | MIP | s=HA | ESP | AH | s=FW1 | | payload | d=COA | | | d=COA | +---------+-------+-----+----+-------+ Figure 9: "Outbound" packet on its way from FW1 to MN. Intermediate routers such as R' and R'' see a topologically correct source address and a routable (known) destination address. Once the packet reaches the mobile node, the original "outbound" datagram is recovered after IPSEC processing and processed as with normal Mobile IP. If FW2, ... FWn require source authentication even on outgoing packets the process by which the outbound datagram reaches FW1 is no longer as simple. In this situation the overall processing is similar to that described for inbound datagrams but in the reverse direction. ----------> +---------+-------+-----+-------+-----+-------+- .. -+-----+-------+ | MIP | s=HA | AH1 | s=HA | AH2 | s=HA | | AHn | s=HA | | payload | d=COA | | d=FW1 | | d=FW2 | | | d=FWn | +---------+-------+-----+-------+-----+-------+- .. -+-----+-------+ Figure 10: An "outbound" packet as it leaves HA. +---------+-------+-----+-------+-----+-------+ | MIP | s=HA | AH1 | s=HA | AH2 | s=HA | | payload | d=COA | | d=FW1 | | d=FW2 | +---------+-------+-----+-------+-----+-------+ Figure 11: An "outbound" packet on its way from FW3 to FW2. +---------+-------+-----+-------+ | MIP | s=HA | AH1 | s=HA | | payload | d=COA | | d=FW1 | +---------+-------+-----+-------+ Figure 12: An "outbound" packet on its way from FW2 to FW1. Note that intermediate firewalls do not need to prepend additional headers before forwarding an outbound packet because already the outermost source and destination are known to internal routers and the source is topologically correct. Gupta & Glass Expires September 17, 1997 [Page 12] INTERNET DRAFT Firewall Traversal for Mobile IP March 1997 5. Closing Remarks The mechanism outlined here allows Mobile IP operation even when a mobile node roams outside its firewall-protected domain. This functionality is achieved at the cost of introducing sub-optimal "quadrangle" routing and additional header overhead. The amount of header overhead depends on the number of intervening firewalls. In most cases just a single firewall must be traversed. Preliminary experiments on a SKIP-based implementation [MoGu96] suggest that the performance penalty due to IPSEC processing and additional headers on sustained throughput is roughly ten percent. Bursty traffic rates can show significant variance because the use of Mobile IP and IPSEC tunnels delays Path MTU discovery. Several packets may need to be sent before the sender's path MTU estimate becomes small enough to account for all intermediate tunnels, e.g. one ftp transfer of a 0.5 MB file attained a transfer rate of 7KB/s but after the path MTU had been cached at the sender, the same file was transferred at a rate of 270 KB/s. 6. Security Considerations This entire document discusses security considerations for mobile nodes. Using the procedure outlined in this document, datagrams between a mobile node and its home agent can pass freely through firewalls protecting its home domain. In this situation, the mobile node acts as an extension of the security perimeter surrounding its home domain and must, therefore, share in the responsibility of protecting it from outsiders. In the absence of user-specific keying information, someone who steals the mobile node may also gain access to the home network. Acknowledgments This document builds upon ideas previously introduced in [MoGu96] and discussions at the "Secure firewall Traversal for Mobile IP" special meeting held during the 37th IETF meeting. References [CA9621] CERT Advisory CA-96.21, "TCP SYN Flooding and IP Spoofing Attacks", available at ftp://info.cert.org/pub/ cert_advisories/CA-96.21.tcp_syn_flooding. [ChZw95] D. B. Chapman and E. Zwicky, "Building Internet Firewalls", O'Reilly & Associates, Inc., Sept. 1995. [GuGl97] V. Gupta and S. Glass, "Firewall traversal for Mobile IP: Goals and Requirements". Draft <draft-ietf-mobileip-ft-req- 00.txt> -- work in progress, January 1997. [LGLK96] M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas and L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996. [Leec96] M. Leech, "Username/Password Authentication for SOCKS V5", RFC 1929, March 1996. [MSST96] D. Maughan, M. Schertler, M. Schneider and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", version 7, Draft <draft-ietf-ipsec-isakmp-07. {ps,txt}> -- work in progress. Gupta & Glass Expires September 17, 1997 [Page 13] INTERNET DRAFT Firewall Traversal for Mobile IP March 1997 [McMa96] P. McMahon, "GSS-API Authentication Method for SOCKS Version 5", RFC 1961, June 1996. [Mont97] G. Montenegro, "Bi-directional Tunneling for Mobile IP", Draft <draft-ietf-mobileip-tunnel-reverse-00.txt> -- work in progress, Feb. 1997. [MoGu96] G. Montenegro and V. Gupta, "Firewall Support for Mobile IP". Draft <draft-montenegro-firewall-sup-00.txt>, work in progress, Sept. 1996. [Orma96] H. Orman, "The Oakley Key Determination Protocol", version 1, Draft <draft-ietf-ipsec-oakley-01.txt> -- work in progress. [Per96a] C. Perkins, "IP Mobility Support", RFC 2002. [Per96b] C. Perkins, "IP Encapsulation within IP", RFC 2003. [Per96c] C. Perkins, "Minimal Encapsulation within IP", RFC 2004. Author's Address Vipul Gupta Sun Microsystems, Inc. 2550 Garcia Avenue Mailstop UMPK 15-214 Mountain View, CA 94043-1100 Tel: (415) 786 3614 Fax: (415) 786 6445 EMail: vipul.gupta@eng.sun.com Steven M. Glass FTP Software 2 High Street North Andover, MA 01949 Tel: (508) 685 4000 Fax: (508) 684 6105 EMail: glass@ftp.com Gupta & Glass Expires September 17, 1997 [Page 14]