draft-ietf-mip6-firewalls-04.txt   rfc4487.txt 
MIP6 F. Le Network Working Group F. Le
Internet-Draft CMU Request for Comments: 4487 CMU
Expires: July 29, 2006 S. Faccin Category: Informational S. Faccin
B. Patil B. Patil
Nokia Nokia
H. Tschofenig H. Tschofenig
Siemens Siemens
January 25, 2006 May 2006
Mobile IPv6 and Firewalls: Problem statement Mobile IPv6 and Firewalls: Problem Statement
draft-ietf-mip6-firewalls-04.txt
Status of this Memo Status of This Memo
By submitting this Internet-Draft, each author represents that any This memo provides information for the Internet community. It does
applicable patent or other IPR claims of which he or she is aware not specify an Internet standard of any kind. Distribution of this
have been or will be disclosed, and any of which he or she becomes memo is unlimited.
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Copyright Notice
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 Copyright (C) The Internet Society (2006).
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 Abstract
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at This document captures the issues that may arise in the deployment of
http://www.ietf.org/shadow.html. 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
General Packet Radio Service / Universal Mobile Telecommunications
System (GPRS/UMTS) and CDMA2000 networks.
This Internet-Draft will expire on July 29, 2006. The goal of this document 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.
Copyright Notice Table of Contents
Copyright (C) The Internet Society (2006). 1. Introduction ....................................................3
2. Terminology .....................................................4
3. Abbreviations ...................................................4
4. Overview of Firewalls ...........................................4
5. Analysis of Various Scenarios Involving MIP6 Nodes and
Firewalls .......................................................6
5.1. Scenario Where the Mobile Node Is in a Network
Protected by Firewall(s) ...................................7
5.2. Scenario Where the Correspondent Node Is in a
Network Protected by Firewall(s) ...........................9
5.3. Scenario Where the HA Is in a Network Protected by
Firewall(s) ...............................................12
5.4. Scenario Where the MN Moves to a Network Protected by
Firewall(s) ...............................................12
6. Conclusions ....................................................13
7. Security Considerations ........................................14
8. Acknowledgements ...............................................14
9. References .....................................................14
9.1. Normative References ......................................14
9.2. Informative References ....................................14
Appendix A. Applicability to 3G Networks ..........................15
Abstract 1. Introduction
Network elements such as firewalls are an integral aspect of a Network elements such as firewalls are an integral aspect of a
majority of IP networks today, given the state of security in the majority of IP networks today, given the state of security in the
Internet, threats, and vulnerabilities to data networks. Current IP Internet, threats, and vulnerabilities to data networks. Current IP
networks are predominantly based on IPv4 technology and hence networks are predominantly based on IPv4 technology, and hence
firewalls have been designed for these networks. Deployment of IPv6 firewalls have been designed for these networks. Deployment of IPv6
networks is currently progressing, albeit at a slower pace. networks is currently progressing, albeit at a slower pace.
Firewalls for IPv6 networks are still maturing and in development. Firewalls for IPv6 networks are still maturing and in development.
Mobility support for IPv6 has been standardized as specified in RFC Mobility support for IPv6 has been standardized as specified in RFC
3775. Given the fact that Mobile IPv6 is a recent standard, most 3775. Given the fact that Mobile IPv6 is a recent standard, most
firewalls available for IPv6 networks do not support Mobile IPv6. firewalls available for IPv6 networks do not 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 with the smooth operation of the
protocol and can be a detriment to deployment. This document protocol and can be a detriment to deployment.
captures the issues that may arise in the 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 CDMA 2000 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.
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) . . . . . . . . . . . . . . . . . . . . . . . 15
5.4. Scenario where MN moves to a network protected by
firewall(s) . . . . . . . . . . . . . . . . . . . . . . . 15
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Applicability to 3G Networks . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 23
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
[1]. [1].
Mobile IPv6 protocol design also incorporates a feature termed as Mobile IPv6 protocol design also incorporates a feature termed Route
Route Optimization. This set of extensions is a fundamental part of Optimization. This set of extensions is a fundamental part of the
the protocol that enables optimized routing of packets between a protocol that enables optimized routing of packets between a mobile
Mobile Node and its correspondent node and therefore the performance node and its correspondent node and therefore optimized 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 aware of Mobile IPv6 headers and and Mobile IPv6 or are not even aware 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 some of the issues that firewalls
present for Mobile IPv6 deployment, as well as the impact of each present for Mobile IPv6 deployment, as well as the impact of each
issue. issue.
2. Terminology 2. Terminology
skipping to change at page 7, line 5 skipping to change at page 4, line 40
o HoTI: Home Test Init o HoTI: Home Test Init
o HoT: Home Test o HoT: Home Test
o MN: Mobile Node o MN: Mobile Node
o RO: Route Optimization o RO: Route Optimization
o RRT: Return Routability Test o RRT: Return Routability Test
4. Overview of firewalls 4. Overview of Firewalls
The following section provides a brief overview of firewalls. It is The following section provides a brief overview of firewalls. It is
intended as background information so that issues with the Mobile intended as background information so that issues with the Mobile
IPv6 protocol can then be presented in detail in the following IPv6 protocol can then be presented in detail in the following
sections. sections.
There are different types of firewalls and state can be created in There are different types of firewalls, and state can be created in
these firewalls through different methods. Independent of the these firewalls through different methods. Independent of the
adopted method, firewalls typically look at five parameters of the adopted method, firewalls typically look at five parameters of the
traffic arriving at the firewalls: traffic arriving at the firewalls:
o Source IP address o Source IP address
o Destination IP address o Destination IP address
o Protocol type o Protocol type
o Source port number o Source port number
o Destination port number o Destination port number
Based on these parameters, firewalls usually decide whether to allow Based on these parameters, firewalls usually decide whether to allow
the traffic or to drop the packets. Some firewalls may filter only the traffic or to drop the packets. Some firewalls may filter only
incoming traffic while others may also filter outgoing traffic. incoming traffic, while others may also filter outgoing traffic.
According to Section 3.29 of RFC 2647 [2] stateful packet filtering According to Section 3.29 of RFC 2647 [2], stateful packet filtering
refers to the process of forwarding or rejecting traffic based on the refers to the process of forwarding or rejecting traffic based on the
contents of a state table maintained by a firewall. These types of contents of a state table maintained by a firewall. These types of
firewalls are commonly deployed to protect networks from different firewalls are commonly deployed to protect networks from different
threats, such as blocking unsolicited incoming traffic from the threats, such as blocking unsolicited incoming traffic from the
external networks. The following briefly describes how these external networks. The following briefly describes how these
firewalls work since they can create additional problems with the firewalls work since they can create additional problems with the
Mobile IPv6 protocol as described in the subsequent sections. Mobile IPv6 protocol as described in the subsequent sections.
When a MN connects using TCP to another host in the Internet, it In TCP, an MN sends a TCP SYN message to connect to another host in
sends a TCP SYN message to set up the connection. When that SYN the Internet.
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 before forwarding
the packet to the destination. When an incoming message from the
external networks reaches the firewall, it searches the packet's
source IP address, destination IP address, Protocol type, source port
number and destination port number in its state table to see if the
packet matches the characteristics of a request sent previously. If
so, the firewall lets the packet pass. Otherwise, the packet is
dropped since it was not requested from inside the network.
The firewall removes the state table entries either when the TCP Upon receiving that SYN packet, the firewall records the source IP
close session negotiation packets are routed through, or after some address, the destination IP address, the Protocol type, the source
configurable timeout period. This ensures that dropped connections port number, and the destination port number indicated in that packet
do not leave holes open in the firewall. before transmitting it to the destination.
For UDP, similar state is created. However, since UDP is When an incoming message from the external networks reaches the
connectionless and the protocol does not have an indication of the firewall, it searches the packet's source IP address, destination IP
beginning nor the end of a session, the state is based only on address, Protocol type, source port number, and destination port
timers. number in its entries to see if the packet matches the
characteristics of a request sent previously. If so, the firewall
allows the packet to enter the network. If the packet was not
solicited from an internal node, the packet is blocked.
5. Analysis of various scenarios involving MIP6 nodes and firewalls When the TCP close session packets are exchanged or after some
configurable period of inactivity, the associated entry in the
firewall is deleted. This mechanism prevents entries from remaining
when TCP are abruptly terminated.
A similar entry is created when using UDP. The difference with this
transport protocol is that UDP is connectionless and does not have
packets signaling the initiation or termination of a session.
Consequently, the duration of the entries relies solely on timers.
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 also presents the issues related to each nodes and firewalls and also presents the issues related to each
scenario. scenario.
The Mobile IPv6 specifications define three main entities: the Mobile The Mobile IPv6 specifications define three main entities: the mobile
Node (MN), the Correspondent Node (CN) and the Home Agent (HA). Each node (MN), the correspondent node (CN), and the home agent (HA).
of these entities may be in a network protected by one or many Each of these entities may be in a network protected by one or many
firewalls: firewalls:
o Section 5.1 analyzes the issues when the MN is in a network o Section 5.1 analyzes the issues when the MN is in a network
protected by firewall(s) protected by firewall(s)
o Section 5.2 analyzes the issues when the CN is in a network o Section 5.2 analyzes the issues when the CN is in a network
protected by firewall(s) protected by firewall(s)
o Section 5.3 analyzes the issues when the HA is in a network o Section 5.3 analyzes the issues when the HA is in a network
protected by firewall(s) protected by firewall(s)
The MN may also be moving from an external network, to a network 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 protected by firewall(s). The issues of this case are described in
Section 5.4. Section 5.4.
Some of the described issues (e.g. Section 5.1 and Section 5.2) may Some of the described issues (e.g., Sections 5.1 and 5.2) may require
require modifications to the protocols or to the firewalls, and modifications to the protocols or to the firewalls, and others (e.g.,
others (e.g. Section 5.3) may require only appropriate rules and Section 5.3) may require only that appropriate rules and
configuration to be in place. configuration be in place.
5.1. Scenario where the Mobile Node is in a network protected by 5.1. Scenario Where the Mobile Node Is in a Network Protected by
firewall(s) Firewall(s)
Let's consider a MN A, in a network protected by firewall(s). Let's consider MN A, in a network protected by firewall(s).
+----------------+ +----+ +----------------+ +----+
| | | HA | | | | HA |
| | +----+ | | +----+
| | Home Agent | | Home Agent
| +---+ +----+ of A +---+ | +---+ +----+ of A +---+
| | A | | FW | | B | | | A | | FW | | B |
| +---+ +----+ +---+ | +---+ +----+ +---+
|Internal | External |Internal | External
| MN | Node | MN | Node
| | | |
+----------------+ +----------------+
Network protected Network protected
Figure 1: Issues between MIP6 and firewalls when MN is in a network Figure 1: Issues between MIP6 and firewalls when MN is in a network
protected by firewalls protected by firewalls
A number of issues need to be considered: A number of issues need to be considered:
Issue 1: When the MN A connects to the network, it should acquire a Issue 1: When MN A connects to the network, it should acquire a local
local IP address (CoA), and send a Binding Update to its Home IP address (CoA) and send a Binding Update (BU) to its Home Agent
Agent to update the HA with its current point of attachment. The to update the HA with its current point of attachment. The
Binding Updates and Acknowledgements should be protected by IPsec Binding Updates and Acknowledgements should be protected by IPsec
ESP according to the MIPv6 specifications [1]. However, as a ESP according to the MIPv6 specifications [1]. However, as a
default rule, many firewalls drop IPsec ESP packets because they default rule, many firewalls drop IPsec ESP packets because they
cannot determine whether inbound ESP packets are legitimate. It cannot determine whether inbound ESP packets are legitimate. It
is difficult or impossible to create useful state by observing the is difficult or impossible to create useful state by observing the
outbound ESP packets. This may cause the Binding Updates and outbound ESP packets. This may cause the Binding Updates and
Acknowledgements between the Mobile Nodes and their Home Agent to Acknowledgements between the mobile nodes and their home agent to
be dropped. be dropped.
Issue 2: Let's now consider a node in the external network, B, trying Issue 2: Let's now consider a node in the external network, B, trying
to establish a communication with MN A. to establish a communication with MN A.
* B sends a packet to the Mobile Node's home address. * B sends a packet to the mobile node's home address.
* The packet is intercepted by the MN's Home Agent which tunnels * The packet is intercepted by the MN's home agent, which tunnels
it to the MN's CoA [1]. it to the MN's CoA [1].
* When arriving at the firewall(s) protecting MN A, the packet * When arriving at the firewall(s) protecting MN A, the packet
may be dropped since the incoming packet may not match any may be dropped since the incoming packet may not match any
existing state. As described in Section 4, stateful inspection existing state. As described in Section 4, stateful inspection
packet filters e.g. typically drop unsolicited incoming packet filters (for example) typically drop unsolicited
traffic. incoming traffic.
* B will thus not be able to contact the MN A and establish a * B will thus not be able to contact MN A and establish a
communication. communication.
Even though the HA is updated with the location of a MN, firewalls Even though the HA is updated with the location of an MN,
may prevent Correspondent nodes from establishing communications firewalls may prevent correspondent nodes from establishing
when the MN is in a network protected by firewall(s). 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 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 node B. MN A may want to use Route Optimization (RO) so that
packets can be directly exchanged between the MN and the CN packets can be directly exchanged between the MN and the CN
without passing through the HA. However the firewalls protecting without passing through the HA. However, the firewalls protecting
the MN might present issues with the Return Routability procedure the MN might present issues with the Return Routability procedure
that needs to be performed prior to using RO. that needs to be performed prior to using RO.
According to the MIPv6 specifications, the Home Test message of According to the MIPv6 specifications, the Home Test message of
the RRT must be protected by IPsec in tunnel mode. However, the RRT must be protected by IPsec in tunnel mode. However,
firewalls might drop any packet protected by ESP, since the firewalls might drop any packet protected by ESP, since the
firewalls cannot analyze the packets encrypted by ESP (e.g. port firewalls cannot analyze the packets encrypted by ESP (e.g., port
numbers). The firewalls may thus drop the Home Test messages and numbers). The firewalls may thus drop the Home Test messages and
prevent the completion of the RRT procedure. prevent the completion of the RRT procedure.
Issue 4: Let's assume that MN A successfully sends a Binding Update Issue 4: Let's assume that MN A successfully sends a Binding Update
to its Home Agent (resp. Correspondent nodes) - issues 1 (resp. to its home agent (resp. correspondent nodes) -- which solves
issue 3) solved - the subsequent traffic is sent from the HA issue 1 (resp. issue 3) -- and that the subsequent traffic is sent
(resp. CN) to the MN's CoA. However there may not be any from the HA (resp. CN) to the MN's CoA. However there may not be
corresponding state in the firewalls. The firewalls protecting A any corresponding state in the firewalls. The firewalls
may thus drop the incoming packets. protecting A may thus drop the incoming packets.
The appropriate states for the traffic to the MN's CoA need to be The appropriate states for the traffic to the MN's CoA need to be
created in the firewall(s). created in the firewall(s).
Issue 5: When the MN A moves, it may move to a link that is served by Issue 5: When MN A moves, it may move to a link that is served by a
a different firewall. MN A might be sending a BU to its CN, different firewall. MN A might be sending a BU to its CN;
however incoming packets may be dropped at the firewall, since the however, incoming packets may be dropped at the firewall, since
firewall on the new link that the MN attaches to does not have any the firewall on the new link that the MN attaches to does not have
state that is associated with the MN. any state that is associated with the MN.
The issues described above result from the fact that the MN is behind The issues described above result from the fact that the MN is behind
the firewall. Consequently, the MN's communication capability with the firewall. Consequently, the MN's communication capability with
other nodes is affected by the firewall rules. other nodes is affected by the firewall rules.
5.2. Scenario where the Correspondent Node is in a network protected by 5.2. Scenario Where the Correspondent Node Is in a Network Protected by
firewall(s) Firewall(s)
Let's consider a MN in a network, communicating with a Correspondent Let's consider an MN in a network, communicating with a Correspondent
Node C in a network protected by firewall(s). There are no issues Node C in a network protected by firewall(s). There are no issues
with the presence of a firewall in the scenario where the MN is with the presence of a firewall in the scenario where the MN is
sending packets to the CN via a reverse tunnel that is setup between sending packets to the CN via a reverse tunnel that is setup between
the MN and HA. However firewalls may present different issues to the MN and HA. However, firewalls may present different issues to
Route Optimization. Route Optimization.
+----------------+ +----+ +----------------+ +----+
| | | HA | | | | HA |
| | +----+ | | +----+
| | Home Agent | | Home Agent
| +---+ +----+ of B | +---+ +----+ of B
| |CN | | FW | | |CN | | FW |
| | C | +----+ | | C | +----+
| +---+ | +---+ | +---+ | +---+
skipping to change at page 12, line 26 skipping to change at page 9, line 34
| | +---+ | | +---+
+----------------+ External Mobile +----------------+ External Mobile
Network protected Node Network protected Node
by a firewall by a firewall
Figure 2: Issues between MIP6 and firewalls when a CN is in a network Figure 2: Issues between MIP6 and firewalls when a CN is in a network
protected by firewalls protected by firewalls
The following issues need to be considered: The following issues need to be considered:
Issue 1: The MN, MN B, should use its Home Address, HoA B, when Issue 1: The MN (MN B) should use its Home Address (HoA B) when
establishing the communication with the CN (CN C) if the MN (MN B) establishing the communication with the CN (CN C), if MN B wants
wants to take advantage of the mobility support provided by the to take advantage of the mobility support provided by the Mobile
Mobile IPv6 protocol, for its communication with CN C. The state IPv6 protocol for its communication with CN C. The state created
created by the firewall protecting CN C is therefore created based by the firewall protecting CN C is therefore created based on the
on the IP address of C (IP C) and the home address of the node B IP address of C (IP C) and the home address of Node B (IP HoA B).
(IP HoA B). The states may be created via different means and the The states may be created via different means, and the protocol
protocol type as well as the port numbers depend on the connection type as well as the port numbers depend on the connection setup.
set up.
Uplink packet filters (1) Uplink packet filters (1)
Source IP address: IP C Source IP address: IP C
Destination IP address: HoA B Destination IP address: HoA B
Protocol Type: TCP/UDP Protocol Type: TCP/UDP
Source Port Number: #1 Source Port Number: #1
skipping to change at page 13, line 16 skipping to change at page 10, line 18
Source IP address: HoA B Source IP address: HoA B
Destination IP address: IP C Destination IP address: IP C
Protocol Type: TCP/UDP Protocol Type: TCP/UDP
Source Port Number: #2 Source Port Number: #2
Destination Port Number: #1 Destination Port Number: #1
Nodes C and B might be topologically close to each other while B's Nodes C and B might be topologically close to each other, while
Home Agent may be far away, resulting in a trombone effect that B's home agent may be far away, resulting in a trombone effect
can create delay and degrade the performance. The MN B may decide that can create delay and degrade the performance. MN B may
to initiate the route optimization procedure with Node C. Route decide to initiate the route optimization procedure with Node C.
optimization requires the MN B to send a Binding Update to Node C Route optimization requires MN B to send a Binding Update to Node
in order to create an entry in its binding cache that maps the MNs C in order to create an entry in its binding cache that maps the
home address to its current care-of-address. However, prior to MN's home address to its current care-of-address. However, prior
sending the binding update, the Mobile Node must first execute a to sending the binding update, the mobile node must first execute
Return Routability Test: a Return Routability Test:
* the Mobile Node B has to send a Home Test Init (HoTI) message * Mobile Node B has to send a Home Test Init (HoTI) message via
via its Home Agent and its home agent and
* a Care of Test Init (COTI) message directly to its * a Care of Test Init (COTI) message directly to its
Correspondent Node C. Correspondent Node C.
The Care of Test Init message is sent using the 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
protecting firewall (2). The CoTi message will thus be dropped by protecting firewall (2). The CoTi message will thus be dropped by
the firewall. the firewall.
The HoTI is a Mobility Header packet, and as the protocol type The HoTI is a Mobility Header packet, and as the protocol type
differs from the established state in the firewall (see (2)), the differs from the established state in the firewall (see (2)), the
HoTI packet will also be dropped. HoTI packet will also be dropped.
As a consequence, the RRT cannot be completed and route As a consequence, the RRT cannot be completed, and route
optimization cannot be applied. Every packet has to go through 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. Node B's home agent and tunneled between B's home agent and B.
+----------------+ +----------------+
| +----+ HoTI (HoA) +----+ | +----+ HoTI (HoA) +----+
| | FW |X<---------------|HA B| | | FW |X<---------------|HA B|
| +----X +----+ | +----X +----+
| +------+ | ^ CoTI & HoTI ^ | +------+ | ^ CoTI & HoTI ^
| | CN C | | | dropped by FW | | | CN C | | | dropped by FW |
| +------+ | | | HoTI | +------+ | | | HoTI
| | | | | | | |
| | | CoTI (CoA)+------+ | | | CoTI (CoA)+------+
| | +------------------| MN B | | | +------------------| MN 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
Issue 2: Let's assume that the Binding Update to the CN is Issue 2: Let's assume that the Binding Update to the CN is
successful, the firewall(s) might still drop packets successful; the firewall(s) might still drop packets that are:
1. coming from the CoA, since these incoming packets are sent 1. coming from the CoA, since these incoming packets are sent
from the CoA and do not match the Downlink Packet filter (2) 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 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 implemented. The uplink packets are sent to the MN's CoA and
do not match the uplink packet filter (1). do not match the uplink packet filter (1).
The packet filters for the traffic sent to (resp. from) the CoA The packet filters for the traffic sent to (resp. from) the CoA
need to be created in the firewall(s). need to be created in the firewall(s).
Requiring the firewalls to update the connection state upon Requiring the firewalls to update the connection state upon
detecting Binding Update messages from a node outside the network detecting Binding Update messages from a node outside the network
protected by the firewall does not appear feasible nor desirable, protected by the firewall does not appear feasible or desirable,
since currently the firewall does not have any means to verify the since currently the firewall does not have any means to verify the
validity of Binding Update messages and to therefore securely validity of Binding Update messages and therefore to modify the
modify the state information. Changing the firewall states state information securely. Changing the firewall states without
without verifying the validity of the Binding Update messages verifying the validity of the Binding Update messages could lead
could lead to denial of service attacks. Malicious nodes may send to denial of service attacks. Malicious nodes may send fake
fake binding updates, forcing the firewall to change its state binding updates, forcing the firewall to change its state
information, and therefore leading the firewall to drop packets information, and therefore leading the firewall to drop 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 pass through the firewall and enter the network. traffic to pass through the firewall and enter the network.
Issue 3: Let's assume that the Binding Update to the CN is Issue 3: Let's assume that the Binding Update to the CN is
successful. The CN may be protected by different firewalls and as successful. The CN may be protected by different firewalls, and
a result of the MN's change of IP address, incoming and outgoing as a result of the MN's change of IP address, incoming and
traffic may pass through a different firewall. The new firewall outgoing traffic may pass through a different firewall. The new
may not have any state associated with the CN and incoming packets firewall may not have any state associated with the CN, and
(and potentially outgoing traffic as well) may be dropped at the incoming packets (and potentially outgoing traffic as well) may be
firewall. dropped at the firewall.
Firewall technology allows clusters of firewalls to share state Firewall technology allows clusters of firewalls to share state
[3]. This, for example, allows the support of routing asymmetry. [3]. This, for example, allows the support of routing asymmetry.
However, if the previous and the new firewalls, where the packets However, if the previous and the new firewalls, through which the
are routed through after the Binding Update has been sent, do not packets are routed after the Binding Update has been sent, do not
share state, this may result in packets being dropped at the new share state, this may result in packets being dropped at the new
firewall. The new firewall not having any state associated with firewall. As the new firewall does not have any state associated
the CN, incoming packets (and potentially outgoing traffic as with the CN, incoming packets (and potentially outgoing traffic as
well) may be dropped at the new firewall. well) may be dropped at the new firewall.
5.3. Scenario where the HA is in a network protected by firewall(s) 5.3. Scenario Where the HA Is in a Network Protected by Firewall(s)
In the scenarios where the Home Agent is in a network protected by In the scenarios where the home agent is in a network protected by
firewall(s), the following issues may exist: firewall(s), the following issues may exist:
Issue 1: If the firewall(s) protecting the Home Agent block ESP Issue 1: If the firewall(s) protecting the home agent block ESP
traffic, many of the MIPv6 signaling (e.g. Binding Update, HoT) traffic, much of the MIPv6 signaling (e.g., Binding Update, HoT)
may be dropped at the firewall(s) preventing MN(s) from updating may be dropped at the firewall(s), preventing MN(s) from updating
their binding cache and performing Route Optimization, since their binding cache and performing Route Optimization, since
Binding Update, HoT and other MIPv6 signaling must be protected by Binding Update, HoT, and other MIPv6 signaling must be protected
IPsec ESP. by IPsec ESP.
Issue 2: If the firewall(s) protecting the Home Agent block Issue 2: If the firewall(s) protecting the home agent block
unsolicited incoming traffic (e.g. as stateful inspection packet unsolicited incoming traffic (e.g., as stateful inspection packet
filters do), the firewall(s) may drop connection set up requests filters do), the firewall(s) may drop connection set up requests
from CN, and packets from MN. from CNs, and packets from MNs.
Issue 3: If the Home Agent is in a network protected by several 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 firewalls, an MN/CN's change of IP address may result in the
traffic to and from the Home Agent passing through a different passage of traffic to and from the home agent through a different
firewall that may not have the states corresponding to the flows. firewall that may not have the states corresponding to the flows.
As a consequence, packets may be dropped at the firewall. As a consequence, packets may be dropped at the firewall.
5.4. Scenario where MN moves to a network protected by firewall(s) 5.4. Scenario Where the MN Moves to a Network Protected by Firewall(s)
Let's consider a HA in a network protected by firewall(s). The Let's consider an HA in a network protected by firewall(s). The
following issues need to be investigated: following issues need to be investigated:
Issue 1: Similarly to the issue 1 described in Section 5.1, the MN Issue 1: Similarly to issue 1 described in Section 5.1, the MN will
will send a Binding Update to its Home Agent after acquiring a send a Binding Update to its home agent after acquiring a local IP
local IP address (CoA). The Binding Updates and Acknowledgements address (CoA). The Binding Updates and Acknowledgements should be
should be protected by IPsec ESP according to the MIPv6 protected by IPsec ESP according to the MIPv6 specifications [1].
specifications [1]. However, as a default rule, many firewalls However, as a default rule, many firewalls drop ESP packets. This
drop ESP packets. This may cause the Binding Updates and may cause the Binding Updates and Acknowledgements between the
Acknowledgements between the Mobile Nodes and their Home Agent to mobile nodes and their home agent to be dropped.
be dropped.
Issue 2: The MN may be in a communication with a CN, or a CN may be 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, 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 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 MN's CoA. However, when the packets arrive at the firewall(s),
incoming traffic may not match any existing state, and the the incoming traffic may not match any existing state, and the
firewall(s) may therefore drop it. firewall(s) may therefore drop it.
Issue 3: If the MN is in a communication with a CN, the MN may 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. attempt to execute an RRT for packets to be route optimized.
Similarly to the issue 3, Section 5.1, the Home Test message which Similarly to issue 3, Section 5.1, the Home Test message that
should be protected by ESP may be dropped by firewall(s) should be protected by ESP may be dropped by firewall(s)
protecting the MN. Firewall(s) may as a default rule drop any ESP protecting the MN. Firewall(s) may as a default rule drop any ESP
traffic. As a consequence, the RRT cannot be completed. traffic. As a consequence, the RRT cannot be completed.
Issue 4: If the MN is in a communication with a CN, and assuming that 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 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 Optimization, packets will then be sent from the CN to the MN's
CoA and from the MN's CoA to the CN. 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 Packets sent from the CN to the MN's CoA may, however, not match
existing entry in the firewall(s) protecting the MN, and therefore any existing entry in the firewall(s) protecting the MN, and
be dropped by the firewall(s). therefore be dropped by the firewall(s).
If packet filtering is applied to uplink traffic (i.e. traffic 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 sent by the MN), packets sent from the MN's CoA to the CN may not
not match any entry in the firewall(s) either and may be dropped match any entry in the firewall(s) either and may be dropped as
as well. well.
6. Conclusions 6. Conclusions
Current firewalls may not only prevent route optimization but may Current firewalls may not only prevent route optimization but may
also prevent regular TCP and UDP sessions from being established in also prevent regular TCP and UDP sessions from being established in
some cases. This document describes some of the issues between the some cases. This document describes some of the issues between the
Mobile IPv6 protocol and current firewall technologies. Mobile IPv6 protocol and current firewall technologies.
This document captures the various issues involved in the deployment This document captures the various issues involved in the deployment
of Mobile IPv6 in networks that would invariably include firewalls. of Mobile IPv6 in networks that would invariably include firewalls.
A number of different scenarios are described which include A number of different scenarios are described, which include
configurations where the mobile node, correspondent node and home configurations where the mobile node, correspondent node, and home
agent exist across various boundaries delimited by the firewalls. agent exist across various boundaries delimited by the firewalls.
This enables a better understanding of the issues when deploying This enables a better understanding of the issues when deploying
Mobile IPv6 as well as providing an understanding for firewall design Mobile IPv6 as well as the issues for firewall design and policies to
and policies to be installed therein. be installed therein.
7. Security Considerations 7. Security Considerations
This document describes several issues that exist between the Mobile This document describes several issues that exist between the Mobile
IPv6 protocol and firewalls. IPv6 protocol and firewalls.
Firewalls may prevent Mobile IP6 signaling in addition to dropping Firewalls may prevent Mobile IP6 signaling in addition to dropping
incoming/outgoing traffic. incoming/outgoing 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 be Mobile IPv6 protocol but not properly configured, many attacks may be
possible as outlined above: malicious nodes may be able to launch possible as outlined above: malicious nodes may be able to launch
different types of denial of service attacks. different types of denial of service attacks.
8. Acknowledgments 8. Acknowledgements
We would like to thank James Kempf, Samita Chakrabarti, Giaretta We would like to thank James Kempf, Samita Chakrabarti, Giaretta
Gerardo, Steve Bellovin, Henrik Levkowetz and Spencer Dawkins for Gerardo, Steve Bellovin, Henrik Levkowetz, and Spencer Dawkins for
their valuable comments. Their suggestions have helped to improve their valuable comments. Their suggestions have helped improve both
both the presentation and the content of the document. the presentation and the content of the document.
9. References 9. References
9.1. Normative References 9.1. Normative References
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004. IPv6", RFC 3775, June 2004.
9.2. Informative References 9.2. Informative References
[2] Newman, D., "Benchmarking Terminology for Firewall Performance", [2] Newman, D., "Benchmarking Terminology for Firewall Performance",
RFC 2647, August 1999. RFC 2647, August 1999.
[3] Noble, J., Doug, D., Hourihan, K., Hourihan, K., Stephens, R., [3] Noble, J., Doug, D., Hourihan, K., Hourihan, K., Stephens, R.,
Stiefel, B., Amon, A., and C. Tobkin, "Check Point NG VPN-1/ Stiefel, B., Amon, A., and C. Tobkin, "Check Point NG VPN-1/
Firewall-1 Advanced Configuration and Troubleshooting", Syngress Firewall-1 Advanced Configuration and Troubleshooting", Syngress
Publishing Inc. , 2003. Publishing Inc. , 2003.
[4] Chen, X., Watson, M., and M. Harris, "Problem Statement for [4] Chen, X., Rinne, J., Wiljakka, J., and M. Watson, "Problem
MIPv6 Interactions with GPRS/UMTS Packet Filtering", Statement for MIPv6 Interactions with GPRS/UMTS Packet
draft-chen-mip6-gprs-03 (work in progress), February 2005. Filtering", Work in Progress, January 2006.
Appendix A. Applicability to 3G Networks Appendix A. Applicability to 3G Networks
In 3G networks, different packet filtering functionalities may be In 3G networks, different packet filtering functionalities may be
implemented to prevent malicious nodes from flooding or launching implemented to prevent malicious nodes from flooding or launching
other attacks against the 3G subscribers. The packet filtering other attacks against the 3G subscribers. The packet filtering
functionality of 3G networks are further described in [4]. Packet functionality of 3G networks is further described in [4]. Packet
filters are set up and applied to both uplink and downlink traffic: filters are set up and applied to both uplink and downlink traffic:
outgoing and incoming data not matching the packet filters is outgoing and incoming data not matching the packet filters is
dropped. The issues described in this document also apply to 3G dropped. The issues described in this document also apply to 3G
networks. networks.
Authors' Addresses Authors' Addresses
Franck Le Franck Le
Carnegie Mellon University Carnegie Mellon University
5000 Forbes Avenue 5000 Forbes Avenue
Pittsburgh, PA 15213 Pittsburgh, PA 15213
USA USA
Email: franckle@cmu.edu EMail: franckle@cmu.edu
Stefano Faccin Stefano Faccin
Nokia Research Center Nokia Research Center
6000 Connection Drive 6000 Connection Drive
Irving, TX 75039 Irving, TX 75039
USA USA
Email: stefano.faccin@nokia.com EMail: sfaccinstd@gmail.com
Basavaraj Patil Basavaraj Patil
Nokia Nokia
6000 Connection Drive 6000 Connection Drive
Irving, TX 75039 Irving, TX 75039
USA USA
Email: Basavaraj.Patil@nokia.com EMail: Basavaraj.Patil@nokia.com
Hannes Tschofenig Hannes Tschofenig
Siemens Siemens
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bavaria 81739 Munich, Bavaria 81739
Germany Germany
Email: Hannes.Tschofenig@siemens.com EMail: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.com URI: http://www.tschofenig.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
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.
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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 23, line 29 skipping to change at page 16, line 45
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 at specification can be obtained from the IETF on-line IPR repository 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 standard. 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 Validity Acknowledgement
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 (2006). 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 Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 82 change blocks. 
246 lines changed or deleted 225 lines changed or added

This html diff was produced by rfcdiff 1.31. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/