draft-krishnan-mip6-firewall-admin-01.txt		draft-krishnan-mip6-firewall-admin-02.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: May 19, 2008 University of Goettingen		Expires: May 21, 2008 University of Goettingen
	Y. Qiu		Y. Qiu
	Institute for Infocomm Research		Institute for Infocomm Research
	November 16, 2007		November 18, 2007
	Guidelines for firewall administrators regarding MIPv6 traffic		Guidelines for firewall administrators regarding MIPv6 traffic
	draft-krishnan-mip6-firewall-admin-01		draft-krishnan-mip6-firewall-admin-02
	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 37
	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 May 19, 2008.		This Internet-Draft will expire on May 21, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	This document presents some recommendations for firewall		This document presents some recommendations for firewall
	administrators to help them configure their firewalls in a way that		administrators to help them configure their existing firewalls in a
	allows Mobile IPv6 signaling and data messages to pass through. This		way that allows in certain deployment scenarios the Mobile IPv6
	document assumes that the firewalls in question include some kind of		signaling and data messages to pass through. For other scenarios,
	stateful packet filtering capability.		the support of additional mechanisms to create pinholes required for
			MIPv6 will be necessary. This document assumes that the firewalls in
			question include some kind of stateful packet filtering capability.
	Table of Contents		Table of Contents
	1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3		1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Home Agent behind a firewall . . . . . . . . . . . . . . . . . 3		3. Home Agent behind a firewall . . . . . . . . . . . . . . . . . 3
	3.1. Signaling between the MN and the HA . . . . . . . . . . . 3		3.1. Signaling between the MN and the HA . . . . . . . . . . . 4
	3.2. IKEv2 signaling between MN and HA for establishing SAs . . 4		3.2. IKEv2 signaling between MN and HA for establishing SAs . . 4
	3.3. Data traffic from and to MN passing through the HA . . . . 4		3.3. Data traffic from and to MN passing through the HA . . . . 4
	4. Correspondent Node behind a firewall . . . . . . . . . . . . . 4		4. Correspondent Node behind a firewall . . . . . . . . . . . . . 5
	4.1. Route optimization signaling between MN and CN through		4.1. Route optimization signaling between MN and CN through
	HA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5		HA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4.2. Route optimization signaling between MN and CN . . . . . . 5		4.2. Route optimization signaling between MN and CN . . . . . . 5
	4.3. Binding Update from MN to CN . . . . . . . . . . . . . . . 6		4.3. Binding Update from MN to CN . . . . . . . . . . . . . . . 6
	4.4. Route Optimization data traffic from MN . . . . . . . . . 6		4.4. Route Optimization data traffic from MN . . . . . . . . . 6
	4.5. Bi-directional tunnelled data traffic from the MN to		4.5. Bi-directional tunnelled data traffic from the MN to
	the CN through HA . . . . . . . . . . . . . . . . . . . . 6		the CN through HA . . . . . . . . . . . . . . . . . . . . 6
	5. Mobile Node behind a firewall . . . . . . . . . . . . . . . . 7		5. Mobile Node behind a firewall . . . . . . . . . . . . . . . . 7
	5.1. Signaling between MN and HA . . . . . . . . . . . . . . . 7		5.1. Signaling between MN and HA . . . . . . . . . . . . . . . 7
	5.2. Signaling between MN and CN . . . . . . . . . . . . . . . 7		5.2. Signaling between MN and CN . . . . . . . . . . . . . . . 8
	5.3. IKEv2 signaling between MN and HA for establishing SAs . . 8		5.3. IKEv2 signaling between MN and HA for establishing SAs . . 8
	6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 8		6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 8
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 9		8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	9. Normative References . . . . . . . . . . . . . . . . . . . . . 9		9. Normative References . . . . . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
	Intellectual Property and Copyright Statements . . . . . . . . . . 11		Intellectual Property and Copyright Statements . . . . . . . . . . 11
	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
	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. MIPv6		Internet, threats, and vulnerabilities to data networks. MIPv6
	[RFC3775] defines mobility support for IPv6 nodes. Since firewalls		[RFC3775] defines mobility support for IPv6 nodes. Since firewalls
	are not aware of MIPv6 protocol details, they will probably interfere		are not aware of MIPv6 protocol details, they will probably interfere
	with the smooth operation of the protocol. The problems caused by		with the smooth operation of the protocol. The problems caused by
	firewalls to Mobile IPv6 are documented in [RFC4487].		firewalls to Mobile IPv6 are documented in [RFC4487].
	This document presents some recommendations for firewall		This document presents some recommendations for firewall
	administrators to help them configure their firewalls in a way that		administrators to help them configure their firewalls in a way that
	allows Mobile IPv6 signaling and data messags to pass through. This		allows the Mobile IPv6 signaling and data messages to pass through.
	document assumes that the firewalls in question include some kind of		This document assumes that the firewalls in question include some
	stateful packet filtering capability. The static rules that need to		kind of stateful packet filtering capability. The static rules that
	be configured are described in this document. The dynamic		need to be configured are described in this document. In some
	capabilities needed for the firewalls to implement stateful filtering		scenarios, the support of additional mechanisms to create pinholes
	of MIPv6 packers is described in a companion document [MIP6FWVENDOR].		required for MIPv6 signalling and data traffic to pass through will
			be necessary. A possible solution, describing the dynamic
			capabilities needed for the firewalls to create pinholes based on
			MIPv6 signalling traffic is described in a companion document
			[MIP6FWVENDOR]. Other solutions may also be possible.
	3. Home Agent behind a firewall		3. Home Agent behind a firewall
	This section presents the recommendations for configuring a firewall		This section presents the recommendations for configuring a firewall
	that protects a home agent. For each type of traffic that needs to		that protects a home agent. For each type of traffic that needs to
	pass through this firewall, recommendations are presented on how to		pass through this firewall, recommendations are presented on how to
	identify that traffic. The following types of traffic are considered		identify that traffic. The following types of traffic are considered
	o Signaling between the MN and the HA		o Signaling between the MN and the HA
	skipping to change at page 4, line 33		skipping to change at page 4, line 41
	The following pattern will detect these messages.		The following pattern will detect these messages.
	Destination Address: Address of HA		Destination Address: Address of HA
	Transport Protocol: UDP		Transport Protocol: UDP
	Destination UDP Port: 500		Destination UDP Port: 500
	3.3. Data traffic from and to MN passing through the HA		3.3. Data traffic from and to MN passing through the HA
	If a CN tries to initiate traffic to an MN, a stateful firewall would		If a CN tries to initiate traffic to an MN, a stateful firewall would
	prevent these connection requests to pass through as there is no		prevent these connection requests to pass through as there is no
	established state on the firewall. Since MNs do not usually provide		established state on the firewall. If this is necessary to do, the
	services, this is not usually a problem. But if this is necessary to		pattern to look for is
	do, the pattern to look for is
	Destination Address: MN HoA		Destination Address: MN HoA
	Allowing this traffic might allow any kind of traffic, including		Allowing this traffic might allow any kind of traffic, including
	malicious traffic, to pass through unfiltered to the MN. This would		malicious traffic, to pass through unfiltered to the MN. This would
	expose the MN to any type of possibly malicious traffic, resulting in		expose the MN to any type of possibly malicious traffic, resulting in
	a denial of service or exploitation of known security		a denial of service or exploitation of known security
	vulnerabilities. This practice is NOT RECOMMENDED.		vulnerabilities. This practice is NOT RECOMMENDED. Instead, a
			dynamically created pinhole like the one specified in [MIP6FWVENDOR]
			can be used to allow this traffic.
	4. Correspondent Node behind a firewall		4. Correspondent Node behind a firewall
	This section presents the recommendations for configuring a firewall		This section presents the recommendations for configuring a firewall
	if a node behind it should be able to act as Mobile IPv6 CN. For		if a node behind it should be able to act as Mobile IPv6 CN. For
	each type of traffic that needs to pass through this firewall,		each type of traffic that needs to pass through this firewall,
	recommendations are presented on how to identify that traffic. The		recommendations are presented on how to identify that traffic. The
	following types of traffic are considered		following types of traffic are considered
	o Route optimization signaling between MN and CN through HA		o Route optimization signaling between MN and CN through HA
	skipping to change at page 6, line 23		skipping to change at page 6, line 30
	Mobility Header Type: 5		Mobility Header Type: 5
	This allows the BU to traverse the firewall and the BA can pass the		This allows the BU to traverse the firewall and the BA can pass the
	firewall without any assistance. Therefore, the Binding Update		firewall without any assistance. Therefore, the Binding Update
	sequence can be performed successfully.		sequence can be performed successfully.
	4.4. Route Optimization data traffic from MN		4.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. The stateful		can not traverse the firewall without assistance. A dynamically
	firewall rules specified in [MIP6FWVENDOR] will open a pinhole for		created pinhole such as the one specified in [MIP6FWVENDOR] will
	this traffic.		allow this traffic to pass.
	4.5. Bi-directional tunnelled data traffic from the MN to the CN		4.5. Bi-directional tunnelled data traffic from the MN to the CN
	through HA		through HA
	If a MN tries to initiate traffic to a CN through the HA using bi-		If a MN tries to initiate traffic to a CN through the HA using bi-
	directional tunnelling, a stateful firewall would prevent these		directional tunnelling, a stateful firewall would prevent these
	connection requests to pass through as there is no established state		connection requests to pass through as there is no established state
	on the firewall. This is usually a problem as CNs often provide		on the firewall. This is usually a problem as CNs often provide
	services. A solution is to static configure the firewall to let this		services. A solution is to static configure the firewall to let this
	traffic pass through. However, this is only an acceptable option if		traffic pass through. However, this is only an acceptable option if
End of changes. 13 change blocks.
	25 lines changed or deleted		32 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/