Internet DRAFT - draft-binkrich-mobisec
draft-binkrich-mobisec
Internet Engineering Task Force Jim Binkley
INTERNET DRAFT Portland State University
Category: Informational John Richardson
Intel
Security Considerations for Mobility and Firewalls
<draft-binkrich-mobisec-00.txt>
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) | <IPSEC> | 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]
