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.
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.
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.
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
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).