draft-ietf-mip6-firewalls-00.txt   draft-ietf-mip6-firewalls-01.txt 
INTERNET DRAFT Franck Le MIP6 F. Le
File: draft-ietf-mip6-firewalls-00.txt Stefano Faccin Internet-Draft S. Faccin
Expires: February 2005 Basavaraj Patil Expires: August 24, 2005 B. Patil
Nokia Nokia
H. Tschofenig H. Tschofenig
Siemens Siemens
August 2004 February 20, 2005
Mobile IPv6 and Firewalls Mobile IPv6 and Firewalls Problem statement
Problem statement draft-ietf-mip6-firewalls-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable This document is an Internet-Draft and is subject to all provisions
patent or other IPR claims of which I am aware have been disclosed, of Section 3 of RFC 3667. By submitting this Internet-Draft, each
and any of which I become aware will be disclosed, in accordance with 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. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as
Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than a "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 24, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract Abstract
Firewalls are an integral aspect of a majority of IP networks today Firewalls are an integral aspect of a majority of IP networks today
given the state of security in the Internet, threats and given the state of security in the Internet, threats and
vulnerabilities to data networks. IP networks today are vulnerabilities to data networks. Current IP networks are
predominantly based on IPv4 technology and hence firewalls have predominantly based on IPv4 technology and hence firewalls have been
been designed for these networks. Deployment of IPv6 networks is designed for these networks. Deployment of IPv6 networks is
currently progressing, albeit at a slower pace. Firewalls for IPv6 currently progressing, albeit at a slower pace. Firewalls for IPv6
networks are still maturing and in development. networks are still maturing and in development.
Mobility support for IPv6 has now been standardized as specified in Mobility support for IPv6 has now been standardized as specified in
RFC3775 [MIP6]. Given the fact that Mobile IPv6 is a recent RFC 3775. Given the fact that Mobile IPv6 is a recent standard, most
standard, most firewalls available for IPv6 networks today do not firewalls available for IPv6 networks do not support Mobile IPv6.
support Mobile IPv6.
Unless firewalls are aware of Mobile IPv6 protocol details, these Unless firewalls are aware of Mobile IPv6 protocol details, these
security devices will interfere in the smooth operation of the security devices will interfere in the smooth operation of the
protocol and can be a detriment to deployment. This document protocol and can be a detriment to deployment. This document
presents in detail some of the issues that people deploying IPv6 presents deployment of IPv6 networks when they support Mobile IPv6
networks which include firewalls should consider when expanding the and firewalls.
scope to support Mobile IPv6 as well.
The issues are not only applicable to firewalls protecting The issues are not only applicable to firewalls protecting enterprise
enterprise networks, but are also applicable in 3G mobile networks networks, but are also applicable in 3G mobile networks such as
such as GPRS/UMTS and cdma2000 networks where packet filters are GPRS/UMTS and CDMA2000 networks, where packet filters are implemented
implemented in the GGSN in GPRS/UMTS networks and the PDSN in in the GGSN in GPRS/UMTS networks and the PDSN in CDMA2000 networks.
cdma2000 networks.
The goal of this Internet draft is to highlight the issues with The goal of this Internet draft is to highlight the issues with
firewalls and Mobile IPv6 and act as an enabler for further firewalls and Mobile IPv6 and act as an enabler for further
discussion. Issues identified here can be solved by developing discussion. Issues identified here can be solved by developing
appropriate solutions in the MIP6 WG. appropriate solutions in the MIP6 WG.
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
1. Introduction 1. Introduction
Mobile IPv6 enables IP mobility for IPv6 nodes. It allows a mobile Mobile IPv6 enables IP mobility for IPv6 nodes. It allows a mobile
IPv6 node to be reachable via its home IPv6 address irrespective of 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 any link that the mobile attaches to. This is possible as a result
of the extensions to IPv6 defined in the Mobile IPv6 specification of the extensions to IPv6 defined in the Mobile IPv6 specification
[MIP6]. [1].
Mobile IPv6 protocol design also incorporates a feature termed as Mobile IPv6 protocol design also incorporates a feature termed as
Route Optimization. This set of extensions is a fundamental part Route Optimization. This set of extensions is a fundamental part of
of the protocol that enables optimized routing of packets between a the protocol that enables optimized routing of packets between a
Mobile Node and its correspondent node and therefore the Mobile Node and its correspondent node and therefore the performance
performance of the communication. of the communication.
In most cases, current firewall technologies however do not support In most cases, current firewall technologies, however, do not support
Mobile IPv6 or are even unaware of Mobile IPv6 headers and Mobile IPv6 or are even unaware of Mobile IPv6 headers and
extensions. Since most networks in the current business environment extensions. Since most networks in the current business environment
deploy firewalls, this may prevent future large-scale deployment of deploy firewalls, this may prevent future large-scale deployment of
the Mobile IPv6 protocol. the Mobile IPv6 protocol.
This document presents in detail some of the issues that firewalls This document presents in detail about some of the issues that
present for Mobile IPv6 deployment, as well as the impact of each firewalls present for Mobile IPv6 deployment, as well as the impact
issue. of each issue.
2. Background information 2. Terminology
2.1 Overview of stateful inspection packet filters 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.
One set of issues is related to the way IP addresses are used in 3. Abbreviations
Mobile IP, and the way state information is created and maintained
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.
Subsequently, we describe how stateful inspection packet filters This document uses the following abbreviations:
work: 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
When a MN connects to a TCP socket on another host in the Internet, 4. Overview of firewalls
it provides, at the connection setup, 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 The following provides a brief overview of firewalls. This section
makes an entry in its state table containing the destination socket is intended as a background information so that issues with the
and the response socket, and then forwards the packet to the Mobile IPv6 protocol can then be presented in detail in the following
destination. sections. Readers familiar with firewall technology may skip this
section.
When the response comes back, the filter looks up the packets There are different types of firewalls and state can be created in
source and destination sockets in its state table: If they match an these firewalls through different methods. Independent of the
expected response, the firewall lets the packet pass. If no table adopted method, firewalls typically look at five parameters of the
entry exists, the packet is dropped since it was not requested from traffic arriving at the firewalls:
inside the network.
The filter removes the state table entries when the TCP close o Source IP address
session negotiation packets are routed through, or after some o Destination IP address
period of delay, usually a few minutes. This ensures that dropped o Protocol type
connections do not leave table holes open. o Source port number
o Destination port number
For UDP, similar state is created but since UDP is connectionless Based on these parameters, firewalls usually decide whether to allow
and the protocol does not have indication of the beginning nor the the traffic or to drop the packets. Some firewalls may filter only
end of a session, the state is based only on timers. incoming traffic while others may also filter outgoing traffic.
2.2 Mobile IP6 issues with packet filtering in 3G networks 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.
In 3G networks, packet filtering functionalities may be implemented When a MN connects using TCP to another host in the Internet, it
to prevent malicious nodes from flooding or launching other attacks sends a TCP SYN message to set up the connection. When that SYN
against the 3G subscribers. The packet filtering functionality of packet is routed through the firewall, the firewall creates an entry
3G networks are further described in [3GPP]. 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.
In such case, packet filters are set up and applied to both uplink The filter removes the state table entries when the TCP close session
and downlink traffic: outgoing and incoming data not matching the negotiation packets are routed through, or after some period of
packet filters is dropped. delay, usually a few minutes. This ensures that dropped connections
do not leave table holes open.
The issues described in the following sections thus also apply to For UDP, similar state is created but since UDP is connectionless and
3G networks. the protocol does not have indication of the beginning nor the end of
a session, the state is based only on timers.
3. Analysis of various scenarios involving MIP6 nodes and firewalls 5. Analysis of various scenarios involving MIP6 nodes and firewalls
The following section describes various scenarios involving MIP6 The following section describes various scenarios involving MIP6
nodes and firewalls and presents the issues related to each nodes and firewalls and also presents the issues related to each
scenario. scenario.
In the following section, the node in a network protected by a The Mobile IPv6 specifications define three main entities: the Mobile
firewall will be refered to the inner node, and the node in the Node (MN), the Correspondent Node (CN) and the Home Agent (HA). Each
external network will be refered to the external node. 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
| | | |
| +---+ +----+ +----------------+
| | A | | FW |
| +---+ +----+
|Inner Node | +---+
| | | B |
| | +---+
+----------------+ External Node
Network protected Network protected
by a firewall
Figure 1. Illustration of inner and external nodes Figure 1: Issues between MIP6 and firewalls when MN is in a network
protected by firewalls
3.1 Scenario when the external node is a Mobile Node A number of issues need to be considered:
Let's assume a communication between an internal node A, and an Issue 1: When the MN A connects to the network, it should acquire a
external Mobile Node B. The node A is in a network protected by a local IP address (CoA), and send a Binding Update to its Home
firewall, and node B may also be protected by a firewall but this Agent to update the HA with its current point of attachment. The
section focuses on the issues related to the firewall protecting Binding Updates and Acknowledgements should be protected by IPsec
the node A. Issues related to the firewall protecting node B are ESP according to the MIPv6 specifications [1]. However, as a
further described in the following section. 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.
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 | | | | HA |
| | +----+ | | +----+
| | Home Agent | | Home Agent
| +---+ +----+ of B | +---+ +----+ of B
| | A | | FW | | |CN | | FW |
| +---+ +----+ | +---+ +----+
| | +---+ | | +---+
| | | B | | | | B |
| | +---+ | | +---+
+----------------+ External Mobile +----------------+ External Mobile
Network protected Node Network protected Node
by a firewall by a firewall
Figure 2. Issues between MIP6 and firewalls Figure 2: Issues between MIP6 and firewalls when a CN is in a network
when a firewall is protecting the CN protected by firewalls
3.1.1 Return Routability Test sp
As specified in Mobile IPv6 [MIP6], a MN should base its
communication on the Home IP address of B, IP HoA B, and not on the
care-of-address that B obtains while attached to a link other than
its home link.
The state created by the stateful inspection packet filter The following issues need to be considered:
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 its home link, packets are Issue 1: The MN, MN B, should use its Home Address, HoA B, when
directly exchanged between the nodes A and B. If the Mobile Node B establishing the communication with the CN (CN A) if the MN (MN B)
is attached to any other link than its home link (in which case it wants to take advantage of the mobility support provided by the
has a care-of-address), the session can still be maintained by Mobile IPv6 protocol, for its communication with CN A. The state
having the MN tunnel the traffic destined to the CN (Node A) via created by the firewall protecting CN A is therefore created based
its home agent [MIP6]. Packets forwarded by the Home Agent to the on the IP address of A (IP A) and the home address of the node B
node A will have the source IP address indicating the Home IP (IP HoA B). The states may be created via different means and the
address of B and the destination IP address indicating the IP protocol type as well as the port numbers depend on the connection
address of A. Such packets can thus pass the firewall functionality set up.
protecting A.
However nodes A and B might be topologically close to each other Uplink packet filters (1)
while B's Home Agent may be far away, resulting in a trombone Source IP address: IP A
effect that can create delay and degrade the performance. Destination IP address: HoA B
Protocol Type: TCP/UDP
Source Port Number: #1
Destination Port Number: #2
Route Optimization is a feature that enables a MN to communicate Downlink packet filters (2)
directly with its CN, without involving the MN's Home Agent in the Source IP address: HoA B
data path. So in the current scenario the MN B can initiate the Destination IP address: IP A
route optimization procedure with Node A. Route optimization Protocol Type: TCP/UDP
requires the MN B to send a Binding Update to Node A in order to Source Port Number: #2
create an entry in its binding cache that maps the MNs home address Destination Port Number: #1
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 message via its Nodes A and B might be topologically close to each other while B's
Home Agent and 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:
- a Care of Test Init message directly to its Correspondent Node A. * 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 new CoA of B as the 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 source address. Such a packet does not match any entry in the
firewall protecting A and as described in Section 2, the CoTi protecting firewall (2). The CoTi message will thus be dropped by
message will thus be dropped by the firewall. As a consequence, the the firewall.
RRT cannot be completed and route optimization cannot be applied.
Every packet has to go through the node B's Home Agent and tunneled The HoTI is a Mobility Header packet, and the protocol type
between B's Home Agent and B. 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.
+----------------+ +----------------+
| +----+ HoTI (HoA) +----+ | +----+ HoTI (HoA) +----+
| | FW |<----------------|HA B| | | FW |X<---------------|HA B|
| +----X +----+ | +----X +----+
| +---+ | ^ (CoTI is dropped ^ | +---+ | ^ CoTI & HoTI ^
| | A | | | by FW) | | | A | | | dropped by FW |
| +---+ | | | HoTI | +---+ | | | HoTI
| | | | | | | |
| | | CoTI (CoA)+---+ | | | CoTI (CoA)+---+
| | +------------------| B | | | +------------------| B |
+----------------+ +---+ +----------------+ +---+
Network protected External Mobile Network protected External Mobile
by a firewall Node by a firewall Node
Figure 3. Issues with Return Routability Test Figure 3: Issues with Return Routability Test
3.1.2 Issues with Firewall Status Update Issue 2: Let's assume that the Binding Update to the CN is
successful, the firewall(s) might still drop packets
Even if firewalls are made MIPv6 aware (which might require a 1. coming from the CoA, since these incoming packets are sent
different Binding Update security solution) a firewall might still from the CoA and do not match the Downlink Packet filter (2)
drop packets coming from the new CoA since these incoming packets 2. sent from the CN to the CoA if uplink packet filters are
do not match any existing entry. implemented. The uplink packets are sent to the MN's CoA and
do not match the uplink packet filter (1).
The packet filters in the firewall need to be updated with the COA The packet filters for the traffic sent to (resp. from) the CoA
of the MN in addition to its HoA. need to be created in the firewall(s).
Requiring the stateful inspection filters to update the connection Requiring the firewalls to update the connection state upon
state upon detecting Binding Update messages from a node outside detecting Binding Update messages from a node outside the network
the network protected by the firewall does not appear feasible nor protected by the firewall does not appear feasible nor desirable,
desirable, since currently the firewall does not have any means to since currently the firewall does not have any means to verify the
verify the validity of Binding Update messages and to therefore validity of Binding Update messages and to therefore securely
securely modify the state information. Changing the firewall modify the state information. Changing the firewall states
states without verifying the validity of the Binding Update without verifying the validity of the Binding Update messages
messages could lead to denial of service attacks. Malicious nodes could lead to denial of service attacks. Malicious nodes may send
may send faked Binding Update forcing the firewall to change its faked Binding Update forcing the firewall to change its state
state information, and therefore leading the firewall to drop information, and therefore leading the firewall to drop packets
packets from the connections that use the legitimate addresses. An from the connections that use the legitimate addresses. An
adversary might also use an address update to enable its own adversary might also use an address update to enable its own
traffic to enter the network. traffic to enter the network.
3.2 Scenario when the inner node is a Mobile Node Issue 3: Let's assume that the Binding Update to the CN is
successful. The CN may be protected by different firewalls and as
Let's assume a communication between an internal Mobile Node A, a result of the MN's change of IP address, incoming and outgoing
protected by a firewall, and an external node B. B can also be a traffic may pass through a different firewall. The new firewall
Mobile Node protected by a firewall and issues raised in Section 3 may not have any state associated with the CN and incoming
apply in such case. (potentially outgoing traffic) may be dropped at the firewall.
+----------------+ +----+
| | | HA |
| | +----+
| | Home Agent
| +---+ +----+ of A +---+
| | A | | FW | | B |
| +---+ +----+ +---+
|Internal | External
| MN | Node
| |
+----------------+
Network protected
Figure 4. Issues between MIP6 and firewalls
when a firewall is protecting the MN
3.2.1 Issues with Binding Updates and Acknowledgements between the
Mobile Nodes and their Home Agent
As required by [MIP6], the Mobile Node and the Home Agent MUST use
IPsec to protect the integrity and authenticity of the Binding
Updates and Acknowledgements. Both the Mobile Nodes and the Home
Agents SHOULD use the Encapsulating Security Payload (ESP).
Many firewalls would however drop ESP packets (default behavior).
This may cause the Binding Updates and Acknowledgements between the
Mobile Nodes and their Home Agent to be dropped.
3.2.2 Issues with Reachability
One of the main advantages of Mobile IPv6 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 MN which causes the packet to be routed to the
home link of the MN. The Home agent intercepts the packet destined
for the MN and forwards it to the MNs current point of attachment
which is indicated by its care-of-address.
When considering firewalls, (e.g. when the Mobile Node roams to a
network protected by a firewall), 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. The following further
describes the problem that might occur:
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 a state in the firewall:
- it may be a state for the IPsec packet (in the case, the Binding
Update message is protected by IPsec)
- or it may be a state for a mobility header in case IPsec is not
used, but the security of the Binding Update is being provided by
some other means such as an authentication option as specified in
[AUTH] to solve the issue described in Section 4.1
The Binding Acknowledgement response can pass the firewall due to
the created state, and be delivered to the Mobile Node.
Some firewalls may leave the created state open for a while
(implementation dependent), whereas other firewalls may delete the
state upon receiving the Binding Acknowledgement message.
Let's assume a Correspondent Node tries to initiate a communication
with a Mobile Node. The Correspondent Node 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.
As described in Section 2, the lifetime corresponding to the state
in the firewall may have been 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 (IPsec or 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.
3.2.3 Return Routability Test
Security of Mobile IPv6 Binding Update between the MN and the CN is
based on the RRT mechanism, the routing infrastructure and secret
sharing (see [MIP6]). Since some RRT messages are routed via the
home network, the strong trust relationship between the mobile node
and the home agent (and the usage of IPsec ESP) is important. 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."
Section 10.4.6 furthermore specifies:
"The return routability procedure described in Section 5.2.5 5.3 Scenario where the HA is in a network protected by firewall(s)
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 Let's consider a MN moving into a network protected by firewall(s).
protected by a firewall, the requirement can be an issue. The following issues may exist:
Typically firewalls need to filter the packets based on the Issue 1: If the firewall(s) block ESP traffic, many of the MIPv6
source/destination IP addresses and the TCP/UDP source/destination signaling (e.g. Binding Update, HoT) may be dropped at the
ports numbers. When a packet is encrypted using IPsec ESP, such firewall(s) preventing MN(s) from updating their binding cache and
information is not available (in particular the port numbers), performing Route Optimization, since Binding Update, HoT and other
therefore firewalls may drop the Home Test messages forwarded by MIPv6 signaling must be protected by IPsec ESP.
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 Issue 2: If the firewall(s) protecting the Home Agent block
containing the Mobility Header defined by MIPv6, i.e., packets for unsolicited incoming traffic (e.g. as stateful inspection packet
which Mobile IPv6 is used, from other packets. In order to support filters do), the firewall(s) may drop connection set up requests
RRT, one possible idea could be to let the firewall pass all ESP from CN, and packets from MN.
packets coming from the MNs Home Agent. This may, however, not be
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 attacks such as overbilling since the
user is required to pay for all air-interface utilization.
A common approach, which is also used for NAT traversal, is to Issue 3: If the Home Agent is in a network protected by several
apply UDP encapsulation of IPsec packets. Unlike with NAT traversal firewalls, a MN/CN's change of IP address may result in the
it is not possible to detect the presence of a Firewall traffic to and from the Home Agent passing through a different
automatically in the same fashion as with a NAT. A NAT modifies the firewall that may not have the states corresponding to the flows.
source IP address when an IP packet travels from the private to the As a consequence, packets may be dropped at the firewall.
public addressing space. For a Firewall this is not true. Hence,
UDP encapsulation needs to be enabled proactively.
The Mobile Node would have to send UDP packets to the Home Agent to 5.4 Scenario where MN moves to a network protected by firewall(s)
create the corresponding necessary state in the firewall. The Home
Agent should also encapsulate the HoT message in a UDP datagram.
As other possible solutions, the home keygen token could be Let's consider a HA in a network protected by firewall(s). The
encrypted not using IPsec ESP but specific MIP6 fields within the following issues need to be investigated:
HoT message so that the packet still appears as a Mobility Header
one to the firewall as specified in [AUTH].
3.2.4 Issues with Change of CoA Issue 1: Similarly to the issue 1 described in Section 5.1, the MN
The internal node A may change its CoA within the network which is will send a Binding Update to its Home Agent after acquiring a
protected by a firewall. Node A updates its mobility binding at the local IP address (CoA). The Binding Updates and Acknowledgements
Home Agent by sending a Binding Update. Node A may also send should be protected by IPsec ESP according to the MIPv6
Binding Update to its correspondent nodes. 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.
However, even if firewalls are made MIPv6 aware to address the Issue 2: The MN may be in a communication with a CN, or a CN may be
issues described in sections 4.1, 4.2 and 4.3, a firewall might attempting to establish a connection with the MN. In both cases,
still drop incoming packets sent to the new CoA since these packets sent from the CN will be forwarded by the MN's HA to the
incoming packets do not match any existing entry. 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.
The packet filters in the firewall needs to be updated with the new Issue 3: If the MN is in a communication with a CN, the MN may
COA of the MN. 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.
3.2.5 Change of firewall 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).
When the MN A moves, it may move to a link that is served by a If packet filtering is applied to uplink traffic (i.e. traffic
different firewall. Node A might be sending BU to its CN, however sent by the MN), packets sent from the MN's CoA to the the CN may
incoming packets may be dropped at the firewall since the firewall not match any entry in the firewall(s) either and may be dropped
on the new link that the MN attaches to does not have any state as well.
that is associated with the MN.
4. Conclusion 6. Conclusions
Current firewalls may not only prevent route optimization but may Current firewalls may not only prevent route optimization but may
also prevent communications to be established in some cases. This also prevent communications to be established in some cases. This
document describes some of the issues between the Mobile IP document describes some of the issues between the Mobile IP protocol
protocol and current firewall technologies. and current firewall technologies.
This document captures the various issues involved in the This document captures the various issues involved in the deployment
deployment of Mobile IPv6 in networks that would invariably include of Mobile IPv6 in networks that would invariably include firewalls.
firewalls. A number of different scenarios are described which A number of different scenarios are described which include
include configurations where the mobile node, correspondent node configurations where the mobile node, correspondent node and home
and home agent exist across various boundaries delimited by the agent exist across various boundaries delimited by the firewalls.
firewalls. This enables a better understanding of the issues when This enables a better understanding of the issues when deploying
deploying Mobile IPv6 as well as providing an understanding for Mobile IPv6 as well as providing an understanding for firewall design
firewall design and policies to be installed therein. and policies to be installed therein.
5. Security Considerations 7. Security Considerations
This document describes several issues that exist between the This document describes several issues that exist between the Mobile
Mobile IPv6 protocol and firewalls. IPv6 protocol and firewalls.
Firewalls may prevent Mobile IP6 traffic and drop incoming/outgoing Firewalls may prevent Mobile IP6 traffic and drop incoming/outgoing
traffic. traffic.
If the firewall configuration is modified in order to support the If the firewall configuration is modified in order to support the
Mobile IPv6 protocol but not properly configured, many attacks may Mobile IPv6 protocol but not properly configured, many attacks may be
be possible as outlined above: malicious nodes may be able to possible as outlined above: malicious nodes may be able to launch
launch different types of denial of service attacks. different types of denial of service attacks.
6. References 8. Acknowledgments
[3GPP] X. Chen, M. Watson, J. Wiljakka and J. Rinne We would like to thank James Kempf, Samita Chakrabarti and Giaretta
Problem Statement for MIPv6 Interactions with GPRS/UMTS Gerardo for their valuable comments. Their suggestions have helped
Packet Filtering IETF internet draft <draft-chen- to improve both the presentation and the content of the document.
mip6-gprs-01.txt>, July 2004
[AUTH] A. Patel, K. Leung, M. Khalil, H. Akhtar and 9. References
K. Chowdhury, Authentication Protocol for Mobile IPv6,
IETF internet draft <draft-patel-mipv6-auth-
protocol-01.txt>, May 24, 2004
[CHES] William R. Cheswick and Steve M. Bellovin 9.1 Normative References
Firewalls and Internet Security, Repelling the Wily
Hacker
[MIP6] D. Johnson, C. Perkins, J. Arkko, "Mobility Support [1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
in IPv6", RFC 3775, June 2004 IPv6", RFC 3775, June 2004.
[STUN] Rosenberg, J., Weinberger, J., Huitema, C. and 9.2 Informative References
R. Mahy, "STUN - Simple Traversal of User Datagram
Protocol (UDP) Through Network Address Translators
(NATs)", RFC 3489, March 2003.
8. Author's Addresses: [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 Franck Le
Nokia Research Center, Dallas Nokia Research Center
6000 Connection Drive 6000 Connection Drive
Irving, TX-75039, USA. Irving, TX 75039
USA
E-Mail: franck.le@nokia.com Email: franck.le@nokia.com
Phone : +1 972 374 1256
Stefano Faccin Stefano Faccin
Nokia Research Center, Dallas Nokia Research Center
6000 Connection Drive 6000 Connection Drive
Irving, TX-75039. USA. Irving, TX 75039
USA
Email: stefano.faccin@nokia.com
E-Mail: stefano.faccin@nokia.com
Phone : +1 972 894 4994
Basavaraj Patil Basavaraj Patil
Nokia, Dallas Nokia Research Center
6000 Connection Drive 6000 Connection Drive
Irving, TX-75039, USA. Irving, TX 75039
USA
EMail: Basavaraj.Patil@nokia.com
Phone: +1 972-894-6709
Email: Basavaraj.Patil@nokia.com
Hannes Tschofenig Hannes Tschofenig
Siemens Siemens
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bayern 81739 Munich, Bavaria 81739
Germany Germany
EMail: Hannes.Tschofenig@siemens.com Email: Hannes.Tschofenig@siemens.com
9. IPR Statement 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.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intel- lectual Property Rights or other rights that might be Intellectual Property Rights or other rights that might be claimed to
claimed to pertain to the implementation or use of the technology pertain to the implementation or use of the technology described in
described in this docu- ment or the extent to which any license this document or the extent to which any license under such rights
under such rights might or might not be available; nor does it might or might not be available; nor does it represent that it has
represent that it has made any independent effort to identify any made any independent effort to identify any such rights. Information
such rights. Information on the procedures with respect to rights on the procedures with respect to rights in RFC documents can be
in RFC documents can be found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use attempt made to obtain a general license or permission for the use of
of such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository at
at http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this stan- dard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Warranty Disclaimer of Validity
This document and the information contained herein are provided on This document and the information contained herein are provided on an
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
THE USE OF THE INFORMA- TION HEREIN WILL NOT INFRINGE ANY RIGHTS OR INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is Copyright (C) The Internet Society (2005). This document is subject
subject to the rights, licenses and restrictions contained in BCP to the rights, licenses and restrictions contained in BCP 78, and
78, and except as set forth therein, the authors retain all their except as set forth therein, the authors retain all their rights.
rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/