< draft-fessi-nsis-natfw-threats-00.txt		draft-fessi-nsis-natfw-threats-01.txt >
	NSIS A. Fessi		NSIS A. Fessi
	Internet-Draft M. Stiemerling		Internet-Draft M. Stiemerling
	Expires: November 23, 2004 NEC		Expires: January 14, 2005 NEC
	S. Thiruvengadam		S. Thiruvengadam
	H. Tschofenig		H. Tschofenig
	Siemens		Siemens
	May 25, 2004		C. Aoun
			Nortel Networks
			July 16, 2004
	Security Threats for the NAT/Firewall NSLP		Security Threats for the NATFW NSLP
	draft-fessi-nsis-natfw-threats-00		draft-fessi-nsis-natfw-threats-01
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is subject to all provisions
	all provisions of Section 10 of RFC2026.		of section 3 of RFC 3667. By submitting this Internet-Draft, each
			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.
	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://
	http://www.ietf.org/ietf/1id-abstracts.txt.		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 November 23, 2004.		This Internet-Draft will expire on January 14, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	Abstract		Abstract
	Opening a firewall pinhole or creating a NAT binding is a very		Opening a firewall pinhole or creating a NAT binding is a very
	security sensitive issue. This memo identifies different security		security sensitive issue. This memo identifies security threats and
	threats that need to be addressed for the NAT/firewall NSLP. Generic		security requirements that need to be addressed for the NATFW NSLP.
	security threats to the NSIS protocols have been already discussed in		Generic security threats to the NSIS protocols have been already
	the NSIS Working Group. This security threats documents is		discussed in the NSIS Working Group.
	specicific to NAT/firewall NSLP.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Attacks related to authentication and authorization . . . . . 5
			3. Attacks related to authentication and authorization . . . . . 4
	3.1 Data Sender (DS) behind a firewall . . . . . . . . . . . . 6		3.1 Data Sender (DS) behind a firewall . . . . . . . . . . . . 6
	3.2 Data Sender (DS) behind a NAT . . . . . . . . . . . . . . 7		3.2 Data Sender (DS) behind a NAT . . . . . . . . . . . . . . 7
	3.3 Data Receiver (DR) behind a firewall . . . . . . . . . . . 7		3.3 Data Receiver (DR) behind a firewall . . . . . . . . . . . 7
	3.4 Data Receiver (DR) behind a NAT . . . . . . . . . . . . . 9		3.4 Data Receiver (DR) behind a NAT . . . . . . . . . . . . . 9
	4. Denial-of-Service Attacks . . . . . . . . . . . . . . . . . . 11		4. Denial-of-Service Attacks . . . . . . . . . . . . . . . . . . 11
	4.1 Flooding with 'create session' messages from outside . . . 11		4.1 Flooding with CREATE messages from outside . . . . . . . . 11
	4.1.1 Attacks due to NSLP state . . . . . . . . . . . . . . 11		4.1.1 Attacks due to NSLP state . . . . . . . . . . . . . . 11
	4.1.2 Attacks due to authentication complexity . . . . . . . 11		4.1.2 Attacks due to authentication complexity . . . . . . . 11
	4.1.3 Attacks to the NTLP . . . . . . . . . . . . . . . . . 11		4.1.3 Attacks to the endpoints . . . . . . . . . . . . . . . 11
	4.2 Flooding with 'reserve' messages from inside . . . . . . . 11		4.1.4 Attacks to the NTLP . . . . . . . . . . . . . . . . . 12
			4.2 Flooding with REA messages from inside . . . . . . . . . . 12
	5. Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . . . 12		5. Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . . . 12
	6. Message Modification . . . . . . . . . . . . . . . . . . . . . 13		6. Message Modification . . . . . . . . . . . . . . . . . . . . . 13
	7. Session Invalidation . . . . . . . . . . . . . . . . . . . . . 14
	8. Session Modification . . . . . . . . . . . . . . . . . . . . . 15		7. Session Modification/Deletion . . . . . . . . . . . . . . . . 14
	9. Misuse of unreleased sessions . . . . . . . . . . . . . . . . 17
	10. Data traffic injection . . . . . . . . . . . . . . . . . . . 18		8. Misuse of unreleased sessions . . . . . . . . . . . . . . . . 15
	11. Misuse of mobility in NAT handling . . . . . . . . . . . . . 19
	12. Eavesdropping and traffic analysis . . . . . . . . . . . . . 21		9. Data traffic injection . . . . . . . . . . . . . . . . . . . . 17
	13. Security Considerations . . . . . . . . . . . . . . . . . . 22
	14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23		10. Misuse of mobility in NAT handling . . . . . . . . . . . . . 18
	15. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
	15.1 Normative References . . . . . . . . . . . . . . . . . . . . 24		11. Eavesdropping and traffic analysis . . . . . . . . . . . . . 20
	15.2 Informative References . . . . . . . . . . . . . . . . . . . 24
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25		12. Security Considerations . . . . . . . . . . . . . . . . . . 21
	A. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
	Intellectual Property and Copyright Statements . . . . . . . . 27		13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 21
			14. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
			14.1 Normative References . . . . . . . . . . . . . . . . . . . . 21
			14.2 Informative References . . . . . . . . . . . . . . . . . . . 21
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22
			Intellectual Property and Copyright Statements . . . . . . . . 24
	1. Introduction		1. Introduction
	This document provides an analysis of the security threats that are		This document provides an analysis of the security threats that are
	specific for the NAT/firewall NSLP. The NAT/firewall NSLP is used to		specific for the NATFW NSLP. The NATFW NSLP is used to install the
	install the required policy rules (firewall pinhole and/or NAT		required policy rules (firewall pinhole and/or NAT binding) on
	binding) on the middleboxes along the path to allow the traversal of		middleboxes along the path to allow the traversal of a data flow.
	a data flow.
	Opening a pinhole in the firewall or creating a NAT binding is a very		Opening a pinhole in the firewall or creating a NAT binding is a very
	security sensitive issue. Thus, we need to examine carefully who is		security sensitive issue. Thus, we need to examine carefully who is
	allowed to install these policy rules and what security threats need		allowed to install these policy rules and what security threats need
	to be addressed. In this document we will analyze different types of		to be addressed. In this document we will analyze different types of
	possible attacks to networks running NSIS for middlebox		possible attacks to networks running NSIS for middlebox
	configuration.		configuration.
	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 [5].		document are to be interpreted as described in [5].
	Furtheremore, we use the same terminology as in [1], [3] and [4].		Furthermore, we use the same terminology as in [1], [3] and [4].
	3. Attacks related to authentication and authorization		3. Attacks related to authentication and authorization
	As described in [1] the NSIS message to install policy rules at a		As described in [1] the NSIS message which installs policy rules at a
	middlebox is the 'create session' message. The 'create session'		middlebox is the CREATE message. The CREATE message travels from the
	message travels from the Data Sender (DS) towards the Data Receiver		Data Sender (DS) toward the Data Receiver (DR). The packet filter or
	(DR). The packet filter or NAT binding is marked as pending by the		NAT binding is marked as pending by the middleboxes along the path.
	middleboxes along the path. If it is confirmed with a 'path		If it is confirmed with a success RESPONSE message from the DR the
	succeeded' message from the DR the requested policy rules on the		requested policy rules on the middleboxes are installed to allow the
	middleboxes are installed to allow the traversal of a data flow.		traversal of a data flow.
	+-----+ +-----+ +-----+		+-----+ +-----+ +-----+
	| DS | | MB | | DR |		| DS | | MB | | DR |
	+-----+ +-----+ +-----+		+-----+ +-----+ +-----+
	| | |		| | |
	| Create | Create |		| CREATE | CREATE |
	|-------------------->+-------------------->|		|-------------------->+-------------------->|
	| | |		| | |
	| Succeeded/Error | Succeeded/Error |		| Succeeded/Error | Succeeded/Error |
	|<--------------------+<--------------------|		|<--------------------+<--------------------|
	| | |		| | |
	==========================================>		==========================================>
	Direction of data traffic		Direction of data traffic
	Figure 1: CREATE Mode		Figure 1: CREATE Mode
	In this section we will consider some simple scenarios for middlebox		In this section we will consider some simple scenarios for middlebox
	configuration:		configuration:
	o Data Sender (DS) behind a firewall		o Data Sender (DS) behind a firewall
	o Data Sender (DS) behind a NAT		o Data Sender (DS) behind a NAT
	o Data Receiver (DR) behind a firewall		o Data Receiver (DR) behind a firewall
	o Data Receiver (DR) behind a NAT		o Data Receiver (DR) behind a NAT
	A real scenario could include a combination of one or more cases		A real scenario could include a combination of one or more cases
	together i.e. DS and/or DR is behind a chain of NATs and firewalls.		together, i.e., DS and/or DR is behind a chain of NATs and firewalls.
	Figure 2 shows such a possible scenario:		Figure 2 shows such a possible scenario:
	+-------------------+ +--------------------+		+-------------------+ +--------------------+
	| | | |		| | | |
	| Network A | | Network B |		| Network A | | Network B |
	| | | |		| | | |
	| +-----+ | //-----\\ | +-----+ |		| +-----+ | //-----\\ | +-----+ |
	| | MB2 |--------+----| INET |----+--------| MB3 | |		| | MB2 |--------+----| INET |----+--------| MB3 | |
	| +-----+ | \\-----// | +-----+ |		| +-----+ | \\-----// | +-----+ |
	| | | | | |		| | | | | |
	skipping to change at page 6, line 41 ¶		skipping to change at page 6, line 41 ¶
	+------------------------------+		+------------------------------+
	| |		| |
	| +-----+ create +-----+		| +-----+ create +-----+
	| | DS | --------------> | FW |		| | DS | --------------> | FW |
	| +-----+ +-----+		| +-----+ +-----+
	| |		| |
	+------------------------------+		+------------------------------+
	Figure 3: DS behind a firewall		Figure 3: DS behind a firewall
	DS sends a 'create session' message to request the traversal of a		DS sends a CREATE message to request the traversal of a data flow.
	data flow.
	It is up to network operators to decide how far they can trust users		It is up to network operators to decide how far they can trust users
	inside their networks. However there are several reasons why they		inside their networks. However, there are several reasons why they
	should not. We list some of them in Appendix A.		should not.
	As already mentiened in [1] Section (3.2.1), the middlebox MUST first		The following attacks are possible:
	check authentication and authorization before any further processing
	is executed. Otherwise, following kind of attacks are possible:
	o DS could open a firewall pinhole with a source address different		o DS could open a firewall pinhole with a source address different
	from its own host.		from its own host.
	o DS could open firewall pinholes for incoming data flows that are		o DS could open firewall pinholes for incoming data flows that are
	not supposed to enter the network.		not supposed to enter the network.
	o DS could request installing any policy rules and allow all traffic
	go through.		o DS could request installation of any policy rules and allow all
			traffic go through.
			SECURITY REQUIREMENT: As already mentioned in [1] Section (3.2), the
			middlebox MUST authenticate and authorize the neighboring NAT/FW NSLP
			node which requests an action. Authentication and authorization of
			the initiator SHOULD be provided to NATs and Firewalls along the path
			as motivated with Section 2.2.3 of [1].
	3.2 Data Sender (DS) behind a NAT		3.2 Data Sender (DS) behind a NAT
	The case 'DS behind a NAT' is analogous to the case 'DS behind a		The case 'DS behind a NAT' is analogous to the case 'DS behind a
	firewall'.		firewall'.
	It is worth mentioning that authentication based on IP address is not		It is worth mentioning that authentication based on IP address is not
	possible if NATs are deployed. Figure 4 illustrates such a scenario:		possible if NATs are deployed. Figure 4 illustrates such a scenario:
	+------------------------------+		+------------------------------+
	| |		| |
	| +------+ create |		| +------+ CREATE |
	| | NI_1 | ------\ +-----+ create +-----+		| | NI_1 | ------\ +-----+ CREATE +-----+
	| +------+ \------> | NAT | -----------> | MB |		| +------+ \------> | NAT |-------->| MB |
	| +-----+ +-----+		| +-----+ +-----+
	| +------+ |		| +------+ |
	| | NI_2 | |		| | NI_2 | |
	| +------+ |		| +------+ |
	+------------------------------+		+------------------------------+
	Figure 4: Several NIs behind a NAT		Figure 4: Several NIs behind a NAT
	In this case the middlebox MB does not know who is the NSIS Initiator		In this case the middlebox MB does not know who is the NSIS Initiator
	since both NI_1 and NI_2 are behind a NAT. Authentication needs to		since both NI_1 and NI_2 are behind a NAT. Authentication needs to
	be provided by an other mean such as the NSLP or the application		be provided by other means such as the NSLP or the application layer.
	layer.
			SECURITY REQUIREMENT: The middlebox MUST authenticate and ensure that
			the neighboring NAT/FW NSLP node is authorized to request an action.
			Authentication and authorization of the initiator (which is the DR in
			this scenario) MAY be provided to the middleboxes.
	3.3 Data Receiver (DR) behind a firewall		3.3 Data Receiver (DR) behind a firewall
	In this case a 'create session' message is coming from an entity DS		In this case a CREATE message comes from an entity DS outside the
	outside the network towards DR inside the network.		network towards the DR inside the network.
	+------------------------------+		+------------------------------+
	| |		| |
	+-----+ create +-----+ create +-----+ |		+-----+ CREATE +-----+ CREATE +-----+ |
	| DS | -------------> | FW | -------------> | DR | |		| DS | -------------> | FW | -------------> | DR | |
	+-----+ <------------- +-----+ <------------- +-----+ |		+-----+ <------------- +-----+ <------------- +-----+ |
	path succeeded | path succeeded |		success RESPONSE | success RESPONSE |
	| |		| |
	+------------------------------+		+------------------------------+
	Figure 5: DR behind a firewall		Figure 5: DR behind a firewall
	According to [1] (Section 3.2.1) "Policy rules at middleboxes MUST be		According to [1] (Section 3.3) "Policy rules at middleboxes MUST be
	only installed upon receiving a successful response of type 'path		only installed upon receiving a successful response of type success
	succeeded'".		RESPONSE".
	This means that the middlebox waits until the Data Receiver DR		This means that the middlebox waits until the Data Receiver DR
	confirms the request of the Data Sender DS with a 'path succeeded'		confirms the request of the Data Sender DS with a success RESPONSE
	message.		message. This is, however, only necessary
			o if the policy rule creation/deletion/update at a firewall along
			the path cannot be authorized and
			o if the middlebox is still forwarding the signaling message towards
			the end host (without state creation/deletion/modification).
	This confirmation implicates that DR is expecting the data flow.		This confirmation implies that the data receiver is expecting the
			data flow.
	At this point we differentiate 2 cases:		At this point we differentiate 2 cases:
	1. DR knows the IP address of the DS (for instance because of some		1. DR knows the IP address of the DS (for instance because of some
	previous application layer signaling) and is expecting the data		previous application layer signaling) and is expecting the data
	flow.		flow.
	2. DR might be expecting the data flow (for instance because of some		2. DR might be expecting the data flow (for instance because of some
	previous application layer signaling) but does not know the IP		previous application layer signaling) but does not know the IP
	address of the Data Sender DS.		address of the Data Sender DS.
	For the second case, Figure 6 illustrates a possible attack: an		For the second case, Figure 6 illustrates a possible attack: an
	adversary Mallory could be sniffing the application layer signaling		adversary Mallory M could be sniffing the application layer signaling
	and thus knows the address and port number where DR is excepting the		and thus knows the address and port number where DR is expecting the
	data flow. Thus it could pretend to be DS and send a 'create		data flow. Thus it could pretend to be DS and send a CREATE message
	session' message towards DR with the data flow description (M -> DR).		towards DR with the data flow description (M -> DR). Since DR does
	Since DR does not know the IP address of DS, it is not able to		not know the IP address of DS, it is not able to recognize that the
	recognize that the request is coming from the "wrong guy". It will		request is coming from the "wrong guy". It will send a success
	send a 'path succeeded' message back and the middlebox will install		RESPONSE message back and the middlebox will install policy rules
	policy rules that will allow Mallory to inject its data into the		that will allow Mallory M to inject its data into the network.
	network.
	Application Layer signaling		Application Layer signaling
	<------------------------------------>		<------------------------------------>
	/ \		/ \
	/ +-----------------\------------+		/ +-----------------\------------+
	/ | \ |		/ | \ |
	+-----+ +-----+ +-----+ |		+-----+ +-----+ +-----+ |
	| DS | -> | FW | | DR | |		| DS | -> | FW | | DR | |
	+-----+ / +-----+ +-----+ |		+-----+ / +-----+ +-----+ |
	create / | |		CREATE / | |
	+-----+ / +-------------------------------+		+-----+ / +-------------------------------+
	| M |----------		| M |----------
	+-----+		+-----+
	Figure 6: DR behind a firewall with an adversary		Figure 6: DR behind a firewall with an adversary
	In real networks, operators will probably not rely on DR if it checks		Network administrators will probably not rely on a DR to check the IP
	the IP address of the DS correctly. Thus we have to assume the worst		address of the DS. Thus we have to assume the worst case with an
	case with an attack such as in Figure 6.		attack such as in Figure 6. Many operators might not allow NSIS
			signaling message to traverse the firewall in Figure 6 without proper
			authorization. In this case the threat is not applicable.
	3.4 Data Receiver (DR) behind a NAT		SECURITY REQUIREMENT: A binding between the application layer and the
			NSIS signaling SHOULD be provided.
	Reminder to the NAT handling solution:		3.4 Data Receiver (DR) behind a NAT
	We will describe briefly the NSIS message flow required here to		We will describe briefly the NSIS message flow that takes place to
	install to necessary rules for the traversal of a data flow from DS		install the necessary rules for the traversal of a data flow from DS
	towards DR. For detailed description please refer to [1] Section		towards DR. For detailed description please refer to [1] Section
	3.2.2.		3.3.
	DR sends a 'reserve external address' message to get itself a		DR sends a RESERVE-EXTERNAL-ADDRESS (REA) message to get a public
	publicly reachable address. The NAT reserves an external address and		reachable address that can be used by potential DSs. The NAT
	port number and sends them back to DR. The NAT adds an entry in its		reserves an external address and port number and sends them back to
	reservation list which looks as follow:		DR. The NAT adds an address mapping entry in its reservation list
			which links the public and private addresses as follows:
	(DR_ext <=> DR_int) (*).		(DR_ext <=> DR_int) (*).
	The NAT sends a 'return external address' message back to DR with the		The NAT sends a RESPONSE message with 'return external address'
	address DR_ext. DR informs DS about the public address that it has		object back to the DR with the address DR_ext. DR informs DS about
	recently received (for instance by some application layer signaling).		the public address that it has recently received, for instance, by
			means of application layer signaling.
	Now DS sends the 'create session' message towards DS_ext. When the		Now DS sends the CREATE message towards DR_ext. When the 'create
	'create session' message arrives at the NAT, the NAT looks up its		session' message arrives at the NAT, the NAT looks up its reservation
	reservation list and finds the entry (*).		list and finds the entry (*).
	Now the NAT knows the address of DS and stores it as a part of the		Now the NAT knows the address of DS and stores it as a part of the
	policy rule to be loaded. It forwards the message towards DR and		policy rule to be loaded. It forwards the message towards DR and
	waits for the confirmation with the 'path succeeded' message.		waits for the confirmation with the success RESPONSE message.
	At the arrival of the 'path succeeded' message from DR, the NAT		At the arrival of the success RESPONSE message from DR, the NAT
	installs the policy rule to forward the data flow correctly from DS		installs the policy rule to forward the data flow correctly from DS
	to DR.		to DR.
	Possible attack:		Possible attack:
	If DS is not correctly authenticated, an attacker Mallory could send		We assume that the adversary obtains the external address allocated
	a 'create session' message to install a NAT binding to forward the		at the NAT (possibly by eavesdropping on the application layer
	data flow from M to DR instead of from DS to DR. This kind of attack		signaling) and triggers the CREATE message before the NAT binding
	is equivalent to the attack described in Section 3.3 above.		expires. The CREATE message is assumed to travel from DS to DR
			through NAT. An attacker Mallory M could send a CREATE message to
			install a NAT binding to forward the data flow from M to DR instead
			of from DS to DR. This kind of attack is equivalent to the attack
			described in Section 3.3 above.
			In order for this attack to work the following pre-requisities need
			to hold:
			The adversary needs to be authorized to create a NAT binding at
			the NAT.
			The adversary needs to know when a DR creates a NAT binding at the
			DR. A certain timing is required and some specific information,
			such as the message routing identifier and session identifier must
			be known
	Application Layer signaling		Application Layer signaling
	<------------------------------------>		<------------------------------------>
	/ \		/ \
	/ +-----------------\------------+		/ +-----------------\------------+
	/ | reserve \ |		/ | REA \ |
	+-----+ +-----+ <----------- +-----+ |		+-----+ +-----+ <----------- +-----+ |
	| DS | -> | NAT | -----------> | DR | |		| DS | -> | NAT | -----------> | DR | |
	+-----+ / +-----+ rtn_ext_addr +-----+ |		+-----+ / +-----+ rtn_ext_addr +-----+ |
	create / | |		CREATE / | |
	+-----+ / +-------------------------------+		+-----+ / +-------------------------------+
	| M |----------		| M |----------
	+-----+		+-----+
	Figure 7: DR behind a NAT with an adversary		Figure 7: DR behind a NAT with an adversary
			SECURITY REQUIREMENT: TBD
	4. Denial-of-Service Attacks		4. Denial-of-Service Attacks
	In this section we describe several ways how an adversary could		In this section we describe several ways how an adversary could
	launch a DoS attack to networks running NSIS for middlebox		launch a Denial of service (DoS) attack on networks running NSIS for
	configuration to exhaust their resources.		middlebox configuration to exhaust their resources.
	4.1 Flooding with 'create session' messages from outside		4.1 Flooding with CREATE messages from outside
	4.1.1 Attacks due to NSLP state		4.1.1 Attacks due to NSLP state
	A 'create session' message requests the NSLP to store some state		A CREATE message requests the NSLP to store some state information
	information such as Session-ID and flow identifier.		such as Session-ID and flow identifier.
	The policy rules requested in the 'create session' message will be		The policy rules requested in the CREATE message will be installed at
	installed at the arrival of a confirmation from the Data Receiver		the arrival of a confirmation from the Data Receiver with a success
	with a 'path succeeded' message. The 'path succeeded' message		RESPONSE message. The success RESPONSE message includes the session
	includes the session ID. So the NSLP looks up the NSIS session and		ID. So the NSLP looks up the NSIS session and installs the requested
	installs the requested policy rules.		policy rules.
	An adversary from outside could launch a DoS attack with arbitrary		An adversary from outside could launch a DoS attack with arbitrary
	'create session' messages. For each of these messages the middlebox		CREATE messages. For each of these messages the middlebox needs to
	needs to store state information such as the policy rules to be		store state information such as the policy rules to be loaded, i.e.,
	loaded, i.e. the middlebox could run out of memory.		the middlebox could run out of memory. This kind of attack is also
			mentioned in [2] Section 4.8.
			SECURITY REQUIREMENT: A NAT/FW NSLP node MUST authorize the
			'create-session' message before storing state information.
	4.1.2 Attacks due to authentication complexity		4.1.2 Attacks due to authentication complexity
	This kind of attack is possible if authentication is based on		This kind of attack is possible if authentication is based on
	mechanisms that require computing power e.g. digital signatures.		mechanisms that require computing power, for example, digital
			signatures.
	4.1.3 Attacks to the NTLP		For a more detailed treatment of this kind of attack, the reader is
			encouraged to see [2].
	Flooding a middlebox with 'create session' messages affects also the		SECURITY REQUIREMENT: A NAT/FW NSLP node MUST NOT introduce new
	NTLP.		denial of service attacks based on authentication or key management
			mechanisms.
	The 'path succeeded' message needs to take the same route as the		4.1.3 Attacks to the endpoints
	previous 'create session' message. Thus the NTLP needs to store
	routing information for each 'create session' message. This kind of
	attack is also described in [2] Section 4.8.
	4.2 Flooding with 'reserve' messages from inside		The NATFW NSLP requires firewalls to forward NSLP messages, a
			malicious node may keep sending NSLP messages to a target. This may
			consume the access network resources of the victim, drain the battery
			of the victim's terminal and may force the victim to pay for the
			received although undesired data.
			This threat may be more particularly be relevant in networks where
			access link is a limited resource, for instance in cellular networks,
			and where the terminal capacities are limited.
			SECURITY REQUIREMENT: A NATFW NSLP aware firewall or NAT MUST be able
			to block unauthorized signaling message, if this threat is a concern.
			4.1.4 Attacks to the NTLP
			Flooding a middlebox with CREATE messages affects also the NTLP.
			The success RESPONSE message needs to take the same route as the
			previous CREATE message. Thus the NTLP needs to store routing
			information for each CREATE message. This kind of attack is also
			described in [2] Section 4.8.
			SECURITY REQUIREMENT: A NAT/FW NSLP node MUST NOT introduce new
			denial of service attacks based on authentication or key management
			mechanisms.
			4.2 Flooding with REA messages from inside
	Although we are more concerned with possible attacks from outside the		Although we are more concerned with possible attacks from outside the
	network, we need also to consider possible attacks from inside the		network, we need also to consider possible attacks from inside the
	network.		network.
	An adversary inside the network could send arbitrary 'reserve'		An adversary inside the network could send arbitrary
	messages. At a certain point the NAT will run out of port numbers		RESERVE-EXTERNAL-ADDRESS messages. At a certain point the NAT will
	and the access for other users to the outside will be disabled.		run out of port numbers and the access for other users to the outside
			will be disabled.
			SECURITY REQUIREMENT: The NAT/FW NSLP node MUST authorize state
			creation for the RESERVE-EXTERNAL-ADDRESS message. Furthermore, the
			NAT/FW NSLP implementation MUST prevent denial of service attacks
			involving the allocation of an arbitrary number of NAT bindings or
			the installation of a large number of packet filters.
	5. Man-in-the-Middle Attacks		5. Man-in-the-Middle Attacks
	Figure 8 illustrates a possible man-in-the-middle attack using the		Figure 8 illustrates a possible man-in-the-middle attack using the
	'reserve external address' message. This message travels from DR		'reserve external address' (REA) message. This message travels from
	towards the public Internet. The message might be not intercepted by		DR towards the public Internet. The message might not be intercepted
	any NAT (either because there are no NATs or because there are only		by any NAT either because there are no NATs or because there are NSIS
	NSIS unaware NATs).		unaware.
	In this case the 'reserve external address' message might be caught		Mallory M returns a faked RESPONSE message with an IP address of its
	by an adversary Mallory that sends back a 'return external address'		choosing. This IP address is meant to be used by the DR as the
	message with its own address. As a consequence DR will think that		public external IP address. Malory might insert it own IP address in
	the address of Mallory is its public address and will inform DS about		the response, the IP address of a third party or the address of a
	it. DS will send the data traffic to Mallory.		black hole. In the first case, the DR thinks that the address of
			Mallory M is its public address and will inform the DS about it. As
			a consequence, the DS will send the data traffic to Mallory M.
	The data traffic from DS to DR will re-directed to Mallory. Mallory		The data traffic from the DS to the DR will re-directed to Mallory M.
	will be able to read, modify or block the data traffic.		Mallory M will be able to read, modify or block the data traffic.
			Eavesdropping and modification is only possible if the data traffic
			is itself unprotected.
	+-----+ +-----+ +-----+ +-----+		+-----+ +-----+ +-----+ +-----+
	| DS | | M | | FW | | DR |		| DS | | M | | FW | | DR |
	+-----+ +-----+ +-----+ +-----+		+-----+ +-----+ +-----+ +-----+
	| | | |		| | | |
	| | reserve | reserve |		| | REA | REA |
	| | <------------------ | <------------ |		| | <------------------ | <------------ |
	| | | |		| | | |
	| | ret_ext_addr | ret_ext_addr |		| | ret_ext_addr | ret_ext_addr |
	| | ------------------> | ------------> |		| | ------------------> | ------------> |
	| | | |		| | | |
	| data traffic | | |		| data traffic | | |
	|===============>| data traffic |		|===============>| data traffic |
	| |===================================> |		| |===================================> |
	Figure 8: Man in the middle attack using the 'reserve' message'		Figure 8: MITM attack using the RESERVE-EXTERNAL-ADDRESS message
	6. Message Modification		Please note that the NSIS aware firewall in Figure 8 might not be
			present when DR communicates directly with the adversary.
	Any NSIS node along the path to the destination could easily modify,		SECURITY REQUIREMENT: Mutual authentication between neighboring NATFW
	inject or just drop an NSIS message.		NSLP MUST be provided. To ensure that only legitimate nodes along
			the path act as NSIS entities the initiator MUST authorize the
			responder. In the example in Figure 8 the firewall FW must perform
			an authorization with the neighboring entities.
	Message modification could allow a malicious user for instance to		6. Message Modification
	open a pinhole for its advantage.
	If message integrity is not provided, any malicious node along the		Any on-path subverted node en route to the destination could easily
	path to the destination could hijack or disrupt the communication.		modify, inject or just drop an NSIS message. It could also hijack or
			disrupt the communication.
	Note however that message integrity is not an obvious issue, since		SECURITY REQUIREMENT: Message integrity, replay protection and data
	NSIS nodes are supposed to modify NSIS messages according to the		origin authentication between neighboring NAT/FW NSLPs MUST be
	protocol specification, which breaks end-to-end message integrity.		provided.
	For example:
			Message modification by a subverted NSIS node could create arbitrary
			pinholes or NAT bindigs. For example:
	o NATs need to modify the source/destination of the data flow in the		o NATs need to modify the source/destination of the data flow in the
	'create session' message.		'create session' message.
	o Each middlebox along the path may change the requested lifetime in		o Each middlebox along the path may change the requested lifetime in
	the 'create session' message to fit their needs and/or local		the CREATE message to fit their needs and/or local policy (see
	policy (See also [1] section 3.2.7: Calculation of Lifetimes)		also section 3.2.7 of [1] with regard to calculation of refresh
			interval).
	7. Session Invalidation
	A malicious NSIS node could tear down an existing valid session by		SECURITY REQUIREMENT: None. Malicous NSIS NATs and Firewalls will
	using the delete session message.		not be addressed.
	8. Session Modification		7. Session Modification/Deletion
	The Session ID is included in signaling messages as a reference to		The Session ID is included in signaling messages as a reference to
	the established state. If an adversary is able to obtain the Session		the established state. If an adversary is able to obtain the Session
	Identifier for example by eavesdropping signaling messages, it would		Identifier for example by eavesdropping on signaling messages, it
	be able to add the same Session Identifier to a new a signaling		would be able to add the same Session Identifier to a new a signaling
	message and effect some modifications.		message and effect some modifications.
	Consider the scenario described in Figure 9. The signalling messages		Consider the scenario described in Figure 9. Here an adversary
	start from the DS and goes through a series of routers towards the		pretends to be 'DS in mobility'. The signaling messages start from
	DR. We assume that an off-path adversary is connected to one of the		the DS and go through a series of routers towards the DR. We assume
	routers along the path (here Router 3). We also assume that the		that an off-path adversary is connected to one of the routers along
	adversary knows the Session ID of the NSIS session initiated by the		the old path (here Router 3). We also assume that the adversary
	DS. Knowing the Session-ID, the adversary now sends signalling		knows the Session ID of the NSIS session initiated by the DS.
	messages towards the DR. When the signaling message hits Router3		Knowing the Session ID, the adversary now sends signalling messages
	then existing state information can be modified. The adversary can		towards the DR. When the signaling message reaches Router3 then
	modify or delete the established reservation causing unexpected		existing state information can be modified or even deleted. The
	behavior to the legitimate user. The source of the problem is that		adversary can modify or delete the established reservation causing
	the Router 3 (cross-over router) is unable to decide whether the new		unexpected behavior for the legitimate user. The source of the
	signaling message was initiated from the owner of the session. In		problem is that the Router 3 (cross-over router) is unable to decide
	this scenario, the adversary need not even be located in the DS-DR		whether the new signaling message was initiated from the owner of the
	path. This problem and the solution approaches are described in more		session. In this scenario, the adversary need not even be located in
	detail in [6].		the DS-DR path. This problem and the solution approaches are
			described in more detail in [6].
	Session ID(SID-x)		Session ID(SID-x)
	+--------+ +--------+		+--------+ +--------+
	+-------->--------+ Router +------------>+ DR |		+-------->--------+ Router +-------->+ DR |
	Session ID(SID-x)| | 4 | | |		Session ID(SID-x)| | 4 | | |
	+---+----+ +--------+ +--------+		+---+----+ +--------+ +--------+
	| Router |		| Router |
	+------+ 3 +*******		+------+ 3 +*******
	| +---+----+ *		| +---+----+ *
	| *		| *
	| Session ID(SID-x) * Session ID(SID-x)		| Session ID(SID-x) * Session ID(SID-x)
	+---+----+ +---+----+		+---+----+ +---+----+
	| Access | | Access |		| Access | | Access |
	| Router | | Router |		| Router | | Router |
	| 1 | | 2 |		| 1 | | 2 |
	+---+----+ +---+----+		+---+----+ +---+----+
	skipping to change at page 17, line 5 ¶		skipping to change at page 15, line 32 ¶
	+----+------+ +----+------+		+----+------+ +----+------+
	| DS | | Adversary |		| DS | | Adversary |
	| | | |		| | | |
	+-----------+ +-----------+		+-----------+ +-----------+
	Figure 9: State Modification by off-path adversary		Figure 9: State Modification by off-path adversary
	Summary: Off-path adversary's knowledge of Session-ID could cause		Summary: Off-path adversary's knowledge of Session-ID could cause
	session modification/deletion.		session modification/deletion.
	9. Misuse of unreleased sessions		SECURITY REQUIREMENT: TBD: This is not a NAT/FW NSLP specific problem
			but a GIMPS problem. The initiator MUST be able to demonstrate
			ownership of the session it wishes to modify.
	Assume that DS is transferring data to DR through a series of		8. Misuse of unreleased sessions
	middleboxes. The Data Sender might not correctly send a 'delete
	session' request to remove the established packet filter state at the
	middleboxes along the path. An intruder might use these packet
	filter states to communicate with DR due to the IP-spoofing
	capability.
	In fact, an adversary can always inject data due to the IP-spoofing		Assume that DS (N1) initiates NSIS session with DR (N2) through a
	capability even at the same time when the session is used by DS (see		series of middleboxes as in Figure 10. When the DS is sending data
	also Section 10).		to DR, it might happen that the DR disconnects from the network
			(crashes or moves out of the network in mobility scenarios). In such
			cases, it is possible that another node N3 (which recently entered
			the network protected by the same firewall) is assigned the same IP
			address that was previously allocated to N2. The DS could take
			advantage of the firewall policies installed already, if the refresh
			interval time is very high. The DS can flood the node (N3), which
			will consume the access network resources of the victim forcing it to
			pay for unwanted traffic as shown in Figure 11.
	10. Data traffic injection		Public Internet
	Due to the IP-spoofing capability an adversary is able to inject its		+--------------------------+
	own data traffic in conformance with the firewall policies.		| |
			| |
			+-------+ CREATE +---+-----+ +-------+ |
			| |-------------->------| |---->---| | |
			| N1 |--------------<------| FW |----<---| N2 | |
			| | success RESPONSE | | | | |
			| |==============>======| |====>===| | |
			+-------+ Data Traffic +---+-----+ +-------+ |
			| |
			| |
			+--------------------------+
	IP-spoofing is a general problem for packet filters. Awareness for		Figure 10: Before mobility
	the limitations of non-cryptographic packet filters is important.
	11. Misuse of mobility in NAT handling		Public Internet
			+--------------------------+
			| |
			| |
			+-------+ +---+-----+ +-------+ |
			| | | | | | |
			| N1 |==============>======| FW |====>===| N3 | |
			| | Data Traffic | | | | |
			| | | | | | |
			+-------+ +---+-----+ +-------+ |
			| |
			| |
			+--------------------------+
			Figure 11: After mobility
			Also, this threat is valid for the other direction as well. The DS
			which is communicating with the DR may disconnect from the network
			and this IP address may be assigned to a new node that had recently
			entered the network. This new node could pretend to be the DS and
			send data traffic to the DR in conformance with the firewall policies
			and cause service disruption.
			SECURITY REQUIREMENT: Data origin authentication is needed to
			mitigate this threat. However, the described threat is applicable
			only for the time until the policy rules are deleted due to NSLP soft
			state. Awareness for this threat is important especially when the
			refresh interval time is high. It should be noted, that networks
			supporting mobility should remove any state at middleboxes when a
			mobile node is diconnecting, thus leaving a clean state.
			9. Data traffic injection
			This attack takes place where there exists trust relationship between
			machines. It is common in corporate networks, where internal
			machines trust each other and authentication is only based on IP
			address. Hence by spoofing a connection, an attacker is able to
			reach the target machines, using the existing firewall rules.
			The adversary is able to inject its own data traffic in conformance
			with the firewall policies simultaneously along with the genuine DS.
			SECURITY REQUIREMENT: Since IP spoofing is a general limitation of
			non-cryptographic packet filters no security requirement needs to be
			created for the NAT/FW NSLP. Techniques such as ingress filtering
			(described below) and data origin authentication (such as provided
			with IPsec based VPNs) can help mitigate this threat. This issue is,
			however, outside the scope of this document.
			Ingress Filtering: Consider the scenario shown in Figure 12. In this
			scenario the DS is behind a router (R1) and a malicious node (M) is
			behind another router (R2). The DS communicates with the DR through
			a firewall (FW). The DS initiates NSIS signaling and installs
			firewall policies at FW. But the malicious node is also able to send
			data traffic using DS's source address. If R2 implements ingress
			filtering, these spoofed packets will be blocked. But this ingress
			filtering may not work in all scenarios. If both the DS and the
			malicious node are behind the same router, then the ingress filter
			will not be able to detect the spoofed packets as both the DS and the
			malicious node are in the same address range.
			+-----------------------------------+
			| +------------------+ |
			| | | |
			| | | |
			| | +-------+ +---+---+ |
			| | | DS +>--+ R1 +->+ |
			| | | | | | | |
			| | +-------+ +---+---+ | |
			| | | v |
			| | | | |
			| +------------------+ | +---+---+ +-------+
			| | | | | |
			| +---+ FW +-->--| DR |
			| +------------------+ | | | |
			| | | ****| |*****| |
			| | | * +---+---+ +-------+
			| | +-------+ +---+---+ * |
			| | | M | | R2 | * |
			| | | |***| |*** |
			| | +-------+ +---+---+ |
			| | | |
			| | | |
			| +------------------+ |
			+-----------------------------------+
			---->---- = genuine data traffic
			********* = spoofed data traffic
			Figure 12: Ingress filtering
			10. Misuse of mobility in NAT handling
	Since NSIS allows end hosts to be mobile it is possible that an NSIS		Since NSIS allows end hosts to be mobile it is possible that an NSIS
	node behind a NAT needs to update its NAT binding in case of address		node behind a NAT needs to update its NAT binding in case of address
	change. Whenever a host behind a NAT initiates a data transfer, it		change. Whenever a host behind a NAT initiates a data transfer, it
	is assigned an external IP and port number. In typical mobility		is assigned an external IP and port number. In typical mobility
	scenarios, the DR might also obtain a new address according to the		scenarios, the DR might also obtain a new address according to the
	topology and it should convey the NAT binding updates. The NAT is		topology and it should convey the NAT binding updates. The NAT is
	assumed to modify these NAT bindings based on the new IP address		assumed to modify these NAT bindings based on the new IP address
	conveyed by the endhost.		conveyed by the endhost.
	skipping to change at page 19, line 32 ¶		skipping to change at page 19, line 21 ¶
	+----------+ +----------+		+----------+ +----------+
	|		|
	|		|
	| +----------+		| +----------+
	\--------------------|Malicious |		\--------------------|Malicious |
	|End host |		|End host |
	+----------+		+----------+
	data traffic		data traffic
	<========================		<========================
	Figure 10: Misuse of mobility in NAT binding		Figure 13: Misuse of mobility in NAT binding
	When DR moves to a new location, it sends an NSIS signalling message		For this description , we assume that a NAT binding state can be
	to modify the NAT binding. It would use the Session-ID and the new		changed with the help of NSIS signalling. When the DR is receiving
	flow-id to update the state. The NAT updates the binding and the DR		data traffic, if it happens to move to a new location, it sends an
	continues to receive the data traffic. Consider the scenario in		NSIS signalling message to modify the NAT binding. It would use the
	Figure 10 where an the endhost(DR) and the adversary are behind a		Session-ID and the new flow-id to update the state. The NAT updates
	NAT. The adversary pretending that it is the end host could generate		the binding and the DR continues to receive the data traffic.
	a spurious signaling message to update the state at the NAT. This		Consider the scenario in Figure 13 where an the endhost(DR) and the
	could be done for these purposes:		adversary are behind a NAT. The adversary pretending that it is the
			end host could generate a spurious signaling message to update the
			state at the NAT. This could be done for these purposes:
	1. Connection hijacking by redirecting packets to the attacker as in		1. Connection hijacking by redirecting packets to the attacker as in
	Figure 11		Figure 14
	2. Third party flooding by redirecting packets to arbitrary hosts		2. Third party flooding by redirecting packets to arbitrary hosts
	3. Service disruption by redirecting to non-existing hosts		3. Service disruption by redirecting to non-existing hosts
	+----------+ +----------+ +----------+		+----------+ +----------+ +----------+
	| NAT | |End host | |Malicious |		| NAT | |End host | |Malicious |
	| | | | |End host |		| | | | |End host |
	+----------+ +----------+ +----------+		+----------+ +----------+ +----------+
	| | |		| | |
	| | |		| | |
	skipping to change at page 20, line 24 ¶		skipping to change at page 20, line 24 ¶
	| | NAT binding update |		| | NAT binding update |
	|---------<----------+--------<------------|		|---------<----------+--------<------------|
	| | |		| | |
	| | |		| | |
	| Data Traffic | |		| Data Traffic | |
	|--------->----------+-------->------------|		|--------->----------+-------->------------|
	| | |		| | |
	| | |		| | |
	| | |		| | |
	Figure 11: Connection Hijacking		Figure 14: Connection Hijacking
	12. Eavesdropping and traffic analysis		SECURITY REQUIREMENT: A NAT/FW signaling message MUST be
			authenticated, authorized, integrity protected and replay protected
			between neighboring NAT/FW NSLP nodes.
			11. Eavesdropping and traffic analysis
	By collecting NSLP messages, an adversary is able to learn policy		By collecting NSLP messages, an adversary is able to learn policy
	rules for packet filters and knows which ports are open. It can use		rules for packet filters and knows which ports are open. It can use
	this to inject its own data traffic due to the IP spoofing capability		this to inject its own data traffic due to the IP spoofing capability
	as already mentiened in Section 10.		as already mentioned in Section 9.
	An adversary could learn authorization tokens included in 'create		An adversary could learn authorization tokens included in CREATE
	session' messages and use them to launch reply-attacks or to create a		messages and use them to launch reply-attacks or to create a session
	session with its own address as source address. (cut-and-paste		with its own address as source address. (cut-and-paste attack)
	attack)
	Furthermore, traffic analysis allows an adversary to learn per flow		As shown in Section 4.3 of [6] a solution of Section 7 might require
	information about the data traffic which might violate user's		confidentiality protection of signaling messages
	preference for privacy. This kind of attacks has been also described
	in [6] Section 4.3.
	13. Security Considerations		SECURITY REQUIREMENT: The threat of eavesdropping itself does not
			mandate the usage of confidentiality protection since an adversary
			can also eavesdrop on data traffic. In the context of a particular
			security solutions (e.g., authorization tokens) it might be necessary
			to offer confidentiality protection. Confidentiality protection also
			needs to be offered to the refresh period.
	The entire document highlights security threats that need to be		12. Security Considerations
	mitigated for the NAT/Firewall NSLP. It also addresses security
	issues related to packet filters.
	Note that the list of threats in this document is not complete. More		The entire document highlights security threats that need to be
	threats might appear during implementation and deployment.		mitigated for the NATFW NSLP. It also addresses security issues
			related to packet filters. Security requirements have been derived
			from the relevant threats.
	14. Contributors		13. Acknowledgments
	Many parts of this documents are the result of some discussions		This document is the result of discussions with many individuals.
	within the NAT/firewall-NSLP-team including: Cedric Aoun, Marcus		The authors would like to thank especially: Marcus Brunner, Miquel
	Brunner, Miquel Martin and Joao Girao.		Martin, Frank Le, Joao Girao, and Elwyn Davis.
	15. References		14. References
	15.1 Normative References		14.1 Normative References
	[1] Stiemerling, M., Tschofenig, H. and M. Martin, "A NAT/Firewall		[1] Stiemerling, M., Tschofenig, H. and M. Martin, "A NAT/Firewall
	NSIS Signaling Layer Protocol (NSLP)",		NSIS Signaling Layer Protocol (NSLP)",
	draft-ietf-nsis-nslp-natfw-01 (work in progress), February 2004,		draft-ietf-nsis-nslp-natfw-03 (work in progress), July 2004,
	<reference.I-D.ietf-nsis-nslp-natfw.xml>.		<reference.I-D.ietf-nsis-nslp-natfw.xml>.
	[2] Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS",		[2] Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS",
	draft-ietf-nsis-threats-04 (work in progress), February 2004,		draft-ietf-nsis-threats-05 (work in progress), June 2004,
	<reference.I-D.ietf-nsis-threats.xml>.		<reference.I-D.ietf-nsis-threats.xml>.
	[3] Schulzrinne, H. and R. Hancock, "GIMPS: General Internet		[3] Schulzrinne, H. and R. Hancock, "GIMPS: General Internet
	Messaging Protocol for Signaling", draft-draft-ietf-nsis-ntlp-00		Messaging Protocol for Signaling", draft-draft-ietf-nsis-ntlp-02
	(work in progress), October 2003,		(work in progress), May 2004,
	<reference.I-D.draft-ietf-nsis-ntlp.xml>.		<reference.I-D.draft-ietf-nsis-ntlp.xml>.
	[4] Brunner, M., "Requirements for Signaling Protocols",		[4] Brunner, M., "Requirements for Signaling Protocols",
	draft-ietf-nsis-requirements (work in progress), April 2004,		draft-ietf-nsis-requirements (work in progress), April 2004,
	<reference.I-D.ietf-nsis-.requirements.xml>.		<reference.I-D.ietf-nsis-.requirements.xml>.
	[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", March 1997.		Levels", March 1997.
	15.2 Informative References		14.2 Informative References
	[6] Tschofenig, H., Schulzrinne, H., Hancock, R., McDonald, A. and		[6] Tschofenig, H., Schulzrinne, H., Hancock, R., McDonald, A. and
	X. Fu, "Security Implications of the Session Identifier", June		X. Fu, "Security Implications of the Session Identifier", June
	2003, <reference.I-D.tschofenig-nsis-sid.xml>.		2003, <reference.I-D.tschofenig-nsis-sid.xml>.
	[7] Aoun, C., Brunner, M., Stiemerling, M., Martin, M. and H.		[7] Aoun, C., Brunner, M., Stiemerling, M., Martin, M. and H.
	Tschofenig, "NAT/Firewall NSLP Migration Considerations",		Tschofenig, "NAT/Firewall NSLP Migration Considerations",
	draft-aoun-nsis-nslp-natfw-migration-01 (work in progress),		draft-aoun-nsis-nslp-natfw-migration-01 (work in progress),
	February 2004,		February 2004,
	<reference.I-D.aoun-nsis-nslp-natfw-migration.xml>.		<reference.I-D.aoun-nsis-nslp-natfw-migration.xml>.
	[8] Bless, R., "Mobility and Internet Signaling Protocols",		[8] Bless, R., "Mobility and Internet Signaling Protocols",
	draft-manyfolks-signaling-protocol-mobility-00 (work in		draft-manyfolks-signaling-protocol-mobility-00 (work in
	progress), January 2004,		progress), January 2004,
	<reference.I-D.manyfolks-signaling-protocol-mobility.xml>.		<reference.I-D.manyfolks-signaling-protocol-mobility.xml>.
	[9] Bosch, S., "NSLP for Quality-of-Service signaling",		[9] Bosch, S., "NSLP for Quality-of-Service signaling",
	draft-ietf-nsis-qos-nslp-01 (work in progress), October 2003,		draft-ietf-nsis-qos-nslp-03 (work in progress), May 2004,
	<reference.I-D.ietf-nsis-qos-nslp.xml>.		<reference.I-D.ietf-nsis-qos-nslp.xml>.
	Authors' Addresses		Authors' Addresses
	Ali Fessi		Ali Fessi
	Network Laboratories, NEC Europe Ltd.		Network Laboratories, NEC Europe Ltd.
	Kurfuersten-Anlage 36
	Heidelberg 69115
	Germany
	EMail: ali.fessi@netlab.nec.de		EMail: alifessi@web.de
	URI:		URI:
	Martin Stiemerling		Martin Stiemerling
	Network Laboratories, NEC Europe Ltd.		Network Laboratories, NEC Europe Ltd.
	Kurfuersten-Anlage 36		Kurfuersten-Anlage 36
	Heidelberg 69115		Heidelberg 69115
	Germany		Germany
	Phone: +49 (0) 6221 905 11 13		Phone: +49 (0) 6221 905 11 13
	EMail: stiemerling@ccrle.nec.de		EMail: stiemerling@ccrle.nec.de
	skipping to change at page 26, line 4 ¶		skipping to change at page 23, line 4 ¶
	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, Bayern 81739
	Germany		Germany
	EMail: Hannes.Tschofenig@siemens.com		EMail: Hannes.Tschofenig@siemens.com
			Cedric Aoun
			Nortel Networks
			France
	Appendix A.		EMail: cedric.aoun@nortelnetworks.com
	There are several reasons why network operator should not trust users
	inside their networks. Just to mention some of them:
	o The internal user could be a malicious entity such as a virus or a
	worm that has succeeded to intrude into the network. This entity
	could for instance send arbitrary 'create session' messages and
	allow all traffic go through.
	o In some scenarios such as mobility scenarios or ad-hoc networks,
	the user could be a visitor that it just happened that he visits
	the network.
	o In some cases users inside a network have the motivation to harm
	other users inside the same network e.g. by trying to re-direct
	data traffic to themselves (see also section ?) or to interrupt
	the sessions of other users (section ?).
	o Different users might have different access right to set up policy
	rules at the middlebox.
	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 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; neither does it represent that it		might or might not be available; nor does it represent that it has
	has made any effort to identify any such rights. Information on the		made any independent effort to identify any such rights. Information
	IETF's procedures with respect to rights in standards-track and		on the procedures with respect to rights in RFC documents can be
	standards-related documentation can be found in BCP-11. Copies of		found in BCP 78 and BCP 79.
	claims of rights made available for publication and any assurances of
	licenses to be made available, or the result of an attempt made to		Copies of IPR disclosures made to the IETF Secretariat and any
	obtain a general license or permission for the use of such		assurances of licenses to be made available, or the result of an
	proprietary rights by implementors or users of this specification can		attempt made to obtain a general license or permission for the use of
	be obtained from the IETF Secretariat.		such proprietary rights by implementers or users of this
			specification can be obtained from the IETF on-line IPR repository at
			http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights which may cover technology that may be required to practice		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF Executive		this standard. Please address the information to the IETF at
	Director.		ietf-ipr@ietf.org.
	Full Copyright Statement
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Disclaimer of Validity
	This document and translations of it may be copied and furnished to		This document and the information contained herein are provided on an
	others, and derivative works that comment on or otherwise explain it		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	or assist in its implementation may be prepared, copied, published		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	and distributed, in whole or in part, without restriction of any		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	kind, provided that the above copyright notice and this paragraph are		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	included on all such copies and derivative works. However, this		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	document itself may not be modified in any way, such as by removing		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of
	developing Internet standards in which case the procedures for
	copyrights defined in the Internet Standards process must be
	followed, or as required to translate it into languages other than
	English.
	The limited permissions granted above are perpetual and will not be		Copyright Statement
	revoked by the Internet Society or its successors or assignees.
	This document and the information contained herein is provided on an		Copyright (C) The Internet Society (2004). This document is subject
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		to the rights, licenses and restrictions contained in BCP 78, and
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		except as set forth therein, the authors retain all their rights.
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	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. 112 change blocks.
	299 lines changed or deleted		483 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/