< draft-bajko-mip6-rrtfw-01.txt		draft-bajko-mip6-rrtfw-02.txt >
	MIP6 Working Group Gabor Bajko		Network Working Group G. Bajko
	Internet Draft		Internet-Draft Nokia
	Document: <draft-bajko-mip6-rrtfw-01.txt> October, 2006		Intended status: Standards Track H. Tschofenig
			Expires: January 10, 2008 Nokia Siemens Networks
			July 9, 2007
	Firewall friendly RTT for MIPv6		Firewall friendly Return-Routability Test (RTT) for Mobile IPv6
			draft-bajko-mip6-rrtfw-02.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents		By submitting this Internet-Draft, each author represents that any
	that any applicable patent or other IPR claims of which he		applicable patent or other IPR claims of which he or she is aware
	or she is aware have been or will be disclosed, and any of		have been or will be disclosed, and any of which he or she becomes
	which he or she becomes aware will be disclosed, in		aware will be disclosed, in accordance with Section 6 of BCP 79.
	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
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six months
	months
	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 20, 2007.		This Internet-Draft will expire on January 10, 2008.
	Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright Notice
	1. Abstract		Copyright (C) The IETF Trust (2007).
	Firewalls represent an integral part of today's IP networks,		Abstract
	currently based on IPv4 technology. Deployment of IPv6 is under way,
	and firewall vendors will need to deploy firewalls which will be
	able to handle IPv6 packets, including its many extensions. Mobile
	IPv6, standardized in RFC3775, specifies a number of extensions and
	procedures to IPv6, which do not work when firewalls are on the data
	communication path [1].
	This document defines a slightly modified Return Routability Test		This document defines a slightly modified Return Routability Test
	(RRT) for MIPv6 [2]. The new method is firewall friendly and allows		(RRT) for MIPv6. The herein defined RRT mechanism is intended for
	a mobile node to send Binding Update message to its correspondent		CoA exchanges between the MN and the CN. Once the MN and CN find out
			their peers' valid addresses, an additional mechanism will be used to
	1		run connectivity checks to figure out which of the address pairs have
	Firewall friendly RTT for MIPv6		connectivity and, if needed, open the required pinholes in the
	October 2006		firewalls. The defined mechanism is intended to work with current
			firewalls without requiring any support from them. The document also
			addresses the use of UDP encapsulation to facilitate MIPv6 signaling
			between involved nodes.
	node (so that Route Optimization can be applied) and ensures that		Table of Contents
	the CN receives the Binding Update, even when either the mobile
	node, the CN, or both are located behind firewalls.
	2. Conventions used in this document		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
			2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
			3. New Return Routability Procedure . . . . . . . . . . . . . . . 4
			4. UDP Encapsulation . . . . . . . . . . . . . . . . . . . . . . 5
			4.1. Problem Description . . . . . . . . . . . . . . . . . . . 5
			4.2. UDP Encapsulation Procedures . . . . . . . . . . . . . . . 5
			4.2.1. Procedures at the MN . . . . . . . . . . . . . . . . . 5
			4.2.2. Procedures at the HA . . . . . . . . . . . . . . . . . 6
			4.2.3. UDP encapsulated HoTI/HoT RRT messages . . . . . . . . 7
			5. Enabling Route Optimization Through Firewalls . . . . . . . . 7
			5.1. Problem Description . . . . . . . . . . . . . . . . . . . 7
			5.2. New RTT Proposal . . . . . . . . . . . . . . . . . . . . . 9
			5.3. Modified RRT Procedures . . . . . . . . . . . . . . . . . 10
			5.3.1. Modified RRT Procedures at the MN . . . . . . . . . . 10
			5.3.2. Modified RRT procedures at the CN . . . . . . . . . . 10
			5.3.3. HA processing of CoTI-ICE and CoT-ICE . . . . . . . . 10
			6. New Mobility Header Types . . . . . . . . . . . . . . . . . . 11
			6.1. CoTI-ICE Message . . . . . . . . . . . . . . . . . . . . . 11
			6.2. CoT-ICE Message . . . . . . . . . . . . . . . . . . . . . 11
			7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
			8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
			9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
			10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
			10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
			10.2. Informative References . . . . . . . . . . . . . . . . . . 13
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
			Intellectual Property and Copyright Statements . . . . . . . . . . 14
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		1. Introduction
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
	this document are to be interpreted as described in RFC-2119 [1].
	3. Abbreviation used in this document		Most of today's IP networks are protected by state full firewalls
			which filter the traffic based on the five tuple (sourceIP, destIP,
			sourcePort, destPort). This filtering could be supplied to incoming
			traffic or both incoming and outcoming. The problems which occure
			when using MIPv6 in firewall protected networks are described in
			detail in [RFC4487].
	This document uses the following abbreviations:		Most of the MIPv6 signalling is, as defined in [RFC3775], is secured
			by IPSec ESP, and most of today's firewalls will drop ESP packets, as
			there are no default rules defined for this traffic. So the mobile
			node is not able to successfully complete the registration of it's
			CoA in the new network and will not be able to communicate with other
			nodes.
	o CN: Correspondent Node		If the the Binding Update (BU) with the home agent (HA) is finished,
	o CoA: Care of Address		and the mobile node wants to use route optimization, it will start
	o CoT: Care-of Test		the Return Routability Procedure (RRT). For this it will send a HoTI
	o CoTI: Care-of Test Init		and a CoTI message to the corresponend node (CN). The HoTI will be
	o HA: Home Agent		send over the HA to the CN and the CoTI message directly to the CN.
	o HoA: Home Address		Normally the HoTI and the corresponet HoT message will go through,
	o HoT Home Test		but the CoTI or CoT message will mostly be dropped. So no route
	o HoTI: Home Test Init		optimization is available and all the traffic need to go over the HA.
	o MN: Mobile Node
	o RO: Route Optimization
	o RRT: Return Routability Test
	3. Table of Content		This document will provide a solution that the MIPv6 signalling will
			successfully complete. First a new return routability procedure will
			be shown and then a was to encapsulate messages in UDP to traverse
			the firewalls.
	1. Abstract 1		2. Terminology
	2. Conventions used in this document 1
	3. Table of Content 2
	4. Introduction 3
	5. Enabling basic mobile IPv6 operation through firewalls 4
	6. Enabling route optimization through firewalls 4
	5. New RRT proposal 8
	5.1 RRT procedures at the MN 9
	5.2 RRT procedures at the CN 9
	5.3 HA processing of CoTI-FW 9
	5.4 CoTI-FW message 9
	5.5 New Mobility Options 10
	6. Race conditions 10
	7. Security considerations 10
	8. Contributors 10
	9. References 11
	10. Author's Addresses 12
	4. Introduction		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in RFC 2119 [RFC2119].
	Current firewalls typically create state and filter data traffic		This document uses the following abbreviations:
	based on the five tuple (sourceIP, destIP, Prot, sourcePort,
	MIP6 Working Group Expiration 08/25/06 2		o CN: Correspondent Node
			o CoA: Care of Address
			o CoT: Care-of Test
			o CoT-ICE: Care-of Test ICE
			o CoTI: Care-of Test Init
			o CoTI-ICE: Care-of Test Init ICE
			o HA: Home Agent
			o HoA: Home Address
			o HoT Home Test
			o HoTI: Home Test Init
			o ICE: Interactive Connectivity Establishment
			o MN: Mobile Node
			o RO: Route Optimization
			o RRT: Return Routability Test
	Firewall friendly RTT for MIPv6		3. New Return Routability Procedure
	October 2006
	destPort). Filtering may be applied either to only incoming		Current firewalls typically create state and filter data traffic
	traffic or both incoming and outgoing traffic.		based on the five tuple (sourceIP, destIP, Prot, sourcePort,
			destPort). Filtering may be applied either to only incoming traffic
			or both incoming and outgoing traffic.
	RFC3775 recommends the use of IPsec ESP to protect packets between		MIP6 [RFC3775] faces a number of problems when used in an environment
	the MN and its home agent, while today's firewalls, as a default		with firewalls:
	rule, drop ESP packets, thus preventing the use of mobile IPv6. As
	mobile IPv6 could be regarded as a service offered to the mobile
	nodes, it is expected that firewalls placed between the access
	network, where the mobile node acquires its CoA, and the home
	network, where the mobile node's HA is residing, will relax the
	filtering rules based on some roaming agreements, thus allowing
	mobile nodes to register their CoA with the HA and use mobile IP.
	Even though mobile IPv6 signaling between the MN and its HA could		o (a) Mobile IP recommends the use of IPsec ESP to protect packets
	be guaranteed using static configurations in the firewalls, there		between the MN and its home agent, while today's firewalls, as a
	is no way to ensure the same for the signaling between the MN and		default rule, drop ESP packets, thus preventing the use of MIP6.
	the CN (for the return routability test purposes). Without		It is possible to configure static pinholes in the firewalls to
	applying route optimization the MN and the CN would be forced to		allow ESP and IKE messages between MN and HA to pass
	communicate through their home agents, and that, based on their		through.[I-D.krishnan-mip6-firewall] describes best current
	topological location, could result in a trombone effect		practices on how to configure firewalls to enable MIPv6.
	introducing delays. Such additional delays might not be tolerated		Alternatively, UDP encapsulation might be used.
	by interactive applications sensitive to delays.		o (b) current firewalls filter on udp and tcp protocol, thus when a
			firewall is protecting the CN, that firewall might not allow a
			HoTI to pass, as that is sent using MH protocol [RFC3775]. If the
			policy in the firewall would allow wildcard for the protocol
			instead of filtering on udp or tcp, this problem would be solved
			as well. Note: here it is assumed that when a HoTI is generated
			by the MN (i.e. start of route optimisation), then there is
			already a data connection between the MN and the CN through the
			HA.
			o (c) similar to the above, when a firewall protecting the MN sees a
			CoTI message, it would need to install state to allow the
			corresponding CoT to pass and reach the MN. Firewalls that do not
			support MH and modifying the firewall policy is not acceptable for
			the administrator, UDP encapsulation might need to be used. This
			is addressed in section 5.
			o (d) a firewall protecting the CN will not allow a CoTI to pass, as
			that is sent from an untrusted address.
			o (e) when both the HA and the MN and/or CN are behind firewalls,
			then a combination of UDP encapsulation and the modified RRT
			mechanism defined in this document might need to be used to enable
			MIPv6 operation.
	In order to ensure a successful deployment of IPv6 and mobile IPv6		As a summary, while some of the mobile IPv6 signaling could be
	in current IP networks, it is important to have mechanisms and		enabled using static configurations in the firewalls, there is no way
	guidelines in place which help the smooth operation of the		to ensure the same for the signaling and data traffic on the direct
	protocol in a firewalled environment.		path between the MN and the CN.
	There are a limited number of possibilities on how to enable		Without applying route optimization, the MN and the CN would be
	mobile IPv6 through firewalls. One proposal, using the NSLP NATFW		forced to communicate through their home agents, and that, based on
	protocol can be found in [3]. The document proposes that the		their topological location, could result in increased latency and
	mobile node running mobile IPv6 uses the NSLP NATFW protocol to		cost. Such additional delays might not be tolerated by interactive
	open the required pinholes in the firewalls on the path between		applications sensitive to delays.
	the MN and the CN, before any and each mobile IPv6 signaling is
	initiated. The proposal also requires that all the firewalls on
	the path support the NSLP NATFW protocol.
	The proposal in this document describes an alternative solution		In order to ensure a successful deployment of IPv6 and mobile IPv6 in
	for the problem by making some recommendations on firewall		current IP networks, it is important to have mechanisms and
	configuration and defining an extension to mobile IPv6.		guidelines in place which help the smooth operation of the protocol
			in an environment with firewalls.
	5. Enabling basic mobile IPv6 operation through firewalls		4. UDP Encapsulation
	MIP6 Working Group Expiration 04/20/07 3		This section addresses scenarios a), b) and c) from Section 1.
	Firewall friendly RTT for MIPv6		4.1. Problem Description
	October 2006
	In order to enable the mobile node to use mobile IPv6, it is		When the MN or the HA or both are behind firewalls that block IPsec
	required to allow a communication path between the MN and its HA.		ESP, then the Binding Update to the Home Agent will fail. To
	More specifically, the Binding Update, Binding Acknowledgement,		overcome this situation, firewall administrators may configure static
	Binding error and Binding Refresh Request messages will need to		pinholes in the firewalls, as described in
	pass through the firewalls on the path unaltered.		[I-D.krishnan-mip6-firewall]. When that is not feasible, as an
			alternative, the MN may use UDP encapsulation to wrap its MIPv6
			messages destined to the HA into a UDP/IP header. As the MN can not
			influence or change the firewall behavior, it has to determine
			whether there are any firewalls blocking ESP between itself and the
			HA or not. When there are, it will need to use UDP encapsulation.
	RFC3775 mandates the use of IPsec and recommends the use of ESP		Additionally, when the MN or the CN or both are behind firewalls that
	for these messages.		do not allow packets with MH protocol to pass, the MN, or the CN or
			both may need to use UDP encapsulation to wrap their MIPv6 messages
			into a duplicate UDP/IP header. Same applies when the firewall
			allows MH packets to pass in the in-->out direction but does not
			install state to allow the corresponding response in the out-->in
			direction.
	It is thus recommended that firewall administrators create a rule		4.2. UDP Encapsulation Procedures
	in the firewall to allow ESP protected packets between the MN and
	its HA to pass through. As these packets might not necessarily be
	ESP protected, the firewall would need to recognize mobility
	header packets and create a rule to allow these packets to pass
	through. One example of such a rule could be to filter on the
	sourceIP, destIP and next header value of 135.
	6. Enabling route optimization through firewalls		4.2.1. Procedures at the MN
	In order to enable route optimizations through firewalls, both		When the MN detects that there is a firewall between itself and the
	HoTI and CoTI messages (and the corresponding HoT and CoT) need to		HA, it SHOULD start using UDP encapsulation to wrap its MIPv6
	successfully pass through.		signaling messages destined to the HA into new UDP/IP header. When
	It is assumed that at the time when the MN initiates a route		using UDP encapsulation, the MN MUST use UDP port 500.
	optimization procedure towards the CN, there is already some sort
	of data communication between the MN and the CN. If the CN is
	behind firewall and that firewall does have a rule to allow
	packets from the HoA of the MN to the address of the CN, then
	there is a good chance that HoTI would also make it through the
	firewall. The filtering rule would need to be relaxed to allow in
	addition MH packets through between the two destinations (HoA of
	the MN and the address of the CN).
	If such a rule does not exist in the firewall protecting the CN,
	then HoTI will be dropped and the return routability test will
	fail.
	In order to facilitate the communication between the mobile nodes,
	firewalls on the data path between an MN and a CN could also
	create the following pinholes automatically:
	- a pinhole from the address of the CN to the HoA of the MN		[Editor's Note: If there is a NAT between the mobile node and the
	present in the type 2 Routing Header		home agent then IKEv2 will enable UDP encapsulation for subsequent
	- - a pinhole from the CoA of the MN to the HoA of the CN present		traffic. For firewalls this UDP encapsulation can either be provided
	in the Destination Options extension Header		by IKEv2 or as part of the mobile IP stack. For the usage with RFC
			4285 mobile IP has to enable this UDP encapsulation procedure since
			IKEv2 is not used in this case.]
	MIP6 Working Group Expiration 04/20/07 4		The MN can detect that there is a firewall on the path by either
			using an external mechanism like STUN [6] or by simply assuming that
			if the Binding Update to its HA fails, then that is probably the
			case.
	Firewall friendly RTT for MIPv6		When the MN receives a packet on UDP port 500 from its HA, it MUST
	October 2006		inspect the first 8 bytes of the UDP payload. If those are set to
			zero then the MN received a UDP encapsulated MH packet and it MUST
			remove the UDP/IP header and process the inner packet as a MH packet.
	If it is only the MN protected by firewalls but the CN is not,		4.2.2. Procedures at the HA
	then HoTI will successfully arrive to the CN. The firewall
	protecting the MN would need to allow the corresponding HoT to
	pass through and reach the MN. For this, the firewall may need to
	create a rule when forwarding the HoTI. An example of such a rule
	is to allow packets between the HoA of the MN and the address of
	the CN with the Next Header value of 135 to pass through.
	Once HoTI is sent out and a HoT response is received, the MN will		When the HA receives a packet on UDP port 500, it MUST inspect the
	send a CoTI message from its current CoA. If there is a firewall		first 8 bytes of the UDP payload. If those are set to zero then the
	protecting the CN, that firewall will drop the CoTI message as it		HA received a UDP encapsulated MH packet and it MUST remove the
	is coming from an untrusted source.		UDP/IP header and process the inner packet as a MH packet.
	In order to illustrate the problem, let’s assume a communication		The HA MUST also use UDP encapsulation with port 500 when sending a
	between an inner node A (protected by the firewall), and an		response to a UDP encapsulated MH packet to the MN.
	external mobile node B. It is assumed that the Firewall protecting
	the CN (node A) trusts the HoA of the mobile node B, therefore MH
	packets like HoTI are allowed to pass through the Firewall without
	problems.
	As specified in the Mobile IP [2], the transport and above layers
	of the ongoing communications should be based on the Home IP
	address and HoA of node B, and not the local IP address that node
	B might get while roaming in order to support mobility.
	The state created in the firewall protecting node A is therefore
	initially based on the IP address of node A, and the home address
	of the node B, HoA of node B.
	If the mobile node B is in its home network, the packets are
	directly exchanged between the nodes A and B.
	If the mobile node B is roaming, the session can be maintained
	thanks to the Home Agent of node B and the reverse tunneling
	mechanism [2]. Packets forwarded by the Home Agent to node A will
	have the source IP address indicating the Home IP address of node
	B and the destination IP address indicating the IP address of node
	A. Such packets can thus pass the packet filter inspection in the
	firewall protecting node A.
	However nodes A and B might be close while node B’s Home agent may
	be far, resulting in a 'trombone effect' that can create delay and
	degrade the performance. The Mobile IP specifications have defined
	the route optimization procedure [2] in order to solve this issue.
	The mobile node should first execute a Return Routability Test:
	the Mobile Node B should send a Home Test Init message (HoTI) via
	MIP6 Working Group Expiration 04/20/07 5		When the HA receives a UDP encapsulated packet containing a HoTI or a
			HoT or a CoTI-ICE (defined in this document) or a CoT-ICE (defined in
			this document) MH packet, it MUST decapsulate and re-encapsulate it
			using UDP port 500 before sending it to the MN or CN, respectively:
	Firewall friendly RTT for MIPv6		Mobile Node Home Agent Correspondent Node
	October 2006		| | |
			| HoTI:=IPv6(MN_COA, HA_ADDR) | HoTI:=IPv6(HA_ADDR, CN_ADDR) |
			| UDP header | UDP header |
			| IPv6 header | IPv6 header |
			| Mobility header | Mobility header |
			| type: HoTI (1) | type: HoTI (1) |
			| | |
			|---------------------------->|----------------------------->|
			| | |
			| HoT:=IPv6(HA_ADDR, MN_CoA) | HoT:=IPv6(CN_ADDR, HA_ADDR) |
			| UDP header | UDP header |
			| IPv6 header | IPv6 header |
			| Mobility header | Mobility header |
			| type: HoT (3) | type: HoT (3) |
			| | |
			|<----------------------------|<-----------------------------|
			| | |
	its Home Agent and a Care of Test Init (CoTI) message directly to		4.2.3. UDP encapsulated HoTI/HoT RRT messages
	its correspondent node A as illustrated in the figure below [1]:
	MIP6 Working Group Expiration 04/20/07 6		The CoTI-ICE/CoT-ICE messages are treated similarly, only the MH type
			will have a different value (22 and 23 respectively)
	Firewall friendly RTT for MIPv6		4.2.3.1. Procedures at the CN
	October 2006
	+----------------+		When the CN receives a packet on UDP port 500, it MUST inspect the
	| +----+ HoTI (HoA) +----+		first 8 bytes of the UDP payload. If those are set to zero then the
	| | FW |<----------------|HA B|		CN received a UDP encapsulated MH packet and it MUST remove the
	| +----X +----+		UDP/IP header and process the inner packet as a MH packet.
	| +---+ | ^ CoTI – dropped ^
	| | A | | | by the FW |
	| +---+ | | | HoTI
	| | | |
	| | | CoTI (CoA)+---+
	| | +------------------| B |
	+----------------+ +---+
	Network protected External Mobile
	by a firewall Node
	The Care of Test Init message is more particularly sent from the		When the CN receives a UDP encapsulated MH message, it MUST send the
	new CoA, however such packet will not match any entry in the		response using UDP encapsulation.
	packet filter in the firewall and, the CoTI message will thus be
	dropped.
	As a consequence, the RRT cannot be completed and Route
	optimization cannot be applied due to the presence of a firewall.
	Support for route optimization is not a non-standard set of		5. Enabling Route Optimization Through Firewalls
	extensions, but a fundamental part of the protocol. Firewalls
	however prevent route optimisation to be applied by blocking the
	Return Routability Test messages.
	The above scenario is one from the problem statements described in		Route optimization can be enabled by either using dedicated signaling
	[1].		to instruct the firewall to create a pinhole, or using a mechanism
			which would make the firewall to install pinholes as part of its
			normal operation. This draft addresses the latter solution.
	One could argue that CoTI could be reverse tunneled in the same		5.1. Problem Description
	way as HoTI, and the problem would be solved. Even though sending
	CoTI through the HA provides solution for the case when the CN is
	behind Firewall, the problem would not be solved for the symmetric
	scenario, when the MN is behind Firewall: if a CoTI is not sent
	from the CoA of the MN, the Firewall protecting the MN would not
	open a pinhole for the <MN CoA, CN CoA> address pair, and thus CoT
	will be dropped, resulting in a failed RRT.
	If CoTI would follow the path of HoTI and CoT would follow the		This section describes in more details scenario d) from Section 1.
	path of HoT, then the Return Routability Test would be successful,
	without actually testing the direct path between the MN and CN. If
	Firewalls are on the path of the data between MN and CN, the data
	MIP6 Working Group Expiration 04/20/07 7		The Return Routability Test defined in [RFC4487] enables the
			correspondent node to obtain some reasonable assurance that the
			mobile node is in fact addressable at its claimed care-of address as
			well as at its home address, while keygen tokens are exchanged and
			combined into a binding management key. In order to enable route
			optimizations through firewalls, both HoTI and CoTI messages (and the
			corresponding HoT and CoT) need to successfully pass through. It is
			assumed that at the time when the MN initiates a route optimization
			procedure towards the CN, there is already some sort of data
			communication between the MN and the CN. If the CN is behind
			firewall and that firewall does have a rule to allow packets from the
			HoA of the MN to the address of the CN, then there is a good chance
			that HoTI would also make it through the firewall.
	Firewall friendly RTT for MIPv6		If such a rule does not exist in the firewall protecting the CN, then
	October 2006		HoTI will be dropped and the return routability test will fail.
	packets would be dropped, as corresponding pinholes were not		Once HoTI is sent out and a HoT response is received, the MN will
	opened. Thus RRT would not reach its purpose.		send a CoTI message from its current CoA. If there is a firewall
			protecting the CN, that firewall will drop the CoTI message as it is
			coming from an untrusted source.
	7. New RTT proposal		In order to illustrate the problem, let's assume a communication
			between an inner node A (protected by the firewall), and an external
			mobile node B. It is assumed that the firewall protecting the CN
			(node A) is configured in such a way that it allows traffic from the
			node B's HoA to bypass, therefore MH packets like HoTI are not
			filtered.
	This document proposes an additional procedure for the Return		As specified in Mobile IP [RFC3775], the transport and higher layers
	Routability Test to be performed by mobile nodes who wish to		should use the Home IP address and HoA of node B, and not the local
	communicate with CNs and either or both parties are behind		IP address that node B might get while roaming in order to support
	Firewalls.		mobility. The state created in the firewall protecting node A is
			therefore initially based on the IP address of node A, and the home
			address of the node B, HoA of node B. If the mobile node B is in its
			home network, the packets are directly exchanged between the nodes A
			and B. If the mobile node B is roaming, the session can be maintained
			thanks to the Home Agent of node B and the reverse tunneling
			mechanism [RFC3775]. Packets forwarded by the Home Agent to node A
			will have the source IP address indicating the Home IP address of
			node B and the destination IP address indicating the IP address of
			node A. Such packets can thus pass the packet filter inspection in
			the firewall protecting node A. However, nodes A and B might be
			located topologically closely together while node B's Home Agent may
			be far away, resulting in a 'trombone effect' that can create delay
			and degrade the performance. The Mobile IP specifications have
			defined the route optimization procedure [RFC3775] in order to solve
			this issue. The mobile node should first execute a Return
			Routability Test: the Mobile Node B should send a Home Test Init
			message (HoTI) via its Home Agent and a Care of Test Init (CoTI)
			message directly to its correspondent node A as illustrated in the
			figure below [RFC4487]:
	A failure in RRT is usually detected in the CN by not receiving a		+----------------+
	CoTI after HOT was sent out. The MN detects the RRT failure by not		| +----+ HoTI (HoA) +----+
	receiving a CoT after sending out a CoTI. To solve this problem,		| | FW |<----------------|HA B|
	this document proposes that when the MN detects the RRT failure, it		| +----X +----+
	will send out a new MH message, called CoTI-FW. The CoTI-FW will		| +---+ | ^ CoTI - dropped ^
	contain the CoA of the MN in the Mobility Options header field and		| | A | | | by the FW |
	it will need to be reverse tunneled through the HA. A CN receiving a		| +---+ | | | HoTI
	CoTI-FW will know that a CoTI has been probably dropped by the		| | | |
	Firewall. It will send a CoT message to the CoA of the MN in		| | | CoTI (CoA)+---+
	response to the CoTI-FW. Even if the MN is behind Firewall, the		| | +------------------| B |
	initial CoTI opened a pinhole which would allow the CoT response to		+----------------+ +---+
	CoTI-FW to pass through the Firewall and reach the MN.		Network protected External Mobile
			by a firewall Node
	Figure 1 illustrates the new RRT procedure (the first three messages		The Care of Test Init message is sent from the new CoA. However,
	are part of the original RRT):		this packet will not match any entry in the packet filter in the
			firewall and the CoTI message will be dropped. As a consequence, the
			RRT cannot be completed and Route optimization cannot be applied due
			to the presence of a firewall.
	Mobile node Home agent Correspondent node		The above scenario is one from the problem statements described in
	| |		[RFC4487].
	| Home Test Init (HoTI) | |
	|------------------------->|------------------------->|
	| | |
	| Care-of Test Init (CoTI) |
	|-----------|FW|---------------------->x|FW| dropped |
	| |
	| | Home Test (HoT) |
	|<-------------------------|<-------------------------|
	| | |
	| CoT not sent (as CoTI was not received by CN)<......|
	timeout waiting for CoT		5.2. New RTT Proposal
	| |		This document proposes a modified RRT for MIPv6 nodes behind
	| CoTI-FW | |		firewalls. In the new RRT mechanism the original HoTI and HoT remain
	|------------------------->|------------------------->|		unchanged, while the new CoTI (called CoTI-ICE) and CoT (called CoT-
	| Care-of Test (CoT) |		ICE) messages will be routed through the HA in a similar way as HoTI
	|<----------|FW|------------------------|FW|----------|		and HoT. While the token exchange for binding management key
	| |		generation purposes from the original RRT is preserved, the new RRT
			mechanism will be used to exchange the valid addresses the MN and CN
			possess. Once the addresses - called candidate addresses - are
			exchanged, both the MN and CN will run connectivity checks as
			described in [I-D.tschofenig-mip6-ice] in order to enable and to
			check the connectivity for the addresses. When a working address
			pair is found, the MN will send a BU from that CoA to the CN's
			address.
	Figure 1 The new RRT procedure		Mobile node Home agent Correspondent node
			| |
			| HoTI | |
			|------------------------->|------------------------->|
			| | |
			| CoTI-ICE | |
			|------------------------->|------------------------->|
			| | |
			| | HoT |
			|<-------------------------|<-------------------------|
			| | |
			| | CoT-ICE |
			|<-------------------------|<-------------------------|
			| | |
	MIP6 Working Group Expiration 04/20/07 8		The new RRT mechanism will not test the connectivity on the direct
			path between the MN and CN. As that is still needed before the nodes
			engage in data exchange, a new mechanism, described in
			[I-D.tschofenig-mip6-ice] is used for this purpose.
	Firewall friendly RTT for MIPv6		5.3. Modified RRT Procedures
	October 2006
	A MN SHOULD always perform the herein described procedure when it		5.3.1. Modified RRT Procedures at the MN
	experiences problems with the original RTT described in [2].
	7.1 RRT procedures at the MN		The MN following the new RRT procedure defined in this draft MUST NOT
			send a CoTI, as defined in [RFC3775], to the CN. Instead it MUST
			generate a CoTI-ICE, as defined in this document. The MN MUST gather
			its addresses from all its interfaces as described in
			[I-D.tschofenig-mip6-ice]. The MN MUST form candidate-addresses as
			described in [I-D.tschofenig-mip6-ice]. The MN MUST put all of its
			candidate-addresses into a MIP-ICE mobility options defined in
			[I-D.tschofenig-mip6-ice] and MUST attach it to the CoTI-ICE message.
	A MN MUST NOT send a COTI-FW without sending first a COTI. The MN		5.3.2. Modified RRT procedures at the CN
	MUST NOT send a COTI-FW if a CoT response has been received for the
	CoTI.
	A MN SHOULD always send a CoTI-FW if it does not receive a CoT
	response to the previously sent CoTI. The CoTI-FW MUST contain the
	same care-of init cookie as the one sent out in CoTI.
	A CoTI-FW MUST contain the MN's CoA in the Mobility Options field.
	7.2 RRT procedures at the CN		The CN supporting the new RRT procedure defined in this document,
			upon receiving a CoTI-ICE message MUST NOT send a CoT response, as
			defined in [RFC3775]. The CN upon receipt of a CoTI-ICE message MUST
			gather its addresses from all its interfaces as described in
			[I-D.tschofenig-mip6-ice]. The CN MUST form candidate-addresses as
			described in [I-D.tschofenig-mip6-ice]. The CN MUST put all of its
			candidate-addresses into a MIP-ICE mobility options defined in
			[I-D.tschofenig-mip6-ice] and MUST attach it to the CoT-ICE message.
	Upon receiving a CoTI-FW request, the CN creates a care-of keygen		5.3.3. HA processing of CoTI-ICE and CoT-ICE
	token and uses the current nonce index as the Care-of Nonce Index.
	It then creates a Care-of Test message and sends it to the care-of
	address of the mobile node found in the Mobility Options field.
	7.3 HA processing of CoTI-FW		Both CoTI-ICE and CoT-ICE messages MUST be processed by the HA as any
			other Mobility Header message, as described in [RFC3775].
	A CoTI-FW message MUST be processed by the HA as any other Mobility		6. New Mobility Header Types
	Header message, as described in [2].
	7.4 CoTI-FW message		6.1. CoTI-ICE Message
	A mobile node uses the CoTI-FW message to finalize the return		A mobile node uses the CoTI-ICE message to finalize the return
	routability procedure and request a care-of keygen token from a		routability procedure and request a care-of keygen token from a
	correspondent node when a CoT response to CoTI has not been		correspondent. The CoTI-ICE message uses the MH Type value 22 (to be
	received. The CoTI-FW message uses the MH Type value 22 (to be		registered with IANA). A CoTI-FW message MUST include a mobility
	registered with IANA).		options carrying the candidate addresses of the MN sending it.
	A CoTI-FW message MUST include a mobility options carrying the CoA
	of the MN sending it.
	MIP6 Working Group Expiration 04/20/07 9		When value 22 is indicated in the MH Type field, the format of the
			Message Data field in the Mobility Header is as follows:
	Firewall friendly RTT for MIPv6		0 1 2 3
	October 2006		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Reserved |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			+ Care of Init Cookie +
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			. MIP-ICE Mobility Options .
			. .
			. .
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	7.5 New Mobility Options		Care of Init Cookie: as defined in RFC 3775
			MIP-ICE Mobility Options: as defined in [I-D.tschofenig-mip6-ice]
	This specification defines a new Mobility Options called 'MN FW-RRT		6.2. CoT-ICE Message
	CoA' which has an alignment requirement of 8n+6. Its format is as
	follows:
	0 1 2 3		The Care-of Test ICE (CoT-ICE) message is a response to the Care-of
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		Test Init ICE (CoTI-ICE) message, and is sent from the correspondent
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		node to the mobile node. The Care-of Test ICE message uses the MH
	| Type = 16 | Length = 16 |		Type value 23 (to be registered with IANA). When this value is
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		indicated in the MH Type field, the format of the Message Data field
	| |		in the Mobility Header is as follows:
	+ +
	| |
	+ MN FW-RRT Care-of Address +
	| |
	+ +
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	The MN FW-RRT CoA mobility options is defined to be carried in a		0 1 2 3
	CoTI-FW message.		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Care-of Nonce Index |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			+ Care of Init Cookie +
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			+ Care-of Keygen Token +
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	8. Race conditions		| |
			. MIP-ICE Mobility Options .
			. .
			. .
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	There are a few cases when the CN may receive both CoTI and CoTI-FW		Care of Init Cookie: as defined in RFC 3775
	messages, e.g. when CoT got delayed and the MN sends a CoTI-FW after		Care-of Keygen Token: as defined in RFC 3775
	sending a CoTI.		MIP-ICE Mobility Options: as defined in [I-D.tschofenig-mip6-ice]
	The CN can and SHOULD detect whether CoTI and CoTI-FW were sent from		7. IANA Considerations
	the same CoA or not. If they came from the same CoA, the CN SHOULD
	NOT respond to both with a CoT, but only to one of them. If CoTI and
	CoTI-FW came from different CoA, that might be the result of the MN
	changing CoA (e.g. from a CoA not belonging to the same FW protected
	network as the CN, to a CoA belonging there) and initiating RRT from
	both CoA. The CN SHOULD respond to both messages with a CoT.
	9. Security considerations		This specification registers new MH type values:
	The proposal herein assumes that future Firewalls supporting MIPv6,		CoTI-ICE message uses MH type value 22.
	will install states for MH packet initiated flows too, in the same
	way as it is currently done for UDP flows. It is the understanding
	of the authors, that this does not introduce any additional security
	threads to the system.
	10. Contributors		CoT-ICE message uses MH type value 23.
	Acknowledgements to Franck Le for contributing to this draft. Thanks		8. Security Considerations
	to Lassi Hippelainen for valuable comments.
	MIP6 Working Group Expiration 04/20/07 10		The security threats described in [I-D.tschofenig-mip6-ice] are
			inherited in addition to the existing ones mentioned in [RFC3775].
	Firewall friendly RTT for MIPv6		[Editor's Note: More work is needed on the security consideration
	October 2006		section particularly since the security properties of the return
			routability check might be changed.]
	11. References		9. Acknowledgments
	[1] Franck Le, Stefano Faccin, Basavaraj Patil, Hannes Tschofenig,		We would like to thank Thomas Schreck for his contributions to this
	'Mobile IPv6 and Firewalls, Problem statement' IETF Internet		document.
	draft, May 2005.
	[2] D. Johnson, C. Perkins, J. Arkko ’Mobility support in IPv6’,		10. References
	RFC3775, June 2004
	[3] http://www.ietf.org/internet-drafts/draft-thiruvengadam-nsis-		10.1. Normative References
	mip6-fw-04.txt, wprk in progress
	12. Author's Addresses		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
			Requirement Levels", March 1997.
	Gabor Bajko		[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
	gabor.bajko@nokia.com		in IPv6", RFC 3775, June 2004.
	Intellectual Property Statement		[I-D.tschofenig-mip6-ice]
			Tschofenig, H. and G. Bajko, "Mobile IP Interactive
			Connectivity Establishment (M-ICE)",
			draft-tschofenig-mip6-ice-00 (work in progress),
			June 2007.
	The IETF takes no position regarding the validity or scope of any		10.2. Informative References
	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		[RFC4487] Le, F., Faccin, S., Patil, B., and H. Tschofenig, "Mobile
	assurances of licenses to be made available, or the result of an		IPv6 and Firewalls: Problem Statement", RFC 4487,
	attempt made to obtain a general license or permission for the use		May 2006.
	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		[I-D.krishnan-mip6-firewall]
	copyrights, patents or patent applications, or other proprietary		Krishnan, S., "Firewall Recommendations for MIPv6",
	rights that may cover technology that may be required to implement		draft-krishnan-mip6-firewall-00 (work in progress),
	this standard. Please address the information to the IETF at		July 2007.
	ietf-ipr@ietf.org.
	Disclaimer of Validity		Authors' Addresses
	This document and the information contained herein are provided on		Gabor Bajko
	an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE		Nokia
	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
	MIP6 Working Group Expiration 04/20/07 11		Hannes Tschofenig
			Nokia Siemens Networks
			Otto-Hahn-Ring 6
			Munich, Bavaria 81739
			Germany
	Firewall friendly RTT for MIPv6		Email: Hannes.Tschofenig@nsn.com
	October 2006		URI: http://www.tschofenig.com
			Full Copyright Statement
			Copyright (C) The IETF Trust (2007).
			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, THE IETF TRUST 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		THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Copyright Statement		Intellectual Property
	Copyright (C) The Internet Society (2006). This document is subject		The IETF takes no position regarding the validity or scope of any
	to the rights, licenses and restrictions contained in BCP 78, and		Intellectual Property Rights or other rights that might be claimed to
	except as set forth therein, the authors retain all their rights.		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.
	Acknowledgment		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.
	Funding for the RFC Editor function is currently provided by the		The IETF invites any interested party to bring to its attention any
	Internet Society.		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.
	MIP6 Working Group Expiration 04/20/07 12		Acknowledgment
			Funding for the RFC Editor function is provided by the IETF
			Administrative Support Activity (IASA).
End of changes. 111 change blocks.
	401 lines changed or deleted		484 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/