Mobile IP Working Group V. Gupta
INTERNET DRAFT SUN Microsystems
S. Glass
FTP Software
January 20, 1997
Firewall Traversal for Mobile IP: Goals and Requirements
draft-ietf-mobileip-ft-req-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.
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 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).
Abstract
This document discusses problems arising out of the use of Mobile IP
in a security conscious Internet and presents a list of solution
requirements deemed important. These problems may need to be resolved
in several stages. A priority order in which these problems should be
solved is also proposed.
All firewalls are assumed to implement standard mechanisms [RFCs
1825,1826,1827] for authentication and encryption proposed by the
IPSec working group of the IETF.
Gupta & Glass Expires July 20, 1997 [Page 1]
INTERNET DRAFT Firewall Traversal for Mobile IP January 1997
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 a FA, on the foreign
subnet. 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 [Mont96]. Under this arrangement, datagrams sent from MN
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
Gupta & Glass Expires July 20, 1997 [Page 2]
INTERNET DRAFT Firewall Traversal for Mobile IP January 1997
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.
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 as
replies from correspondent nodes to the private address are likely to
generate a "host unreachable" ICMP message. If, somehow, a reverse
tunnel can be established from the mobile node to its home agent, the
Gupta & Glass Expires July 20, 1997 [Page 3]
INTERNET DRAFT Firewall Traversal for Mobile IP January 1997
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. Appropriate security mechanisms are required to successfully
traverse these firewalls to achieve required connectivity.
2. Proposed Solution Framework
The firewall traversal problem in its most general form (e.g.
multiple firewalls under different administrative controls with
limited mutual trust) does not lend itself directly to an easy
solution. Therefore, it is reasonable to try solving this problem in
several phases starting with the simplest (and still useful) variant
described below.
Consider Mobile IP operation for a mobile node (e.g. a notebook
computer belonging to a corporate employee) when it is moved outside
its firewall protected home domain into the general internet (e.g. a
university or ISP environment) which imposes no access restrictions
other than network ingress filtering. In order to reach it's home
subnet, packets from a mobile node may need to traverse Multiple
firewalls. However, they all belong to the mobile node's protected
domain and their existence and relative placement (with respect to a
mobile node's current location) is known apriori.
The simplified problem does not address the case when some of the
intermediate firewalls belong to administrative domains other than
the mobile node's, nor does it address the case when a correspondent
node (outside the mobile node's protected domain) is itself protected
by a firewall. This latter issue, however, is orthogonal to mobility
since the problem is unchanged even when the mobile node is at home.
A reasonable aim is to provide a mobile node with the same
connectivity (modulo performance penalties) outside its protected
network that it enjoys at home. Additionally, it should be possible
to encrypt all traffic to/from the mobile node in an effort to
preserve the level of privacy that a mobile node enjoys at home.
The problem of dynamically discovering intermediate firewalls should
be treated separately at a later time (see item (e) in Section 3).
3. Issues to Consider
Gupta & Glass Expires July 20, 1997 [Page 4]
INTERNET DRAFT Firewall Traversal for Mobile IP January 1997
This section discusses several important issues that should be
considered while solving the firewall traversal problem for Mobile
IP.
(a) Security processing of registrations requests sent on behalf of
(or by) a Mobile node must not depend on its reachability at its home
address. A violation of this assumption will create a circular
dependency since a Mobile Node's reachability at its home address is
at best uncertain until the registration request gets past the
firewall.
Solutions that involve a separate phase in which the mobile node
negotiates access parameters with the firewall should attempt to
minimize the number of round-trip delays.
(b) Colocating Home Agent and Firewall functionality on the same host
considerably simplifies the firewall traversal problem. However,
doing so effectively restricts the number of networks with mobility
support. For example, in Figure 1, hosts on the perimeter network
would enjoy mobility support but none on the internal network.
Therefore, a solution must not require Home Agent and Firewall
functionality to be colocated.
(c) It is possible to configure intermediate firewalls such that UDP
packets sent to port 434 of "well known" Home Agents are allowed to
pass through without any IPSEC processing. This solves the firewall
traversal problem for registration requests but not for reverse
tunneled traffic. This approach also involves administrative
maintenance of the list of "well known" home agents and assumes that
all processes running on port 434 of these hosts are trusted.
Ideally, a firewall should decide to let in a packet based solely on
its IPSEC characteristics (e.g. is it authenticated, encrypted or
both) rather than any higher level information. A solution that does
not require Firewalls to understand Mobile IP is preferred.
(d) If firewalls are unable to parse Mobile IP registrations,
complications arise when the mobile node uses a care-of address
belonging to a Foreign Agent (rather than a co-located address). The
main problem is that even if the Foreign Agent (FA) implements IPSEC
and is able to establish a security association with the Mobile
Node's firewall (FW), it can not win the Firewall's trust. A valid
authentication header on a packet generated by a FA only tells a FW
that the packet was indeed generated by the FA. However, the FW has
no way of knowing whether it was generated on behalf of a trusted
mobile node. The FA may have generated this packet on its own and the
FW may not trust the FA. (Obviously, a mobile node must not divulge
the secret it shares with the FW to its FA just so registrations can
go through.)
Gupta & Glass Expires July 20, 1997 [Page 5]
INTERNET DRAFT Firewall Traversal for Mobile IP January 1997
Consider the case of a FA relaying a mobile node's (MN) registration
request. For this request to pass through FW, it must have an
authenticator based on a security association between FW and MN. We
could have MN precompute an "IP Authentication Header (AH)" [RFC
1826] authenticator which, if inserted by the FA in the relayed
datagram, will pass authentication at the firewall. The tricky part
here is that the AH authenticator includes the Identifier field of
the immediately preceding IP header and there is no easy way for MN
to predetermine its value generated by FA for the relayed request.
There is a questionable solution. The MN could generate its own
Identifier and convey it to the FA with the understanding that the FA
must use this value in the IP header of the relayed request. This
value, the AH authenticator and the firewall address etc could all be
bundled in a new MN to FA registration extension. With this
mechanism, the FA need not even be an IPSEC node. For the case we are
considering (FA belongs to a trusting university/ISP environment), it
is quite likely that none of the mobility agents are capable of IPSEC
processing. However, this approach gets more convoluted when a
mobile node must separately authenticate itself to multiple firewalls
(see item (e) below).
In contrast, Mobile nodes operating with a co-located care-of address
are a lot simpler to deal with. In this case, requests seen by the
firewall are generated directly by a mobile node for which a trusted
relationship already exists.
Solving the firewall traversal problem for mobile nodes registered
through foreign agents may perhaps be postponed to a later phase.
(e) When multiple firewalls within the home domain must be traversed,
each firewall may require a different level of trust, e.g. a large
corporation may have one firewall guarding its connection to the
Internet and another guarding the finance department network from the
rest of the company (Figure 2). Amongst all the employees that are
allowed access through the main firewall, only a small subset may be
allowed in through the finance firewall.
Gupta & Glass Expires July 20, 1997 [Page 6]
INTERNET DRAFT Firewall Traversal for Mobile IP January 1997
[FW1]-------------------- INTERNET
|
|
[R]
/ \
/ \
{Engineering} [FW2]
|
{Finance}
Figure 2: Nested firewalls requiring different levels
of trust.
In this scenario, a mobile node on the outside that wishes to
communicate with its home agent in the finance network must be able
to explicitly (separately) authenticate itself to each intervening
firewall.
(f) Many organizations use firewalls along with private addresses.
If private addresses are used by the Mobile node's home domain, these
addresses must not be exposed to routers on the outside. This may
require additional tunneling e.g. a tunnel from the care-of address
to at least the (outer most) Firewall may be needed to hide/bury the
Home Agent's 'private' address as destination on reverse tunneled
traffic.
The problem is complicated when routers within the home domain are
(by design) kept unaware of external destinations. Analogously, extra
tunneling may be needed even on the inside, e.g. in Figure 2, a
tunnel may be needed between a home agent on the finance network and
(the proxy) FW1 to hide the 'external' care-of destination address on
encapsulated packets meant for a mobile node roaming outside.
So far we've only considered the problem of exposing addresses as
destinations to routers that are unaware of them. To make things
worse, routers are likely to disallow unknown addresses even in the
source field of the datagrams they forward. For example, internal
routers may disallow an external care-of address as source on reverse
tunneled traffic. This may necessitate additional tunneling within
the protected domain even for incoming packets e.g. an external
care-of address may need to be hidden from R (Figure 2) on reverse-
tunneled traffic. Similarly, extra tunneling may be required to hide
internal addresses (e.g. home agent's) from appearing as source on
outgoing packets routed by external routers.
Due to the widespread use of private addresses, solutions to the
firewall traversal problem must accommodate private addresses.
Gupta & Glass Expires July 20, 1997 [Page 7]
INTERNET DRAFT Firewall Traversal for Mobile IP January 1997
(g) Proposals for dynamic discovery of intervening firewalls must not
rely on firewalls generating ICMP "administratively unreachable"
messages since many firewalls are designed to hide as much of their
presence as possible.
According to Chapman and Zwicky [ChZw95, Chap 6, Section titled
"Returning ICMP Error Codes"]:
"Returning the new 'host administratively unreachable' or the fact
that there is a packet filtering system at your site, which you may
or may not want to do. These codes may also cause excessive reactions
in faulty IP implementations."
"If your router returns an ICMP error code for every packet that
violates your filtering policy, you're also giving an attacker a way
to probe your filtering system. By observing which packets evoke an
ICMP error response, attackers can discover what types of packets do
and don't violate your policy. You should not give this information
away, because it greatly simplifies the attacker's job. The attacker
knows that packets that don't get the ICMP error are going somewhere,
and can concentrate on those protocols, where you actually have
vulnerabilities. You'd rather that the attacker spent plenty of time
sending you packets you happily throw away."
"All in all, the safest thing to do seems to be to drop packets
without returning any ICMP error codes. If your router offers
flexibility, it might make sense to configure it to return ICMP error
codes to internal systems (which would like to know immediately that
something is going to fail, rather than wait for a timeout), but not
to external systems ... "
(h) The Authenticated Firewall Traversal (AFT) working group of the
IETF has developed the SOCKS protocol [LGLKKJ96] as a general
mechanism for firewall traversal. The protocol is conceptually a
"shim-layer" between the application layer and the transport layer,
and as such does not provide network layer gateway services, such as
forwarding of ICMP (or even IPinIP) messages. IPinIP messages (from
HA to MN) would have to be encapsulated within UDP or TCP in order to
use SOCKS. Beside the resulting inefficiency, there are other
concerns regarding its appropriateness for the problem at hand
[MoGu96].
The SOCKS solution requires that the mobile node -- or another node
on its behalf -- establish a TCP session to exchange UDP traffic with
each firewall. SOCKS incurs a minimum delay of four round-trips (six
with GSS-API) before a client is able to pass data through the
firewall. It seems unlikely that this negotiation will be efficient
enough to allow a mobile node to change its point of attachment as
Gupta & Glass Expires July 20, 1997 [Page 8]
INTERNET DRAFT Firewall Traversal for Mobile IP January 1997
often as once per second, as specified in [Per96a].
Given the likelihood that most firewalls in the future will be based
on IPSEC mechanisms, it is imperative that a solution be based on
standard IPSEC protocols, e.g. ISAKMP/Oakley.
4. Security Considerations
Mobile IP assumes that routing of unicast datagrams is based solely
on the destination address. Packet filtering routers and Firewalls
include additional considerations in their routing decisions. Special
mechanisms are needed to ensure Mobile IP operation in the presence
of these and related (e.g. use of private addresses) security
measures currently becoming popular on the Internet.
Acknowledgments
Ideas in this document have benefited from discussions with at least
the following people: Gabriel Montenegro, Rich Skrenta and Tsutomo
Shimomura.
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.
[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.
[McMa96] P. McMahon, "GSS-API Authentication Method for SOCKS
Version 5", RFC 1961, June 1996.
[Mont96] G. Montenegro, "Bi-directional Tunneling for Mobile IP",
Draft <draft-montenegro-tunneling-01.txt>-- work in progress,
Sept. 1996.
[MoGu96] G. Montenegro and V. Gupta, "Firewall Support for Mobile
IP". Draft <draft-montenegro-firewall-sup-00.txt>, work
in progress, Sept. 1996.
Gupta & Glass Expires July 20, 1997 [Page 9]
INTERNET DRAFT Firewall Traversal for Mobile IP January 1997
[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 July 20, 1997 [Page 10]
