One document matched: draft-le-mip6-firewalls-00.txt
INTERNET DRAFT Franck Le
File: draft-le-mip6-firewalls-00.txt Stefano Faccin
Expires: August 2004 Basavaraj Patil
Nokia Research Center
Dallas
February 2004
Mobile IPv6 and Firewalls
Problem statement
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of [RFC2026].
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
Firewalls are an integral part of most IP networks deployed today.
Firewall technology available today is predominantly for IPv4
networks. Firewalls for IPv6 networks are slowly becoming
available. In most cases, current firewall technologies do not
support Mobile IPv6. Unless firewalls are aware of Mobile IPv6
protocol details, these security devices will hamper large-scale
deployment of the protocol. This document presents in detail some
of the issues that firewalls present for Mobile IPv6 deployment.
The goal of this Internet draft is to highlight the issues with
firewalls and Mobile IPv6 and act as an enabler for further
discussion. Issues identified here can be solved by developing
appropriate solutions in the MIP6 WG.
Expires: August 2004 [Page 1]
draft-le-mip6-firewalls-00.txt February 2004
1. Introduction
Mobile IPv6 enables IP mobility for IPv6 nodes. It allows a mobile
IPv6 node to be reachable via its home IPv6 address irrespective of
any link that the mobile attaches to. This is possible as a result
of the extensions to IPv6 defined by Mobile IPv6.
Mobile IPv6 protocol design also incorporates a feature termed as
Route Optimization. This is not a nonstandard set of extensions
but a fundamental part of the protocol that allows to optimize the
routing of the packets between a Mobile Node and its correspondent
node and therefore the performance of the communication.
In most cases, current firewall technologies however do not support
Mobile IPv6 or are even aware of Mobile IPv6 headers and
extensions. Since most networks in the current business environment
deploy firewalls, this may prevent future large-scale deployment of
the Mobile IPv6 protocol.
This document presents in detail some of the issues that firewalls
present for Mobile IPv6 deployment, and the impact of each issue is
also described. The goal of this Internet draft is to highlight the
issues and act as an enabler for further discussion. Issues
identified here can be solved by developing appropriate solutions
in the MIP6 WG.
2. Background information
One set of issues is related to the way IP addresses are used in
Mobile IP, and the way state information is created and mintained
in stateful inspection packet filters. We refer to the internal
node as the node connected to the network protected by the
firewall, and to external node as the node outside the boundaries
of the network protected by the firewall.
The following describes how stateful inspection packet filters
work:
When a MN connects to a TCP socket on another host in the
Internet, it provides, at the connection synchronization, the
socket (IP address and port) on which it expects to receive a
response.
When that SYN packet is routed through the firewall, the
firewall makes an entry in its state table containing the
destination socket and the response socket, and then forwards
the packet to the destination.
Expires: August 2004 [Page 2]
draft-le-mip6-firewalls-00.txt February 2004
When the response comes back, the filter looks up the packets
source and destination sockets in its state table: If they
match an expected response, the firewall lets the packet pass.
If no table entry exists, the packet is dropped since it was
not requested from inside the network.
The filter removes the state table entries when the TCP close
session negotiation packets are routed through, or after some
period of delay, usually a few minutes. This ensures that
dropped connections dont leave table holes open.
For UDP, similar state is created but since UDP is
connectionless and the protocol does not have indication of
the beginning nor the end of a session, the state is based
only on timers.
3. Scenario where the external node is a Mobile Node
Lets assume a communication between an internal node A, and an
external Mobile Node B.
+----------------+ +----+
| | | HA |
| | +----+
| | Home Agent
| +---+ +----+ of B
| | A | | FW |
| +---+ +----+
| | +---+
| | | B |
| | +---+
+----------------+ External Mobile
Network protected Node
by a firewall
3.1 Issues with Return Routability Test
As specified in Mobile IP [MIP6], the tranport and above layers of
the ongoing communications should be based on the Home IP address
of B, IP HoA B, and not the local IP address that B might get while
roaming in order to support mobility.
The state created in the stateful inspection packet filter
protecting A is therefore initially based on the IP address of A,
IP A, and the home address of the node B, IP HoA B.
If the Mobile Node B is connected to the home network, packets are
directly exchanged between the nodes A and B. If the Mobile Node B
Expires: August 2004 [Page 3]
draft-le-mip6-firewalls-00.txt February 2004
is roaming to a vsited network, the session can be maintained
thanks to the Home Agent of B and the reverse tunneling mechanism
[MIP6]. Packets forwarded by the Home Agent to the node A will have
the source IP address indicating the Home IP address of B and the
destination IP address indicating the IP address of A. Such packets
can thus pass the stateful inspection packet filter protecting A.
However nodes A and B might be close while B's Home Agent may be
far, resulting in a trombone effect that can create delay and
degrade the performance.
The Mobile IP specifications have defined the route optimization
procedure [MIP6] in order to solve this issue and, to send a
Binding Update, the Mobile Node should first execute a Return
Routability Test: the Mobile Node B should send a Home Test Init
message via its Home Agent and a Care of Test Init message directly
to its correspondent node A.
The Care of Test Init message is sent using the new CoA of B as
source address, however such a packet does not match any entry in
the stateful inspection packet filter and as described in section
2. The COTi message will thus be dropped by the firewall. As a
consequence, the RRT cannot be completed and route optimization
cannot be applied. Every packet has to go through the node Bs Home
Agent and tunneled between Bs Home Agent and B.
3.2 Issues with Firewall Status Update
Assuming alternatives mechanisms are developed for authenticating
the Binding Update, or other mechanisms are developed to let the
RRT packets pass through the stateful inspection packet filter
(e.g. rate limiting), the firewall may still drop the packets
coming from the new CoA since these incoming packets do not match
any existing entry.
Requiring the stateful inspection filters to update the connection
state upon detecting Binding Update messages from a node outside
the network protected by the firewall does not appear feasible nor
desirable, since currently the firewall does not have any mean to
verify the validity of Binding Update messages and to therefore
securely modify the sate information. .sp Changing the firewall
states without verifying the validity of the Binding Update
messages could lead to Denial of service attacks: malicious nodes
may send fake Binding Update forcing the firewall to change the
state information, and therefore leading the firewall to drop
packets from the connections that use the legitimate addresses.
Expires: August 2004 [Page 4]
draft-le-mip6-firewalls-00.txt February 2004
4. Scenario where the internal node is a Mobile Node
Lets assume a communication between an internal Mobile Node A, and
an external node B. B can also be a Mobile Node and issues raised
in section 3 still apply.
+----------------+ +----+
| | | HA |
| | +----+
| | Home Agent
| +---+ +----+ of A +---+
| | A | | FW | | B |
| +---+ +----+ +---+
|Internal | External
| MN | Node
| |
+----------------+
Network protected
by a firewall
4.1 Issues with Triangular Routing
One of the main advantages claimed by Mobile IP is that it allows
the Mobile Node to be always reachable thanks to the Home Agent. A
node desiring to establish a communication will send a packet to
the Home Address of the Mobile Node which forwards it to the CoA of
the MN.
When considering stateful inspection packet filters, e.g. when the
Mobile Node roams to a network protected by a firewall with such
filters, the packet forwarded from the Home Agent to the Mobile
Node CoA may be dropped at the firewall since it does not match any
existing entry.
When entering the visited network, the MN first acquires a Care of
Address and then sends a Binding Update to its Home Agent. This
message creates as specified in section 1 a state in the firewall
so that the response can pass the firewall and be delivered to the
Mobile Node. The state created in the firewall is specific to the
Mobility Header being used for the Mobile IPv6 signalling. Also
some FW may leave this state open for a while (implementation
dependent), whereas other firewalls may delete the state upon
receiving the Binding Acknowledgement message.
Lets assume a Correspondent node trying to initiate a communication
with the Mobile Node. The Correspondent node sends a packet to the
Mobile Nodes home address. The packet is intercepted by the MNs
Home Agent which tunnels it to the MNs CoA.
Expires: August 2004 [Page 5]
draft-le-mip6-firewalls-00.txt February 2004
As described in section 1, the lifetime corresponding to the state
in the firewall may have expired and the state may have been
removed. In such case, the incoming packet sent from the CN does
not match any existing entry and is therefore dropped at the
firewall.
Even if the state created above has not expired yet, the state
created is for the Binding Update message (Mobility Header) whereas
the packet sent from the CN is received under the form of an IP in
IP packet. The latter does not match any existing entry and is also
dropped.
4.2 Issues with Return Routability Test
Security of Mobile IPv6 Binding Update is based on the RRT
mechanism [MIP6]. RRT robustness and security level relies on the
application of IPsec ESP between the Home Agent and the MN. As
specified in Mobile IPv6 [MIP6] in section 5.2.5 'For improved
security, the data passed between the Home Agent and the Mobile
Node is made immune to inspection and passive attacks. Such
protection is gained by encrypting the home keygen token as it is
tunneled from the Home Agent to the Mobile Node as specified in
Section 10.4.6.'
Also section 10.4.6 specifies that 'The return routability
procedure described in Section 5.2.5 assumes that the
confidentiality of the Home Test Init and Home Test messages is
protected as they are tunneled between the Home Agent to the Mobile
Node. Therefore, the Home Agent MUST support tunnel mode IPsec ESP
for the protection of packets belonging to the return routability
procedure.' This assumption is valid in some environments, however
for networks protected by a firewall, the requirement can be an
issue.
Typically firewalls need to filter the packets based on the
source/destination IP addresses and the TCP/UDP source/destination
ports numbers. When a packet is encrypted using IPsec ESP, such
information is not available (in particular the port numbers),
therefore firewalls may drop the Home Test messages forwarded by
the HA to the MNs CoA. The result is that the MN cannot complete
the RRT procedure, and consequently cannot perform route
optimization by sending any Binding Update messages.
When ESP is applied, the firewall cannot differentiate packets
containing the Mobility Header defined by MIPv6 i.e. packets for
which Mobile IPv6 is used, from other packets. In order to support
RRT, one possible idea could be to let the firewall pass all ESP
packets coming from the MN Home Agent. This may however not be
Expires: August 2004 [Page 6]
draft-le-mip6-firewalls-00.txt February 2004
desirable since it would allow several types of attacks (e.g.
flooding) to be carried out against the MN. In cellular networks
such flooding may result in e.g. overbilling attacks since the user
has to pay for the air interface utilization.
4.3 Issues with Change of CoA
The internal node A may change CoA within the network protected by
the firewall. In such instances A updates its Home Agent with its
current location by sending a Binding Update. This Binding Update
message may present issues with the firewall if encrypted. Lets
assume that the Mobile Node therefore only integrity protects the
Binding Update message.
When passing the firewall, this message creates a state in the
firewall that will allow the response to pass the firewall and
reach the Mobile Node. The state information includes the Mobile
Node, the Home Agents IP addresses, and the Protocol Identifier
indicating a a packet containing a Mobility Header
The Home Agent updates its binding cache and replies with a Binding
Acknowledgement message. The latter can pass the firewall and reach
the Mobile Node thanks to the state previously created in the
firewall. After this procedure the Home Agent forwards subsequent
packets destined to the Mobile Node to the new CoA.
The firewall however does not have any state for the new incoming
data packets, since such packets are addressed to the new CoA of
the Mobile Node, whereas the firewall state was created based on
the old CoA. The incoming packets are therefore dropped at the
firewall. If the Mobile Node were communicating with correspondent
nodes, all the states in the firewall had been created for the
previous MNs CoA.
4.4 Change of firewall
When the MN A moves, it may roams to a subnet served by a different
firewall. A might be sending BU to the CN (even assuming RRT
problem section 4.2 - can be solved or other authentication
mechanism is developed), incoming packets may however be dropped at
the firewall since this latter does not have any state.
5. Conclusion
Current firewalls may not only prevent route optimization but may
also prevent communications to be established in some cases. This
document describes some of the issues between the Mobile IP
protocol and current firewall technologies, but the issues are not
Expires: August 2004 [Page 7]
draft-le-mip6-firewalls-00.txt February 2004
limited to the ones described in this document. There are other
ones and the next version of this Internet draft will detail other
issues.
However the authors considered relevant to present these problems
as soon as possible, so that network administrators who intend to
deploy Mobile IPv6 can consider them, and so that solutions/tools
can be developed to solve the identified problems.
6. Security Considerations
This document describes the issues between current firewall
technology and the Mobile IP protocol. No solution is being
proposed, and therefore no security risks are being introduced.
7. References
[MIP6]
D. Johnson, C. Perkins, J. Arkko, "Mobility Support in in
IPv6", draft-ietf-mobileip-ipv6-24.txt, June 30, 2003
[GONC]
Firewalls complete / Marcus Goncalves
[STRE]
Firewalls 24 seven / Matthew Strebe and Charles Perkins
[CHES]
Firewalls and Internet Security, Repelling the Wily Hacker /
William R. Cheswick and Steve M. Bellovin
Author's Address:
Franck Le Stefano Faccin
Nokia Research Center, Dallas Nokia Research Center, Dallas
6000 Connection Drive 6000 Connection Drive
Irving, TX-75063, USA. Irving, TX-75063. USA.
E-Mail: franck.le@nokia.com E-Mail: stefano.faccin@nokia.com
Phone : +1 972 374 1256 Phone : +1 972 894 4994
Basavaraj Patil
Nokia, Dallas
6000 Connection Drive
Irving, TX-75063, USA.
EMail: Basavaraj.Patil@nokia.com
Phone: +1 972-894-6709
Expires: August 2004 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-23 11:00:26 |