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 40		skipping to change at page 6, line 40
	+------------------------------+		+------------------------------+
	| |		| |
	| +-----+ 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 th