draft-thiruvengadam-nsis-mip6-fw-05.txt		draft-thiruvengadam-nsis-mip6-fw-04.txt
	NSIS S. Thiruvengadam		NSIS S. Thiruvengadam
	Internet-Draft H. Tschofenig		Internet-Draft H. Tschofenig
	Intended status: Informational Siemens		Expires: December 28, 2006 Siemens
	Expires: April 25, 2007 F. Le		F. Le
	CMU		CMU
	N. Steinleitner		N. Steinleitner
	X. Fu		X. Fu
	Univ. Goettingen		Univ. Goettingen
	October 22, 2006		June 26, 2006
	Mobile IPv6 - NSIS Interaction for Firewall traversal		Mobile IPv6 - NSIS Interaction for Firewall traversal
	draft-thiruvengadam-nsis-mip6-fw-05.txt		draft-thiruvengadam-nsis-mip6-fw-04.txt
	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 25, 2007.		This Internet-Draft will expire on December 28, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	Most of the firewalls deployed today are Mobile IPv6 unaware.		Most of the firewalls deployed today are Mobile IPv6 unaware.
	Widespread Mobile IPv6 deployment is not possible unless Mobile IPv6		Widespread Mobile IPv6 deployment is not possible unless Mobile IPv6
	messages can pass through these firewalls. One approach is to use a		messages can pass through these firewalls. One approach is to use a
	skipping to change at page 2, line 23		skipping to change at page 2, line 17
	enabling Mobile IPv6 traversal.		enabling Mobile IPv6 traversal.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Mobile node behind a firewall . . . . . . . . . . . . . . . . 5		3. Mobile node behind a firewall . . . . . . . . . . . . . . . . 5
	3.1. Binding updates . . . . . . . . . . . . . . . . . . . . . 5		3.1. Binding updates . . . . . . . . . . . . . . . . . . . . . 5
	3.2. Route optimization . . . . . . . . . . . . . . . . . . . . 5		3.2. Route optimization . . . . . . . . . . . . . . . . . . . . 5
	3.3. Bi-directional tunneling . . . . . . . . . . . . . . . . . 7		3.3. Bi-directional tunneling . . . . . . . . . . . . . . . . . 7
	3.4. Change of Firewalls . . . . . . . . . . . . . . . . . . . 7		3.4. Triangular routing . . . . . . . . . . . . . . . . . . . . 7
	3.5. Operations when MN is behind a firewall . . . . . . . . . 8		3.5. Change of Firewalls . . . . . . . . . . . . . . . . . . . 8
	4. Correspondent Node behind a firewall . . . . . . . . . . . . . 9		3.6. Operations when MN is behind a firewall . . . . . . . . . 9
	4.1. Route Optimization . . . . . . . . . . . . . . . . . . . . 9		4. Correspondent Node behind a firewall . . . . . . . . . . . . . 10
	4.2. Bi-directional Tunneling . . . . . . . . . . . . . . . . . 11		4.1. Route Optimization . . . . . . . . . . . . . . . . . . . . 10
	4.3. Change of Firewalls . . . . . . . . . . . . . . . . . . . 12		4.2. Bi-directional Tunneling . . . . . . . . . . . . . . . . . 12
	4.4. Operations when CN is behind a firewall . . . . . . . . . 12		4.3. Triangular routing . . . . . . . . . . . . . . . . . . . . 13
	5. Home Agent behind a firewall . . . . . . . . . . . . . . . . . 14		4.4. Change of Firewalls . . . . . . . . . . . . . . . . . . . 14
	5.1. Route Optimization . . . . . . . . . . . . . . . . . . . . 14		4.5. Operations when CN is behind a firewall . . . . . . . . . 14
	5.2. Bi-directional tunneling . . . . . . . . . . . . . . . . . 15		5. Home Agent behind a firewall . . . . . . . . . . . . . . . . . 16
	5.3. Operations when HA is behind a firewall . . . . . . . . . 16		5.1. Route Optimization . . . . . . . . . . . . . . . . . . . . 16
	6. Additional Discussions . . . . . . . . . . . . . . . . . . . . 17		5.2. Bi-directional tunneling . . . . . . . . . . . . . . . . . 17
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 18		5.3. Triangular routing . . . . . . . . . . . . . . . . . . . . 18
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19		5.4. Operations when HA is behind a firewall . . . . . . . . . 18
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20		6. Additional Discussions . . . . . . . . . . . . . . . . . . . . 20
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 20		7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
	9.2. Informative References . . . . . . . . . . . . . . . . . . 20		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
	Intellectual Property and Copyright Statements . . . . . . . . . . 22		9.1. Normative References . . . . . . . . . . . . . . . . . . . 23
			9.2. Informative References . . . . . . . . . . . . . . . . . . 23
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
			Intellectual Property and Copyright Statements . . . . . . . . . . 25
	1. Introduction		1. Introduction
	Route optimization, an integral part of Mobile IPv6 specification		Route optimization, an integral part of Mobile IPv6 specification
	does not work with state of the art firewalls that employ stateful		does not work with state of the art firewalls that employ stateful
	packet filtering (SPF). This problem is well described in [1]. The		packet filtering (SPF). This problem is well described in [1]. The
	other mode of communication in Mobile IPv6, namely bi-directional		other modes of communication in Mobile IPv6, namely bi-directional
	tunneling, also do not work under some firewall placements. Apart		tunneling and triangular routing, also do not work under some
	from this, the Mobile IPv6 binding updates (encapsulated using IPsec		firewall placements. Apart from this, the Mobile IPv6 binding
	ESP) packets also have problems with firewall traversal. To tackle		updates (encapsulated using IPsec ESP) packets also have problems
	these issues, one approach is to utilize a signaling protocol to		with firewall traversal. To tackle these issues, one approach is to
	install some firewall rules for allowing these Mobile IPv6 messages		utilize a signaling protocol to install some firewall rules for
	to pass through. The NSIS NAT/FW NSLP, as described in [2], allows		allowing these Mobile IPv6 messages to pass through. The NSIS NAT/FW
	to establish, maintain and delete middlebox state (i.e., NAT bindings		NSLP, as described in [2], allows to establish, maintain and delete
	and Firewall rules), and allow packets to traverse these boxes. This		middlebox state (i.e., NAT bindings and Firewall rules), and allow
	protocol thus provides a possible way to address the aforementioned		packets to traverse these boxes. This protocol thus provides a
	problem. This document describe the considerations of NSIS NAT/FW		possible way to address the aforementioned problem. This document
	NSLP, especially the involved messages and necessary firewall rules,		describe the considerations of NSIS NAT/FW NSLP, especially the
	when firewalls are encountered in a Mobile IPv6 network. More		involved messages and necessary firewall rules, when firewalls are
	specifically, the following basic scenarios are studied individually.		encountered in a Mobile IPv6 network. More specifically, the
			following basic scenarios are studied individually.
	o Mobile Node (MN) behind a firewall;		o Mobile Node (MN) behind a firewall;
	o Correspondent Node (CN) behind a firewall;		o Correspondent Node (CN) behind a firewall;
	o Home Agent (HA) behind a firewall.		o Home Agent (HA) behind a firewall.
	For every scenario, we will discuss how to apply NSIS signaling for		For every scenario, we will discuss how to apply NSIS signaling for
	the routing modes. It has to be noted that a real scenario could		the three routing modes. It has to be noted that a real scenario
	include a combination of some set of these cases. In any case, we		could include a combination of some set of these cases. In any case,
	assume that the MN, the CN, the HA and the Firewalls (FWs) are NSIS		we assume that the MN, the CN, the HA and the Firewalls (FWs) are
	aware. Also note that for every NSIS message, the undelying GIST[5]		NSIS aware. Also note that for every NSIS message, the undelying
	level provides flow-id information which will be used to install the		GIST[5] level provides flow-id information which will be used to
	firewall policies.		install the firewall policies.
	2. Terminology		2. Terminology
	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 [3].		document are to be interpreted as described in [3].
	Furthermore, we use the same terminology as in [4], [2], and [6].		Furthermore, we use the same terminology as in [4], [2], and [6].
	Apart from this, we use some abbreviations to describe the flow-id of		Apart from this, we use some abbreviations to describe the flow-id of
	the NSIS messages: SA-Source Address, DA-Destination Address, SP-		the NSIS messages: SA-Source Address, DA-Destination Address, SP-
	skipping to change at page 7, line 47		skipping to change at page 7, line 47
	+-------------------------+ ^		+-------------------------+ ^
	*		*
	+----+		+----+
	| CN |		| CN |
	|(DS)|		|(DS)|
	***** = Data traffic +----+		***** = Data traffic +----+
	----- = Signaling traffic Correspondent node		----- = Signaling traffic Correspondent node
	Figure 3: NSIS signaling for MN behind the firewall		Figure 3: NSIS signaling for MN behind the firewall
	3.4. Change of Firewalls		3.4. Triangular routing
			After mobility the MN sends a Binding update message to register its
			new CoA. If the CN is the DS, it sends the data to MN through HA.
			If the MN is the data sender, no further signaling is needed as the
			session is initiated by the MN. The message flow is shown in
			Figure 4.
			For the CREATE message for data traffic from HA to MN, the MN
			signaling using REA for the flow-id: SA: HA, DA: CoA. Note these
			data messages for which we do signaling, are IP-in-IP tunneled
			messages.
			Network protected
			+-------------------------+
			| | Home Agent
			| +-----+ +-----+ +----+
			| | |Binding update| | | |
			| | |-------->-----+ +--------->----------+ |
			| | | | | Binding ACK | |
			| | |--------<-----+ +---------<----------+ |
			| | | REA | | | HA |
			| | +-------->-----+ | | |
			| | | RESPONSE | | | |
			| | +--------<-----+ | | |
			| | MN | | FW | Tunneled packets | |
			| |(DR) +########<#####+ +#########<##########+ |
			| | | | | +----+
			| | | | | *
			| | | | | ^
			| | | | | *
			| | | | | +----+
			| | | | | | CN |
			| +-----+ +-----+ |(DS)|
			| | +----+
			+-------------------------+ Correspondent Node
			----- = Signaling traffic
			***** = Data traffic
			##### = Tunneled data traffic
			Figure 4: NSIS signaling for MN behind the firewall
			3.5. Change of Firewalls
	If the MN roams and attaches to a different firewall, the above-		If the MN roams and attaches to a different firewall, the above-
	mentioned routing methods will have problems in traversing the new		mentioned routing methods will have problems in traversing the new
	firewall. In this case the data sender (where it is MN or the CN or		firewall. In this case the data sender (where it is MN or the CN or
	the HA) should re-signaling to the firewall using NSIS and establish		the HA) should re-signaling to the firewall using NSIS and establish
	the policies accordingly (mentioned above according to the routing		the policies accordingly (mentioned above according to the routing
	methods).		methods).
	Since the NAT/FW NSLP rely on a soft-state approach, established		Since the NAT/FW NSLP rely on a soft-state approach, established
	sessions will be automatically be teardown after a specified timeout		sessions will be automatically be teardown after a specified timeout
	value. Thus it is not necessary to delete or teardown a session		value. Thus it is not necessary to delete or teardown a session
	after an MN roams to another network, as the protocol will do this by		after an MN roams to another network, as the protocol will do this by
	it own. More discussions about a possible alternative way by tearing		it own. More discussions about a possible alternative way by tearing
	down the established state are given in [7].		down the established state are given in [7].
	3.5. Operations when MN is behind a firewall		3.6. Operations when MN is behind a firewall
	MN configure the firewall(s) using CREATE to let following traverse:		MN configure the firewall(s) using CREATE to let following traverse:
	o binding update messages (src: CoA, dst: HA) {BU}		o binding update messages (src: CoA, dst: HA) {BU}
	o HoTI messages (src: CoA, dst: HA) {RO}		o HoTI messages (src: CoA, dst: HA) {RO}
	o if uplink firewall, for data traffic from MN (src: MN, dst: *)		o if uplink firewall, for data traffic from MN (src: MN, dst: *)
	MN configures the firewall(s) using REA to let following traverse:		MN configures the firewall(s) using REA to let following traverse:
	o HoT messages (src: HA dst: CoA) {RO}		o HoT messages (src: HA dst: CoA) {RO}
	o if CN is DS		o if CN is DS
	* for data traffic from HA to MN (src: HA, dst: CoA) {BT}		* for data traffic from HA to MN (src: HA, dst: CoA) {BT}
			* for data traffic from HA to MN (src: HA, dst: CoA) {TR}
	* for data traffic from CN to MN (src: CN, dst: CoA, SP: data		* for data traffic from CN to MN (src: CN, dst: CoA, SP: data
	application port, DP: data application port) {RO}		application port, DP: data application port) {RO}
	4. Correspondent Node behind a firewall		4. Correspondent Node behind a firewall
	4.1. Route Optimization		4.1. Route Optimization
	In Figure 4, the CN is protected by a firewall that employs stateful		In Figure 5, the CN is protected by a firewall that employs stateful
	packet filtering (SPF). The external MN and its associated HA are		packet filtering (SPF). The external MN and its associated HA are
	also shown in the figure. The MN is in its home network and is		also shown in the figure. The MN is in its home network and is
	communicating with the CN. Here it is assumed that CN has initiated		communicating with the CN. Here it is assumed that CN has initiated
	the communication and hence it has no problems with the SPF.		the communication and hence it has no problems with the SPF.
	+----------------+ +----+		+----------------+ +----+
	| | | HA |		| | | HA |
	| | +----+		| | +----+
	| | Home Agent		| | Home Agent
	| +----+ +----+		| +----+ +----+
	| | CN | | FW |		| | CN | | FW |
	| +----+ +----+		| +----+ +----+
	| | +----+		| | +----+
	| | | MN |		| | | MN |
	| | +----+		| | +----+
	+----------------+ External Mobile		+----------------+ External Mobile
	Network protected Node		Network protected Node
	by a firewall		by a firewall
	Figure 4: CN behind the firewall		Figure 5: CN behind the firewall
	The MN moves out of its home network and has to perform the return		The MN moves out of its home network and has to perform the return
	routability test (RRT) before sending the binding update to the CN.		routability test (RRT) before sending the binding update to the CN.
	It sends a HoTI message through the HA to the CN and expects a HoT		It sends a HoTI message through the HA to the CN and expects a HoT
	message from the CN along the same path. It also sends a CoTI		message from the CN along the same path. It also sends a CoTI
	message directly to the CN and expects CoT message in the same path		message directly to the CN and expects CoT message in the same path
	from the CN. The SPF will only allow packets that belong to an		from the CN. The SPF will only allow packets that belong to an
	existing session and hence both the packets (HoTI, CoTI) will be		existing session and hence both the packets (HoTI, CoTI) will be
	dropped as these packets are Mobile IPv6 packets and these packets		dropped as these packets are Mobile IPv6 packets and these packets
	have different header structure. The existing rules at the firewall		have different header structure. The existing rules at the firewall
	might have been installed for some kind of data traffic.		might have been installed for some kind of data traffic.
	As the RRT can not be executed, the firewalls rules have to be		As the RRT can not be executed, the firewalls rules have to be
	modified to allow these MIPv6 messages to go through. The MN		modified to allow these MIPv6 messages to go through. The MN
	initiates the NSIS session by sending a CREATE message to the CN.		initiates the NSIS session by sending a CREATE message to the CN.
	When the MN receives both the messages CoT and HoT, it will construct		When the MN receives both the messages CoT and HoT, it will construct
	the binding key and perform binding update to the CN. Note, the		the binding key and perform binding update to the CN. Note, the
	signaling that was aforementioned was only to allow the Mobile IPv6		signaling that was aforementioned was only to allow the Mobile IPv6
	messages. The message flow for NSIS signaling (with MN as data		messages. The message flow for NSIS signaling (with MN as data
	sender) is shown in Figure 5. Note, only the message flow between MN		sender) is shown in Figure 6. Note, only the message flow between MN
	and CN is shown in the diagram.		and CN is shown in the diagram.
	For the CREATE message for MIPv6 signaling traffic from MN to CN,		For the CREATE message for MIPv6 signaling traffic from MN to CN,
	the flow-id will be: SA: CoA, DA: CN. Note: The policy rules that		the flow-id will be: SA: CoA, DA: CN. Note: The policy rules that
	are to be installed to allow the HoTI and CoTI packets are		are to be installed to allow the HoTI and CoTI packets are
	different and the NI has to perform signaling twice.		different and the NI has to perform signaling twice.
	If the CN wants to continue sending data traffic (CN is the DS) to		If the CN wants to continue sending data traffic (CN is the DS) to
	the new CoA, it can do so without any additional signaling. This is		the new CoA, it can do so without any additional signaling. This is
	because the SPF will allow the traffic initiated by the nodes that it		because the SPF will allow the traffic initiated by the nodes that it
	skipping to change at page 11, line 26		skipping to change at page 12, line 26
	|| | CoT | | | |		|| | CoT | | | |
	||(DR)+-------->-----+ +--------->----------+(DS)|		||(DR)+-------->-----+ +--------->----------+(DS)|
	|| | | | Binding update | |		|| | | | Binding update | |
	|| +--------<-----+ +---------<----------+ |		|| +--------<-----+ +---------<----------+ |
	|+----+ +-----+ +----+		|+----+ +-----+ +----+
	| | Mobile		| | Mobile
	+-----------------------+ Node		+-----------------------+ Node
	Network protected		Network protected
	by a firewall		by a firewall
	Figure 5: NSIS signaling for CN behind the firewall		Figure 6: NSIS signaling for CN behind the firewall
	4.2. Bi-directional Tunneling		4.2. Bi-directional Tunneling
	If the CN is protected by a SPF-firewall, there is no need for any		If the CN is protected by a SPF-firewall, there is no need for any
	signaling if the CN starts sending data traffic. The CN sends the		signaling if the CN starts sending data traffic. The CN sends the
	data traffic and hence the SPF will store relevant state information		data traffic and hence the SPF will store relevant state information
	and accepts packets from the reverse direction.		and accepts packets from the reverse direction.
	If MN is the DS, then the CN has to initiate the signaling using REA,		If MN is the DS, then the CN has to initiate the signaling using REA,
	in order to configure the firewall to allow the data traffic traverse		in order to configure the firewall to allow the data traffic traverse
	from the HA to CN. The message flow is shown in Figure 6.		from the HA to CN. The message flow is shown in Figure 7.
	For the CREATE message for data traffic from HA to CN, the CN		For the CREATE message for data traffic from HA to CN, the CN
	signaling using REA for the flow-id will be: SA: HA, DA: CN.		signaling using REA for the flow-id will be: SA: HA, DA: CN.
	Protected network		Protected network
	+-------------------------+		+-------------------------+
	| | Home Agent		| | Home Agent
	| +-----+ +-----+ +----+		| +-----+ +-----+ +----+
	| | | | | | |		| | | | | | |
	| | CN | REA | FW | | HA |		| | CN | REA | FW | | HA |
	skipping to change at page 12, line 26		skipping to change at page 13, line 26
	| +-----+ +-----+ +----+		| +-----+ +-----+ +----+
	| | #		| | #
	+-------------------------+ #		+-------------------------+ #
	+----+		+----+
	| MN |		| MN |
	|(DS)|		|(DS)|
	***** = Data traffic (both direction) +----+		***** = Data traffic (both direction) +----+
	----- = signaling traffic Correspondent node		----- = signaling traffic Correspondent node
	##### = tunneled traffic		##### = tunneled traffic
	Figure 6: NSIS signaling for CN behind the firewall		Figure 7: NSIS signaling for CN behind the firewall
	4.3. Change of Firewalls		4.3. Triangular routing
			This section considers the scenario shown in Figure 8 where the CN is
			protected by a FW that has SPF functionality. If the CN is the DS,
			then the data traffic will be bypassed by the firewall. But if the
			MN is the DS, the firewall will not allow the data packets from the
			MN (packets in the reverse direction) as it does not belong to any
			connection that exists already.
			Hence, the MN has to initiate signaling by sending the CREATE message
			to the CN and the FW will install the policies when it receives the a
			sucessful response. Now, the MN is allowed to communicate in the
			reverse direction.
			For the CREATE message for data traffic from MN to CN, the flow-id
			will be: SA: MN, DA: CN, SP: Data application port, DP: Data
			application port.
			+-------------------------+
			| | Home Agent
			| +-----+ +-----+ +----+
			| | | | | | HA |
			| | | | | +----+
			| | CN | | FW |
			| |(DR) | | | CREATE +----+
			| | +--------<-----+ +---------<----------+ |
			| | | RESPONSE | | | MN |
			| | +-------->-----+ +--------->----------+(DS)|
			| | | | | Data traffic | |
			| | +********<*****+ +*********<**********+ |
			| +-----+ +-----+ +----+
			| | External Mobile
			+-------------------------+ Node
			Network protected
			----- = signaling traffic
			***** = Data traffic
			Figure 8: NSIS signaling for CN behind the firewall
			4.4. Change of Firewalls
	If the MN roams and attaches to a network with a different firewall		If the MN roams and attaches to a network with a different firewall
	then the above-mentioned routing methods will have problems in		then the above-mentioned routing methods will have problems in
	traversing the new firewall. In this case the data sender (where it		traversing the new firewall. In this case the data sender (where it
	is MN or the CN or the HA) should re-signaling to the firewall using		is MN or the CN or the HA) should re-signaling to the firewall using
	NSIS and establish the policies accordingly (mentioned above		NSIS and establish the policies accordingly (mentioned above
	according to the routing methods).		according to the routing methods).
	4.4. Operations when CN is behind a firewall		4.5. Operations when CN is behind a firewall
	MN configure the firewall(s) using CREATE to let following traverse:		MN configure the firewall(s) using CREATE to let following traverse:
	o HoTI messages (src: CoA, dst: CN) {BU}		o HoTI messages (src: CoA, dst: CN) {BU}
	o CoTI messages (src: CoA, dst: CN) {BU}		o CoTI messages (src: CoA, dst: CN) {BU}
	o if MN is DS		o if MN is DS
	* for data traffic from MN to CN (src: CoA, dst: CN) {RO}		* for data traffic from MN to CN (src: CoA, dst: CN) {RO}
			* for data traffic from MN to CN (src: CoA, dst: CN, SP: data
			application port, DP: data application port) {TR}
	CN configure the firewall(s) to let following traverse:		CN configure the firewall(s) to let following traverse:
	o HoTI messages (src: HA, dst: CN) {BU}		o HoTI messages (src: HA, dst: CN) {BU}
	o if MN is DS for data traffic from HA to CN (src: HA, dst: CN) {BT}		o if MN is DS for data traffic from HA to CN (src: HA, dst: CN) {BT}
	o if uplink firewall, for data traffic from CN (src: CN, dst: MN)		o if uplink firewall, for data traffic from CN (src: CN, dst: MN)
	5. Home Agent behind a firewall		5. Home Agent behind a firewall
	5.1. Route Optimization		5.1. Route Optimization
	The MN, after entering a new network, sends a Binding Update to the		The MN, after entering a new network, sends a Binding Update to the
	HA. But as it is initiated by the MN, it first has to install some		HA. But as it is initiated by the MN, it first has to install some
	skipping to change at page 14, line 44		skipping to change at page 16, line 44
	then send the HoTI to CN and obviously this message is allowed as it		then send the HoTI to CN and obviously this message is allowed as it
	is initiated by the HA. The HoT message from the CN to the HA is		is initiated by the HA. The HoT message from the CN to the HA is
	also allowed by the SPF as it belongs to the session previously		also allowed by the SPF as it belongs to the session previously
	initiated by the HA. The HoT message from the HA to the MN is also		initiated by the HA. The HoT message from the HA to the MN is also
	allowed as it is initiated by the HA. The RRT completes		allowed as it is initiated by the HA. The RRT completes
	successfully.		successfully.
	For the CREATE message for the from the MIPv6 signaling traffic MN		For the CREATE message for the from the MIPv6 signaling traffic MN
	to the HA, the flow-id will be: SA: MN, DA: HA.		to the HA, the flow-id will be: SA: MN, DA: HA.
	Detailed message flow (with MN as data sender) is shown in Figure 7.		Detailed message flow (with MN as data sender) is shown in Figure 9.
	Note, only the interaction between the HA and the MN is shown in the		Note, only the interaction between the HA and the MN is shown in the
	figure.		figure.
	+------------------------+ +----+		+------------------------+ +----+
	| | | CN |		| | | CN |
	| | |(DR)|		| | |(DR)|
	| | +----+		| | +----+
	| |		| |
	| +----+ +-----+ +------------------+		| +----+ +-----+ +------------------+
	| | | | | CREATE | +----+ |		| | | | | CREATE | +----+ |
	skipping to change at page 15, line 34		skipping to change at page 17, line 34
	| | | | | HoTI | | | |		| | | | | HoTI | | | |
	| | +--------<-----+ +---------<------|---<---+ | |		| | +--------<-----+ +---------<------|---<---+ | |
	| | | | | HoT | | | |		| | | | | HoT | | | |
	| | +-------->-----+ +--------->------|--->---+ | |		| | +-------->-----+ +--------->------|--->---+ | |
	| +----+ +-----+ | +----+ |		| +----+ +-----+ | +----+ |
	| | | |		| | | |
	+------------------------+ +------------------+		+------------------------+ +------------------+
	HA protected by firewall Visited Network		HA protected by firewall Visited Network
	(Home Network)		(Home Network)
	Figure 7: NSIS signaling for HA behind the firewall		Figure 9: NSIS signaling for HA behind the firewall
	For the data traffic, there is no additional signaling as the MN		For the data traffic, there is no additional signaling as the MN
	sends data directly to CN and none of these networks (CN network and		sends data directly to CN and none of these networks (CN network and
	MN network) are protected by firewalls. This is applicable for both,		MN network) are protected by firewalls. This is applicable for both,
	MN and CN, as data senders.		MN and CN, as data senders.
	5.2. Bi-directional tunneling		5.2. Bi-directional tunneling
	Here, it is necessary that the HA open pinholes for the data traffic		Here, it is necessary that the HA open pinholes for the data traffic
	from the CN using REA. The CN is then allowed to send the data		from the CN using REA. The CN is then allowed to send the data
	traffic through the FW. After intercepting the packets, the HA		traffic through the FW. After intercepting the packets, the HA
	tunnels the packet to the MN. Figure 8 shows the message flow.		tunnels the packet to the MN. Figure 10 shows the message flow.
	For the CREATE message for data traffic from CN to HA, the flow-id		For the CREATE message for data traffic from CN to HA, the flow-id
	initiated by the HA using REA will be: SA: CN, DA: HoA, SP: Data		initiated by the HA using REA will be: SA: CN, DA: HoA, SP: Data
	application port, DP: Data application port.		application port, DP: Data application port.
	HA Network protected		HA Network protected
	+-------------------------+		+-------------------------+
	| |		| |
	| +-----+ +-----+ +----+		| +-----+ +-----+ +----+
	| | | REA | | | |		| | | REA | | | |
	skipping to change at page 16, line 28		skipping to change at page 18, line 28
	| | +########>#####+ +#########>##########+ MN |		| | +########>#####+ +#########>##########+ MN |
	| | | | | |(DR)|		| | | | | |(DR)|
	| +-----+ +-----+ +----+		| +-----+ +-----+ +----+
	| |		| |
	+-------------------------+		+-------------------------+
	----- = Signaling traffic		----- = Signaling traffic
	***** = Data traffic		***** = Data traffic
	##### = Tunneled data packet		##### = Tunneled data packet
	Figure 8: NSIS signaling for HA behind the firewall		Figure 10: NSIS signaling for HA behind the firewall
	5.3. Operations when HA is behind a firewall		5.3. Triangular routing
			The HA initiates NSIS signaling to open pinholes in the FW for the
			traffic from CN using REA. Then the CN can send the data traffic to
			HoA. The message flow is the same as shown in Figure 10.
			For the CREATE message for data traffic from CN to HA, the flow-id
			initiated by the HA using REA will be: SA: CN, DA: HoA, SP: Data
			application port, DP: Data application port.
			5.4. Operations when HA is behind a firewall
	MN configure the firewall(s) using CREATE to let following traverse:		MN configure the firewall(s) using CREATE to let following traverse:
	o binding update messages (src: CoA, dst: HA, SPIx) {BU}		o binding update messages (src: CoA, dst: HA, SPIx) {BU}
	o HoTI messages (src: CoA, dst: HA) {RO}		o HoTI messages (src: CoA, dst: HA) {RO}
	HA configure the firewall(s) using REA to let following traverse:		HA configure the firewall(s) using REA to let following traverse:
	o for data traffic from CN to HA (src: CN, dst: HA, SP: data		o for data traffic from CN to HA (src: CN, dst: HA, SP: data
	application port, DP: data application port) {BT}		application port, DP: data application port) {BT}
			o for data traffic from CN to HA (src: CN, dst: HoA, SP: data
			application port, DP: data application port) {TR}
	6. Additional Discussions		6. Additional Discussions
	To support the operations described in this draft, it would be		To support the operations described in this draft, it would be
	desireable if the NSIS NAT/FW NSLP has the ability to discover the		desireable if the NSIS NAT/FW NSLP has the ability to discover the
	presence and the characteristics (e.g., uplink or downlink filter) of		presence and the characteristics (e.g., uplink or downlink filter) of
	firewalls. This will be useful in several cases. For instance, it		firewalls. This will be useful in several cases. For instance, it
	would be desireable if one could detect whether a firewall exists, if		would be desireable if one could detect whether a firewall exists, if
	no, then NAT/FW NSLP will be unnecessary. Moreover, it is necessary		no, then NAT/FW NSLP will be unnecessary. Moreover, it is necessary
	to determine where (i.e., in which MIPv6 segment/scenario) is the		to determine where (i.e., in which MIPv6 segment/scenario) is the
	skipping to change at page 18, line 5		skipping to change at page 20, line 38
	roaming into a new network and provides the required information		roaming into a new network and provides the required information
	(CoA, HoA, ...). This notification triggeres the required operation.		(CoA, HoA, ...). This notification triggeres the required operation.
	The protocol uses a firewall detection approach to determine the		The protocol uses a firewall detection approach to determine the
	current scenario and performs the pinhole creation process necessary		current scenario and performs the pinhole creation process necessary
	for this case. After creation of the pinholes, MIP6 signaling is		for this case. After creation of the pinholes, MIP6 signaling is
	enabled to traverse possible firewalls.		enabled to traverse possible firewalls.
	The operation overview will be explained in more detail in future		The operation overview will be explained in more detail in future
	versions of this draft.		versions of this draft.
			This draft also handles the Triangle Routing case. Further
			discussion will cover wheter it is needed to consider triangle
			routing at all.
	7. Security Considerations		7. Security Considerations
	The NAT/FW NSLP is in itself a very security sensitive service. A		The NAT/FW NSLP is in itself a very security sensitive service. A
	detailed description of possible threats and countermeasures are		detailed description of possible threats and countermeasures are
	described in [2].		described in [2].
	More details to authorization and authentication will be provided in		More details to authorization and authentication will be provided in
	the next version of this draft.		the next version of this draft.
	8. Acknowledgements		8. Acknowledgements
	skipping to change at page 20, line 13		skipping to change at page 23, line 13
	for their feedback.		for their feedback.