draft-thiruvengadam-nsis-mip6-fw-03.txt		draft-thiruvengadam-nsis-mip6-fw-04.txt
	NSIS S. Thiruvengadam		NSIS S. Thiruvengadam
	Internet-Draft H. Tschofenig		Internet-Draft H. Tschofenig
	Expires: April 27, 2006 Siemens		Expires: December 28, 2006 Siemens
	F. Le		F. Le
	CMU		CMU
	October 24, 2005		N. Steinleitner
			X. Fu
			Univ. Goettingen
			June 26, 2006
	Mobile IPv6 - NSIS Interaction for Firewall traversal		Mobile IPv6 - NSIS Interaction for Firewall traversal
	draft-thiruvengadam-nsis-mip6-fw-03.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 36		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 27, 2006.		This Internet-Draft will expire on December 28, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		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 are allowed to pass through these firewalls. A signaling		messages can pass through these firewalls. One approach is to use a
	protocol is needed which can communicate with these firewalls and		signaling protocol to communicate with these firewalls and instruct
	instruct them to bypass these Mobile IPv6 messages. The goal of this		them to bypass these Mobile IPv6 messages. The goal of this document
	document is to describe the interaction between NSIS and Mobile IPv6		is to describe the interaction between NSIS and Mobile IPv6 for
	for successful deployment of Mobile IPv6.		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 . . . . . . . . . . . . . . . . . 6		3.3. Bi-directional tunneling . . . . . . . . . . . . . . . . . 7
	3.4. Triangular routing . . . . . . . . . . . . . . . . . . . . 8		3.4. Triangular routing . . . . . . . . . . . . . . . . . . . . 7
	3.5. Change of Firewalls . . . . . . . . . . . . . . . . . . . 9		3.5. Change of Firewalls . . . . . . . . . . . . . . . . . . . 8
			3.6. Operations when MN is behind a firewall . . . . . . . . . 9
	4. Correspondent Node behind a firewall . . . . . . . . . . . . . 10		4. Correspondent Node behind a firewall . . . . . . . . . . . . . 10
	4.1. Route Optimization . . . . . . . . . . . . . . . . . . . . 10		4.1. Route Optimization . . . . . . . . . . . . . . . . . . . . 10
	4.2. Bi-directional Tunneling . . . . . . . . . . . . . . . . . 12		4.2. Bi-directional Tunneling . . . . . . . . . . . . . . . . . 12
	4.3. Triangular routing . . . . . . . . . . . . . . . . . . . . 13		4.3. Triangular routing . . . . . . . . . . . . . . . . . . . . 13
	4.4. Change of Firewalls . . . . . . . . . . . . . . . . . . . 14		4.4. Change of Firewalls . . . . . . . . . . . . . . . . . . . 14
	5. Home Agent behind a firewall . . . . . . . . . . . . . . . . . 15		4.5. Operations when CN is behind a firewall . . . . . . . . . 14
	5.1. Route Optimization . . . . . . . . . . . . . . . . . . . . 15		5. Home Agent behind a firewall . . . . . . . . . . . . . . . . . 16
	5.2. Bi-directional tunneling . . . . . . . . . . . . . . . . . 16		5.1. Route Optimization . . . . . . . . . . . . . . . . . . . . 16
	5.3. Triangular routing . . . . . . . . . . . . . . . . . . . . 17		5.2. Bi-directional tunneling . . . . . . . . . . . . . . . . . 17
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 19		5.3. Triangular routing . . . . . . . . . . . . . . . . . . . . 18
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20		5.4. Operations when HA is behind a firewall . . . . . . . . . 18
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21		6. Additional Discussions . . . . . . . . . . . . . . . . . . . . 20
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 21		7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
	8.2. Informative References . . . . . . . . . . . . . . . . . . 21		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
	Intellectual Property and Copyright Statements . . . . . . . . . . 23		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. This problem is well described in [1]. The other		packet filtering (SPF). This problem is well described in [1]. The
	modes of communication in Mobile IPv6 namely bi-directional tunneling		other modes of communication in Mobile IPv6, namely bi-directional
	and triangular routing also do not work under some firewall		tunneling and triangular routing, also do not work under some
	placements. Apart from this, the Mobile IPv6 binding updates (ESP)		firewall placements. Apart from this, the Mobile IPv6 binding
	packets also have problems with Firewall traversal. There is a need		updates (encapsulated using IPsec ESP) packets also have problems
	for identifying a signaling protocol that can install some firewall		with firewall traversal. To tackle these issues, one approach is to
	rules to allow these Mobile IPv6 messages to pass through. The NSIS		utilize a signaling protocol to install some firewall rules for
	NAT/FW NSLP, as described in [2], allows to establish, maintain and		allowing these Mobile IPv6 messages to pass through. The NSIS NAT/FW
	delete middlebox state (i.e., NAT bindings and Firewall rules) to		NSLP, as described in [2], allows to establish, maintain and delete
	allow packets to traverse these boxes. We identify NSIS as possible		middlebox state (i.e., NAT bindings and Firewall rules), and allow
	solution to the aforementioned problem and describe the solution in		packets to traverse these boxes. This protocol thus provides a
	detail. For every scenario mode, we will consider the application of		possible way to address the aforementioned problem. This document
	NSIS signaling for the three routing modes. We also study other		describe the considerations of NSIS NAT/FW NSLP, especially the
	problematic aspects in these scenarios:		involved messages and necessary firewall rules, when firewalls are
			encountered in a Mobile IPv6 network. More specifically, the
			following basic scenarios are studied individually.
	o Correspondent Node (CN) behind a firewall		o Mobile Node (MN) behind a firewall;
	o Mobile Node (MN) behind a firewall		o Correspondent Node (CN) behind a firewall;
	o Home Agent (HA) behind a firewall		o Home Agent (HA) behind a firewall.
	It is to be noted that a real scenario could include a combination of		For every scenario, we will discuss how to apply NSIS signaling for
	these cases. In all the scenarios, we assume that the Correspondent		the three routing modes. It has to be noted that a real scenario
	Node(CN), Mobile Node(MN) and the Firewalls(FW) are NSIS aware. For		could include a combination of some set of these cases. In any case,
	every NSIS message, we have also provided the NTLP flow-id which will		we assume that the MN, the CN, the HA and the Firewalls (FWs) are
	be used to install the firewall policies.		NSIS aware. Also note that for every NSIS message, the undelying
			GIST[5] level provides flow-id information which will be used to
			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 [5].		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-
	Source Port, DP-Destination Port and an asterisk is used as wild-		Source Port, DP-Destination Port and an asterisk is used as wild-
	card.		card.
	Signaling-D is used as an abbreviation for signaling packet filters
	to allow data traffic to traverse a firewall.
	Signaling-C is used as an abbreviation for signaling packet filters
	to allow MIPv6 signaling messages to traverse a firewall.
	The term 'DS' refers to data sender and the term 'DR' to data		The term 'DS' refers to data sender and the term 'DR' to data
	receiver.		receiver.
	3. Mobile Node behind a firewall		3. Mobile node behind a firewall
			In Figure 1, the MN is protected by a firewall that employs stateful
			packet filtering (SPF). The external CN and the HA are also shown in
			the figure. The MN is in a foreign network and is communicating with
			the CN. Here it is assumed that MN has initiated the communication
			and hence it has no problems with the SPF.
			+----------------+ +----+
			| | | HA |
			| | +----+
			| | Home Agent
			| +----+ +----+
			| | MN | | FW |
			| +----+ +----+
			| | +----+
			| | | CN |
			| | +----+
			+----------------+ External CN
			Network protected
			by a firewall
			Figure 1: MN behind the firewall
	3.1. Binding updates		3.1. Binding updates
	IPsec protected Binding Updates cause problems in some deployment		IPsec protected Binding Updates cause problems in some deployment
	environments, as described in [1]. An interim solution might in some		environments, as described in [1]. As a solution, NAT/FW NSLP can be
	environments the configuration of a firewall to allow the IPsec		used to dynamically configure the firewall(s) to allow the IPsec
	packets and associated traffic like IKE/IKEv2 packets to traverse.		packets and associated traffic like IKE/IKEv2 packets to traverse,
	For both inbound and outbound filters, in order to allow IPsec ESP,		before sending the binding updates. Therefore, IP Protocol ID 50
	IP Protocol ID 50 should be allowed in the filter policies.		should be allowed in the filter policies in order to allow IPsec ESP
	Similarly, to allow IPsec AH, IP Protocol ID 51 should be allowed.		and IP Protocol ID 51 to allow IPsec AH. The firewall should also
	The firewall should also allow IKE packets (to UDP port 500) to		allow IKE packets (to UDP port 500) to bypass.
	bypass. These packet filters can be configured manually or
	dynamically using NSIS before sending the binding updates.		For the BU message from MN to HA, the MN installs rules using
			CREATE for the flow-id: SA: COA, DA: HA.
	3.2. Route optimization		3.2. Route optimization
	In Figure 1, the message flow for MN behind firewall scenario is		In Figure 2, the message flow for MN behind firewall scenario is
	shown (with CN as data sender). Here, all the messages initiated by		shown (with CN as data sender). Here, all the messages initiated by
	the MN will be bypassed. Immediately after moving to a new network,		the MN will be bypassed. Immediately after moving to a new network,
	the MN acquires a new CoA and it performs the Binding Update to the		the MN acquires a new CoA and it performs the Binding Update to the
	HA. The HoT message received by the MN is actually a tunneled		HA. The HoT message received by the MN is actually a tunneled
	message and as it does not belong to the session initiated by the MN,		message and as it does not belong to the session initiated by the MN,
	it will be dropped by the FW. Hence, either the HA could initiate		it will be dropped by the FW. Using REA, the MN initiate NSIS
	NSIS signaling to the MN and open pin-holes (only for NSIS aware HA)		signaling to the FW and open pinholes for the HoT message.
	or the MN can open pin-holes for these messages to traverse (for NSIS
	unaware HA). The latter solution raises additional concerns about
	routing asymmetry.
	For the Signaling-C CREATE message from HA to MN, the flow-id will		For the HoT message from HA to MN, the MN signaling using REA for
	be: SA: HA, DA: CoA		the flow-id: SA: HA, DA: CoA.
	Once the RRT is successful, the binding update message is sent to the		Once the RRT is successful, the binding update message is sent to the
	CN. If the MN wants to continue sending data traffic, then no NSIS		CN. If the MN wants to continue sending data traffic, then no NSIS
	signaling is needed at all for this scenario. However, if the CN		signaling is needed at all for this scenario. However, if the CN
	wants to send data traffic, the relevant packet filter rules have to		wants to send data traffic, the relevant packet filter rules have to
	be installed at the firewall. Hence, the CN has to initiate		be installed at the firewall. Hence, the CN has to initiate sending
	Signaling-D to the MN but this happens after the RRT. The MN has to		datta traffic to the MN but this happens after the RRT. The MN has
	perform a Binding Update to the CN, conveying its new CoA. Then, if		to perform a Binding Update to the CN, conveying its new CoA.
	the CN wants to start the data transfer, it will send an NSLP message		Therefore, the MN open pinholes using REA to let the data traffic
	directly to the MN. The HA is not involved in this process (for this		traverse the firewalls.
	scenario). In scenarios where the network is protected by a single
	firewall, the MN can open pin-holes. It should be noted that the HA
	signals on behalf of the CN because the CN may not know that the MN
	is behind a firewall.
	For the Signaling-D CREATE message from CN to MN, the flow-id will		For the CREATE message for data traffic from CN to MN, the MN
	be: SA: CN, DA: CoA, SP: data application port, DP: data application		signaling using REA for the flow-id: SA: CN, DA: CoA, SP: data
	port.		application port, DP: data application port.
	Network protected		Network protected
	+-------------------------+		+-------------------------+
	| |		| |
	| +-----+ +-----+ +----+		| +-----+ +-----+ +----+
	| | | | | | |
	| | |Binding Update| | | |		| | |Binding Update| | | |
	| | |-------->-----+ +--------->----------+ |		| | |-------->-----+ +--------->----------+ |
	| | | | | Binding ACK | |		| | | | | Binding ACK | |
	| | |--------<-----+ +---------<----------+ |		| | |--------<-----+ +---------<----------+ |
	| | | | | | |		| | MN | REA | FW | | HA |
	| | MN | | FW | CREATE-C | HA |		| | +-------->-----+ | | |
	| | +--------<-----+ +---------<----------+ |		| |(DS) | RESPONSE | | | |
	| |(DS) | SUCCEED | | | |		| | +--------<-----+ | | |
	| | +-------->-----+ +--------->----------+ |
	| | | | | HoTI | |		| | | | | HoTI | |
	| | +-------->-----+ +--------->----------+ |		| | +-------->-----+ +--------->----------+ |
	| | | HoT | | | |		| | | HoT | | | |
	| | +--------<-----+ +---------<----------+ |		| | +--------<-----+ +---------<----------+ |
	| | | | | | |
	| +-----+ +-----+ +----+		| +-----+ +-----+ +----+
	| | |
	| | ^		| | ^
	+-------------------------+ v		+-------------------------+ |
	|		v
	+----+		+----+
	| CN |		| CN |
	| |
	|(DR)|		|(DR)|
	+----+		+----+
	----- = signaling traffic Correspondent		----- = signaling traffic Correspondent node
	node
	Figure 1: NSIS signaling for MN behind the firewall		Figure 2: NSIS signaling for MN behind the firewall
	3.3. Bi-directional tunneling		3.3. Bi-directional tunneling
	Consider the scenario where the MN is protected by a SPF. The CN is		Consider the scenario where the MN is protected by a SPF. Even
	generally unaware that the MN is behind the firewall. This might		though the MN had earlier initiated a connection for the purpose of
	happen because, as the MN roams it might find itself protected by a		binding update, new filter rules have to be installed to allow the
	firewall in some networks and the CN is not aware of this situation.		tunneled data traffic. The message flow is shown in Figure 3.
	For this scenario, the HA is forced to do the NSIS signaling. This
	is unavoidable because the outer header (in the encapsulated packet)
	will have HA as the source address and the CoA as the destination
	address. The CN does not know the CoA of the MN and hence it has not
	chance of opening the pin-hole. Ultimately, the responsibility falls
	on the HA. If CN is the DS, then we would require an NSIS aware HA.
	Even though the MN had earlier initiated a connection for the purpose
	of binding update, new filter rules have to be installed to allow the
	tunneled data traffic. The message flow is shown in Figure 2. As
	explained earlier, it could be done either by NSIS aware HA or by the
	MN itself. The latter solution might require some topology
	assumptions. Ideally, when the HA receives data from the CN
	(destined to MN) for the first time, it should initiated the
	Signaling-D to the MN. If the MN is the DS, no signaling is needed
	at all.
	For the Signaling-D CREATE message from HA to MN, the flow-id will		If the MN is the DS, no signaling is needed at all. Otherwise, the
	be: SA: HA, DA: MN. Note these data messages for which we do		MN open pinholes to let the data messages traverse, with the help of
	signaling, are IP-in-IP tunneled messages.		REA.
			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
	Protected network		Protected network
	+-------------------------+ External Mobil		+-------------------------+
	| | Node		| | Home Agent
	| +-----+ +-----+ +----+		| +-----+ +-----+ +----+
	| | | | | | |
	| | |Binding update| | | |		| | |Binding update| | | |
	| | |-------->-----+ +--------->----------+ |		| | |-------->-----+ +--------->----------+ |
	| | | | | Binding ACK | |		| | | | | Binding ACK | |
	| | |--------<-----+ +---------<----------+ |		| | |--------<-----+ +---------<----------+ |
	| | | | | | |		| | MN | REA | FW | | HA |
	| | MN | | FW | CREATE-D | HA |		| |(DR) +--------<-----+ | | |
	| |(DR) +--------<-----+ +---------<----------+ |		| | | RESPONSE | | | |
	| | | SUCCEED | | | |		| | +-------->-----+ | | |
	| | +-------->-----+ +--------->----------+ |
	| | | | | | |
	| | | | | Data traffic | |		| | | | | Data traffic | |
	| | +*******<******+ +*********<**********+ |		| | +*******<******+ +*********<**********+ |
	| | | | | | |
	| +-----+ +-----+ +----+		| +-----+ +-----+ +----+
	| | *		| | *
	+-------------------------+ ^		+-------------------------+ ^
	*		*
	+----+		+----+
	| CN |		| CN |
	|(DS)|		|(DS)|
	***** = Data traffic +----+		***** = Data traffic +----+
	----- = Signaling traffic Correspondent node		----- = Signaling traffic Correspondent node
	Figure 2: NSIS signaling for MN behind the firewall
	3.4. Triangular routing		Figure 3: NSIS signaling for MN behind the firewall
	This is a special case where the HA should be NSIS aware and should		3.4. Triangular routing
	have NSIS Initiator (NI) capabilities. 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. It is HA's responsibility to
	discover that the MN is behind a SPF and to initiate signaling to the
	MN. The HA to MN signaling is completely transparent to the CN. The
	CN is not aware of the fact that the MN is behind a firewall. The MN
	could also install the firewall rules in single firewall scenarios.
	For the Signaling-D CREATE message from HA to MN, the flow-id will		After mobility the MN sends a Binding update message to register its
	be: SA: HA, DA: MN. Note these data messages for which we do		new CoA. If the CN is the DS, it sends the data to MN through HA.
	signaling, are IP-in-IP tunneled messages.
	If the MN is the data sender, no further signaling is needed as the		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		session is initiated by the MN. The message flow is shown in
	Figure 3.		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		Network protected
	+-------------------------+		+-------------------------+
	| | Home Agent		| | Home Agent
	| +-----+ +-----+ +----+		| +-----+ +-----+ +----+
	| | |Binding update| | | |		| | |Binding update| | | |
	| | |-------->-----+ +--------->----------+ |		| | |-------->-----+ +--------->----------+ |
	| | | | | Binding ACK | |		| | | | | Binding ACK | |
	| | |--------<-----+ +---------<----------+ |		| | |--------<-----+ +---------<----------+ |
	| | | | | CREATE-D | HA |		| | | REA | | | HA |
	| | +--------<-----+ +---------<----------+ |		| | +-------->-----+ | | |
	| | | SUCCEED | | | |		| | | RESPONSE | | | |
	| | +-------->-----+ +--------->----------+ |		| | +--------<-----+ | | |
	| | MN | | FW | Tunneled packets | |		| | MN | | FW | Tunneled packets | |
	| |(DR) +########<#####+ +#########<##########+ |		| |(DR) +########<#####+ +#########<##########+ |
	| | | | | | |
	| | | | | +----+		| | | | | +----+
	| | | | | *		| | | | | *
	| | | | | ^		| | | | | ^
	| | | | | *		| | | | | *
	| | | | | +----+		| | | | | +----+
	| | | | | | CN |		| | | | | | CN |
	| +-----+ +-----+ |(DS)|		| +-----+ +-----+ |(DS)|
	| | +----+		| | +----+
	+-------------------------+ Correspondent Node		+-------------------------+ Correspondent Node
	----- = Signaling traffic		----- = Signaling traffic
	***** = Data traffic		***** = Data traffic
	##### = Tunneled data traffic		##### = Tunneled data traffic
	Figure 3: NSIS signaling for MN behind the firewall		Figure 4: NSIS signaling for MN behind the firewall
	3.5. Change of Firewalls		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
			sessions will be automatically be teardown after a specified timeout
			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
			it own. More discussions about a possible alternative way by tearing
			down the established state are given in [7].
			3.6. Operations when MN is behind a firewall
			MN configure the firewall(s) using CREATE to let following traverse:
			o binding update messages (src: CoA, dst: HA) {BU}
			o HoTI messages (src: CoA, dst: HA) {RO}
			o if uplink firewall, for data traffic from MN (src: MN, dst: *)
			MN configures the firewall(s) using REA to let following traverse:
			o HoT messages (src: HA dst: CoA) {RO}
			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) {TR}
			* for data traffic from CN to MN (src: CN, dst: CoA, SP: data
			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.
	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.
	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 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
	existing session and hence both the packets (HoTI, CoTI) will be
	dropped as these packets are Mobile IPv6 packets and these packets
	have different header structure. The existing rules at the firewall
	might have been installed for some kind of data traffic.
	+----------------+ +----+		+----------------+ +----+
	| | | HA |		| | | HA |
	| | +----+		| | +----+
	| | Home Agent		| | Home Agent
	| +----+ +----+ of MN		| +----+ +----+
	| | 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 in RRT		Figure 5: CN behind the firewall
			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.
			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 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
			existing session and hence both the packets (HoTI, CoTI) will be
			dropped as these packets are Mobile IPv6 packets and these packets
			have different header structure. The existing rules at the firewall
			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.
	The FW may not necessarily know the MN and it may not be able to		When the MN receives both the messages CoT and HoT, it will construct
	authenticate the MN. Hence it stores some relevant state regarding		the binding key and perform binding update to the CN. Note, the
	this 'firewall policy installation' request and waits for the CN's		signaling that was aforementioned was only to allow the Mobile IPv6
	authorization. Once the CN approves the request, the FW will install		messages. The message flow for NSIS signaling (with MN as data
	the relevant policy requested by the MN. When the MN receives both		sender) is shown in Figure 6. Note, only the message flow between MN
	the messages CoT and HoT, it will construct the binding key and		and CN is shown in the diagram.
	perform binding update to the CN. Note, the signaling that was
	aforementioned was only to allow the Mobile IPv6 messages. The
	message flow for NSIS signaling (with MN as data sender) is shown in
	Figure 5. Note, only the message flow between MN and CN is shown in
	the diagram.
	For the Signaling-C CREATE message from MN to CN, the flow-id will		For the CREATE message for MIPv6 signaling traffic from MN to CN,
	be: SA: CoA, DA: CN. It is to be noted that policy rules that are to		the flow-id will be: SA: CoA, DA: CN. Note: The policy rules that
	be installed to allow the HoTI and CoTI packets are different and the		are to be installed to allow the HoTI and CoTI packets are
	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
	protects. But if the MN wants to continue sending data traffic (MN		protects. But if the MN wants to continue sending data traffic (MN
	is the DS), it has to perform Signaling-D to install filter rules for		is the DS), it has to install filter rules for data traffic. The
	data traffic. The prospect of combined Signaling (for control and		prospect of combined signaling (for control and data traffic) could
	data traffic) could be useful, but currently the NSIS NAT/FW protocol		be useful, but currently the NSIS NAT/FW protocol does not support
	does not support installing multiple rules at the same time.		installing multiple rules at the same time.
	For the Signaling-D CREATE message from MN to CN, the flow-id will		For the CREATE message for data traffic from MN to CN, the flow-id
	be: SA: CoA, DA: CN		will be: SA: CoA, DA: CN.
	This solution works with the assumption that the firewalls will allow		This solution works with the assumption that the firewalls will allow
	NSIS messages from external network to bypass with delayed packet		NSIS messages from external network to bypass with delayed packet
	filter state establishment and authorization from the CN. However,		filter state establishment and authorization from the CN. However,
	operators might be reluctant to allow NSIS message from external		operators might be reluctant to allow NSIS message from external
	network as this might lead to DoS attacks. The CR might therefore be		network as this might lead to DoS attacks. The CN might therefore be
	required to authorize the traversal of NSIS signaling message		required to authorize the traversal of NSIS signaling message
	implicitly to reduce unwanted traffic.		implicitly to reduce unwanted traffic.
	To avoid this, it is also possible to ask the CN to open pi