draft-ietf-mext-firewall-admin-00.txt   draft-ietf-mext-firewall-admin-01.txt 
Network Working Group S. Krishnan Network Working Group S. Krishnan
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Informational N. Steinleitner Intended status: Informational N. Steinleitner
Expires: April 11, 2009 University of Goettingen Expires: November 20, 2009 University of Goettingen
Y. Qiu Y. Qiu
Institute for Infocomm Research Institute for Infocomm Research
G. Bajko G. Bajko
Nokia Nokia
October 8, 2008 May 19, 2009
Guidelines for firewall administrators regarding MIPv6 traffic Guidelines for firewall administrators regarding MIPv6 traffic
draft-ietf-mext-firewall-admin-00 draft-ietf-mext-firewall-admin-01
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 39 skipping to change at page 1, line 39
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 April 11, 2009. This Internet-Draft will expire on November 20, 2009.
Abstract Abstract
This document presents some recommendations for firewall This document presents some recommendations for firewall
administrators to help them configure their existing firewalls in a administrators to help them configure their existing firewalls in a
way that allows in certain deployment scenarios the Mobile IPv6 way that allows in certain deployment scenarios the Mobile IPv6
signaling and data messages to pass through. For other scenarios, signaling and data messages to pass through. For other scenarios,
the support of additional mechanisms to create pinholes required for the support of additional mechanisms to create pinholes required for
MIPv6 will be necessary. This document assumes that the firewalls in MIPv6 will be necessary. This document assumes that the firewalls in
question include some kind of stateful packet filtering capability. question include some kind of stateful packet filtering capability.
skipping to change at page 3, line 33 skipping to change at page 3, line 33
administrators to help them configure their firewalls in a way that administrators to help them configure their firewalls in a way that
allows the Mobile IPv6 signaling and data messages to pass through. allows the Mobile IPv6 signaling and data messages to pass through.
This document assumes that the firewalls in question include some This document assumes that the firewalls in question include some
kind of stateful packet filtering capability. The static rules that kind of stateful packet filtering capability. The static rules that
need to be configured are described in this document. In some need to be configured are described in this document. In some
scenarios, the support of additional mechanisms to create pinholes scenarios, the support of additional mechanisms to create pinholes
required for MIPv6 signalling and data traffic to pass through will required for MIPv6 signalling and data traffic to pass through will
be necessary. A possible solution, describing the dynamic be necessary. A possible solution, describing the dynamic
capabilities needed for the firewalls to create pinholes based on capabilities needed for the firewalls to create pinholes based on
MIPv6 signalling traffic is described in a companion document MIPv6 signalling traffic is described in a companion document
[MIP6FWVENDOR]. Other solutions may also be possible. [I-D.ietf-mext-firewall-vendor]. Other solutions may also be
possible.
Some Mobile IPv6 signalling messages require the use of encryption to Some Mobile IPv6 signalling messages require the use of encryption to
protect the confidentiality of the payload (e.g. the HoTI and HoT protect the confidentiality of the payload (e.g. the HoTI and HoT
messages between the MN and the HA). The other signalling messages messages between the MN and the HA). The other signalling messages
allow the use of encryption. If encryption is being used, it is not allow the use of encryption. If encryption is being used, it is not
possible to inspect the contents of the signalling packets. For possible to inspect the contents of the signalling packets. For
these messages to get through, a generic rule needs to be added in these messages to get through, a generic rule needs to be added in
the firewall to let ESP packets through without further inspection. the firewall to let ESP packets through without further inspection.
3. Abbreviations 3. Abbreviations
skipping to change at page 7, line 36 skipping to change at page 7, line 36
where CN Address describes the address(es) of the priviledged where CN Address describes the address(es) of the priviledged
node(s).This allows the BU to traverse the firewall and the BA can node(s).This allows the BU to traverse the firewall and the BA can
pass the firewall without any assistance. Therefore, the Binding pass the firewall without any assistance. Therefore, the Binding
Update sequence can be performed successfully. Update sequence can be performed successfully.
5.4. Route Optimization data traffic from MN 5.4. Route Optimization data traffic from MN
Also the Route Optimization data traffic from MN directly to the CN Also the Route Optimization data traffic from MN directly to the CN
can not traverse the firewall without assistance. A dynamically can not traverse the firewall without assistance. A dynamically
created pinhole such as the one specified in [MIP6FWVENDOR] will created pinhole such as the one specified in
allow this traffic to pass. [I-D.ietf-mext-firewall-vendor] will allow this traffic to pass.
6. Mobile Node behind a firewall 6. Mobile Node behind a firewall
This section presents the recommendations for configuring a firewall This section presents the recommendations for configuring a firewall
that protects the network a mobile node visiting. that protects the network a mobile node visiting.
+----------------+ +----+ +----------------+ +----+
| | | HA | | | | HA |
| | +----+ | | +----+
| | Home Agent | | Home Agent
skipping to change at page 10, line 29 skipping to change at page 10, line 29
discern whether it is safe or not. This document recommends a discern whether it is safe or not. This document recommends a
liberal setting so that all legitimate traffic can pass. This means liberal setting so that all legitimate traffic can pass. This means
that some malicious traffic may be permitted by these rules. These that some malicious traffic may be permitted by these rules. These
rules may allow the initiation of Denial of Service attacks against rules may allow the initiation of Denial of Service attacks against
Mobile IPv6 capable nodes (the MNs, CNs and the HAs). Mobile IPv6 capable nodes (the MNs, CNs and the HAs).
11. References 11. References
11.1. Normative References 11.1. Normative References
[MIP6FWVENDOR] [I-D.ietf-mext-firewall-vendor]
Krishnan, S., Sheffer, Y., Steinleitner, N., and G. Bajko, Krishnan, S., Sheffer, Y., Steinleitner, N., and G. Bajko,
"Guidelines for firewall vendors regarding MIPv6 traffic", "Guidelines for firewall vendors regarding MIPv6 traffic",
draft-ietf-mext-firewall-vendor-0 (work in progress), draft-ietf-mext-firewall-vendor-00 (work in progress),
October 2008. October 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[RFC4487] Le, F., Faccin, S., Patil, B., and H. Tschofenig, "Mobile [RFC4487] Le, F., Faccin, S., Patil, B., and H. Tschofenig, "Mobile
IPv6 and Firewalls: Problem Statement", RFC 4487, IPv6 and Firewalls: Problem Statement", RFC 4487,
skipping to change at page 12, line 7 skipping to change at page 12, line 7
Phone: +65-6874-6742 Phone: +65-6874-6742
Email: qiuying@i2r.a-star.edu.sg Email: qiuying@i2r.a-star.edu.sg
Gabor Bajko Gabor Bajko
Nokia Nokia
Email: gabor.bajko@nokia.com Email: gabor.bajko@nokia.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2009).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 9 change blocks. 
10 lines changed or deleted 11 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/