draft-thiruvengadam-nsis-mip6-fw-01.txt		draft-thiruvengadam-nsis-mip6-fw-02.txt
	NSIS S. Thiruvengadam		NSIS S. Thiruvengadam
	Internet-Draft H. Tschofenig		Internet-Draft H. Tschofenig
	Expires: April 23, 2005 Siemens		Expires: October 30, 2005 Siemens
	F. Le		F. Le
	Nokia		Nokia
	October 23, 2004		April 28, 2005
	Mobile IPv6 - NSIS Interaction for Firewall traversal		Mobile IPv6 - NSIS Interaction for Firewall traversal
	draft-thiruvengadam-nsis-mip6-fw-01		draft-thiruvengadam-nsis-mip6-fw-02.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is subject to all provisions		This document is an Internet-Draft and is subject to all provisions
	of section 3 of RFC 3667. By submitting this Internet-Draft, each		of Section 3 of RFC 3667. By submitting this Internet-Draft, each
	author represents that any applicable patent or other IPR claims of		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 is aware have been or will be disclosed, and any of
	which he or she become aware will be disclosed, in accordance with		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-
	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 April 23, 2005.		This Internet-Draft will expire on October 30, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004).		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
	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.
	skipping to change at page 2, line 35		skipping to change at page 2, line 36
	5.2 Mobile Node behind Firewall . . . . . . . . . . . . . . . 17		5.2 Mobile Node behind Firewall . . . . . . . . . . . . . . . 17
	5.3 Home Agent behind Firewall . . . . . . . . . . . . . . . . 18		5.3 Home Agent behind Firewall . . . . . . . . . . . . . . . . 18
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 20		6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
	8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 22		8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 22
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
	9.1 Normative References . . . . . . . . . . . . . . . . . . . . 23		9.1 Normative References . . . . . . . . . . . . . . . . . . . 23
	9.2 Informative References . . . . . . . . . . . . . . . . . . . 23		9.2 Informative References . . . . . . . . . . . . . . . . . . 23
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23
	Intellectual Property and Copyright Statements . . . . . . . . 25		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 [6]. The other		packet filtering. This problem is well described in [5]. The other
	modes of communication in Mobile IPv6 nameley bi-directional		modes of communication in Mobile IPv6 nameley bi-directional
	tunneling and triangular routing also do not work under some firewall		tunneling and triangular routing also do not work under some firewall
	placements. There is a need for identifying a signaling protocol		placements. There is a need for identifying a signaling protocol
	that can install some firewall rules to allow these Mobile IPv6		that can install some firewall rules to allow these Mobile IPv6
	messages to pass through. The NSIS NAT/FW NSLP described in [2],		messages to pass through. The NSIS NAT/FW NSLP described in [2],
	allows other protocols to establish, maintain and delete Middlebox		allows other protocols to establish, maintain and delete Middlebox
	state (NAT bindings and Firewall rules). We identify NSIS as		state (NAT bindings and Firewall rules). We identify NSIS as
	possible solution to the aforementioned problem and describe the		possible solution to the aforementioned problem and describe the
	solution in detail. For every communication mode, we will consider		solution in detail. For every communication mode, we will consider
	the application of NSIS signaling for the following simple scenarios:		the application of NSIS signaling for the following simple scenarios:
	skipping to change at page 4, line 11		skipping to change at page 4, line 11
	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 [7].		Furthermore, we use the same terminology as in [1], [2], and [6].
	Apart from this, we use some abbreviations to describe the flow-id of		Apart from this, we use some abbreviations to describe the flow-id of
	the NSIS messages: SA-Source Address, DA-Destination Address,		the NSIS messages: SA-Source Address, DA-Destination Address, SP-
	SP-Source Port, DP-Destination Port and an asterisk is used as		Source Port, DP-Destination Port and an asterisk is used as wild-
	wild-card.		card.
	3. Route Optimization		3. Route Optimization
	In this communication mode, the CN and the MN deliver packets		In this communication mode, the CN and the MN deliver packets
	directly to each other. But before this, the MN has to perform		directly to each other. But before this, the MN has to perform
	Return Routability Test (RRT), where it has to send a home test init		Return Routability Test (RRT), where it has to send a home test init
	(HoTI) message (through the HA) and a Careof test init (CoTI)		(HoTI) message (through the HA) and a Careof test init (CoTI)
	(directly) to the CN. The replies for these two messages home test		(directly) to the CN. The replies for these two messages home test
	(HoT) message (from the HA) and the Careof test (CoT) message (from		(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		the CN) are used to construct the binding-key which is used in the
	skipping to change at page 7, line 16		skipping to change at page 6, line 48
	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 NSIS assumption that the firewalls will
	allow NSIS message from external network. However, operators might		allow NSIS message from external network. However, operators might
	be reluctant to allow NSIS message from external network as this		be reluctant to allow NSIS message from external network as this
	might lead to DoS attacks. This threat assumes significant		might lead to DoS attacks. This threat assumes significant
	importance if the NR is a mobile terminal.		importance if the NR is a mobile terminal.
	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 [5].		some scenarios due to routing asymmetry concerns as explained in [4].
	+-----------------------+		+-----------------------+
	| | Home Agent		| | Home Agent
	| +-----+ +----+		| +-----+ +----+
	| | | | HA |		| | | | HA |
	| | | +----+		| | | +----+
	|+----+ | |		|+----+ | |
	|| | | | CREATE-C +----+		|| | | | CREATE-C +----+
	|| +--------<-----+ +---------<----------+ |		|| +--------<-----+ +---------<----------+ |
	|| | SUCCEED | | | |		|| | SUCCEED | | | |
	skipping to change at page 18, line 7		skipping to change at page 18, line 7
	transparent to CN. The CN is not aware of the fact that the MN is		transparent to 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		behind a firewall. The MN could also install the firewall rules in
	single firewall scenarios.		single firewall scenarios.
	For the Signaling-D CREATE message from HA to MN, the flow-id will		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		be: SA: HA, DA: MN. Note these data messages for which we do
	signaling, are IP-in-IP tunneled messages and do not have any		signaling, are IP-in-IP tunneled messages and do not have any
	transport header.		transport header.
	If the MN is the data sender, no further signaling is needed as the		If the MN is the data sender, no further signaling is needed as the
	session is initiated by the MN. The message flow is shown in Figure		session is initiated by the MN. The message flow is shown in
	9.		Figure 9.
	Network protected		Network protected
	+-------------------------+		+-------------------------+
	| | Home Agent		| | Home Agent
	| +-----+ +-----+ +----+		| +-----+ +-----+ +----+
	| | |Binding update| | | |		| | |Binding update| | | |
	| | |-------->-----+ +--------->----------+ |		| | |-------->-----+ +--------->----------+ |
	| | | | | Binding ACK | |		| | | | | Binding ACK | |
	| | |--------<-----+ +---------<----------+ |		| | |--------<-----+ +---------<----------+ |
	| | | | | CREATE-D | HA |		| | | | | CREATE-D | HA |
	skipping to change at page 18, line 46		skipping to change at page 18, line 46
	***** = Data traffic		***** = Data traffic
	##### = tunneled traffic		##### = tunneled traffic
	Figure 9: NSIS signaling for MN behind the firewall		Figure 9: NSIS signaling for MN behind the firewall
	5.3 Home Agent behind Firewall		5.3 Home Agent behind Firewall
	This is also a special case where the HA is assumed to be NSIS aware		This is also a special case where the HA is assumed to be NSIS aware
	with NSIS Responder (NR) capabilities. The CN initiates NSIS		with NSIS Responder (NR) capabilities. The CN initiates NSIS
	signaling to open pin-holes in the FW protecting the HA. Then it can		signaling to open pin-holes in the FW protecting the HA. Then it can
	send the data traffic to HoA. The message flow is shown in Figure		send the data traffic to HoA. The message flow is shown in
	10.		Figure 10.
	For the Signaling-D CREATE message from HA to MN, the flow-id will		For the Signaling-D CREATE message from HA to MN, the flow-id will
	be: SA: CN, DA: HoA, SP: Data application port, DP: Data application		be: SA: CN, DA: HoA, SP: Data application port, DP: Data application
	port.		port.
	+------------------------+		+------------------------+
	| |		| |
	| +----+ +-----+		| +----+ +-----+
	| | | | | CREATE +----+		| | | | | CREATE +----+
	| | +--------<-----+ +---------<---------+ |		| | +--------<-----+ +---------<---------+ |
	skipping to change at page 20, line 9		skipping to change at page 20, line 9
	----- = signaling traffic		----- = signaling traffic
	***** = Data traffic		***** = Data traffic
	##### = tunneled traffic		##### = tunneled traffic
	Figure 10: NSIS signaling for HA behind the firewall		Figure 10: NSIS signaling for HA behind the firewall
	6. Security Considerations		6. Security Considerations
	The NAT/FW NSLP is in itself a very security sensitive service. A		The NAT/FW NSLP is in itself a very security sensitive service. A
	detailed description of possible threats and counter measures are		detailed description of possible threats and counter measures are
	described in [4]. In addition to that, the prospect of DoS when		described in [2]. In addition to that, the prospect of DoS when
	firewalls allow all NSIS signaling messages is dealt with in this		firewalls allow all NSIS signaling messages is dealt with in this
	draft.		draft.
	7. Acknowledgements		7. Acknowledgements
	Many parts of this documents are the result of some discussions		Many parts of this documents are the result of some discussions
	within the NAT/firewall-NSLP-team including: Marcus Brunner, Miquel		within the NAT/firewall-NSLP-team including: Marcus Brunner, Miquel
	Martin, Martin Stiemerling, and Cedric Aoun.		Martin, Martin Stiemerling, and Cedric Aoun.
	8. Open Issues		8. Open Issues
	skipping to change at page 22, line 8		skipping to change at page 22, line 8
	7. Acknowledgements		7. Acknowledgements
	Many parts of this documents are the result of some discussions		Many parts of this documents are the result of some discussions
	within the NAT/firewall-NSLP-team including: Marcus Brunner, Miquel		within the NAT/firewall-NSLP-team including: Marcus Brunner, Miquel
	Martin, Martin Stiemerling, and Cedric Aoun.		Martin, Martin Stiemerling, and Cedric Aoun.
	8. Open Issues		8. Open Issues
	o Do we need to combine Signaling-C and Signaling-D?		o Do we need to combine Signaling-C and Signaling-D?
	o The timing of the HA-MN signaling i.e., when the HA should signal		o The timing of the HA-MN signaling i.e., when the HA should signal
	to the MN behind the firewall.		to the MN behind the firewall.
	9. References		9. References
	9.1 Normative References		9.1 Normative References
	[1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in		[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
	IPv6", RFC 3775, June 2004.		IPv6", RFC 3775, June 2004.
	[2] Stiemerling, M., "A NAT/Firewall NSIS Signaling Layer Protocol		[2] Stiemerling, M., "A NAT/Firewall NSIS Signaling Layer Protocol
	(NSLP)", draft-ietf-nsis-nslp-natfw-03 (work in progress), July		(NSLP)", draft-ietf-nsis-nslp-natfw-05 (work in progress),
	2004.		February 2005.
	[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", March 1997.		Levels", March 1997.
	9.2 Informative References		9.2 Informative References
	[4] Fessi, A., "Security Threats for the NAT/Firewall NSLP",		[4] Tschofenig, H., "Path-coupled NAT/Firewall Signaling Security
	draft-fessi-nsis-natfw-threats-01 (work in progress), July 2004.
	[5] Tschofenig, H., "Path-coupled NAT/Firewall Signaling Security
	Problems", draft-tschofenig-nsis-natfw-security-problems-00		Problems", draft-tschofenig-nsis-natfw-security-problems-00
	(work in progress), July 2004.		(work in progress), July 2004.
	[6] Le, F., "Mobile IPv6 and Firewalls Problem statement",		[5] Le, F., "Mobile IPv6 and Firewalls Problem statement",
	draft-ietf-mip6-firewalls-00 (work in progress), August 2004.		draft-ietf-mip6-firewalls-01 (work in progress), February 2005.
	[7] Brunner, M., "Requirements for Signaling Protocols", RFC 3726,		[6] Brunner, M., "Requirements for Signaling Protocols", RFC 3726,
	April 2004.		April 2004.
	Authors' Addresses		Authors' Addresses
	Srinath Thiruvengadam		Srinath Thiruvengadam
	Siemens		Siemens
	Otto-Hahn-Ring 6		Otto-Hahn-Ring 6
	Munich, Bayern 81739		Munich, Bavaria 81739
	Germany		Germany
	EMail: srinath@mytum.de		Email: srinath@mytum.de
	Hannes Tschofenig		Hannes Tschofenig
	Siemens		Siemens
	Otto-Hahn-Ring 6		Otto-Hahn-Ring 6
	Munich, Bayern 81739		Munich, Bavaria 81739
	Germany		Germany
	EMail: Hannes.Tschofenig@siemens.com		Email: Hannes.Tschofenig@siemens.com
	Franck Le		Franck Le
	Nokia Research Center		Nokia Research Center
	6000 Connection Drive, Irving		6000 Connection Drive, Irving
	Dallas, Texas 75063		Dallas, Texas 75063
	USA		USA
	EMail: franck.le@nokia.com		Email: franck.le@nokia.com
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	skipping to change at page 25, line 41		skipping to change at page 25, line 41
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Copyright Statement		Copyright Statement
	Copyright (C) The Internet Society (2004). This document is subject		Copyright (C) The Internet Society (2005). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and		to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.		except as set forth therein, the authors retain all their rights.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes. 27 change blocks.
	37 lines changed or deleted		35 lines changed or added
This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/