draft-thiruvengadam-nsis-mip6-fw-00.txt		draft-thiruvengadam-nsis-mip6-fw-01.txt
	NSIS S. Thiruvengadam		NSIS S. Thiruvengadam
	Internet-Draft H. Tschofenig		Internet-Draft H. Tschofenig
	Expires: January 10, 2005 Siemens		Expires: April 23, 2005 Siemens
	F. Le		F. Le
	Nokia		Nokia
	July 12, 2004		October 23, 2004
	Mobile IPv6 - NSIS interaction for Firewalls		Mobile IPv6 - NSIS Interaction for Firewall traversal
	draft-thiruvengadam-nsis-mip6-fw-00		draft-thiruvengadam-nsis-mip6-fw-01
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable		This document is an Internet-Draft and is subject to all provisions
	patent or other IPR claims of which I am aware have been disclosed,		of section 3 of RFC 3667. By submitting this Internet-Draft, each
	and any of which I become aware will be disclosed, in accordance with		author represents that any 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 become aware will be disclosed, in accordance with
	RFC 3668.		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		other groups may also distribute working documents as
	Internet-Drafts.		Internet-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 January 10, 2005.		This Internet-Draft will expire on April 23, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004).
	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
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Route Optimization . . . . . . . . . . . . . . . . . . . . . . 3		3. Route Optimization . . . . . . . . . . . . . . . . . . . . . . 5
	3.1 Correspondant Node (CN) behind a firewall . . . . . . . . 3		3.1 Correspondant Node behind a firewall . . . . . . . . . . . 5
	3.2 Mobile Node (MN) behind a firewall . . . . . . . . . . . . 5		3.2 Mobile Node behind a firewall . . . . . . . . . . . . . . 7
	3.3 Home Agent (HA) behind a firewall . . . . . . . . . . . . 6		3.3 Home Agent behind a firewall . . . . . . . . . . . . . . . 9
	4. Other Routing Considerations . . . . . . . . . . . . . . . . . 8		4. Bi-directional tunneling . . . . . . . . . . . . . . . . . . . 12
	4.1 Triangular routing (CN behind Firewall) . . . . . . . . . 8		4.1 Correspondant Node behind firewall . . . . . . . . . . . . 12
	4.2 Bi-directional routing (MN behind firewall) . . . . . . . 9		4.2 Mobile Node behind firewall . . . . . . . . . . . . . . . 13
			4.3 Home Agent behind firewall . . . . . . . . . . . . . . . . 14
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 10		5. Triangular routing . . . . . . . . . . . . . . . . . . . . . . 16
			5.1 Correspondant Node behind Firewall . . . . . . . . . . . . 16
			5.2 Mobile Node behind Firewall . . . . . . . . . . . . . . . 17
			5.3 Home Agent behind Firewall . . . . . . . . . . . . . . . . 18
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10		6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
	7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 11		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11		8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 22
	8.1 Normative References . . . . . . . . . . . . . . . . . . . . 11
	8.2 Informative References . . . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
			9.1 Normative References . . . . . . . . . . . . . . . . . . . . 23
			9.2 Informative References . . . . . . . . . . . . . . . . . . . 23
	Intellectual Property and Copyright Statements . . . . . . . . 13		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		packet filtering. This problem is well described in [6]. The other
	[I-D.le-mip6-firewalls]. There is a need for identifying a signaling		modes of communication in Mobile IPv6 nameley bi-directional
	protocol that can install some firewall rules to allow these Mobile		tunneling and triangular routing also do not work under some firewall
	IPv6 messages to pass through. The NSIS NAT/FW NSLP described in		placements. There is a need for identifying a signaling protocol
	[I-D.ietf-nsis-nslp-natfw], allows other protocols to establish/		that can install some firewall rules to allow these Mobile IPv6
	maintain/delete Middlebox state(NAT bindings and Firewall rules). We		messages to pass through. The NSIS NAT/FW NSLP described in [2],
	identify NSIS as possible solution to the aforementioned problem and		allows other protocols to establish, maintain and delete Middlebox
	describe the solution in detail.		state (NAT bindings and Firewall rules). We identify NSIS as
			possible solution to the aforementioned problem and describe the
			solution in detail. For every communication mode, we will consider
			the application of NSIS signaling for the following simple scenarios:
			o Correspondant Node (CN) behind a firewall
			o Mobile Node (MN) behind a firewall
			o Home Agent (HA) behind a firewall
			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
			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
			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 [RFC2119].		document are to be interpreted as described in [3].
	Furthermore, we use the same terminology as in [RFC3775],		Furthermore, we use the same terminology as in [1], [2], and [7].
	[I-D.ietf-nsis-nslp-natfw], and [I-D.ietf-nsis-requirements].		Apart from this, we use some abbreviations to describe the flow-id of
			the NSIS messages: SA-Source Address, DA-Destination Address,
			SP-Source Port, DP-Destination Port and an asterisk is used as
			wild-card.
	3. Route Optimization		3. Route Optimization
	In this section we will consider the application of NSIS signaling		In this communication mode, the CN and the MN deliver packets
	for some simple scenarios. It is to be noted that a real scenario		directly to each other. But before this, the MN has to perform
	could include a combination of these cases. In all the scenarios, we		Return Routability Test (RRT), where it has to send a home test init
	assume that the Correspondant Node(CN), Mobile Node(MN) and the		(HoTI) message (through the HA) and a Careof test init (CoTI)
	Firewalls(FW) are NSIS aware. When we mention that a network is		(directly) to the CN. The replies for these two messages home test
	protected by a firewall, we assume that there is one central firewall		(HoT) message (from the HA) and the Careof test (CoT) message (from
	for the whole network. This assumption will be relaxed in the later		the CN) are used to construct the binding-key which is used in the
	versions of this draft.		binding update procedure.
	o Correspondant Node (CN) behind a firewall
	o Mobile Node (MN) behind a firewall
	o Home Agent (HA) behind a firewall
	3.1 Correspondant Node (CN) behind a firewall		3.1 Correspondant Node behind a firewall
	In Figure 1, the correspondant node (CN) is protected by a firewall		In Figure 1, the CN is protected by a firewall that employs stateful
	that employs stateful packet filtering (SPF). The external mobile		packet filtering (SPF). The external MN and its associated HA are
	node (MN) and its associated home agent (HA) are also shown in the		also shown in the figure. The MN is in its home network and is
	figure. The MN is in its home network and is communicating with CN.		communicating with the CN. Here it is assumed that CN has initiated
	Here it is assumed that CN has initiated the communication and hence		the communication and hence it has no problems with the SPF.
	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 home test init (HoTI) message through the HA to the CN and		It sends a HoTI message through the HA to the CN and expects a HoT
	expects a home test (HoT) message from the CN in the same path. It		message from the CN in the same path. It also sends a CoTI message
	also sends a Careof test init (CoTI) message directly to the CN and		directly to the CN and expects CoT message in the same path from the
	expects Careof test (CoT) message in the same path from the CN. The		CN. The SPF will only allow packets that belong to an existing
	SPF will only allow packets that belong to an existing session and		session and hence both the packets (HoTI, CoTI) will be dropped as
	hence will drop the COTI packet as this packet has a new source		these packets are Mobile IPv6 packets and these packets have
	address.		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		| +----+ +----+ 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 scenario		Figure 1: CN behind the firewall
	The MN initiates the NSIS session by sending a 'create-session'		As the RRT can not be executed, the firewalls rules have to be
	message to the CN. The FW may not necessarily know the MN and it may		modified to allow these MIPv6 messages to go through. The MN
	not be able to authenticate the MN. Hence it stores some relevant		initiates the NSIS session by sending a CREATE message to the CN.
	state regarding this 'firewall policy installation' request and waits		The FW may not necessarily know the MN and it may not be able to
	for the CN's authentication result. Once the CN approves the		authenticate the MN. Hence it stores some relevant state regarding
	request, the FW will install the relevant policy requested by the MN.		this 'firewall policy installation' request and waits for the CN's
	When the MN receives both the messages CoT and HoT, it will construct		authorization. Once the CN approves the request, the FW will install
	the binding key and perform binding update to the CN. Note, the		the relevant policy requested by the MN. When the MN receives both
	signaling that was aforementioned was only to allow the Mobile IPv6		the messages CoT and HoT, it will construct the binding key and
	messages. This will be referred to as Signaling-C from hereon. If		perform binding update to the CN. Note, the signaling that was
	the CN wants to continue sending data traffic to the new CoA, it can		aforementioned was only to allow the Mobile IPv6 messages. Signaling
	do so without any additional signaling. But if the MN wants to		to let the MIPv6 messages will be referred to as Signaling-C and
	continue sending data traffic, it has to perform one more round of		signaling to let the data traffic pass through will be referred to as
	signaling to install filter rules for data traffic. This will be		Signaling-D from hereon. The message flow for NSIS signaling (with
	referred to as Signaling-D from hereon. The possibility of combined		MN as data sender) is shown in Figure 2. Note, only the message flow
	signaling is a topic for further discussion. The message flow for
	NSIS signaling is shown in Figure 2. Note, only the message flow
	between MN and CN is shown in the diagram.		between MN and CN is shown in the diagram.
	+-----------------------+ +----+		For the Signaling-C CREATE message from MN to CN, the flow-id will
	| | | HA |		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
			NI has to perform signaling twice.
			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
			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
			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.
			The possibility of combined signaling is a topic for further
			discussion.
			For the Signaling-D CREATE message from MN to CN, the flow-id will
			be: SA: CoA, DA: CN
			This solution works with the NSIS assumption that the firewalls will
			allow NSIS message from external network. However, operators might
			be reluctant to allow NSIS message from external network as this
			might lead to DoS attacks. This threat assumes significant
			importance if the NR is a mobile terminal.
			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
			some scenarios due to routing asymmetry concerns as explained in [5].
			+-----------------------+
	| | Home Agent		| | Home Agent
	| | of MN		| +-----+ +----+
	| |		| | | | HA |
	| |		| | | +----+
	|+----+ +-----+		|+----+ | |
	|| | | | CREATE-SESSION +----+		|| | | | CREATE-C +----+
	|| +--------<-----+ +---------<----------+ |
	|| | PATH-SUCCEED | | | |
	|| +-------->-----+ +--------->----------+ |
	|| CN | | FW | CoTI | MN |
	|| +--------<-----+ +---------<----------+ |		|| +--------<-----+ +---------<----------+ |
			|| | SUCCEED | | | |
			|| +-------->-----+ FW +--------->----------+ |
			|| | | | CoTI | |
			|| CN +--------<-----+ +---------<----------+ MN |
	|| | CoT | | | |		|| | CoT | | | |
	|| +-------->-----+ +--------->----------+ |		||(DR)+-------->-----+ +--------->----------+(DS)|
	|| | | | Binding update | |		|| | | | Binding update | |
	|| +--------<-----+ +---------<----------+ |		|| +--------<-----+ +---------<----------+ |
	|| | | | Binding ACK | |
	|| +-------->-----+ +--------->----------+ |
	|| | | | | |		|| | | | | |
	|+----+ +-----+ +----+		|+----+ +-----+ +----+
	| |		| | Mobile
	| | External Mobile
	| | Node		| | Node
	+-----------------------+		+-----------------------+
	Network protected		Network protected
	by a firewall		by a firewall
	Figure 2: NSIS signaling for CN behind the firewall		Figure 2: NSIS signaling for CN behind the firewall
	3.2 Mobile Node (MN) behind a firewall		3.2 Mobile Node behind a firewall
	In Figure 3, the least problematic scenario is shown. This is		In Figure 3, the message flow for MN behind firewall scenario is
	because the MN is protected by the firewall and all the messages		shown (with CN as data sender). Here, all the messages initiated by
	initiated by the MN will be bypassed. Immediatly after moving to a		the MN will be bypassed. Immediately after moving to a new network,
	new network, the MN acquires a new CoA and it performs the binding		the MN acquires a new CoA and it performs the Binding Update to the
	update to the HA. The RRT procedure follows and then it performs the		HA. The HoT message received by the MN is actually a tunneled
	binding update to the CN. If the MN wants to continue sending data		message and as it does not belong to the session initiated by the MN,
	traffic, then no NSIS signaling is needed at all for this scenario.		it will be dropped by the FW. Hence, either the HA could initiate
	However, if the CN wants to send data traffic, CN has to initiate		NSIS signaling to MN and open pin-holes (only for NSIS aware HA) or
	Signaling-D.		the MN can open pin-holes for these messages to traverse (for NSIS
			unaware HA). The latter solution has additional concerns about
			routing asymmetry.
	Home Network		For the Signaling-C CREATE message from HA to MN, the flow-id will
	+----------------+		be: SA: HA, DA: CoA
	| |
	| +----+ |		Once the RRT is successfull, the binding update message is sent to
	| | HA | |		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 CN has to initiate
	| | | : |		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
	| | CN | | :		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
	| | v		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
	CN's Network | : |		protected by a firewall.
	| : |
	+----+ +----+ |		For the Signaling-D CREATE message from CN to MN, the flow-id will
	| FW | | MN | |		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)|
	Visited Network		+----+
			----- = signaling traffic Correspondant
	...... = Mobility direction		node
	Figure 3: MN behind the firewall scenario		Figure 3: MN behind the firewall scenario
	3.3 Home Agent (HA) behind a firewall		3.3 Home Agent behind a firewall
	This is a special case which requires the HA also to be NSIS aware.		This is a special case which requires the HA also to be NSIS aware.
			The HA should have NR (NSIS) responder capabilities.
	The first thing the MN has to do after entering a new network is to		MN, after entering a new network, sends a binding update to the HA.
	send a binding update to the HA. But as it is initiated by the MN,		But as it is initiated by the MN, it first has to install some filter
	it first has to install some filter rules in the FW before sending		rules in the FW before sending the binding update.
	the binding update. Hence, it initiates the NSIS Signaling-C to
	create rules that will allow the binding update messages.
	Then it performs the binding update to the HA. The MN-HA binding		The MN-HA binding update message is assumed to be IPsec protected.
	update message is assumed to be IPsec protected. This might cause		This might cause problems, as some primitive firewalls do not
	problems, as some firewalls do not allow IPsec traffic. Hence UDP		recognise IPsec traffic and hence drop the packets because of the
	encapsulation of IPsec traffic might be needed to alleviate this		absence of any transport header. Hence UDP encapsulation of IPsec
	problem. The authors are awaiting feedback from the MIP6 WG which is		traffic might be needed to alleviate this problem. The present
	currently discussing the possibility of using Authentication Data		firewalls use the SPI (Security Parameter Index) instead of the port
	field to carry Binding Update/Acknowledgement. This might be a		numbers for IPsec traffic.
	possible alternative for Binding update protection.
	The firewall rules previously installed will also allow the HoTI		The MN initiates the NSIS Signaling-C to create rules that will allow
	message. The HA will then send the HoTI to CN and obviously this		the binding update messages. Then it performs the binding update to
	message is allowed as it is initiated by the HA. The HoT message		the HA. For the Signaling-C CREATE message from MN to HA, the
	from CN to HA is also allowed by the SPF as it belongs to the session		flow-id will be: SA: MN, DA: HA, SPIx.
	previously initiated by the HA. The HoT message from HA to MN is
	also allowed as it is initiated by the HA. The RRT completes
	successfully.
	Now the MN has to perform Signaling-D so that the tunneled packets		The authors are awaiting feedback from the MIP6 WG which is currently
	will be allowed by the FW. Detailed message flow is shown in Figure		discussing the possibility of using Authentication Data field to
	4. Note, only the interaction between HA and MN is shown in the		carry Binding Update/Acknowledgement. This might be a possible
	figure.		alternative for Binding update protection.
			The firewall rules previously installed will not allow the HoTI
			message. Hence the MN has to install a different set of rules to
			allow these messages, by initiating another Signaling-C and then it
			sends teh HOTI message to HA. The HA will then send the HoTI to CN
			and obviously this message is allowed as it is initiated by the HA.
			The HoT message from CN to HA is also allowed by the SPF as it
			belongs to the session previously initiated by the HA. The HoT
			message from HA to MN is also allowed as it is initiated by the HA.
			The RRT completes successfully.
			For the Signaling-C CREATE message from MN to HA, the flow-id will
			be: SA: MN, DA: HA
			Detailed message flow (with MN as data sender) is shown in Figure 4.
			Note, only the interaction between HA and MN is shown in the figure.
	+------------------------+ +----+		+------------------------+ +----+
	| | | CN |		| | | CN |
			| | |(DR)|
	| | +----+		| | +----+
	| | Correspondant node
	| |		| |
	| +----+ +-----+ +------------------+		| +----+ +-----+ +------------------+
	| | | | | CREATE-SESSION | +----+ |		| | | | | CREATE-C | +----+ |
	| | +--------<-----+ +---------<------|---<---+ | |		| | +--------<-----+ +---------<------|---<---+ | |
	| | | PATH-SUCCEED | | | | | |		| | | SUCCEED | | | | | |
	| | +-------->-----+ +--------->------|--->---+ | |		| | +-------->-----+ +--------->------|--->---+ | |
	| | | | | Binding update | | | |		| | | | | Binding update | | | |
	| | +--------<-----+ +---------<------|---<---+ | |		| | +--------<-----+ +---------<------|---<---+ | |
	| | | | | Binding ACK | | | |		| | HA | | FW | Binding ACK | | MN | |
			| | +-------->-----+ +--------->------|--->---+ | |
			| | | | | | |(DS)| |
			| | | | | CREATE-C | | | |
			| | +--------<-----+ +---------<------|---<---+ | |
			| | | SUCCEED | | | | | |
	| | +-------->-----+ +--------->------|--->---+ | |		| | +-------->-----+ +--------->------|--->---+ | |
	| | | | | HoTI | | | |		| | | | | HoTI | | | |
	| | +--------<-----+ +---------<------|---<---+ | |		| | +--------<-----+ +---------<------|---<---+ | |
	| | | | | HoT | | | |		| | | | | HoT | | | |
	| | +-------->-----+ +--------->------|--->---+ | |		| | +-------->-----+ +--------->------|--->---+ | |
	| | HA | | FW | | | | |
	| | | | | | | MN | |
	| | | | | | | | |
	| | | | | CREATE-SESSION | | | |
	| | +--------<-----| +---------<------|---<---+ | |
	| | | PATH-SUCCEED | | | | | |
	| | +-------->-----+ +--------->------|--->---+ | |
	| | | | | DATA | | | |
	| | +========<=====+ +=========<======|===<===+ | |
	| | | | | | | | |		| | | | | | | | |
	| +----+ +-----+ | +----+ |		| +----+ +-----+ | +----+ |
	| | | |		| | | |
	| | | |
	+------------------------+ +------------------+		+------------------------+ +------------------+
	HA protected by firewall Visited Network		HA protected by firewall Visited Network
	(Home Network)		(Home Network)
	Figure 4: NSIS signaling for HA behind the firewall		Figure 4: NSIS signaling for HA behind the firewall
	4. Other Routing Considerations		For the data traffic, there is no additional signaling as the MN
			sends data directly to CN and none of these networks (CN network and
			MN network) are protected by firewalls. This is applicable for both
			MN and CN as data senders.
	In this section we will consider the application of NSIS signaling		4. Bi-directional tunneling
	for the other routing scenarios namely:
	o Triangular routing
	o Bi-directional tunneling
	We will treat only some scenarios here. More scenarios will be
	treated in later versions of this draft.
	4.1 Triangular routing (CN behind Firewall)		After roaming into a new network, the MN obtains a CoA in the
			visiting network. The MN registers itself with the HA. If CN is the
			data sender, it sends data to the HoA of the MN. It is routed to the
			Home Agent in a normal manner. HA encapsulates this packet and sends
			it to the MN. The MN decapsulates the packet. In the opposite
			direction, it is reverse tunneled to the Home Agent and then uses
			normal IP routing from there to the CN.
			4.1 Correspondant Node behind firewall
			If we consider the scenario of the CN being protected by a firewall,
			there is no need for any signaling if the CN initiates data traffic.
			The CN sends the data traffic and hence the SPF will store relevant
			connection information and allow the packets in the reverse
			direction.
			If MN is the DS, then the HA has to initiate signaling-D, so that the
			firewall will allow the data traffic from the HA to CN. The message
			flow is shown in Figure 5.
			Protected network
			+-------------------------+ External Mobile
			| | Node
			| +-----+ +-----+ +----+
			| | | | | | |
			| | | | | | |
			| | CN | | FW | CREATE-D | HA |
			| | +--------<-----+ +---------<----------+ |
			| |(DR) | SUCCEED | | | |
			| | +-------->-----+ +--------->----------+ |
			| | | | | | |
			| | | | | Data traffic | |
			| | +**************+ +********************+ |
			| | | | | | |
			| +-----+ +-----+ +----+
			| | #
			+-------------------------+ #
			#
			+----+
			| MN |
			|(DS)|
			***** = Data traffic (both direction) +----+
			----- = signaling traffic Correspondant node
			##### = tunneled traffic
			Figure 5: NSIS signaling for CN behind the firewall
			4.2 Mobile Node behind firewall
			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 conveyed this
			information. For this scenario, the HA is forced to do the NSIS