draft-thiruvengadam-nsis-mip6-fw-02.txt		draft-thiruvengadam-nsis-mip6-fw-03.txt
	NSIS S. Thiruvengadam		NSIS S. Thiruvengadam
	Internet-Draft H. Tschofenig		Internet-Draft H. Tschofenig
	Expires: October 30, 2005 Siemens		Expires: April 27, 2006 Siemens
	F. Le		F. Le
	Nokia		CMU
	April 28, 2005		October 24, 2005
	Mobile IPv6 - NSIS Interaction for Firewall traversal		Mobile IPv6 - NSIS Interaction for Firewall traversal
	draft-thiruvengadam-nsis-mip6-fw-02.txt		draft-thiruvengadam-nsis-mip6-fw-03.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is subject to all provisions		By submitting this Internet-Draft, each author represents that any
	of Section 3 of RFC 3667. By submitting this Internet-Draft, each		applicable patent or other IPR claims of which he or she is aware
	author represents that any applicable patent or other IPR claims of		have been or will be disclosed, and any of which he or she becomes
	which he or she is aware have been or will be disclosed, and any of		aware will be disclosed, in accordance with Section 6 of BCP 79.
	which he or she become aware will be disclosed, in accordance with
	RFC 3668.
	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 months		Internet-Drafts are draft documents valid for a maximum of six 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 October 30, 2005.		This Internet-Draft will expire on April 27, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2005).
	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 are allowed to pass through these firewalls. A signaling
	skipping to change at page 2, line 11		skipping to change at page 2, line 9
	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 are allowed to pass through these firewalls. A signaling
	protocol is needed which can communicate with these firewalls and		protocol is needed which can communicate with these firewalls and
	instruct them to bypass these Mobile IPv6 messages. The goal of this		instruct them to bypass these Mobile IPv6 messages. The goal of this
	document is to describe the interaction between NSIS and Mobile IPv6		document is to describe the interaction between NSIS and Mobile IPv6
	for successful deployment of Mobile IPv6.		for successful deployment of Mobile IPv6.
	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. Route Optimization . . . . . . . . . . . . . . . . . . . . . . 5		3.1. Binding updates . . . . . . . . . . . . . . . . . . . . . 5
	3.1 Correspondant Node behind a firewall . . . . . . . . . . . 5		3.2. Route optimization . . . . . . . . . . . . . . . . . . . . 5
	3.2 Mobile Node behind a firewall . . . . . . . . . . . . . . 7		3.3. Bi-directional tunneling . . . . . . . . . . . . . . . . . 6
	3.3 Home Agent behind a firewall . . . . . . . . . . . . . . . 9		3.4. Triangular routing . . . . . . . . . . . . . . . . . . . . 8
			3.5. Change of Firewalls . . . . . . . . . . . . . . . . . . . 9
	4. Bi-directional tunneling . . . . . . . . . . . . . . . . . . . 12		4. Correspondent Node behind a firewall . . . . . . . . . . . . . 10
	4.1 Correspondant Node behind firewall . . . . . . . . . . . . 12		4.1. Route Optimization . . . . . . . . . . . . . . . . . . . . 10
	4.2 Mobile Node behind firewall . . . . . . . . . . . . . . . 13		4.2. Bi-directional Tunneling . . . . . . . . . . . . . . . . . 12
	4.3 Home Agent behind firewall . . . . . . . . . . . . . . . . 14		4.3. Triangular routing . . . . . . . . . . . . . . . . . . . . 13
			4.4. Change of Firewalls . . . . . . . . . . . . . . . . . . . 14
	5. Triangular routing . . . . . . . . . . . . . . . . . . . . . . 16		5. Home Agent behind a firewall . . . . . . . . . . . . . . . . . 15
	5.1 Correspondant Node behind Firewall . . . . . . . . . . . . 16		5.1. Route Optimization . . . . . . . . . . . . . . . . . . . . 15
	5.2 Mobile Node behind Firewall . . . . . . . . . . . . . . . 17		5.2. Bi-directional tunneling . . . . . . . . . . . . . . . . . 16
	5.3 Home Agent behind Firewall . . . . . . . . . . . . . . . . 18		5.3. Triangular routing . . . . . . . . . . . . . . . . . . . . 17
			6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 20		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
			8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21		8.1. Normative References . . . . . . . . . . . . . . . . . . . 21
			8.2. Informative References . . . . . . . . . . . . . . . . . . 21
	8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 22		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
			Intellectual Property and Copyright Statements . . . . . . . . . . 23
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
	9.1 Normative References . . . . . . . . . . . . . . . . . . . 23
	9.2 Informative References . . . . . . . . . . . . . . . . . . 23
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23
	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 [5]. The other		packet filtering. This problem is well described in [1]. The other
	modes of communication in Mobile IPv6 nameley bi-directional		modes of communication in Mobile IPv6 namely bi-directional tunneling
	tunneling and triangular routing also do not work under some firewall		and triangular routing also do not work under some firewall
	placements. There is a need for identifying a signaling protocol		placements. Apart from this, the Mobile IPv6 binding updates (ESP)
	that can install some firewall rules to allow these Mobile IPv6		packets also have problems with Firewall traversal. There is a need
	messages to pass through. The NSIS NAT/FW NSLP described in [2],		for identifying a signaling protocol that can install some firewall
	allows other protocols to establish, maintain and delete Middlebox		rules to allow these Mobile IPv6 messages to pass through. The NSIS
	state (NAT bindings and Firewall rules). We identify NSIS as		NAT/FW NSLP, as described in [2], allows to establish, maintain and
	possible solution to the aforementioned problem and describe the		delete middlebox state (i.e., NAT bindings and Firewall rules) to
	solution in detail. For every communication mode, we will consider		allow packets to traverse these boxes. We identify NSIS as possible
	the application of NSIS signaling for the following simple scenarios:		solution to the aforementioned problem and describe the solution in
			detail. For every scenario mode, we will consider the application of
			NSIS signaling for the three routing modes. We also study other
			problematic aspects in these scenarios:
	o Correspondant Node (CN) behind a firewall		o Correspondent Node (CN) behind a firewall
	o Mobile Node (MN) behind a firewall		o Mobile Node (MN) 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		It is to be noted that a real scenario could include a combination of
	these cases. In all the scenarios, we assume that the Correspondant		these cases. In all the scenarios, we assume that the Correspondent
	Node(CN), Mobile Node(MN) and the Firewalls(FW) are NSIS aware. For		Node(CN), Mobile Node(MN) and the Firewalls(FW) are NSIS aware. For
	every NSIS message, we have also provided the NTLP flow-id which will		every NSIS message, we have also provided the NTLP flow-id which will
	be used to install the firewall policies.		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 [1], [2], and [6].		Furthermore, we use the same terminology as in [4], [2], and [5].
	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.
	3. Route Optimization		Signaling-D is used as an abbreviation for signaling packet filters
			to allow data traffic to traverse a firewall.
	In this communication mode, the CN and the MN deliver packets		Signaling-C is used as an abbreviation for signaling packet filters
	directly to each other. But before this, the MN has to perform		to allow MIPv6 signaling messages to traverse a firewall.
	Return Routability Test (RRT), where it has to send a home test init
	(HoTI) message (through the HA) and a Careof test init (CoTI)
	(directly) to the CN. The replies for these two messages home test
	(HoT) message (from the HA) and the Careof test (CoT) message (from
	the CN) are used to construct the binding-key which is used in the
	binding update procedure.
	3.1 Correspondant Node behind a firewall		The term 'DS' refers to data sender and the term 'DR' to data
			receiver.
	In Figure 1, the CN is protected by a firewall that employs stateful		3. Mobile Node behind a firewall
			3.1. Binding updates
			IPsec protected Binding Updates cause problems in some deployment
			environments, as described in [1]. An interim solution might in some
			environments the configuration of a firewall to allow the IPsec
			packets and associated traffic like IKE/IKEv2 packets to traverse.
			For both inbound and outbound filters, in order to allow IPsec ESP,
			IP Protocol ID 50 should be allowed in the filter policies.
			Similarly, to allow IPsec AH, IP Protocol ID 51 should be allowed.
			The firewall should also allow IKE packets (to UDP port 500) to
			bypass. These packet filters can be configured manually or
			dynamically using NSIS before sending the binding updates.
			3.2. Route optimization
			In Figure 1, the message flow for MN behind firewall scenario is
			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 acquires a new CoA and it performs the Binding Update to the
			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,
			it will be dropped by the FW. Hence, either the HA could initiate
			NSIS signaling to the MN and open pin-holes (only for NSIS aware HA)
			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
			be: SA: HA, DA: CoA
			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
			signaling is needed at all for this scenario. However, if the CN
			wants to send data traffic, the relevant packet filter rules have to
			be installed at the firewall. Hence, the CN has to initiate
			Signaling-D to the MN but this happens after the RRT. The MN has to
			perform a Binding Update to the CN, conveying its new CoA. Then, if
			the CN wants to start the data transfer, it will send an NSLP message
			directly to the MN. The HA is not involved in this process (for this
			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
			be: SA: CN, DA: CoA, SP: data application port, DP: data application
			port.
			Network protected
			+-------------------------+
			| |
			| +-----+ +-----+ +----+
			| | | | | | |
			| | |Binding Update| | | |
			| | |-------->-----+ +--------->----------+ |
			| | | | | Binding ACK | |
			| | |--------<-----+ +---------<----------+ |
			| | | | | | |
			| | MN | | FW | CREATE-C | HA |
			| | +--------<-----+ +---------<----------+ |
			| |(DS) | SUCCEED | | | |
			| | +-------->-----+ +--------->----------+ |
			| | | | | HoTI | |
			| | +-------->-----+ +--------->----------+ |
			| | | HoT | | | |
			| | +--------<-----+ +---------<----------+ |
			| | | | | | |
			| +-----+ +-----+ +----+
			| | |
			| | ^
			+-------------------------+ v
			|
			+----+
			| CN |
			| |
			|(DR)|
			+----+
			----- = signaling traffic Correspondent
			node
			Figure 1: NSIS signaling for MN behind the firewall
			3.3. Bi-directional tunneling
			Consider the scenario where the MN is protected by a SPF. The CN is
			generally unaware that the MN is behind the firewall. This might
			happen because, as the MN roams it might find itself protected by a
			firewall in some networks and the CN is not aware of this situation.
			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
			be: SA: HA, DA: MN. Note these data messages for which we do
			signaling, are IP-in-IP tunneled messages.
			Protected network
			+-------------------------+ External Mobil
			| | Node
			| +-----+ +-----+ +----+
			| | | | | | |
			| | |Binding update| | | |
			| | |-------->-----+ +--------->----------+ |
			| | | | | Binding ACK | |
			| | |--------<-----+ +---------<----------+ |
			| | | | | | |
			| | MN | | FW | CREATE-D | HA |
			| |(DR) +--------<-----+ +---------<----------+ |
			| | | SUCCEED | | | |
			| | +-------->-----+ +--------->----------+ |
			| | | | | | |
			| | | | | Data traffic | |
			| | +*******<******+ +*********<**********+ |
			| | | | | | |
			| +-----+ +-----+ +----+
			| | *
			+-------------------------+ ^
			*
			+----+
			| CN |
			|(DS)|
			***** = Data traffic +----+
			----- = Signaling traffic Correspondent node
			Figure 2: NSIS signaling for MN behind the firewall
			3.4. Triangular routing
			This is a special case where the HA should be NSIS aware and should
			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
			be: SA: HA, DA: MN. Note these data messages for which we do
			signaling, are IP-in-IP tunneled messages.
			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 3.
			Network protected
			+-------------------------+
			| | Home Agent
			| +-----+ +-----+ +----+
			| | |Binding update| | | |
			| | |-------->-----+ +--------->----------+ |
			| | | | | Binding ACK | |
			| | |--------<-----+ +---------<----------+ |
			| | | | | CREATE-D | HA |
			| | +--------<-----+ +---------<----------+ |
			| | | SUCCEED | | | |
			| | +-------->-----+ +--------->----------+ |
			| | MN | | FW | Tunneled packets | |
			| |(DR) +########<#####+ +#########<##########+ |
			| | | | | | |
			| | | | | +----+
			| | | | | *
			| | | | | ^
			| | | | | *
			| | | | | +----+
			| | | | | | CN |
			| +-----+ +-----+ |(DS)|
			| | +----+
			+-------------------------+ Correspondent Node
			----- = Signaling traffic
			***** = Data traffic
			##### = Tunneled data traffic
			Figure 3: NSIS signaling for MN behind the firewall
			3.5. Change of Firewalls
			If the MN roams and attaches to a different firewall, the above-
			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
			the HA) should re-signaling to the firewall using NSIS and establish
			the policies accordingly (mentioned above according to the routing
			methods).
			4. Correspondent Node behind a firewall
			4.1. Route Optimization
			In Figure 4, 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		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 in the same path. It also sends a CoTI message		message from the CN along the same path. It also sends a CoTI
	directly to the CN and expects CoT message in the same path from the		message directly to the CN and expects CoT message in the same path
	CN. The SPF will only allow packets that belong to an existing		from the CN. The SPF will only allow packets that belong to an
	session and hence both the packets (HoTI, CoTI) will be dropped as		existing session and hence both the packets (HoTI, CoTI) will be
	these packets are Mobile IPv6 packets and these packets have		dropped as these packets are Mobile IPv6 packets and these packets
	different header structure. The existing rules at the firewall might		have different header structure. The existing rules at the firewall
	have been installed for some kind of data traffic.		might have been installed for some kind of data traffic.
	+----------------+ +----+		+----------------+ +----+
	| | | HA |		| | | HA |
	| | +----+		| | +----+
	| | Home Agent		| | Home Agent
	| +----+ +----+ of MN		| +----+ +----+ 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 1: CN behind the firewall
			Figure 4: CN behind the firewall in RRT
	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		The FW may not necessarily know the MN and it may not be able to
	authenticate the MN. Hence it stores some relevant state regarding		authenticate the MN. Hence it stores some relevant state regarding
	this 'firewall policy installation' request and waits for the CN's		this 'firewall policy installation' request and waits for the CN's
	authorization. Once the CN approves the request, the FW will install		authorization. Once the CN approves the request, the FW will install
	the relevant policy requested by the MN. When the MN receives both		the relevant policy requested by the MN. When the MN receives both
	the messages CoT and HoT, it will construct the binding key and		the messages CoT and HoT, it will construct the binding key and
	perform binding update to the CN. Note, the signaling that was		perform binding update to the CN. Note, the signaling that was
	aforementioned was only to allow the Mobile IPv6 messages. Signaling		aforementioned was only to allow the Mobile IPv6 messages. The
	to let the MIPv6 messages will be referred to as Signaling-C and		message flow for NSIS signaling (with MN as data sender) is shown in
	signaling to let the data traffic pass through will be referred to as		Figure 5. Note, only the message flow between MN and CN is shown in
	Signaling-D from hereon. The message flow for NSIS signaling (with		the diagram.
	MN as data sender) is shown in Figure 2. 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 Signaling-C CREATE message from MN to CN, the flow-id will
	be: SA: CoA, DA: CN. It is to be noted that policy rules that are to		be: SA: CoA, DA: CN. It is to be noted that policy rules that are to
	be installed to allow the HoTI and CoTI packets are different and the		be installed to allow the HoTI and CoTI packets are different and the
	NI has to perform signaling twice.		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 perform Signaling-D to install filter rules for
	data traffic. This will be referred to as Signaling-D from hereon.		data traffic. The prospect of combined Signaling (for control and
	The possibility of combined signaling is a topic for further		data traffic) could be useful, but currently the NSIS NAT/FW protocol
	discussion.		does not support installing multiple rules at the same time.
	For the Signaling-D CREATE message from MN to CN, the flow-id will		For the Signaling-D CREATE message from MN to CN, the flow-id will
	be: SA: CoA, DA: CN		be: SA: CoA, DA: CN
	This solution works with the NSIS assumption that the firewalls will		This solution works with the assumption that the firewalls will allow
	allow NSIS message from external network. However, operators might		NSIS messages from external network to bypass with delayed packet
	be reluctant to allow NSIS message from external network as this		filter state establishment and authorization from the CN. However,
	might lead to DoS attacks. This threat assumes significant		operators might be reluctant to allow NSIS message from external
	importance if the NR is a mobile terminal.		network as this might lead to DoS attacks. The CR might therefore be
			required to authorize the traversal of NSIS signaling message
			implicitly to reduce unwanted traffic.
	To avoid this, it is also possible to ask the CN to open pin-holes in		To avoid this, it is also possible to ask the CN to open pin-holes in
	the firewall on behalf of the MN. But this solution will not work in		the firewall on behalf of the MN. But this solution will not work in
	some scenarios due to routing asymmetry concerns as explained in [4].		some scenarios due to routing asymmetry as explained in [2].
	+-----------------------+		+-----------------------+
	| | Home Agent		| | Home Agent
	| +-----+ +----+		| +-----+ +----+
	| | | | HA |		| | | | HA |
	| | | +----+		| | | +----+
	|+----+ | |		|+----+ | |
	|| | | | CREATE-C +----+		|| | | | CREATE-C +----+
	|| +--------<-----+ +---------<----------+ |		|| +--------<-----+ +---------<----------+ |
	|| | SUCCEED | | | |		|| | SUCCEED | | | |
	skipping to change at page 7, line 29		skipping to change at page 12, line 29
	|| | | | Binding update | |		|| | | | Binding update | |
	|| +--------<-----+ +---------<----------+ |		|| +--------<-----+ +---------<----------+ |
	|| | | | | |		|| | | | | |
	|+----+ +-----+ +----+		|+----+ +-----+ +----+
	| | Mobile		| | Mobile
	| | Node		| | Node
	+-----------------------+		+-----------------------+
	Network protected		Network protected
	by a firewall		by a firewall
	Figure 2: NSIS signaling for CN behind the firewall		Figure 5: NSIS signaling for CN behind the firewall
	3.2 Mobile Node behind a firewall
	In Figure 3, the message flow for MN behind firewall scenario is
	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 acquires a new CoA and it performs the Binding Update to the
	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,
	it will be dropped by the FW. Hence, either the HA could initiate
	NSIS signaling to MN and open pin-holes (only for NSIS aware HA) or
	the MN can open pin-holes for these messages to traverse (for NSIS
	unaware HA). The latter solution has additional concerns about
	routing asymmetry.
	For the Signaling-C CREATE message from HA to MN, the flow-id will		4.2. Bi-directional Tunneling
	be: SA: HA, DA: CoA
	Once the RRT is successfull, the binding update message is sent to		If we consider the scenario of the CN being protected by a firewall,
	the CN. If the MN wants to continue sending data traffic, then no		there is no need for any signaling if the CN starts sending data
	NSIS signaling is needed at all for this scenario. However, if the		traffic. The CN sends the data traffic and hence the SPF will store
	CN wants to send data traffic, the relevant packet filter rules have		relevant state information and accepts packets from the reverse
	to be installed at the firewall. Hence CN has to initiate		direction.
	Signaling-D to MN but this happens after the RRT. The MN has to
	perform binding update to the CN, conveying its new CoA. Then, if
	the CN wants to start the data transfer, it will send an NSLP message
	directly to the MN. The HA is not involved in this process (for this
	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. The MN might move to different networks, some
	protected by a firewall.
	For the Signaling-D CREATE message from CN to MN, the flow-id will		If MN is the DS, then the HA has to initiate Signaling-D, so that the
	be: SA: CN, DA: CoA, SP: data application port, DP: data application		firewall will allow the data traffic from the HA to CN. The message
	port.		flow is shown in Figure 6.
	Network protected		Protected network
	+-------------------------+		+-------------------------+ External Mobile
	| |		| | Node
	| +-----+ +-----+ +----+		| +-----+ +-----+ +----+
	| | | | | | |		| | | | | | |
	| | |Binding Update| | | |
	| | |-------->-----+ +--------->----------+ |
	| | | | | Binding ACK | |
	| | |--------<-----+ +---------<----------+ |
	| | | | | | |		| | | | | | |
	| | MN | | FW | CREATE-C | HA |		| | CN | | FW | CREATE-D | HA |
	| | +--------<-----+ +---------<----------+ |		| | +--------<-----+ +---------<----------+ |
	| |(DS) | SUCCEED | | | |		| |(DR) | SUCCEED | | | |
	| | +-------->-----+ +--------->----------+ |
	| | | | | HoTI | |
	| | +-------->-----+ +--------->----------+ |		| | +-------->-----+ +--------->----------+ |
	| | | HoT | | | |		| | | | | | |
	| | +--------<-----+ +---------<----------+ |		| | | | | Data traffic | |