Internet Engineering Task Force Jim Binkley INTERNET DRAFT Portland State University Category: Informational John Richardson Intel Security Considerations for Mobility and Firewalls Status of This Memo Distribution of this memo is unlimited. 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 made obsolete by other documents at any time. It is not appropriate to use Internet Drafts as reference material, or to cite them other than as a ``working draft'' or ``work in progress.'' To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nic.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast) or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. Abstract In this paper we discuss various security issues concerning Mobile Hosts using Mobile-IP or other mobility systems (DHCP standalone) and current firewall technology. We first present some recent attacks on the Internet and what they might mean for mobile systems like Mobile-IP that rely on tunneling technologies. We point out that tunnels are a security threat and suggest how mobile systems may be made "less insecure" with the use of IP layer security (IPSEC) as one means for creating Virtual Private Networks. The goal is to describe a security model wherein mobile systems can work across the Internet and not just as an interior routing protocol within one security and/or interior routing domain. Both the protection of Mobile Systems abroad and of Security Enclaves that tolerate mobile visitors must be considered. Binkley & Richardson Expires April 16 1999 [Page 1] ^L INTERNET DRAFT Mobility Security Considerations November 1998 Table of Contents 1. Introduction and Assumptions 2. The Problem Space 2.1 Spoofing Attack Examples 2.2 Prevention of Spoof Attacks 2.3 Anti-Spoofing Measures and Mobile-IP 3. Tunnels Considered Harmful 4. Problem Solution Space 4.1 Mobile Nodes Abroad Point of View 4.1.1 Packets from the Mobile Node Out 4.1.2 Packets Coming From Home to the Mobile Node 4.1.3 Tunnel Security at Tunnel-Exit Agents 4.2 Hosting Visitors From Abroad 5. Miscellaneous Considerations 5.1 Firewall Discovery 5.2 The Role of Foreign Agents 6. Security Considerations 6.1 Security Considerations for Tunnel-Entrances 7. Conclusions 8. Acknowledgements 9. References 10. Contact Information Binkley & Richardson Expires April 16 1999 [Page 2] ^L INTERNET DRAFT Mobility Security Considerations November 1998 1. Introduction and Assumptions With the rapid growth of Virtual Private Networks, tunneling protocols are assuming a high profile in the Internet. Our work with tunnels as applied to Mobile-IP has uncovered a vulnerability that most tunnels leave unprotected. Basically, while most of today's firewalls stop IP Spoofing attacks, tunnels "drilled" through those firewalls re-enable that class of attack. Strong authentication of the remote systems by the tunnel endpoint, while necessary, is not sufficient to maintain the protection provided by the firewall complex. More generally, if a tunnel server allows authenticated remote systems to become part of a "secure enclave", it must also provide the basic protection that the firewall provides for native hosts in that enclave. The problem becomes more interesting if the secure enclave wishes to host "visiting" systems locally. For example, a company might wish to provide Internet connectivity in conference rooms and allow visitors to access the Internet (and not the secure enclave). We will consider these problems below in more detail. 1.1 Assumptions Networking, especially when done securely, has been developed from many different perspectives. Each community starts from a presumed base of common language and "normal" assumptions. To minimize confusion, we begin by stating our assumptions and provide a brief description of how commonly used terms are used in this document. We do not mean to imply anything about how they "should be used", just how we chose to use them here. The focus of this document is on how a secure enclave (firewall protected area) may tolerate Mobile-IP [RFC-2002] or simpler mobility systems (for example, DHCP used standalone) and remain secure. By "secure enclave" we mean a conventional IP site with one management domain and a centralized security administration typically behind one IP firewall [Chapman]. By "firewall" we refer to one or more systems acting together to provide protection for a network. In particular, we assume that one (or more) endpoints of IP tunnels are part of the firewall complex. Our focus here is on how a secure enclave can protect itself from foreign (non-local) Mobile Nodes. We also deal with IP spoofing issues and possible security problems that might occur due to naive implementations of IP tunneling [RFC-2003] when combined with such spoofing. The discussion is focused on the network layer. We are not considering higher-level authentication or confidentiality services that might be part of an application-level system. When we talk about firewalls, we are mostly talking about network layer access, and such mechanisms as packet-level firewalls with access control, Virtual Private Networks implemented as IP tunnels, and IP layer security (IPSEC) [RFC-1825]. We do not mean to discourage application or transport layer security in any way (Please see [RFC-2316] for the latest IAB discussion on network security in general). It is simply not our focus in this document. Regarding firewalls, we assume Cisco access lists as a rough lingua franca for access control on routers and will use access list examples suitable for Cisco routers. Please see [Ballew] for discussion of Cisco access list mechanisms. We assume packet filter technology simply because accidental holes may indeed be poked through such a router if its manager is not careful. Binkley & Richardson Expires April 16 1999 [Page 3] ^L INTERNET DRAFT Mobility Security Considerations November 1998 When we cite IP addresses as examples in the text, we will use private IP addresses as mentioned in [RFC 1918]. These should be viewed as surrogates for public ("real") IP addresses associated with an interior routing domain. We use these addresses because we do not want to cite "real" addresses in any examples. 2. The Problem Space Firewalls are designed to separate "inside" from "outside". A naive approach to protection would use the source IP address to make the distinction. Unfortunately, IP header information is unreliable as it can be set by the source (or any intermediary) to any arbitrary value. The attacker community knows this well and it forms the foundation for an entire class of attacks known as "Spoofing". Spoofing has been used as the basis for a whole set of recent attacks (for example, see [RFC-2267]). Some of the attacks are denial of service oriented. Some seek to cause the attacked system to crash or hang. Many of the attacks can be characterized as single packets wherein the IP source and destination addresses in the IP header appear to originate within the attacked systems site. 2.1 Spoofing Attack Examples To highlight the importance of spoofing attacks, we will briefly discuss three such attacks, TCP SYN [CA-96.21], "smurf" [CA-97.28], and "land" [CA-97.28]. In TCP SYN attacks, the attacker sends TCP initialization packets to a given site. The attacked system is tied up simply due to opening too many TCP control blocks which cause allocation of precious kernel memory. The attacker need only send one TCP SYN packet. The attacker may choose to use a spoofed IP source address so that tracing the attack back to its originating system is difficult. In "smurf" attacks, the attacker sends one or many ping packets to an IP directed-broadcast address with an IP source address that may also be at the destination site. For example, if a site had a site specific class C address along the lines of 192.168.1.0, the attacking IP destination might be 192.168.1.255 or 192.168.1.0 (0 broadcast addresses may be used as well) with an IP source of 192.168.1.1. The result is that two systems (at least) may be attacked. The IP source itself is bombarded with ping reflections from all the systems at the directed broadcast address. Further the smurf vehicle could also be used for single packet "ping of death" attacks. "Land" attacks involve one TCP SYN packet in which the IP source is set to be the same as the IP destination. The attack may cause the receiving machine to hang. In general, note these attacks do not involve packets being returned, unless the packets are returned to another system that is being indirectly attacked itself ("smurf"). 2.2 Prevention of Spoofing Attacks One general technique that can be used is to disallow IP spoofing for internal source addresses [RFC-2267]. Filters can be put in place so that packets arriving on an "outside" interface must have an "outside" source address (or must NOT have an "inside" source address). One may also filter out spoofing attacks attempting to leave from the "inside" of a network. Binkley & Richardson Expires April 16 1999 [Page 4] ^L INTERNET DRAFT Mobility Security Considerations November 1998 We will briefly look at how spoofing may be prevented with a Cisco router which we assume is the interface between a site having 172.16.*.* as its internal IP address space and the Internet at large. Note that the access list entries shown here may be part of a more complex firewall policy and/or access list, but we only show the part relevant to IP spoofing. The following access list entry may be bound to an external router interface and would be applied to packets entering the site. access-list 101 ... access-list 101 172.16.0.0 0.0.255.255 any Packets entering the site with 172.16.*.* addresses will be discarded. We apply the following access list to packets headed out on the external interface: access-list 111 ... access-list permit ip 172.16.0.0 0.0.255.255. any access-list deny ip any any log This blocks packets headed out that do not have IP src addresses in the 172.16.*.* range and logs any internal attempts at spoofing. Thus spoofing attacks cannot originate at this site. The result is that a site firewall or border router will neither send or receive packets over an interface when the packets do not belong to the source IP routing domain. 2.3 Anti-Spoofing Measures and Mobile-IP The result of such anti-spoofing measures is that packets headed into the enclave to "foreign" Mobile Nodes; i.e., Mobile-Nodes from some other site than 172.16..*.* will not be permitted to enter. Packets trying to leave the site from systems from another site, say 192.168.1.0, will not be permitted to leave. Mobile-IP within the same routing domain, which we might call "interior Mobile-IP" would be permitted. Mobile-IP ("exterior Mobile-IP") between two interior routing domains would not be permitted. Now we must consider what happens to packets sent from a "visiting" foreign Mobile Node that is somehow operating within the secure enclave. Please refer to the picture below. First the UDP-based Mobile-IP registration protocol would still work if Foreign Agents were used as Foreign Agents act as UDP proxies for Mobile-IP registration; i.e., they will replace a Mobile Nodes IP source address with their own (legal) source address. A Mobile Node using DHCP as a source of local addresses could also succeed if it used the DHCP-obtained local address. Data packets sent directly out of the domain from the visiting Mobile Node (unless tunneled via a local IP source address) would be discarded at the border. Data packets that somehow escaped the local secure enclave's border router could also be discarded by the "home" border router's spoofing filter as well, as it would not permit packets to enter that have "local" IP source addresses. Data packets tunneled from the (exterior) Home Agent to the (interior) Foreign Agent would be allowed through because the external encapsulation would get past the spoofing filter; i.e., Home Agent to Foreign Agent IPIP packets would have the legal interior IP source for the Foreign Agent as the exterior IP source address. Binkley & Richardson Expires April 16 1999 [Page 5] ^L INTERNET DRAFT Mobility Security Considerations November 1998 Home Agent <-------> Border Router (for 192.168.1.X domain) (192.168.1.X) ^ | | the Internet | v Border Router (secure enclave) ^ | | secure enclave (172.16.*.*) V Foreign Agent (172.16.*.* address for Care Of Address) ^ | V Visiting Mobile Node (192.168.1.X) In addition to the obvious problems that anti-spoofing raises for Mobile-IP, one must also ask if tunnels raise additional security concerns and how one might address both those concerns and security for both the Mobile Node itself, its home domain, and the "visited" domain too. 3. Tunnels Considered Harmful One mechanism that is part of Mobile-IP and in point of fact many other routing protocols are IP tunnels which might be implemented with IPIP, IPSEC Tunnel Mode, or Cisco's Generic Routing Encapsulation [RFC-1701]. It should be pointed out that IPIP tunnels are not peculiar to Mobile-IP. They are used in many routing protocols for many purposes including tunneling non-IETF protocols (e.g., Appletalk) or building virtual networks on top of the current Internet (MBONE, 6BONE). Tunnels may mean encapsulated packets where one has one IP datagram inside another IP datagram and we will use IPIP (IP protocol 4) as our example here. Mobile-IP uses tunnel mechanisms like IPIP to forward packets from the Home Agent to a remote "Care Of Address". The COA is a local site IP address that may represent a Mobile Node that has acquired a local IP address itself directly via DHCP or a router system that understands Mobile-IP called a Foreign Agent. Any Mobile-IP system, including Mobile Nodes, Home Agents, or Foreign Agents, may source or sink tunnel packets. When a Home Agent forwards packets to a Mobile Node that is at a Foreign Agent, the use of IPIP in a datagram may appear as follows: IP outer header IP inner IP datagram -------- -------- ip src= Home Agent ip src = peer end host | TCP, etc. ip dst= Foreign Agent ip dst = Mobile Node | | | packets to MN v Home Agent ========= IPIP tunnel to COA ===> FA and Mobile Node One might ask if it is enough to simply use IPIP tunneling and somehow tunnel either from the Foreign Agent or Mobile Node back to the Home Agent and thus evade the anti-spoofing measures at a firewall? Unfortunately, this is an insecure approach. Binkley & Richardson Expires April 16 1999 [Page 6] ^L INTERNET DRAFT Mobility Security Considerations November 1998 In the first place, it is not enough to simply tunnel over the IP spoofing firewall. This is simply a new form of spoofing which we might call: "IPIP spoofing". The problem is that if one has a tunnel sink (be it any kind of agent or Mobile Node) that decapsulates packets and then forwards them, others can launch their spoofing attacks with IPIP too and thus have the spoofing emerge "inside" the enclave firewall. For example, smurfing might simply be redirected through a tunnel. The inner IP header might be directed broadcast with an interior IP source named as a target. All the previous attacks (TCP SYN, "smurf", "land") can thus be done through the firewall. We suggest that one can block tunnels with current access list mechanisms and thus control tunnels so that tunneling from the outside can only be done to certain hosts that will be considered as "network-layer" bastion hosts. For example, with Cisco IOS one can add the following statements to access list 101: access-list 101 deny ipinip any any access-list 101 deny gre any any and thus block any IPIP or GRE packets coming in over the router. One may further add a permit statement to force any IPIP packets coming in to land at a certain host and then treat that host as a bastion host; i.e., a nexus of security focus. For example, ... access-list 101 permit ipinip any host 172.16.1.3 access-list 101 deny ipinip any any access-list 101 deny gre any any ... in a Cisco input access list, means IPIP will only be allowed to the host 172.16.1.3, which we will assume is a tunnel sink agent. We have focused internal trust for IPIP on that one system. We next need to explore how to make sure that packets arriving at the tunnel sink agent are *not* attacks that can be made via a tunnel sink. This can be done with "tunnel-mode" IPSEC tied to IPIP. We will explore this idea further in the next section. 4. Problem Solution Space We will discuss how to solve these problems from two topological points of view. First we look at the situation from the Mobile Node abroad's point of view. We assume it actually wants to get packets home and not compromise home security. Thus this point of view must necessarily include the Mobile Node's home enclave. We then look at the situation from the "foreign" security enclave's point of view. We assume that the foreign enclave wants to allow mobile service but protect itself. We also must consider the question of how both security enclaves (home and away) in general protect themselves from any tunnel-based attacks. In this discussion we also try to contrast the use of Mobile-IP versus a simpler form of DHCP-only mobility that does not use Mobile-IP. Keep in mind that the main semantic for the use of Mobile-IP is that the Mobile Node retains at least one fixed IP address that is non-local for the subnet it is visiting. Binkley & Richardson Expires April 16 1999 [Page 7] ^L INTERNET DRAFT Mobility Security Considerations November 1998 A Mobile-IP system may have two IP addresses associated with it, a fixed permanent Mobile-IP address (call it the "Mobile-IP address"), and a locally acquired address (call it the "DHCP address"). A DHCP-only system would only have one locally acquired IP address. 4.1 Mobile Nodes Abroad Point of View In this section we will consider the problems for a secure enclave if Mobile Nodes in that secure enclave go abroad; i.e., out to the Internet beyond the firewall. We must ask how the Mobile Node can secure its own traffic and in effect, take its security enclave with it. We must also ask how the home enclave can secure traffic coming from that Mobile Node back inside, which will extend the thinking about tunnels in the previous section. Glass and Gupta [Gupta-draft] suggest that Mobile-IP Mobile Nodes abroad may use DHCP to acquire "local" IP addresses, Thus they can get by the anti-spoofing measures in the firewall router. This is indeed a reasonable possibility. Further, the Mobile Nodes can use IPSEC with two-way tunnels between the Home Agent as a classic bastion host and the Mobile Node. (See [http://www.cs.pdx.edu/research/SMN for a combined Mobile-IP IPSEC system in which Mobile Nodes can do two-way MN/HA ESP tunnels). Please see the figure below: Internet 172.16.1.1 Home Agent: <----> Firewall <-----------------> router/DHCP server 192.168.1.1 | | | Mobile Node 172.16.1.2/ 192.168.1.2 4.1.1 Packets from the Mobile Node Out If we assume Mobile-IP and two addresses in use by the Mobile Node, packets tunneled from the Mobile Node to the Home Agent might have the structure: IP(1) | IP(2) | | IP(3) Each IP header has its own purpose. The most external header, IP(1) exists to get the packets to the Home Agent with the DHCP acquired address == 172.16.1.2. The IP destination would be 192.168.1.1. Thus header(1) allows transit of the Internet and any anti-spoofing firewalls. When the packet arrives at the Home Agent, that header is discarded and header(2), consisting of IP(2) combined with an IPSEC header is processed. Here we assume that the Mobile-IP address 192.168.1.2 is used for the source address and the Home Agent is again the destination. The fixed Mobile-IP address may be needed here as it allows a-priori manual IPSEC keys to exist between the Mobile Node and the Home Agent. In effect, this is an IPSEC tunnel between the Mobile Node and the Home Agent. The interior header would contain the Mobile Nodes fixed address (192.168.1.2) as IP source and the address of any destination to which it is allowed to send packets. The above triple-header system could be optimized by a higher-level protocol that could produce a dynamic binding between the local DHCP-acquired COA and the Home Agent's destination address. There is no reason Internet Key Exchange protocols [IKE] where non-IP naming schemes are used could not be deployed here. This would allow one header to be deleted. Binkley & Richardson Expires April 16 1999 [Page 8] ^L INTERNET DRAFT Mobility Security Considerations November 1998 For a DHCP-only form of mobility, the packet layout situation would be simpler. The Mobile Node would use a non-IP naming scheme with IKE to form a security association with a Home Security Agent. IP header (2) would not be needed. 4.1.2 Packets Coming From Home to the Mobile Node For Mobile-IP, we must now consider packets coming back to the Mobile Node via a tunnel from the Home Agent. By definition these packets are tunneled to a local IP address and are not subject to problems caused by anti-spoofing filtering. However IPIP unadorned is a security threat to the receiving enclave. And of course, the Mobile Node may choose to have IPSEC-based security between itself and its home enclave. One possible encapsulation scheme might take this form: IP(1) | IP(2) | IPSEC | IP datagram IP(1) exists to get the packets from the Home Agent to the remote Care Of Address which might be a Foreign Agent or a Mobile Node that has acquired a local IP address. The inner IP header would exist where manual keying is needed with IPSEC and the IP source would be the Home Agent. The IP destination would be the Mobile Node itself. Note that again IKE could be used to optimize out an IP header as long as IP addresses are not part of a manual configuration scheme. It is highly likely that from a security policy point of view, one would not form security associations (especially confidentiality-based security associations) between random Home Agents and random enterprise-external Foreign Agents. As a policy consideration, unsecured IPIP might simply not be allowed to Foreign Agents. Foreign Agents might insist that all IPIP packets be sent to them from internal Home Agents with which they share an a priori security association. Alternatively Foreign Agents might exist "outside" a secure enclave, or unadorned IPIP packets when decapsulated might only be allowed to go "outside". 4.1.3 Tunnel Security at Tunnel-Exit Agents We suggest that a tunnel-sink agent like a Mobile-IP Home Agent may want to guarantee that all packets sent to it via a tunnel are cryptographically verified; e.g., shared secret keys might exist between it and the Mobile Node abroad. No packets forwarded to the tunnel-sink agent by the firewall will be internally decapsulated and forwarded until they have been cryptographically verified. This might be done with an access list mechanism tied to IPSEC or by simpler means. For example, the PSU system mentioned above has a BSD sysctl(8) switch: # sysctl -w net.inet.ip.mvifipsecinput=1 that if set forces the IPIP driver to only forward packets if and only if IPSEC authentication or decryption has successfully occured between the remote system and this system. As a consequence, one may be sure that a Mobile-IP Home or Foreign Agent or any tunnel sink only forwards IPIP packets that have successfully passed IPSEC processing. Put another way, a security association must exist between the tunnel sink and the tunnel source system. Packets coming from remote security-aware Mobile Nodes might have several forms: IP(1) | IPSEC | IP datagram or possibly IP(1) | IP(2) | IPSEC | IP datagram Binkley & Richardson Expires April 16 1999 [Page 9] ^L INTERNET DRAFT Mobility Security Considerations November 1998 For example, the former packet architecture might occur with a remote Mobile Node that is only using DHCP and wants to securely tunnel home. The latter might be used by a remote Mobile Node that is using Mobile-IP and has also used DHCP to acquire a local COA. The local anti-IP-spoofing firewall might then be configured in a number of possible manners depending on local security policies and the structure of external but acceptable packets. For example, with current Cisco access list technology, we could permit IP | IPSEC packets using ESP (ip proto 50) or AH (51) to the Home Agent: ... access-list 101 permit 50 any host 172.16.1.3 access-list 101 permit 51 any host 172.16.1.3 access-list 101 deny ipinip any any ... As in our previous example, the firewall might simply allow IPIP but only to a Home Agent. This would apply to the second IP | IP | IPSEC example. We must point out that the security problems here are not terribly different from those encountered by current dialup clients into a secure enclave that access the enclave via an internal terminal multiplexor. The exterior host tunnels into a secure enclave and an agent in the secure enclave applies cryptographic measures to packets that have come in from the outside. 4.2 Hosting Visitors From Abroad In the previous section we have focused on how to protect the Mobile Node abroad and also discussed the problem of how to make tunnel (exits) more secure. One must also worry about the security of the "other" enclave, else enclaves may not desire to host foreign Mobile Nodes. It makes little sense for a firewall-protected enclave to allow visitors to penetrate the enclave at will and thus enable possible attacks on internal systems by visitors. Of course, we could start with a security policy that does not allow visitors to penetrate the firewall. In effect, that is the current security policy for many sites. However it is our goal here to discuss how we might tolerate "less trusted" visitors, not define them out of existance. We suggest a topological approach based on network design measures that can be made with current (or near-current) technology and that should allow a secure enclave to remain secure. Our basic principle is: "design the network so that visitor packets are not allowed inside". We observe that whatever is done to implement this goal will probably be similar to current systems that have two-level security enclaves. For example, one might have a network designed as follows: ^ | Router(1) | ------------------------- internal less secure DMZ | | | Firewall(2) term mux DHCP/router for Mobile Visitors | ------------------------ | secure enclave | Binkley & Richardson Expires April 16 1999 [Page 10] ^L INTERNET DRAFT Mobility Security Considerations November 1998 The above may be viewed as a logical (not necessarily physical) structure. We have a Router(1) that simply serves to allow access to the Internet. Inside the external router we have a less secure DMZ network that may serve to allow unfiltered access to the Internet. This network might include terminal multiplexors and local mobility servers. Behind it we could have at least one level of firewalls with bastion hosts (which may or may not be on the DMZ network). Firewall(2) would serve the function of the traditional firewall machine. One might observe that the above scheme does not force visiting laptops to acquire local addresses to bypass IP-spoofing filters. True, but unfortunately there may be other firewalls on the way home that possess such filters. Certainly the firewall at home may possess such a filter. The above may be viewed as a physical network design that would tolerate visitors. However it is very likely that such a design may not be very convenient to implement. We suggest that various virtual network techniques may be used to approximate the physical structure above. Let us briefly consider two methods that may be used to logically separate networks and thus remove construction difficulties and make the deployment of mobile networks easier. Note that these techniques *require* careful network security design. The security onus here is certainly on both the network designer, and on the creators of both Mobile Agents and security gateways. Caution needs to be employed in the design of such systems and functionality must be clearly communicated by implementors to potential network designers. First one may use a combination of simple tunneling sans IPSEC and/or authenticated tunnel packets (e.g., IPSEC AH) between a mobile router (MIP foreign agent or DHCP router/server) and the "outside" network. The basic idea would be that a router (e.g., a Mobile-IP Foreign Agent) could take all packets presented to an "exterior" interface and tunnel them (using IPIP or GRE) (possibly with additional IPSEC to alleviate paranoia) to a firewall-exterior interface on a border router. As a result, visitor packets would have no opportunity to access interior hosts. They would be tunneled "outside" and would be treated as external packets coming back through any existing firewall mechanism. | ---------------------------------- Internet accessible network Firewall(1) exit tunnel router (2) | ^ | | v | tunnel to outside secure enclave | v DHCP server router or MIP agent (3) ^ | external visitor link (4) v visiting mobile node (5) Note that we assume here that the agent(3) and the exit tunnel router(2) are under the control of the same network administration. We suggest that careful combination of access lists with tunnel technology should allow the above picture to be collapsed in various ways. For example the Firewall(1) and exit router(2) systems could be the same system. In addition, the router(3) that enables mobility could potentially optimize packet delivery. If IPSEC security associations existed at that router between a Mobile Node and the router itself, it might choose to NOT forward IPSEC-verified packets that show up via the external visitor link(4) over the internal tunnel. Thus IPSEC packets from "local" mobile systems that belong to the enclave itself could be allowed direct access to the local enclave. Of course, packets that lacked a security association with the mobile agent router would be forced over the tunnel to the "outside" world. Binkley & Richardson Expires April 16 1999 [Page 11] ^L INTERNET DRAFT Mobility Security Considerations November 1998 We will not go into details, but link-layer switching technologies can also be of use here. For example, Virtual Lans [3com] when assumed to be 1-1 with IP subnets could be used as a way to funnel visitor packets back to a router that might apply access list technology to packets trying to cross from an "exterior" subnet to an "interior" subnet. 5. Miscellaneous Considerations 5.1 Firewall Discovery Although we cannot attribute such discussion, some have suggested that some sort of Firewall Discovery system might allow Mobile Nodes to dynamically tunnel to and from firewalls. There are several problems with this notion: 1. It is unnecessary since our solution here will work with current or near-current firewall technology. 2. It is not very likely from a security point of view. Security people and network managers may not care for notions that involve poking holes dynamically through firewalls. Complexities involved in cross-security domain certification are likely beyond near-term scope. Further the security folks "at-home" may not care for schemes that involve key exchange with strangers; i.e., a Mobile Node from home somehow secures packets between itself and a foreign firewall at a different enterprise. After all, that firewall might choose to store all data traffic, and enable a classic "man-in-the-middle" attack. 3. Traditional notions of IP fate sharing (considered bad) may apply here. Mobile-IP systems are already tied to the fate of their Home Agent. Additional ties between systems that are not related from interal routing or security enclave considerations may be complex. After all, it is hard to predict how many firewalls that rule out IP spoofing to/from a given site may exist. Schemes that allow trusted locals to poke holes through firewalls are perilous by definition since "untrusted" people may crack the scheme. It is unlikely that dynamic mechanisms that allow random visitors access will prove widely acceptable. 5.2 The Role of a Mobile-IP Foreign Agent In the previous discussion, we suggested that DHCP can be used to simply allow Mobile Nodes abroad to obtain a local address. Using that address they can then send packets wherever they choose. As a result, it might seem that there is little role for a Mobile-IP Foreign Agent in a security system. Ultimately the roles that mobility systems play depend upon policy considerations. One could suggest a policy wherein Mobile Nodes abroad are not allowed to speak directly to (as opposed to through) or exchange cryptographic material with "foreign agents". This is certainly a reasonable policy. However the focus of such a policy is on the Mobile Node. We need to also consider Foreign Agent oriented policy and how a Foreign Agent might serve as a border router for a secure enclave. Foreign Agents may serve as routers that simply do not allow foreign visitors any access to an internal enclave and only allow authorized local Mobile Nodes entrance. Many techniques exist for such screening including the pre-existing Mobile-IP manually keyed registration that can secure Mobile Node access via a given Foreign Agent. However, security techniques should apply to all packets and not just Mobile-IP registration packets. Binkley & Richardson Expires April 16 1999 [Page 12] ^L INTERNET DRAFT Mobility Security Considerations November 1998 As another possibility (and there are probably others), IPSEC-aware Foreign Agents can discriminate between locals (who hold security credentials) and non-locals (who lack security credentials). Once a Mobile Node has identified itself to a Foreign Agent as belonging to the agent's secure enclave, it could use an IPSEC security tunnel between itself and the Foreign Agent. Any packets verified by the Foreign Agent as belonging to the local secure enclave could thus be delivered locally and not pushed out of the routing domain via a tunnel. Non-local visitor packets might be unceremoniously escorted off the premises via another kind of tunnel and would have no access to internal resources. Thus local mobile systems and visitors could both be tolerated at the same agent link. Of course a paranoid enclave might choose for policy reasons to force all wireless visitors to be "foreign". "Locals" could be always treated as remote visitors and tunneled outside, thus having to use secure means to come back inside. Or foreigners might simply not be permitted entrance at a given agent. Both policy considerations are possible and should be considered in implementations. 6. Security Considerations The entire document is about security, mobility, and dangers inherent in IP tunnels. We focus specifically on issues arising out of the interaction between firewalls and any tunneled protocol and highlight security concerns regarding Mobile-IP or simple DHCP for foreign visitors "beyond" the home firewall. We should point out at least one more specific security consideration for tunnel entrances. If IPSEC is used in "tunnel-mode" at a router or forwarding system that is neither the IP source or IP destination, it is possible that the security system may be subject to "proposed plaintext attacks". Please refer to the following figure: Home Agent (1) (or tunnel entrance) | ^ | | plaintext packets | attacking system (3) --- | | cryptotext packets to Mobile Node V remote Mobile Node (2) (tunnel exit) If a attacking system(3) can present plaintext packets to (1), and then read them back after encryption in the tunnel between (1) and (2), the potential for proposed plaintext attacks exists. This liability exists for a number of proposed combined tunnel and security systems, as long as network-layer forwarding combined with IPSEC (or cryptography) is part of the architecture. Solutions for the problem include session keys [IKE] and possible restriction of communication between the Home Agent(1) and the Mobile Node(2) to exclude IP sources that do not lie within the home enclave. By definition, this problem is found only with network-layer forwarding (i.e., at IPSEC gateways), and is not present in any end-system to end-system IPSEC. 7. Conclusions In this document we have presented proposals that will enable Mobile Nodes from abroad or nearby to less insecurely access the Internet. Such systems are not dissimilar from current dialup systems that involve a remote PPP-based dialup client and a local terminal multiplexor. IPSEC-enabled tunnel mechanisms may be used between the Mobile Node system and its home security companion. Very simply put, the Mobile Node is an extension of the local security domain. However, in addition to securing the Mobile Node and its home enclave, one must also give thought both to the dangers of tunnels and to how a local enclave may enable its own security and still tolerate visitors. Binkley & Richardson Expires April 16 1999 [Page 13] ^L INTERNET DRAFT Mobility Security Considerations November 1998 In summary, we will make the following suggestions: 1. DHCP to acquire a local COA solves problems caused by IP spoofing prevention for visiting Mobile Nodes abroad and may or may not be combined with Mobile-IP. 2. Suitable two-way cryptographic tunnels between a system abroad and a routing system at home will allow a Mobile Node's own traffic to be securely tunneled over the Internet. 3. IPIP tunnels sans cryptographic safeguards should be viewed with caution. If an IPIP tunnel sink does not guarantee cryptographically controlled access, an attacker may tunnel various one-way attacks (land, etc.) into an enclave. The tunnel sink may be logically regarded as an extension of the firewall itself. It may be co-located. If it is *not* co-located, firewall filtering mechanisms may need to be duplicated at the tunnel-exit point. 4. Flexibility in routing, access list mechanisms, and encapsulation possibly with authentication should be considered by implementors so that a secure enclave can securely escort visitor packets off-site without threat to secured systems within the site. 5. Security considerations must apply both to Mobile Nodes abroad, their own home enclave itself, and also to how enclaves may be designed to tolerate visitors. 8. Acknowledgements We would like to thank David Reeder of Trusted Information Systems and Mark Morrissey of Oregon Graduate Institute for their comments. 9. References [Ballew] Ballew, Scott, "Managing IP Networks", O'Reilly and Associates, Inc., 1997; ISBN 1-56592-320-0 [Chapman] Chapman, D.B., and Zwicky, E.D., "Building Internet Firewalls", O'Reilly and Associates, Inc., 1995; ISBN 1-56592-124-0 [RFC-1701] Hanks, S., Li, T., Farinacci, D., Traina, P., "Generic Routing Encapsulation", October 1994. [RFC-1825] Atkinson, R., "Security Architecture for the Internet Protocol", August 1995. [RFC-1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", February 1996. [RFC-2002] Perkins, C., "IP Mobility Support", October 1996. [RFC-2003] Perkins, C., "IP Encapsulation within IP", October 1996. [RFC-2267] Ferguson, P., and Senie, D., "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", January 1998. [RFC-2316] Bellovin, Steve, "Report of the IAB Security Architecture Workshop", April 1998. [IKE drafts] Internet Key Exchange (ISAKMP/Oakley). Works in progress. Binkley & Richardson Expires April 16 1999 [Page 14] ^L INTERNET DRAFT Mobility Security Considerations November 1998 [CA-96.21] CERT Advisory CA-96.21; TCP SYN Flooding and IP Spoofing Attacks; September 24, 1996. http://www.cert.org/advisories/CA-96.21.tcp_syn_flooding.html [CA-97.28] CERT Advisory CA-97.28; "Teardrop/Land" IP Denial-of-Service Attacks; December 16, 1997. http://www.cert.org/advisories/CA-97.28.Teardrop_Land.html [CA-98.01] CERT Advisory CA-98.01; "smurf" IP Denial-of-Service Attacks; January 5, 1998. http://www.cert.org/advisories/CA-98.01.smurf.html [3com] http://www.3com.com/nsc/200374.html; Passmore, David, and Freeman, John. "The Virtual Lan Technology". 3com Inc. [Gupta-draft] Gupta, V., Glass, S., "Firewall Traversal for Mobile IP: Guidelines for Firewalls and Mobile Ip entities", draft-ietf-mobileip-firewall-trav-00.txt, work in progress, March 17, 1997. 10. Contact Information Jim Binkley Computer Science Department Portland State University Email: jrb@cs.px.edu John Richardson Intel Email: jwr@intel.com Binkley & Richardson Expires April 16 1999 [Page 15]