summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4487.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4487.txt')
-rw-r--r--doc/rfc/rfc4487.txt899
1 files changed, 899 insertions, 0 deletions
diff --git a/doc/rfc/rfc4487.txt b/doc/rfc/rfc4487.txt
new file mode 100644
index 0000000..7d46249
--- /dev/null
+++ b/doc/rfc/rfc4487.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group F. Le
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Le, et al. Informational [Page 1]
+
+RFC 4487 MIPv6 and Firewalls May 2006
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Le, et al. Informational [Page 2]
+
+RFC 4487 MIPv6 and Firewalls May 2006
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+Le, et al. Informational [Page 3]
+
+RFC 4487 MIPv6 and Firewalls May 2006
+
+
+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:
+
+
+
+
+
+Le, et al. Informational [Page 4]
+
+RFC 4487 MIPv6 and Firewalls May 2006
+
+
+ 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.
+
+
+
+Le, et al. Informational [Page 5]
+
+RFC 4487 MIPv6 and Firewalls May 2006
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Le, et al. Informational [Page 6]
+
+RFC 4487 MIPv6 and Firewalls May 2006
+
+
+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.
+
+
+
+Le, et al. Informational [Page 7]
+
+RFC 4487 MIPv6 and Firewalls May 2006
+
+
+ * 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.
+
+
+
+
+
+
+
+
+
+
+Le, et al. Informational [Page 8]
+
+RFC 4487 MIPv6 and Firewalls May 2006
+
+
+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
+
+
+
+
+Le, et al. Informational [Page 9]
+
+RFC 4487 MIPv6 and Firewalls May 2006
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+Le, et al. Informational [Page 10]
+
+RFC 4487 MIPv6 and Firewalls May 2006
+
+
+ +----------------+
+ | +----+ 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
+
+
+
+
+Le, et al. Informational [Page 11]
+
+RFC 4487 MIPv6 and Firewalls May 2006
+
+
+ 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
+ firewall(s), the following issues may exist:
+
+ Issue 1: If the firewall(s) protecting the home agent block ESP
+ traffic, much of the MIPv6 signaling (e.g., Binding Update, HoT)
+ may be dropped at the firewall(s), preventing MN(s) from updating
+ their binding cache and performing Route Optimization, since
+ Binding Update, HoT, and other MIPv6 signaling must be protected
+ by IPsec ESP.
+
+ Issue 2: If the firewall(s) protecting the home agent block
+ unsolicited incoming traffic (e.g., as stateful inspection packet
+ filters do), the firewall(s) may drop connection setup requests
+ from CNs, and packets from MNs.
+
+ Issue 3: If the home agent is in a network protected by several
+ firewalls, an MN/CN's change of IP address may result in the
+ passage of traffic to and from the home agent through a different
+ firewall that may not have the states corresponding to the flows.
+ As a consequence, packets may be dropped at the firewall.
+
+5.4. Scenario Where the MN Moves to a Network Protected by Firewall(s)
+
+ Let's consider an HA in a network protected by firewall(s). The
+ following issues need to be investigated:
+
+ Issue 1: Similarly to issue 1 described in Section 5.1, the MN will
+ send a Binding Update to its home agent after acquiring a local IP
+ address (CoA). The Binding Updates and Acknowledgements should be
+ protected by IPsec ESP according to the MIPv6 specifications [1].
+ However, as a default rule, many firewalls drop ESP packets. This
+ may cause the Binding Updates and Acknowledgements between the
+ mobile nodes and their home agent to be dropped.
+
+
+
+Le, et al. Informational [Page 12]
+
+RFC 4487 MIPv6 and Firewalls May 2006
+
+
+ Issue 2: The MN may be in a communication with a CN, or a CN may be
+ attempting to establish a connection with the MN. In both cases,
+ packets sent from the CN will be forwarded by the MN's HA to the
+ MN's CoA. However, when the packets arrive at the firewall(s),
+ the incoming traffic may not match any existing state, and the
+ firewall(s) may therefore drop it.
+
+ Issue 3: If the MN is in a communication with a CN, the MN may
+ attempt to execute an RRT for packets to be route optimized.
+ Similarly to issue 3, Section 5.1, the Home Test message that
+ should be protected by ESP may be dropped by firewall(s)
+ protecting the MN. Firewall(s) may as a default rule drop any ESP
+ traffic. As a consequence, the RRT cannot be completed.
+
+ Issue 4: If the MN is in a communication with a CN, and assuming that
+ the MN successfully sent a Binding Update to its CN to use Route
+ Optimization, packets will then be sent from the CN to the MN's
+ CoA and from the MN's CoA to the CN.
+
+ Packets sent from the CN to the MN's CoA may, however, not match
+ any existing entry in the firewall(s) protecting the MN, and
+ therefore be dropped by the firewall(s).
+
+ If packet filtering is applied to uplink traffic (i.e., traffic
+ sent by the MN), packets sent from the MN's CoA to the CN may not
+ match any entry in the firewall(s) either and may be dropped as
+ well.
+
+6. Conclusions
+
+ Current firewalls may not only prevent route optimization but may
+ also prevent regular TCP and UDP sessions from being established in
+ some cases. This document describes some of the issues between the
+ Mobile IPv6 protocol and current firewall technologies.
+
+ This document captures the various issues involved in the deployment
+ of Mobile IPv6 in networks that would invariably include firewalls.
+ A number of different scenarios are described, which include
+ configurations where the mobile node, correspondent node, and home
+ agent exist across various boundaries delimited by the firewalls.
+ This enables a better understanding of the issues when deploying
+ Mobile IPv6 as well as the issues for firewall design and policies to
+ be installed therein.
+
+
+
+
+
+
+
+
+Le, et al. Informational [Page 13]
+
+RFC 4487 MIPv6 and Firewalls May 2006
+
+
+7. Security Considerations
+
+ This document describes several issues that exist between the Mobile
+ IPv6 protocol and firewalls.
+
+ Firewalls may prevent Mobile IP6 signaling in addition to dropping
+ incoming/outgoing traffic.
+
+ If the firewall configuration is modified in order to support the
+ Mobile IPv6 protocol but not properly configured, many attacks may be
+ possible as outlined above: malicious nodes may be able to launch
+ different types of denial of service attacks.
+
+8. Acknowledgements
+
+ We would like to thank James Kempf, Samita Chakrabarti, Giaretta
+ Gerardo, Steve Bellovin, Henrik Levkowetz, and Spencer Dawkins for
+ their valuable comments. Their suggestions have helped improve both
+ the presentation and the content of the document.
+
+9. References
+
+9.1. Normative References
+
+ [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
+ IPv6", RFC 3775, June 2004.
+
+9.2. Informative References
+
+ [2] Newman, D., "Benchmarking Terminology for Firewall Performance",
+ RFC 2647, August 1999.
+
+ [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., Rinne, J., Wiljakka, J., and M. Watson, "Problem
+ Statement for MIPv6 Interactions with GPRS/UMTS Packet
+ Filtering", Work in Progress, January 2006.
+
+
+
+
+
+
+
+
+
+
+
+Le, et al. Informational [Page 14]
+
+RFC 4487 MIPv6 and Firewalls May 2006
+
+
+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 is 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
+
+ Franck Le
+ Carnegie Mellon University
+ 5000 Forbes Avenue
+ Pittsburgh, PA 15213
+ USA
+
+ EMail: franckle@cmu.edu
+
+
+ Stefano Faccin
+ Nokia Research Center
+ 6000 Connection Drive
+ Irving, TX 75039
+ USA
+
+ EMail: sfaccinstd@gmail.com
+
+
+ Basavaraj Patil
+ Nokia
+ 6000 Connection Drive
+ Irving, TX 75039
+ USA
+
+ EMail: Basavaraj.Patil@nokia.com
+
+
+ Hannes Tschofenig
+ Siemens
+ Otto-Hahn-Ring 6
+ Munich, Bavaria 81739
+ Germany
+
+ EMail: Hannes.Tschofenig@siemens.com
+ URI: http://www.tschofenig.com
+
+
+
+Le, et al. Informational [Page 15]
+
+RFC 4487 MIPv6 and Firewalls May 2006
+
+
+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
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Le, et al. Informational [Page 16]
+