投递文章
投稿指南
Request for Comments: 4487 CMU
Category: Informational S. Faccin
B. Patil
Nokia
H. Tschofenig
Siemens
May 2006
Mobile IPv6 and Firewalls: Problem Statement
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document 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
General Packet Radio Service / Universal Mobile Telecommunications
System (GPRS/UMTS) and CDMA2000 networks.
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.
Table of Contents
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
1. Introduction
Network elements such as firewalls are an integral aspect of a
majority of IP networks today, given the state of security in the
Internet, threats, and vulnerabilities to data networks. Current IP
networks are predominantly based on IPv4 technology, and hence
firewalls have been designed for these networks. Deployment of IPv6
networks is currently progressing, albeit at a slower pace.
Firewalls for IPv6 networks are still maturing and in development.
Mobility support for IPv6 has been standardized as specified in RFC
3775. Given the fact that Mobile IPv6 is a recent standard, most
firewalls available for IPv6 networks do not support Mobile IPv6.
Unless firewalls are aware of Mobile IPv6 protocol details, these
security devices will interfere with the smooth operation of the
protocol and can be a detriment to deployment.
Mobile IPv6 enables IP mobility for IPv6 nodes. It allows a mobile
IPv6 node to be reachable via its home IPv6 address irrespective of
any link that the mobile attaches to. This is possible as a result
of the extensions to IPv6 defined in the Mobile IPv6 specification
[1].
Mobile IPv6 protocol design also incorporates a feature termed Route
Optimization. This set of extensions is a fundamental part of the
protocol that enables optimized routing of packets between a mobile
node and its correspondent node and therefore optimized performance
of the communication.
In most cases, current firewall technologies, however, do not support
Mobile IPv6 or are not even aware of Mobile IPv6 headers and
extensions. Since most networks in the current business environment
deploy firewalls, this may prevent future large-scale deployment of
the Mobile IPv6 protocol.
This document presents in detail some of the issues that firewalls
present for Mobile IPv6 deployment, as well as the impact of each
issue.
2. Terminology
Return Routability Test (RRT): The Return Routability Test is a
procedure defined in RFC 3775 [1]. It is performed prior to the
Route Optimization (RO), where a mobile node (MN) instructs a
correspondent node (CN) to direct the mobile node’s data traffic
to its claimed care-of address (CoA). The Return Routability
procedure provides some security assurance and prevents the misuse
of Mobile IPv6 signaling to maliciously redirect the traffic or to
launch other attacks.
3. Abbreviations
This document uses the following abbreviations:
o CN: Correspondent Node
o CoA: Care of Address
o CoTI: Care of Test Init
o HA: Home Agent
o HoA: Home Address
o HoTI: Home Test Init
o HoT: Home Test
o MN: Mobile Node
o RO: Route Optimization
o RRT: Return Routability Test
4. Overview of Firewalls
The following section provides a brief overview of firewalls. It is
intended as background information so that issues with the Mobile
IPv6 protocol can then be presented in detail in the following
sections.
There are different types of firewalls, and state can be created in
these firewalls through different methods. Independent of the
adopted method, firewalls typically look at five parameters of the
traffic arriving at the firewalls:
o Source IP address
o Destination IP address
o Protocol type
o Source port number
o Destination port number
Based on these parameters, firewalls usually decide whether to allow
the traffic or to drop the packets. Some firewalls may filter only
incoming traffic, while others may also filter outgoing traffic.
According to Section 3.29 of RFC 2647 [2], stateful packet filtering
refers to the process of forwarding or rejecting traffic based on the
contents of a state table maintained by a firewall. These types of
firewalls are commonly deployed to protect networks from different
threats, such as blocking unsolicited incoming traffic from the
external networks. The following briefly describes how these
firewalls work since they can create additional problems with the
Mobile IPv6 protocol as described in the subsequent sections.
In TCP, an MN sends a TCP SYN message to connect to another host in
the Internet.
Upon receiving that SYN packet, the firewall records 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 transmitting it 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 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.
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
nodes and firewalls and also presents the issues related to each
scenario.
The Mobile IPv6 specifications define three main entities: the mobile
node (MN), the correspondent node (CN), and the home agent (HA).
Each of these entities may be in a network protected by one or many
firewalls:
o Section 5.1 analyzes the issues when the MN is in a network
protected by firewall(s)
o Section 5.2 analyzes the issues when the CN is in a network
protected by firewall(s)
o Section 5.3 analyzes the issues when the HA is in a network
protected by firewall(s)
The MN may also be moving from an external network, to a network
protected by firewall(s). The issues of this case are described in
Section 5.4.
Some of the described issues (e.g., Sections 5.1 and 5.2) may require
modifications to the protocols or to the firewalls, and others (e.g.,
Section 5.3) may require only that appropriate rules and
configuration be in place.
5.1. Scenario Where the Mobile Node Is in a Network Protected by
Firewall(s)
Let’s consider MN A, in a network protected by firewall(s).
+----------------+ +----+
| | | HA |
| | +----+
| | Home Agent
| +---+ +----+ of A +---+
| | A | | FW | | B |
| +---+ +----+ +---+
|Internal | External
| MN | Node
| |
+----------------+
Network protected
Figure 1: Issues between MIP6 and firewalls when MN is in a network
protected by firewalls
A number of issues need to be considered:
Issue 1: When MN A connects to the network, it should acquire a local
IP address (CoA) and send a Binding Update (BU) to its Home Agent
to update the HA with its current point of attachment. The
Binding Updates and Acknowledgements should be protected by IPsec
ESP according to the MIPv6 specifications [1]. However, as a
default rule, many firewalls drop IPsec ESP packets because they
cannot determine whether inbound ESP packets are legitimate. It
is difficult or impossible to create useful state by observing the
outbound 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 (for example) typically drop unsolicited
incoming traffic.
* B will thus not be able to contact MN A and establish a
communication.
Even though the HA is updated with the location of an 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) -- which solves
issue 1 (resp. issue 3) -- and that 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 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.
The issues described above result from the fact that the MN is behind
the firewall. Consequently, the MN’s communication capability with
other nodes is affected by the firewall rules.
5.2. Scenario Where the Correspondent Node Is in a Network Protected by
Firewall(s)
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
with the presence of a firewall in the scenario where the MN is
sending packets to the CN via a reverse tunnel that is set up between
the MN and HA. However, firewalls may present different issues to
Route Optimization.
+----------------+ +----+
| | | HA |
| | +----+
| | Home Agent
| +---+ +----+ of B
| |CN | | FW |
| | C | +----+
| +---+ | +---+
| | | B |
| | +---+
+----------------+ External Mobile
Network protected Node
by a firewall
Figure 2: Issues between MIP6 and firewalls when a CN is in a network
protected by firewalls
The following issues need to be considered:
Issue 1: The MN (MN B) should use its Home Address (HoA B) when
establishing the communication with the CN (CN C), if MN B wants
to take advantage of the mobility support provided by the Mobile
IPv6 protocol for its communication with CN C. The state created
by the firewall protecting CN C is therefore created based on the
IP address of C (IP C) and the home address of Node B (IP HoA B).
The states may be created via different means, and the protocol
type as well as the port numbers depend on the connection setup.
Uplink packet filters (1)
Source IP address: IP C
Destination IP address: HoA B
Protocol Type: TCP/UDP
Source Port Number: #1
Destination Port Number: #2
Downlink packet filters (2)
Source IP address: HoA B
Destination IP address: IP C
Protocol Type: TCP/UDP
Source Port Number: #2
Destination Port Number: #1
Nodes C and B might be topologically close to each other, while
B’s home agent may be far away, resulting in a trombone effect
that can create delay and degrade the performance. MN B may
decide to initiate the route optimization procedure with Node C.
Route optimization requires MN B to send a Binding Update to Node
C in order to create an entry in its binding cache that maps the
MN’s 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:
* 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 C.
The Care of Test Init message is sent using the CoA of B as the
source address. Such a packet does not match any entry in the
protecting firewall (2). The CoTi message will thus be dropped by
the firewall.
The HoTI is a Mobility Header packet, and as the protocol type
differs from the established state in the firewall (see (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
Node B’s home agent and tunneled between B’s home agent and B.
+----------------+
| +----+ HoTI (HoA) +----+
| | FW |X<---------------|HA B|
| +----X +----+
| +------+ | ^ CoTI & HoTI ^
| | CN C | | | dropped by FW |
| +------+ | | | HoTI
| | | |
| | | CoTI (CoA)+------+
| | +------------------| MN B |
+----------------+ +------+
Network protected External Mobile
by a firewall Node
Figure 3: Issues with Return Routability Test
Issue 2: Let’s assume that the Binding Update to the CN is
successful; the firewall(s) might still drop packets that are:
1. coming from the CoA, since these incoming packets are sent
from the CoA and do not match the Downlink Packet filter (2).
2. sent from the CN to the CoA if uplink packet filters are
implemented. The uplink packets are sent to the MN’s CoA and
do not match the uplink packet filter (1).
The packet filters for the traffic sent to (resp. from) the CoA
need to be created in the firewall(s).
Requiring the firewalls to update the connection state upon
detecting Binding Update messages from a node outside the network
protected by the firewall does not appear feasible or desirable,
since currently the firewall does not have any means to verify the
validity of Binding Update messages and therefore to modify the
state information securely. Changing the firewall states without
verifying the validity of the Binding Update messages could lead
to denial of service attacks. Malicious nodes may send fake
binding updates, forcing the firewall to change its state
information, and therefore leading the firewall to drop packets
from the connections that use the legitimate addresses. An
adversary might also use an address update to enable its own
traffic to pass through the firewall and enter the network.
Issue 3: Let’s assume that the Binding Update to the CN is
successful. The CN may be protected by different firewalls, and
as a result of the MN’s change of IP address, incoming and
outgoing traffic may pass through a different firewall. The new
firewall may not have any state associated with the CN, and
incoming packets (and potentially outgoing traffic as well) may be
dropped at the firewall.
Firewall technology allows clusters of firewalls to share state
[3]. This, for example, allows the support of routing asymmetry.
However, if the previous and the new firewalls, through which the
packets are routed after the Binding Update has been sent, do not
share state, this may result in packets being dropped at the new
firewall. As the new firewall does not have any state associated
with the CN, incoming packets (and potentially outgoing traffic as
well) may be dropped at the new firewall.
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