draft-krishnan-mip6-firewall-vendor-03.txt		draft-krishnan-mip6-firewall-vendor-04.txt
	Network Working Group S. Krishnan		Network Working Group S. Krishnan
	Internet-Draft Ericsson		Internet-Draft Ericsson
	Intended status: Standards Track Y. Sheffer		Intended status: Standards Track Y. Sheffer
	Expires: August 25, 2008 Check Point		Expires: November 1, 2008 Check Point
	N. Steinleitner		N. Steinleitner
	University of Goettingen		University of Goettingen
	G. Bajko		G. Bajko
	Nokia		Nokia
	February 22, 2008		April 30, 2008
	Guidelines for firewall vendors regarding MIPv6 traffic		Guidelines for firewall vendors regarding MIPv6 traffic
	draft-krishnan-mip6-firewall-vendor-03		draft-krishnan-mip6-firewall-vendor-04
	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 August 25, 2008.		This Internet-Draft will expire on November 1, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2008).		Copyright (C) The IETF Trust (2008).
	Abstract		Abstract
	This document presents some recommendations for firewall vendors to		This document presents some recommendations for firewall vendors to
	help them implement their firewalls in a way that allows Mobile IPv6		help them implement their firewalls in a way that allows Mobile IPv6
	signaling and data messages to pass through. This document describes		signaling and data messages to pass through. This document describes
	skipping to change at page 2, line 16		skipping to change at page 2, line 16
	Table of Contents		Table of Contents
	1. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3		1. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. MIPv6 Firewall Primitives . . . . . . . . . . . . . . . . . . . 3		3. MIPv6 Firewall Primitives . . . . . . . . . . . . . . . . . . . 3
	3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 3		3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 3
	3.2. Detecting and parsing the Mobility Header . . . . . . . . . 3		3.2. Detecting and parsing the Mobility Header . . . . . . . . . 3
	3.3. Parsing Mobility Options . . . . . . . . . . . . . . . . . 3		3.3. Parsing Mobility Options . . . . . . . . . . . . . . . . . 3
	4. Allowing signaling response packets . . . . . . . . . . . . . . 4		4. Allowing signaling response packets . . . . . . . . . . . . . . 4
	5. Allowing data packets based on signaling . . . . . . . . . . . 5		5. Allowing data packets based on signaling . . . . . . . . . . . 5
	6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 6		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
	8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6		8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
	9. Normative References . . . . . . . . . . . . . . . . . . . . . 7		9. Normative References . . . . . . . . . . . . . . . . . . . . . 7
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
	Intellectual Property and Copyright Statements . . . . . . . . . . 9		Intellectual Property and Copyright Statements . . . . . . . . . . 8
	1. Requirements notation		1. Requirements notation
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	2. Introduction		2. Introduction
	Network elements such as firewalls are an integral aspect of a		Network elements such as firewalls are an integral aspect of a
	skipping to change at page 5, line 4		skipping to change at page 5, line 4
	+---------------------------------+---------------------------------+		+---------------------------------+---------------------------------+
	| Passing packet MH Type | Setup return filter with MH |		| Passing packet MH Type | Setup return filter with MH |
	| | Type |		| | Type |
	+---------------------------------+---------------------------------+		+---------------------------------+---------------------------------+
	| Mobility Header Type:1(HoTI) | Mobility Header Type:3(HoT) |		| Mobility Header Type:1(HoTI) | Mobility Header Type:3(HoT) |
	| Mobility Header Type:2(CoTI) | Mobility Header Type:4(CoT) |		| Mobility Header Type:2(CoTI) | Mobility Header Type:4(CoT) |
	| Mobility Header Type:5(BU) | Mobility Header Type:6(BA) |		| Mobility Header Type:5(BU) | Mobility Header Type:6(BA) |
	+---------------------------------+---------------------------------+		+---------------------------------+---------------------------------+
	Table 1: Message Pairs in MIPv6		Table 1: Message Pairs in MIPv6
	Such dynamic rules can be timed out after 420 seconds (the maximum		Such dynamic rules can be timed out after a configurable period
	lifetime of a Binding Cache Entry), unless renewed by new mobility		STATEFUL_PINHOLE_LIFETIME, unless renewed by new mobility messages.
	messages.		This document recommends that the default value of
			STATEFUL_PINHOLE_LIFETIME be set to 30 seconds.
			These dynamic rules MUST be immediately deleted after the return
			message passes through. e.g. Once a return HoT message for a HoTI
			passes through, the pinhole must be immediately removed. The loss of
			the HoT packet after passing the firewall needs to be handled by the
			original MN retransmitting the HoTI message.
	5. Allowing data packets based on signaling		5. Allowing data packets based on signaling
	Once the MIPv6 signaling completes, the data traffic can begin to		Once the MIPv6 signaling completes, the data traffic can begin to
	flow. The traffic filters for the data traffic can be inferred from		flow. The traffic filters for the data traffic can be inferred from
	the contents of the signaling messages that setup the session. This		the contents of the signaling messages that setup the session. This
	section describes how firewalls can intelligently setup filters for		section describes how firewalls can intelligently setup filters for
	data traffic based on signaling traffic.The following example		data traffic based on signaling traffic.The following example
	describes how to setup a filter for allowing incoming route optimized		describes how to setup a filter for allowing incoming route optimized
	messages from a CN to an MN after the MN sent a BU message to a CN.		messages from a CN to an MN after the MN sent a BU message to a CN.
	skipping to change at page 6, line 5		skipping to change at page 6, line 10
	This pattern allows all route optimized traffic coming from the MN to		This pattern allows all route optimized traffic coming from the MN to
	the CN to pass through.		the CN to pass through.
	A firewall protecting the HA can add the following rule on reception		A firewall protecting the HA can add the following rule on reception
	of a HA binding update, in order to let the incoming bi-directional		of a HA binding update, in order to let the incoming bi-directional
	tunneled traffic pass.		tunneled traffic pass.
	Destination Address: Source Address of the packet (MN HoA)		Destination Address: Source Address of the packet (MN HoA)
	Source Address: Destination Address of packet (CN)		Source Address: Destination Address of packet (CN)
	6. Contributors		6. Acknowledgements
	This document is one of the deliverables of the MIPv6 firewall
	design. The following members of the team were involved in the
	creation of this document.
	Hannes Tschofenig Hannes.Tschofenig@gmx.net
	Gabor Bajko Gabor.Bajko@nokia.com
	Suresh Krishnan suresh.krishnan@ericsson.com
	Hesham Soliman solimanhs@gmail.com
	Yaron Sheffer yaronf@checkpoint.com
	Qiu Ying qiuying@i2r.a-star.edu.sg
	Niklas Steinleitner steinleitner@cs.uni-goettingen.de
	Vijay Devarapalli vijay.devarapalli@AzaireNet.com		The authors would like to thank the following members of the MIPv6
			firewall design team for contributing to this document: Hannes
			Tschofenig, Hesham Soliman, Qiu Ying, and Vijay Devarapalli. The
			authors would also like to thank William Ivancic, Ryuji Wakikawa,
			Jari Arkko and Henrik Levkowetz for their thorough reviews of the
			document and for providing comments to improve the quality of the
			document.
	7. IANA Considerations		7. IANA Considerations
	This document does not require any IANA action.		This document does not require any IANA action.
	8. Security Considerations		8. Security Considerations
	This document specifies recommendations for firewall vendors to allow		This document specifies recommendations for firewall vendors to allow
	Mobile IPv6 traffic to pass through unhindered. This document		Mobile IPv6 traffic to pass through unhindered. This document
	recommends a liberal setting of firewall rules so that all legitimate		recommends a liberal setting of firewall rules so that all legitimate
End of changes. 9 change blocks.
	29 lines changed or deleted		24 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/