draft-thiruvengadam-nsis-mip6-fw-06.txt		draft-thiruvengadam-nsis-mip6-fw-05.txt
	NSIS S. Thiruvengadam		NSIS S. Thiruvengadam
	Internet-Draft H. Tschofenig		Internet-Draft H. Tschofenig
	Expires: September 3, 2007 Siemens		Intended status: Informational Siemens
	F. Le		Expires: April 25, 2007 F. Le
	CMU		CMU
	N. Steinleitner, Ed.		N. Steinleitner
	X. Fu		X. Fu
	Univ. Goettingen		Univ. Goettingen
	March 2, 2007		October 22, 2006
	Mobile IPv6 - NSIS Interaction for Firewall traversal		Mobile IPv6 - NSIS Interaction for Firewall traversal
	draft-thiruvengadam-nsis-mip6-fw-06.txt		draft-thiruvengadam-nsis-mip6-fw-05.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 September 3, 2007.		This Internet-Draft will expire on April 25, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		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
	signaling protocol to communicate with these firewalls and instruct		signaling protocol to communicate with these firewalls and instruct
	them to bypass these Mobile IPv6 messages. The goal of this document		them to bypass these Mobile IPv6 messages. The goal of this document
	is to describe the interaction between NSIS and Mobile IPv6 for		is to describe the interaction between NSIS and Mobile IPv6 for
	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 . . . . . . . . . . . . . . . . . . . 8		3.4. Change of Firewalls . . . . . . . . . . . . . . . . . . . 7
	3.5. Operations when MN is behind a firewall . . . . . . . . . 8		3.5. Operations when MN is behind a firewall . . . . . . . . . 8
	4. Correspondent Node behind a firewall . . . . . . . . . . . . . 10		4. Correspondent Node behind a firewall . . . . . . . . . . . . . 9
	4.1. Route Optimization . . . . . . . . . . . . . . . . . . . . 10		4.1. Route Optimization . . . . . . . . . . . . . . . . . . . . 9
	4.2. Bi-directional Tunneling . . . . . . . . . . . . . . . . . 12		4.2. Bi-directional Tunneling . . . . . . . . . . . . . . . . . 11
	4.3. Change of Firewalls . . . . . . . . . . . . . . . . . . . 13		4.3. Change of Firewalls . . . . . . . . . . . . . . . . . . . 12
	4.4. Operations when CN is behind a firewall . . . . . . . . . 14		4.4. Operations when CN is behind a firewall . . . . . . . . . 12
	5. Home Agent behind a firewall . . . . . . . . . . . . . . . . . 15		5. Home Agent behind a firewall . . . . . . . . . . . . . . . . . 14
	5.1. Route Optimization . . . . . . . . . . . . . . . . . . . . 15		5.1. Route Optimization . . . . . . . . . . . . . . . . . . . . 14
	5.2. Bi-directional tunneling . . . . . . . . . . . . . . . . . 17		5.2. Bi-directional tunneling . . . . . . . . . . . . . . . . . 15
	5.3. Operations when HA is behind a firewall . . . . . . . . . 17		5.3. Operations when HA is behind a firewall . . . . . . . . . 16
	6. Additional Discussions . . . . . . . . . . . . . . . . . . . . 19		6. Additional Discussions . . . . . . . . . . . . . . . . . . . . 17
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 20		7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 22		9.1. Normative References . . . . . . . . . . . . . . . . . . . 20
	9.2. Informative References . . . . . . . . . . . . . . . . . . 22		9.2. Informative References . . . . . . . . . . . . . . . . . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
	Intellectual Property and Copyright Statements . . . . . . . . . . 24		Intellectual Property and Copyright Statements . . . . . . . . . . 22
	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 mode of communication in Mobile IPv6, namely bi-directional
	tunneling, also do not work under some firewall placements. Apart		tunneling, also do not work under some firewall placements. Apart
	from this, the Mobile IPv6 binding updates (encapsulated using IPsec		from this, the Mobile IPv6 binding updates (encapsulated using IPsec
	ESP) packets also have problems with firewall traversal. To tackle		ESP) packets also have problems with firewall traversal. To tackle
	skipping to change at page 3, line 35		skipping to change at page 3, line 35
	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 routing modes. It has to be noted that a real scenario could
	include a combination of some set of these cases. In any case, we		include a combination of some set of these cases. In any case, we
	assume that the MN, the CN, the HA and the Firewalls (FWs) are NSIS		assume that the MN, the CN, the HA and the Firewalls (FWs) are NSIS
	and NAT/FW NSLP aware. Also note that for every NSIS message, the		aware. Also note that for every NSIS message, the undelying GIST[5]
	underlying GIST[5] level provides flow-id information which will be		level provides flow-id information which will be used to install the
	used to install the firewall policies.		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:		the NSIS messages: SA-Source Address, DA-Destination Address, SP-
			Source Port, DP-Destination Port and an asterisk is used as wild-
	o SA-Source Address,		card.
	o DA-Destination Address,
	o SP-Source Port,
	o DP-Destination Port, and
	o an asterisk is used as wild-card.
	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		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		packet filtering (SPF). The external CN and the HA are also shown in
	the figure. The MN is located in a visited network and is expecting		the figure. The MN is in a foreign network and is communicating with
	to communicate with the CN. If the MN initiated normal data traffic		the CN. Here it is assumed that MN has initiated the communication
	there is no problem with the SPF firewall, as the communication is		and hence it has no problems with the SPF.
	initiated from internal.
	+----------------+ +----+		+----------------+ +----+
	| | | HA |		| | | HA |
	| | +----+		| | +----+
	| | Home Agent		| | Home Agent
	| +----+ +----+		| +----+ +----+
	| | MN | | FW |		| | MN | | FW |
	| +----+ +----+		| +----+ +----+
	| | +----+		| | +----+
	| | | CN |		| | | CN |
	skipping to change at page 5, line 39		skipping to change at page 5, line 38
	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]. As a solution, NAT/FW NSLP can be		environments, as described in [1]. As a solution, NAT/FW NSLP can be
	used to dynamically configure the firewall(s) 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,
	before sending the binding updates. Therefore, IP Protocol ID 50		before sending the binding updates. Therefore, IP Protocol ID 50
	should be allowed in the filter policies in order to allow IPsec ESP		should be allowed in the filter policies in order to allow IPsec ESP
	and IP Protocol ID 51 to allow IPsec AH. The firewall should also		and IP Protocol ID 51 to allow IPsec AH. The firewall should also
	allow IKE packets (to UDP port 500) to bypass. As the firewall is a		allow IKE packets (to UDP port 500) to bypass.
	SPF, the subsequent Binding Acknowledgement from the HA to the CoA
	can pass the firewall, as it matches an existing state inside the
	firewall.
	For the BU message (IPsec ESP in transport mode) from MN to HA,		For the BU message from MN to HA, the MN installs rules using
	the MN installs rules using CREATE for the flow-id: SA: CoA, DA:		CREATE for the flow-id: SA: COA, DA: HA.
	HA, SPIx.
	3.2. Route optimization		3.2. Route optimization
	Immediately after moving into a new network, the MN acquires a new		In Figure 2, the message flow for MN behind firewall scenario is
	CoA, performs the pinhole creation as described in section		shown (with CN as data sender). Here, all the messages initiated by
	Section 3.1 and runs the Binding Update to the HA. The HoTI message		the MN will be bypassed. Immediately after moving to a new network,
	from the MN is IPsec encapsulated in tunnel mode and as it does not		the MN acquires a new CoA and it performs the Binding Update to the
	belong to the session initiated by the MN or match a previously		HA. The HoT message received by the MN is actually a tunneled
	installed rule, it will be dropped by the firewall. Using CREATE,		message and as it does not belong to the session initiated by the MN,
	the MN initiates NSIS signalling to the firewall and open pinholes		it will be dropped by the FW. Using REA, the MN initiate NSIS
	for the HoTI message. The message flow is shown in Figure 2. The		signaling to the FW and open pinholes for the HoT message.
	HoT message can re-use this pinhole and is able to reach the MN.
	For the HoTI message (IPsec ESP in tunnel mode) from MN to HA, the		For the HoT message from HA to MN, the MN signaling using REA for
	MN installs rules using the CREATE message for the flow-id: SA:		the flow-id: SA: HA, DA: CoA.
	CoA, DA:HA, SPIx.
			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 sending
			datta traffic to the MN but this happens after the RRT. The MN has
			to perform a Binding Update to the CN, conveying its new CoA.
			Therefore, the MN open pinholes using REA to let the data traffic
			traverse the firewalls.
			For the CREATE message for data traffic from CN to MN, the MN
			signaling using REA for the flow-id: SA: CN, DA: CoA, SP: data
			application port, DP: data application port.
	Network protected		Network protected
	+-------------------------+		+-------------------------+
	| |		| |
	| +-----+ +-----+ +----+		| +-----+ +-----+ +----+
	| | |Binding Update| | | |		| | |Binding Update| | | |
	| | |-------->-----+ +--------->----------+ |		| | |-------->-----+ +--------->----------+ |
	| | | | | Binding ACK | |		| | | | | Binding ACK | |
	| | |--------<-----+ +---------<----------+ |		| | |--------<-----+ +---------<----------+ |
	| | MN | CREATE | FW | | HA |		| | MN | REA | FW | | HA |
	| | +-------->-----+ |--------->----------| |		| | +-------->-----+ | | |
	| |(DS) | | | RESPONSE | |		| |(DS) | RESPONSE | | | |
	| | +--------<-----+ |---------<----------| |		| | +--------<-----+ | | |
	| | | HoTI | | | |		| | | | | HoTI | |
	| | +-------->-----+ +--------->----------+ |		| | +-------->-----+ +--------->----------+ |
	| | | | | HoT | |		| | | HoT | | | |
	| | +--------<-----+ +---------<----------+ |		| | +--------<-----+ +---------<----------+ |
	| +-----+ +-----+ +----+		| +-----+ +-----+ +----+
	| | ^		| | ^
	+-------------------------+ |		+-------------------------+ |
	v		v
	+----+		+----+
	| CN |		| CN |
	|(DR)|		|(DR)|
	+----+		+----+
	----- = signaling traffic Correspondent node		----- = signaling traffic Correspondent node
	Figure 2: NSIS signaling for MN behind the firewall		Figure 2: NSIS signaling for MN behind the firewall
	The CoTI message and the CoT message can traverse the MN's ASP-
	firewall, as the CoTI message is not IPsec encapsulated and the CoT
	message correspond to the state previously installed by the CoTI
	message. Once the RRT is successful, the binding update message is
	sent to the CN. If the MN wants to continue sending data traffic, no
	NSIS signaling is needed at all for this scenario. However, if the
	CN wants to send data traffic and the rules installed before matching
	again the addresses, the ports and the IPsec encapsulation, the
	relevant packet filter rules have to be installed at the firewall.
	If the rules installed before only matching again source and
	destination address, the data traffic exchanged with the CN in RO-
	case can also traverse the firewall with no need of installing
	additional rules. However, that would allow all kind of traffic from
	the CN and is rejected. Hence, the MN has to initiate sending data
	traffic to the CN but this happens after the RRT.
	For the data traffic from CN to MN the MN installs rules using EXT
	for the flow-id: SA: CN, DA:CoA, SP: data application port, DP:
	data application port.
	3.3. Bi-directional tunneling		3.3. Bi-directional tunneling
	Consider the scenario where the MN is protected by a SPF. Even		Consider the scenario where the MN is protected by a SPF. Even
	though the MN had earlier initiated a connection for the purpose of		though the MN had earlier initiated a connection for the purpose of
	binding update, new filter rules have to be installed to allow the		binding update, new filter rules have to be installed to allow the
	tunnelled data traffic as the rules before installed rules match		tunneled data traffic. The message flow is shown in Figure 3.
	again the addresses, the ports and the IPsec ESP encapsulation. The
	message flow is shown in Figure 3. If the MN is the DS, no signaling
	is needed at all. Otherwise, the MN open pinholes to let the data
	messages traverse, with the help of EXT.
	For the data traffic from HA to MN, the MN installs rules using		If the MN is the DS, no signaling is needed at all. Otherwise, the
	EXT for the flow-id: SA: HA, DA: CoA. Note these data messages		MN open pinholes to let the data messages traverse, with the help of
	for which we do 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
	+-------------------------+		+-------------------------+
	| | Home Agent		| | Home Agent
	| +-----+ +-----+ +----+		| +-----+ +-----+ +----+
	| | |Binding update| | | |		| | |Binding update| | | |
	| | |------->------+ +--------->----------+ |		| | |-------->-----+ +--------->----------+ |
	| | | | | Binding ACK | |		| | | | | Binding ACK | |
	| | |-------<------+ +---------<----------+ |		| | |--------<-----+ +---------<----------+ |
	| | MN | EXT | FW | | HA |		| | MN | REA | FW | | HA |
	| |(DR) +------->------+ | | |		| |(DR) +--------<-----+ | | |
	| | | RESPONSE | | | |		| | | RESPONSE | | | |
	| | +-------<------+ | | |		| | +-------->-----+ | | |
	| | | | | Data traffic | |		| | | | | Data traffic | |
	| | +*******<******+ +*********<**********+ |		| | +*******<******+ +*********<**********+ |
	| +-----+ +-----+ +----+		| +-----+ +-----+ +----+
	| | *		| | *
	+-------------------------+ ^		+-------------------------+ ^
	*		*
	+----+		+----+
	| CN |		| CN |
	|(DS)|		|(DS)|
	***** = Data traffic +----+		***** = Data traffic +----+
	skipping to change at page 8, line 49		skipping to change at page 8, line 17
	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.5. Operations when MN is behind a firewall
	In summary, when a firewall is located in MN's ASP, the MN configures		MN configure the firewall(s) using CREATE to let following traverse:
	the firewall(s) using CREATE to let following messages traverse:
	o Binding update messages (src: CoA, dst: HA, SPIx) (IPsec ESP in		o binding update messages (src: CoA, dst: HA) {BU}
	transport mode) {for BU}
	o HoTI message (src: CoA, dst: HA, SPIx) (IPsec ESP in tunnel mode)		o HoTI messages (src: CoA, dst: HA) {RO}
	{for RO}
	MN configures the firewall(s) using EXT to let following traverse:		o if uplink firewall, for data traffic from MN (src: MN, dst: *)
	o for data traffic from HA to MN (src: HA, dst: CoA) {BT}		MN configures the firewall(s) using REA to let following traverse:
	o for data traffic from CN to MN (src: CN, dst: CoA) {RO}		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 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 4, the CN is protected by a firewall that employs stateful
	packet filtering. The external MN and its associated HA are also		packet filtering (SPF). The external MN and its associated HA are
	shown in the figure. The MN communicates with the CN. If the CN		also shown in the figure. The MN is in its home network and is
	initiated normal data traffic there is no problem with the SPF, as		communicating with the CN. Here it is assumed that CN has initiated
	the communication is initiated from internal.		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 4: 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 before sending the binding update to the CN. It		routability test (RRT) before sending the binding update to the CN.
	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 a different header structure. The existing rules at the		have different header structure. The existing rules at the firewall
	firewall might have been installed for some kind of data traffic.		might have been installed for some kind of data traffic.
	+-----------------------+ Home Agent
	| | +----+
	| +-----+ | HA |
	| | | +----+
	|+----+ | |
	|| | | | CREATE +----+
	|| +--------<-----+ +---------<----------+ |
	|| | RESPONSE | | | |
	|| +-------->-----+ FW +--------->----------+ |
	|| | | | CoTI | |
	|| CN +--------<-----+ +---------<----------+ MN |
	|| | CoT | | | |
	||(DR)+-------->-----+ +--------->----------+(DS)|
	|| | | | Binding update | |
	|| +--------<-----+ +---------<----------+ |
	|+----+ +-----+ +----+
	| | Mobile
	+-----------------------+ Node
	Network protected
	by a firewall
	Figure 5: CN behind the firewall
	As the RRT procedure cannot be executed, the firewall rules have to
	be modified to allow these MIPv6 messages to go through. The MN
	initiates the NSIS session by sending a CREATE message to the CN to
	install rules for the CoTI message. The NSIS signaling to allow the
	CoTI message is shown in Figure 5.
	For the CoTI message from MN to CN, the MN installs rules using
	CREATE for the flow-id: SA: CoA, DA: CN.
	This allows the CoTI to reach the CN. If the MN signal as described
	in section Section 3.2 the HoTI is able to reach the HA.
	Nevertheless, the HoTI message from the HA to the CN is not able to
	traverse, as it does not match any state at the CN's ASP-FW.
	Therefore, either the HA or the CN has to signal install rules to let
	the HoTI traverse.
	If the HA initiates the pinhole creation, the CREATE message for
	the HoTI message from HA to CN the flow-id will be: SA: HoA, DA:
	CN.
	If the CN initiates the pinhole creation, the EXT message for the		As the RRT can not be executed, the firewalls rules have to be
	HoTI message from HA to CN the flow-id will be: SA: HoA, DA: CN.		modified to allow these MIPv6 messages to go through. The MN
			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
			the binding key and 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.
	When the MN receives both CoT and HoT messages, it performs binding		For the CREATE message for MIPv6 signaling traffic from MN to CN,
	update to the CN which is possible, as the BU can re-uses the		the flow-id will be: SA: CoA, DA: CN. Note: The policy rules that
	previously installed rules. Note that the aforementioned signalling		are to be installed to allow the HoTI and CoTI packets are
	was only to allow the Mobile IPv6 messages.		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 install filter rules for data traffic. The		is the DS), it has to install filter rules for data traffic. The
	prospect of combined signaling (for control and data traffic) could		prospect of combined signaling (for control and data traffic) could
	be useful, but currently the NSIS NAT/FW protocol does not support		be useful, but currently the NSIS NAT/FW protocol does not support
	installing multiple rules at the same time.		installing multiple rules at the same time.
	For the data traffic from MN to CN, the MN installs rules using		For the CREATE message for data traffic from MN to CN, the flow-id
	CREATE for the flow-id: SA: CoA, DA:CN, SP: data application port,		will be: SA: CoA, DA: CN.
	DP: data application port.
	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 CN 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 pinholes in		To avoid this, it is also possible to ask the CN to open pinholes 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 as explained in [2].		some scenarios due to routing asymmetry as explained in [2].
			+-----------------------+ Home Agent
			| | +----+
			| +-----+ | HA |
			| | | +----+
			|+----+ | |
			|| | | | CREATE +----+
			|| +--------<-----+ +---------<----------+ |
			|| | RESPONSE | | | |
			|| +-------->-----+ FW +--------->----------+ |
			|| | | | CoTI | |
			|| CN +--------<-----+ +---------<----------+ MN |
			|| | CoT | | | |
			||(DR)+-------->-----+ +--------->----------+(DS)|
			|| | | | Binding update | |
			|| +--------<-----+ +---------<----------+ |
			|+----+ +-----+ +----+
			| | Mobile
			+-----------------------+ Node
			Network protected
			by a firewall
			Figure 5: 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,
			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.
			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.
	Protected network		Protected network
	+-------------------------+		+-------------------------+
	| | Home Agent		| | Home Agent
	| +-----+ +-----+ +----+		| +-----+ +-----+ +----+
	| | | | | | |		| | | | | | |
	| | CN | EXT | FW | | HA |		| | CN | REA | FW | | HA |
	| | +-------->-----+ | | |		| | +-------->-----+ | | |
	| |(DR) | RESPONSE | | | |		| |(DR) | RESPONSE | | | |
	| | +--------<-----+ | | |		| | +--------<-----+ | | |
	| | | | | Data traffic | |		| | | | | Data traffic | |
	| | +**************+ +********************+ |		| | +**************+ +********************+ |
	| +-----+ +-----+ +----+		| +-----+ +-----+ +----+
	| | #		| | #
	+-------------------------+ #		+-------------------------+ #
	+----+		+----+
	| 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 6: NSIS signaling for CN behind the firewall