draft-ietf-mip6-firewalls-02.txt   draft-ietf-mip6-firewalls-03.txt 
MIP6 F. Le MIP6 F. Le
Internet-Draft S. Faccin Internet-Draft CMU
Expires: November 6, 2005 B. Patil Expires: April 20, 2006 S. Faccin
B. Patil
Nokia Nokia
H. Tschofenig H. Tschofenig
Siemens Siemens
May 5, 2005 October 17, 2005
Mobile IPv6 and Firewalls: Problem statement Mobile IPv6 and Firewalls: Problem statement
draft-ietf-mip6-firewalls-02.txt draft-ietf-mip6-firewalls-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 1, line 37 skipping to change at page 1, line 38
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 as "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/ietf/1id-abstracts.txt. 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 November 6, 2005. This Internet-Draft will expire on April 20, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
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
skipping to change at page 3, line 13 skipping to change at page 3, line 13
appropriate solutions in the MIP6 WG. appropriate solutions in the MIP6 WG.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Overview of firewalls . . . . . . . . . . . . . . . . . . . . 7 4. Overview of firewalls . . . . . . . . . . . . . . . . . . . . 7
5. Analysis of various scenarios involving MIP6 nodes and 5. Analysis of various scenarios involving MIP6 nodes and
firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . 9 firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1 Scenario where the Mobile Node is in a network 5.1. Scenario where the Mobile Node is in a network
protected by firewall(s) . . . . . . . . . . . . . . . . . 9 protected by firewall(s) . . . . . . . . . . . . . . . . . 9
5.2 Scenario where the Correspondent Node is in a network 5.2. Scenario where the Correspondent Node is in a network
protected by firewall(s) . . . . . . . . . . . . . . . . . 11 protected by firewall(s) . . . . . . . . . . . . . . . . . 11
5.3 Scenario where the HA is in a network protected by 5.3. Scenario where the HA is in a network protected by
firewall(s) . . . . . . . . . . . . . . . . . . . . . . . 14 firewall(s) . . . . . . . . . . . . . . . . . . . . . . . 15
5.4 Scenario where MN moves to a network protected by 5.4. Scenario where MN moves to a network protected by
firewall(s) . . . . . . . . . . . . . . . . . . . . . . . 15 firewall(s) . . . . . . . . . . . . . . . . . . . . . . . 15
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 17 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1 Normative References . . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20
9.2 Informative References . . . . . . . . . . . . . . . . . . 20 9.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 Appendix A. Applicability to 3G Networks . . . . . . . . . . . . 21
A. Applicability to 3G Networks . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . 23 Intellectual Property and Copyright Statements . . . . . . . . . . 23
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
[1]. [1].
Mobile IPv6 protocol design also incorporates a feature termed as Mobile IPv6 protocol design also incorporates a feature termed as
skipping to change at page 7, line 45 skipping to change at page 7, line 45
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 When a MN connects using TCP to another host in the Internet, it
sends a TCP SYN message to set up the connection. When that SYN sends a TCP SYN message to set up the connection. When that SYN
packet is routed through the firewall, the firewall creates an entry packet is routed through the firewall, the firewall creates an entry
in its state table containing the source IP address, the destination in its state table containing the source IP address, the destination
IP address, the Protocol type, the source port number and the IP address, the Protocol type, the source port number and the
destination port number indicated in that packet and then forwards destination port number indicated in that packet before forwarding
the packet to the destination. When the response comes back, the the packet to the destination. When an incoming message from the
filter looks up the packet's source IP address, destination IP external networks reaches the firewall, it searches the packet's
address, Protocol type, source port number and destination port source IP address, destination IP address, Protocol type, source port
number in its state table: If they match an expected response, the number and destination port number in its state table to see if the
firewall let the packet to pass. If no table entry exists, the packet matches the characteristics of a request sent previously. If
packet is dropped since it was not requested from inside the network. so, the firewall lets the packet pass. Otherwise, the packet is
dropped since it was not requested from inside the network.
The filter removes the state table entries when the TCP close session The firewall removes the state table entries either when the TCP
negotiation packets are routed through, or after some period of close session negotiation packets are routed through, or after some
delay, usually a few minutes. This ensures that dropped connections configurable timeout period. This ensures that dropped connections
do not leave table holes open. do not leave holes in the table.
For UDP, similar state is created but since UDP is connectionless and For UDP, similar state is created. However, since UDP is
the protocol does not have an indication of the beginning or the end connectionless and the protocol does not have an indication of the
of a session, the state is based only on timers. beginning nor the end of a session, the state is based only on
timers.
5. 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 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). Each
of these entities may be in a network protected by one or many of these entities may be in a network protected by one or many
skipping to change at page 9, line 29 skipping to change at page 9, line 29
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.3. Section 5.3.
5.1 Scenario where the Mobile Node is in a network protected by Some of the described issues (e.g. Section 5.1 and Section 5.2) may
require modifications to the protocols or to the firewalls, and
others (e.g. Section 5.3) may require only appropriate rules and
configuration to be in place.
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 a 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 |
skipping to change at page 10, line 10 skipping to change at page 10, line 28
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 the MN A connects to the network, it should acquire a
local IP address (CoA), and send a Binding Update to its Home local IP address (CoA), and send a Binding Update to its Home
Agent to update the HA with its current point of attachment. The Agent 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 ESP packets. This may cause the default rule, many firewalls drop IPsec ESP packets because they
Binding Updates and Acknowledgements between the Mobile Nodes and cannot determine whether inbound ESP packets are legitimate. It
their Home Agent to be dropped. 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 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
skipping to change at page 11, line 21 skipping to change at page 11, line 39
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 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, a 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 the
firewall on the new link that the MN attaches to does not have any firewall on the new link that the MN attaches to does not have any
state that is associated with the MN. state that is associated with the MN.
5.2 Scenario where the Correspondent Node is in a network protected by 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) firewall(s)
Let's consider a MN in a network, communicating with a Correspondent Let's consider a MN in a network, communicating with a Correspondent
Node A 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 | +----+
| | +---+ | +---+ | +---+
| | | 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 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 A) if the MN (MN B) establishing the communication with the CN (CN C) if the MN (MN B)
wants to take advantage of the mobility support provided by the wants to take advantage of the mobility support provided by the
Mobile IPv6 protocol, for its communication with CN A. The state Mobile IPv6 protocol, for its communication with CN C. The state
created by the firewall protecting CN A is therefore created based created by the firewall protecting CN C is therefore created based
on the IP address of A (IP A) and the home address of the node B on the IP address of C (IP C) and the home address of the node B
(IP HoA B). The states may be created via different means and the (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 protocol type as well as the port numbers depend on the connection
set up. set up.
Uplink packet filters (1) Uplink packet filters (1)
Source IP address: IP A 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
Destination Port Number: #2 Destination Port Number: #2
Downlink packet filters (2) Downlink packet filters (2)
Source IP address: HoA B Source IP address: HoA B
Destination IP address: IP A 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 A and B might be topologically close to each other while B's 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 Home Agent may be far away, resulting in a trombone effect that
can create delay and degrade the performance. The MN B may decide can create delay and degrade the performance. The MN B may decide
to initiate the route optimization procedure with Node A. Route to initiate the route optimization procedure with Node C. Route
optimization requires the MN B to send a Binding Update to Node A optimization requires the MN B to send a Binding Update to Node C
in order to create an entry in its binding cache that maps the MNs 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 home address to its current care-of-address. However, prior to
sending the binding update, the Mobile Node must first execute a sending the binding update, the Mobile Node must first execute a
Return Routability Test: Return Routability Test:
* the Mobile Node B has to send a Home Test Init (HoTI) message * the Mobile Node B has to send a Home Test Init (HoTI) message
via its Home Agent and via 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 A. 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 the protocol type The HoTI is a Mobility Header packet, and the protocol type
differing from the existing states (2), the HoTI packet will also differs from the existing states (2), the HoTI packet will also be
be dropped. 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. the 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 ^
| | A | | | dropped by FW | | | CN C | | | dropped by FW |
| +---+ | | | HoTI | +------+ | | | HoTI
| | | | | | | |
| | | CoTI (CoA)+---+ | | | CoTI (CoA)+------+
| | +------------------| 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
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)
skipping to change at page 14, line 30 skipping to change at page 15, line 13
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 as
a result of the MN's change of IP address, incoming and outgoing a result of the MN's change of IP address, incoming and outgoing
traffic may pass through a different firewall. The new firewall traffic may pass through a different firewall. The new firewall
may not have any state associated with the CN and incoming packets may not have any state associated with the CN and incoming packets
(and potentially outgoing traffic as well) may be dropped at the (and potentially outgoing traffic as well) may be dropped at the
firewall. firewall.
5.3 Scenario where the HA is in a network protected by firewall(s) 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, where the packets
are routed through after the Binding Update has been sent, do not
share state, this may result in packets being dropped at the new
firewall. The new firewall not having any state associated with
the CN, incoming packets (and potentially outgoing traffic as
well) may be dropped at the new firewall.
Let's consider a MN moving into a network protected by firewall(s). 5.3. Scenario where the HA is in a network protected by firewall(s)
The following issues may exist:
Issue 1: If the firewall(s) block ESP traffic, many of the MIPv6 In the scenarios where the Home Agent is in a network protected by
signaling (e.g. Binding Update, HoT) may be dropped at the firewall(s), the following issues may exist:
firewall(s) preventing MN(s) from updating their binding cache and
performing Route Optimization, since Binding Update, HoT and other Issue 1: If the firewall(s) protecting the Home Agent block ESP
MIPv6 signaling must be protected by IPsec ESP. traffic, many of the MIPv6 signaling (e.g. Binding Update, HoT)
may be dropped at the firewall(s) preventing MN(s) from updating
their binding cache and performing Route Optimization, since
Binding Update, HoT and other MIPv6 signaling must be protected by
IPsec ESP.
Issue 2: If the firewall(s) protecting the Home Agent block 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 CN, and packets from MN.
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, a MN/CN's change of IP address may result in the
traffic to and from the Home Agent passing through a different traffic to and from the Home Agent passing 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 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 a 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 the issue 1 described in Section 5.1, the MN
will send a Binding Update to its Home Agent after acquiring a will send a Binding Update to its Home Agent after acquiring a
local IP address (CoA). The Binding Updates and Acknowledgements local IP address (CoA). The Binding Updates and Acknowledgements
should be protected by IPsec ESP according to the MIPv6 should be protected by IPsec ESP according to the MIPv6
specifications [1]. However, as a default rule, many firewalls specifications [1]. However, as a default rule, many firewalls
drop ESP packets. This may cause the Binding Updates and drop ESP packets. This may cause the Binding Updates and
skipping to change at page 19, line 7 skipping to change at page 19, line 7
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. Acknowledgments
We would like to thank James Kempf, Samita Chakrabarti and Giaretta We would like to thank James Kempf, Samita Chakrabarti, Giaretta
Gerardo for their valuable comments. Their suggestions have helped Gerardo, Steve Bellovin, Henrik Levkowetz and Spencer Dawkins for
to improve both the presentation and the content of the document. their valuable comments. Their suggestions have helped to improve
both 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] Chen, X., Watson, M., and M. Harris, "Problem Statement for [3] Noble, J., Doug, D., Hourihan, K., Hourihan, K., Stephens, R.,
Stiefel, B., Amon, A., and C. Tobkin, "Check Point NG VPN-1/
Firewall-1 Advanced Configuration and Troubleshooting", Syngress
Publishing Inc. , 2003.
[4] Chen, X., Watson, M., and M. Harris, "Problem Statement for
MIPv6 Interactions with GPRS/UMTS Packet Filtering", MIPv6 Interactions with GPRS/UMTS Packet Filtering",
draft-chen-mip6-gprs-03 (work in progress), February 2005. draft-chen-mip6-gprs-03 (work in progress), February 2005.
Appendix A. Applicability to 3G Networks
In 3G networks, different packet filtering functionalities may be
implemented to prevent malicious nodes from flooding or launching
other attacks against the 3G subscribers. The packet filtering
functionality of 3G networks are further described in [4]. 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.
Authors' Addresses Authors' Addresses
Franck Le Franck Le
Nokia Research Center Carnegie Mellon University
6000 Connection Drive 5000 Forbes Avenue
Irving, TX 75039 Pittsburgh, PA 15213
USA USA
Email: franck.le@nokia.com 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: stefano.faccin@nokia.com
Basavaraj Patil Basavaraj Patil
skipping to change at page 21, line 4 skipping to change at page 22, line 30
Email: stefano.faccin@nokia.com Email: stefano.faccin@nokia.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
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 [3]. 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
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.
 End of changes. 40 change blocks. 
85 lines changed or deleted 117 lines changed or added

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