MIP6 F. Le
Internet-Draft S. Faccin
Expires: August 24, 2005 B. Patil
Nokia
H. Tschofenig
Siemens
February 20, 2005
Mobile IPv6 and Firewalls Problem statement
draft-ietf-mip6-firewalls-01.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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.
This Internet-Draft will expire on August 24, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Firewalls are an integral aspect of a majority of IP networks today
given the state of security in the Internet, threats and
vulnerabilities to data networks. Current IP networks are
Le, et al. Expires August 24, 2005 [Page 1]
Internet-Draft mipv6 February 2005
predominantly based on IPv4 technology and hence firewalls have been
designed for these networks. Deployment of IPv6 networks is
currently progressing, albeit at a slower pace. Firewalls for IPv6
networks are still maturing and in development.
Mobility support for IPv6 has now been standardized as specified in
RFC 3775. Given the fact that Mobile IPv6 is a recent standard, most
firewalls available for IPv6 networks do not support Mobile IPv6.
Unless firewalls are aware of Mobile IPv6 protocol details, these
security devices will interfere in the smooth operation of the
protocol and can be a detriment to deployment. This document
presents deployment of IPv6 networks when they support Mobile IPv6
and firewalls.
The issues are not only applicable to firewalls protecting enterprise
networks, but are also applicable in 3G mobile networks such as
GPRS/UMTS and CDMA2000 networks, where packet filters are implemented
in the GGSN in GPRS/UMTS networks and the PDSN in CDMA2000 networks.
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.
Le, et al. Expires August 24, 2005 [Page 2]
Internet-Draft mipv6 February 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Overview of firewalls . . . . . . . . . . . . . . . . . . . . 7
5. Analysis of various scenarios involving MIP6 nodes and
firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1 Scenario where the Mobile Node is in a network
protected by firewall(s) . . . . . . . . . . . . . . . . . 9
5.2 Scenario where the Correspondent Node is in a network
protected by firewall(s) . . . . . . . . . . . . . . . . . 11
5.3 Scenario where the HA is in a network protected by
firewall(s) . . . . . . . . . . . . . . . . . . . . . . . 14
5.4 Scenario where MN moves to a network protected by
firewall(s) . . . . . . . . . . . . . . . . . . . . . . . 14
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1 Normative References . . . . . . . . . . . . . . . . . . . 19
9.2 Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19
A. Applicability to 3G Networks . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . 22
Le, et al. Expires August 24, 2005 [Page 3]
Internet-Draft mipv6 February 2005
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 in the Mobile IPv6 specification
[1].
Mobile IPv6 protocol design also incorporates a feature termed as
Route Optimization. This set of extensions is a fundamental part of
the protocol that enables optimized routing of 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 unaware 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 about some of the issues that
firewalls present for Mobile IPv6 deployment, as well as the impact
of each issue.
Le, et al. Expires August 24, 2005 [Page 4]
Internet-Draft mipv6 February 2005
2. Terminology
Return Routability Test (RRT): The Return Routability Test is a
procedure defined in RFC 3775 [1]. It is performed prior to the
Route Optimization (RO), where a mobile node (MN) instructs a
correspondent node (CN) to direct the mobile node's data traffic
to its claimed care-of address (CoA). The Return Routability
procedure provides some security assurance and prevents the misuse
of Mobile IPv6 signaling to maliciously redirect the traffic or to
launch other attacks.
Le, et al. Expires August 24, 2005 [Page 5]
Internet-Draft mipv6 February 2005
3. Abbreviations
This document uses the following abbreviations:
o CN Correspondent Node
o CoA Care of Address
o CoTI Care of Test Init
o HA Home Agent
o HoA Home Address
o HoTI Home Test Init
o MN Mobile Node
o RO Route Optimization
o RRT Return Routability Test
Le, et al. Expires August 24, 2005 [Page 6]
Internet-Draft mipv6 February 2005
4. Overview of firewalls
The following provides a brief overview of firewalls. This section
is intended as a background information so that issues with the
Mobile IPv6 protocol can then be presented in detail in the following
sections. Readers familiar with firewall technology may skip this
section.
There are different types of firewalls and state can be created in
these firewalls through different methods. Independent of the
adopted method, firewalls typically look at five parameters of the
traffic arriving at the firewalls:
o Source IP address
o Destination IP address
o Protocol type
o Source port number
o Destination port number
Based on these parameters, firewalls usually decide whether to allow
the traffic or to drop the packets. Some firewalls may filter only
incoming traffic while others may also filter outgoing traffic.
Stateful packet filters are a specific type of firewalls. They are
commonly deployed to protect networks from different threats.
Stateful packet filters typically block unsolicited incoming traffic
from the external networks. The following briefly describe how these
firewalls work since they can create additional issues with the
Mobile IPv6 protocol as described in the subsequent sections.
When a MN connects using TCP to another host in the Internet, it
sends a TCP SYN message to set up the connection. When that SYN
packet is routed through the firewall, the firewall creates an entry
in its state table containing the source IP address, the destination
IP address, the Protocol type, the source port number and the
destination port number indicated in that packet and then forwards
the packet to the destination. When the response comes back, the
filter looks up the packet's source IP address, destination IP
address, Protocol type, source port number and destination port
number in its state table: If they match an expected response, the
firewall let the packet to 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
do not leave table holes open.
Le, et al. Expires August 24, 2005 [Page 7]
Internet-Draft mipv6 February 2005
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.
Le, et al. Expires August 24, 2005 [Page 8]
Internet-Draft mipv6 February 2005
5. Analysis of various scenarios involving MIP6 nodes and firewalls
The following section describes various scenarios involving MIP6
nodes and firewalls and also presents the issues related to each
scenario.
The Mobile IPv6 specifications define three main entities: the Mobile
Node (MN), the Correspondent Node (CN) and the Home Agent (HA). Each
of these entities may be in a network protected by one or many
firewalls:
o Section 5.1 analyzes the issues when the MN is in a network
protected by firewall(s)
o Section 5.2 analyzes the issues when the CN is in a network
protected by firewall(s)
o Section 5.3 analyzes the issues when the HA is in a network
protected by firewall(s)
The MN may also be moving from an external network, to a network
protected by firewall(s). The issues of this case are described in
Section 5.3.
5.1 Scenario where the Mobile Node is in a network protected by
firewall(s)
Let's consider a MN A, in a network protected by firewall(s).
+----------------+ +----+
| | | HA |
| | +----+
| | Home Agent
| +---+ +----+ of A +---+
| | A | | FW | | B |
| +---+ +----+ +---+
|Internal | External
| MN | Node
| |
+----------------+
Network protected
Figure 1: Issues between MIP6 and firewalls when MN is in a network
protected by firewalls
A number of issues need to be considered:
Le, et al. Expires August 24, 2005 [Page 9]
Internet-Draft mipv6 February 2005
Issue 1: When the MN A connects to the network, it should acquire a
local IP address (CoA), and send a Binding Update to its Home
Agent to update the HA with its current point of attachment. The
Binding Updates and Acknowledgements should be protected by IPsec
ESP according to the MIPv6 specifications [1]. However, as a
default rule, many firewalls drop ESP packets. This may cause the
Binding Updates and Acknowledgements between the Mobile Nodes and
their Home Agent to be dropped.
Issue 2: Let's now consider a node in the external network, B, trying
to establish a communication with MN A.
* B sends a packet to the Mobile Node's home address.
* The packet is intercepted by the MN's Home Agent which tunnels
it to the MN's CoA [1].
* When arriving at the firewall(s) protecting MN A, the packet
may be dropped since the incoming packet may not match any
existing state. As described in Section 4, stateful inspection
packet filters e.g. typically drop unsolicited incoming
traffic.
* B will thus not be able to contact the MN A and establish a
communication.
Even though the HA is updated with the location of a MN, firewalls
may prevent Correspondent nodes from establishing communications
when the MN is in a network protected by firewall(s).
Issue 3: Let's assume a communication between MN A and an external
node B. MN A may want to use Route Optimization (RO) so that
packets can be directly exchanged between the MN and the CN
without passing through the HA. However the firewalls protecting
the MN might present issues with the Return Routability procedure
that needs to be performed prior to using RO.
According to the MIPv6 specifications, the Home Test message of
the RRT must be protected by IPsec in tunnel mode. However,
firewalls might drop any packet protected by ESP, since the
firewalls cannot analyze the packets encrypted by ESP (e.g. port
numbers). The firewalls may thus drop the Home Test messages and
prevent the completion of the RRT procedure.
Issue 4: Let's assume that MN A successfully sends a Binding Update
to its Home Agent (resp. Correspondent nodes) - issues 1 (resp.
issue 3) solved - the subsequent traffic is sent from the HA
(resp. CN) to the MN's CoA. However there may not be any
corresponding state in the firewalls. The firewalls protecting A
may thus drop the incoming packets.
Le, et al. Expires August 24, 2005 [Page 10]
Internet-Draft mipv6 February 2005
The appropriate states for the traffic to the MN's CoA need to be
created in the firewall(s).
Issue 5: When the MN A moves, it may move to a link that is served by
a different firewall. MN A might be sending a BU to its CN,
however incoming packets may be dropped at the firewall, since the
firewall on the new link that the MN attaches to does not have any
state that is associated with the MN.
5.2 Scenario where the Correspondent Node is in a network protected by
firewall(s)
Let's consider a MN in a network, communicating with a Correspondent
Node A in a network protected by firewall(s). There is no issue with
Reverse Tunneling. However firewalls may present different issues to
Route Optimization.
+----------------+ +----+
| | | HA |
| | +----+
| | Home Agent
| +---+ +----+ of B
| |CN | | FW |
| +---+ +----+
| | +---+
| | | B |
| | +---+
+----------------+ External Mobile
Network protected Node
by a firewall
Figure 2: Issues between MIP6 and firewalls when a CN is in a network
protected by firewalls
The following issues need to be considered:
Issue 1: The MN, MN B, should use its Home Address, HoA B, when
establishing the communication with the CN (CN A) if the MN (MN B)
wants to take advantage of the mobility support provided by the
Mobile IPv6 protocol, for its communication with CN A. The state
created by the firewall protecting CN A is therefore created based
on the IP address of A (IP A) and the home address of the node B
(IP HoA B). The states may be created via different means and the
protocol type as well as the port numbers depend on the connection
set up.
Le, et al. Expires August 24, 2005 [Page 11]
Internet-Draft mipv6 February 2005
Uplink packet filters (1)
Source IP address: IP A
Destination IP address: HoA B
Protocol Type: TCP/UDP
Source Port Number: #1
Destination Port Number: #2
Downlink packet filters (2)
Source IP address: HoA B
Destination IP address: IP A
Protocol Type: TCP/UDP
Source Port Number: #2
Destination Port Number: #1
Nodes A and B might be topologically close to each other while B's
Home Agent may be far away, resulting in a trombone effect that
can create delay and degrade the performance. The MN B may decide
to initiate the route optimization procedure with Node A. Route
optimization requires the MN B to send a Binding Update to Node A
in order to create an entry in its binding cache that maps the MNs
home address to its current care-of-address. However, prior to
sending the binding update, the Mobile Node must first execute a
Return Routability Test:
* the Mobile Node B has to send a Home Test Init (HoTI) message
via its Home Agent and
* a Care of Test Init (COTI) message directly to its
Correspondent Node A.
The Care of Test Init message is sent using the CoA of B as the
source address. Such a packet does not match any entry in the
protecting firewall (2). The CoTi message will thus be dropped by
the firewall.
The HoTI is a Mobility Header packet, and the protocol type
differing from the existing states (2), the HoTI packet will also
be dropped.
As a consequence, the RRT cannot be completed and route
optimization cannot be applied. Every packet has to go through
the node B's Home Agent and tunneled between B's Home Agent and B.
Le, et al. Expires August 24, 2005 [Page 12]
Internet-Draft mipv6 February 2005
+----------------+
| +----+ HoTI (HoA) +----+
| | FW |X<---------------|HA B|
| +----X +----+
| +---+ | ^ CoTI & HoTI ^
| | A | | | dropped by FW |
| +---+ | | | HoTI
| | | |
| | | CoTI (CoA)+---+
| | +------------------| B |
+----------------+ +---+
Network protected External Mobile
by a firewall Node
Figure 3: Issues with Return Routability Test
Issue 2: Let's assume that the Binding Update to the CN is
successful, the firewall(s) might still drop packets
1. coming from the CoA, since these incoming packets are sent
from the CoA and do not match the Downlink Packet filter (2)
2. sent from the CN to the CoA if uplink packet filters are
implemented. The uplink packets are sent to the MN's CoA and
do not match the uplink packet filter (1).
The packet filters for the traffic sent to (resp. from) the CoA
need to be created in the firewall(s).
Requiring the firewalls 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 means to verify the
validity of Binding Update messages and to therefore securely
modify the state information. Changing the firewall states
without verifying the validity of the Binding Update messages
could lead to denial of service attacks. Malicious nodes may send
faked Binding Update forcing the firewall to change its state
information, and therefore leading the firewall to drop packets
from the connections that use the legitimate addresses. An
adversary might also use an address update to enable its own
traffic to enter the network.
Issue 3: Let's assume that the Binding Update to the CN is
successful. The CN may be protected by different firewalls and as
a result of the MN's change of IP address, incoming and outgoing
traffic may pass through a different firewall. The new firewall
may not have any state associated with the CN and incoming
Le, et al. Expires August 24, 2005 [Page 13]
Internet-Draft mipv6 February 2005
(potentially outgoing traffic) may be dropped at the firewall.
5.3 Scenario where the HA is in a network protected by firewall(s)
Let's consider a MN moving into a network protected by firewall(s).
The following issues may exist:
Issue 1: If the firewall(s) block ESP traffic, many of the MIPv6
signaling (e.g. Binding Update, HoT) may be dropped at the
firewall(s) preventing MN(s) from updating their binding cache and
performing Route Optimization, since Binding Update, HoT and other
MIPv6 signaling must be protected by IPsec ESP.
Issue 2: If the firewall(s) protecting the Home Agent block
unsolicited incoming traffic (e.g. as stateful inspection packet
filters do), the firewall(s) may drop connection set up requests
from CN, and packets from MN.
Issue 3: If the Home Agent is in a network protected by several
firewalls, a MN/CN's change of IP address may result in the
traffic to and from the Home Agent passing through a different
firewall that may not have the states corresponding to the flows.
As a consequence, packets may be dropped at the firewall.
5.4 Scenario where MN moves to a network protected by firewall(s)
Let's consider a HA in a network protected by firewall(s). The
following issues need to be investigated:
Issue 1: Similarly to the issue 1 described in Section 5.1, the MN
will send a Binding Update to its Home Agent after acquiring a
local IP address (CoA). The Binding Updates and Acknowledgements
should be protected by IPsec ESP according to the MIPv6
specifications [1]. However, as a default rule, many firewalls
drop ESP packets. This may cause the Binding Updates and
Acknowledgements between the Mobile Nodes and their Home Agent to
be dropped.
Issue 2: The MN may be in a communication with a CN, or a CN may be
attempting to establish a connection with the MN. In both cases,
packets sent from the CN will be forwarded by the MN's HA to the
MN's CoA. However when the packets arrive at the firewall(s), the
incoming traffic may not match any existing state, and the
firewall(s) may therefore drop it.
Le, et al. Expires August 24, 2005 [Page 14]
Internet-Draft mipv6 February 2005
Issue 3: If the MN is in a communication with a CN, the MN may
attempt to execute a RRT for packets to be route optimized.
Similarly to the issue 3, Section 5.1, the Home Test message which
should be protected by ESP may be dropped by firewall(s)
protecting the MN. Firewall(s) may as a default rule drop any ESP
traffic. As a consequence, the RRT cannot be completed.
Issue 4: If the MN is in a communication with a CN, and assuming that
the MN successfully sent a Binding Update to its CN to use Route
Optimization, packets will then be sent from the CN to the MN's
CoA and from the MN's CoA to the CN.
Packets sent from the CN to the MN's CoA may however not match any
existing entry in the firewall(s) protecting the MN, and therefore
be dropped by the firewall(s).
If packet filtering is applied to uplink traffic (i.e. traffic
sent by the MN), packets sent from the MN's CoA to the the CN may
not match any entry in the firewall(s) either and may be dropped
as well.
Le, et al. Expires August 24, 2005 [Page 15]
Internet-Draft mipv6 February 2005
6. Conclusions
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.
This document captures the various issues involved in the deployment
of Mobile IPv6 in networks that would invariably include firewalls.
A number of different scenarios are described which include
configurations where the mobile node, correspondent node and home
agent exist across various boundaries delimited by the firewalls.
This enables a better understanding of the issues when deploying
Mobile IPv6 as well as providing an understanding for firewall design
and policies to be installed therein.
Le, et al. Expires August 24, 2005 [Page 16]
Internet-Draft mipv6 February 2005
7. Security Considerations
This document describes several issues that exist between the Mobile
IPv6 protocol and firewalls.
Firewalls may prevent Mobile IP6 traffic and drop incoming/outgoing
traffic.
If the firewall configuration is modified in order to support the
Mobile IPv6 protocol but not properly configured, many attacks may be
possible as outlined above: malicious nodes may be able to launch
different types of denial of service attacks.
Le, et al. Expires August 24, 2005 [Page 17]
Internet-Draft mipv6 February 2005
8. Acknowledgments
We would like to thank James Kempf, Samita Chakrabarti and Giaretta
Gerardo for their valuable comments. Their suggestions have helped
to improve both the presentation and the content of the document.
Le, et al. Expires August 24, 2005 [Page 18]
Internet-Draft mipv6 February 2005
9. References
9.1 Normative References
[1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
9.2 Informative References
[2] Chen, X., Watson, M. and M. Harris, "Problem Statement for MIPv6
Interactions with GPRS/UMTS Packet Filtering",
Internet-Draft draft-chen-mip6-gprs-02, October 2004.
Authors' Addresses
Franck Le
Nokia Research Center
6000 Connection Drive
Irving, TX 75039
USA
Email: franck.le@nokia.com
Stefano Faccin
Nokia Research Center
6000 Connection Drive
Irving, TX 75039
USA
Email: stefano.faccin@nokia.com
Basavaraj Patil
Nokia Research Center
6000 Connection Drive
Irving, TX 75039
USA
Email: Basavaraj.Patil@nokia.com
Le, et al. Expires August 24, 2005 [Page 19]
Internet-Draft mipv6 February 2005
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Email: Hannes.Tschofenig@siemens.com
Le, et al. Expires August 24, 2005 [Page 20]
Internet-Draft mipv6 February 2005
Appendix A. Applicability to 3G Networks
In 3G networks, different packet filtering functionalities may be
implemented to prevent malicious nodes from flooding or launching
other attacks against the 3G subscribers. The packet filtering
functionality of 3G networks are further described in [2]. Packet
filters are set up and applied to both uplink and downlink traffic:
outgoing and incoming data not matching the packet filters is dropped
. The issues described in this document also apply to 3G networks.
Le, et al. Expires August 24, 2005 [Page 21]
Internet-Draft mipv6 February 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Le, et al. Expires August 24, 2005 [Page 22]