< draft-ietf-nsis-nslp-natfw-02.txt		draft-ietf-nsis-nslp-natfw-03.txt >
	NSIS Working Group M. Stiemerling		NSIS Working Group M. Stiemerling
	Internet-Draft NEC		Internet-Draft NEC
	Expires: November 19, 2004 H. Tschofenig		Expires: January 17, 2005 H. Tschofenig
	Siemens		Siemens
	M. Martin		M. Martin
	NEC		NEC
	C. Aoun		C. Aoun
	Nortel Networks		Nortel Networks
	May 21, 2004		July 19, 2004
	NAT/Firewall NSIS Signaling Layer Protocol (NSLP)		NAT/Firewall NSIS Signaling Layer Protocol (NSLP)
	draft-ietf-nsis-nslp-natfw-02		draft-ietf-nsis-nslp-natfw-03
	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 19, 2004.		This Internet-Draft will expire on January 17, 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
	This memo defines the NSIS Signaling Layer Protocol (NSLP) for		This memo defines the NSIS Signaling Layer Protocol (NSLP) for
	Network Address Translators and Firewalls. This NSLP allows hosts to		Network Address Translators and Firewalls. This NSLP allows hosts to
	signal along a data path for Network Address Translators and		signal along a data path for Network Address Translators and
	Firewalls to be configured according to the data flow needs. The		Firewalls to be configured according to the data flow needs. The
	network scenarios, problems and solutions for path-coupled Network		network scenarios, problems and solutions for path-coupled Network
	Address Translator and Firewall signaling are described. The overall		Address Translator and Firewall signaling are described. The overall
	architecture is given by the framework and requirements defined by		architecture is given by the framework and requirements defined by
	Next Steps in Signaling (NSIS) working group. This is one of two		the Next Steps in Signaling (NSIS) working group.
	NSIS Signaling Layer Protocols (NSLPs) the working group will address
	during its work.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
	1.1 Terminology and Abbreviations . . . . . . . . . . . . . . 5		1.1 Terminology and Abbreviations . . . . . . . . . . . . . . 6
	1.2 Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 7		1.2 Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 8
	1.3 General Scenario for NATFW Traversal . . . . . . . . . . . 8		1.3 Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 9
			1.4 General Scenario for NATFW Traversal . . . . . . . . . . . 9
	2. Network Environment . . . . . . . . . . . . . . . . . . . . . 10		2. Network Deployment Scenarios using NATFW NSLP . . . . . . . . 11
	2.1 Network Scenarios for Protocol Functionality . . . . . . . 10		2.1 Firewall Traversal . . . . . . . . . . . . . . . . . . . . 11
	2.1.1 Firewall traversal . . . . . . . . . . . . . . . . . . 10		2.2 NAT with two private Networks . . . . . . . . . . . . . . 12
	2.1.2 NAT with two private Networks . . . . . . . . . . . . 11		2.3 NAT with Private Network on Sender Side . . . . . . . . . 12
	2.1.3 NAT with private network on sender side . . . . . . . 12		2.4 NAT with Private Network on Receiver Side Scenario . . . . 13
	2.1.4 NAT with private network on receiver side . . . . . . 12		2.5 Both End Hosts behind twice-NATs . . . . . . . . . . . . . 14
	2.1.5 Both End Hosts behind twice-NATs . . . . . . . . . . . 13		2.6 Both End Hosts Behind Same NAT . . . . . . . . . . . . . . 15
	2.1.6 Both End Hosts behind same NAT . . . . . . . . . . . . 14		2.7 IPv4/v6 NAT with two Private Networks . . . . . . . . . . 15
	2.1.7 IPv4/v6 NAT with two private networks . . . . . . . . 15		2.8 Multihomed Network with NAT . . . . . . . . . . . . . . . 16
	2.1.8 Multihomed Network with NAT . . . . . . . . . . . . . 16
	2.2 Trust Relationship and Authorization . . . . . . . . . . . 17
	2.2.1 Peer-to-Peer Trust Relationship . . . . . . . . . . . 17
	2.2.2 Intra-Domain Trust Relationship . . . . . . . . . . . 18
	2.2.3 End-to-Middle Trust Relationship . . . . . . . . . . . 19
	3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 21		3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 18
	3.1 Basic protocol overview . . . . . . . . . . . . . . . . . 21		3.1 Policy Rules . . . . . . . . . . . . . . . . . . . . . . . 18
	3.2 Protocol Operations . . . . . . . . . . . . . . . . . . . 23		3.2 Basic protocol overview . . . . . . . . . . . . . . . . . 18
	3.2.1 Creating Sessions . . . . . . . . . . . . . . . . . . 23		3.3 Protocol Operations . . . . . . . . . . . . . . . . . . . 20
	3.2.2 Reserving External Addresses . . . . . . . . . . . . . 25		3.3.1 Creating Sessions . . . . . . . . . . . . . . . . . . 21
	3.2.3 Reserving External Addresses and Create Session . . . 28		3.3.2 Reserving External Addresses . . . . . . . . . . . . . 23
	3.2.4 Prolonging Sessions . . . . . . . . . . . . . . . . . 28		3.3.3 NATFW Session refresh . . . . . . . . . . . . . . . . 27
	3.2.5 Deleting Sessions . . . . . . . . . . . . . . . . . . 29		3.3.4 Deleting Sessions . . . . . . . . . . . . . . . . . . 28
	3.2.6 Authorization . . . . . . . . . . . . . . . . . . . . 30		3.3.5 Reporting Asynchronous Events . . . . . . . . . . . . 29
	3.2.7 Calculation of Lifetimes . . . . . . . . . . . . . . . 30		3.3.6 QUERY capabilities within the NATFW NSLP protocol . . 30
	3.2.8 Middlebox Resource . . . . . . . . . . . . . . . . . . 31		3.3.7 QUERY Message semantics . . . . . . . . . . . . . . . 31
	3.2.9 De-Multiplexing at NATs . . . . . . . . . . . . . . . 31		3.4 NATFW NSLP proxy mode of operation . . . . . . . . . . . . 32
	3.2.10 Selecting Destination IP addresses for REA . . . . . . 32		3.4.1 Reserving External Addresses and triggering Create
	3.3 NATFW NSLP Messages Components . . . . . . . . . . . . . . 33		messages . . . . . . . . . . . . . . . . . . . . . . . 32
	3.3.1 NSLP Header . . . . . . . . . . . . . . . . . . . . . 33		3.4.2 Using CREATE messages to Trigger Reverse Path
	3.3.2 NSLP message types . . . . . . . . . . . . . . . . . . 34		CREATE Messages . . . . . . . . . . . . . . . . . . . 35
	3.3.3 NSLP Objects . . . . . . . . . . . . . . . . . . . . . 34		3.4.2.1 CREATE Responses Sent on Previously Pinned
	3.3.3.1 Session ID Object . . . . . . . . . . . . . . . . 35		Down Reverse Path . . . . . . . . . . . . . . . . 35
	3.3.3.2 Session Lifetime Object . . . . . . . . . . . . . 35		3.4.2.2 CREATE Responses Sent on Separately
	3.3.3.3 External Address Object . . . . . . . . . . . . . 36		Established Reverse Path . . . . . . . . . . . . . 36
	3.3.3.4 Extended Flow Information Object . . . . . . . . . 37		3.5 Calculation of Session Lifetime . . . . . . . . . . . . . 37
	3.3.3.5 Error Object . . . . . . . . . . . . . . . . . . . 37		3.6 Middlebox Resource . . . . . . . . . . . . . . . . . . . . 39
	3.4 Message Formats . . . . . . . . . . . . . . . . . . . . . 38		3.7 De-Multiplexing at NATs . . . . . . . . . . . . . . . . . 39
	3.4.1 Policy Rules . . . . . . . . . . . . . . . . . . . . . 38		3.8 Selecting Opportunistic Addresses for REA . . . . . . . . 40
	3.4.2 Create Session (CRS) . . . . . . . . . . . . . . . . . 39
	3.4.3 Reserve External Address (REA) . . . . . . . . . . . . 39
	3.4.4 Reserve-Create (REC) . . . . . . . . . . . . . . . . . 39
	3.4.5 Prolong Session (PLS) . . . . . . . . . . . . . . . . 39
	3.4.6 Delete Session (DLS) . . . . . . . . . . . . . . . . . 40
	3.4.7 Path Succeeded (PS) . . . . . . . . . . . . . . . . . 40
	3.4.8 Path Deleted (PD) . . . . . . . . . . . . . . . . . . 40
	3.4.9 Return External Address (RA) . . . . . . . . . . . . . 40
	3.4.10 Error Response (ER) . . . . . . . . . . . . . . . . . 41
	4. NSIS NAT and Firewall transitions issues . . . . . . . . . . . 42		4. NATFW NSLP NTLP Requirements . . . . . . . . . . . . . . . . . 42
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 43		5. NATFW NSLP Message Components . . . . . . . . . . . . . . . . 43
			5.1 NSLP Header . . . . . . . . . . . . . . . . . . . . . . . 43
			5.2 NSLP message types . . . . . . . . . . . . . . . . . . . . 43
			5.3 NSLP Objects . . . . . . . . . . . . . . . . . . . . . . . 44
			5.3.1 Session Lifetime Object . . . . . . . . . . . . . . . 44
			5.3.2 External Address Object . . . . . . . . . . . . . . . 45
			5.3.3 Extended Flow Information Object . . . . . . . . . . . 46
			5.3.4 Response Code Object . . . . . . . . . . . . . . . . . 47
			5.3.5 Response Type Object . . . . . . . . . . . . . . . . . 47
			5.3.6 Message Sequence Number Object . . . . . . . . . . . . 48
			5.3.7 Scoping Object . . . . . . . . . . . . . . . . . . . . 48
			5.3.8 Bound Session ID Object . . . . . . . . . . . . . . . 49
			5.3.9 Notify Target Object . . . . . . . . . . . . . . . . . 49
			5.4 Message Formats . . . . . . . . . . . . . . . . . . . . . 50
			5.4.1 CREATE . . . . . . . . . . . . . . . . . . . . . . . . 50
			5.4.2 RESERVE-EXTERNAL-ADDRESS (REA) . . . . . . . . . . . . 50
			5.4.3 TRIGGER . . . . . . . . . . . . . . . . . . . . . . . 51
			5.4.4 RESPONSE . . . . . . . . . . . . . . . . . . . . . . . 51
			5.4.5 QUERY . . . . . . . . . . . . . . . . . . . . . . . . 51
			5.4.6 NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . 52
	6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 45		6. NSIS NAT and Firewall Transition Issues . . . . . . . . . . . 53
	7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 46		7. Security Considerations . . . . . . . . . . . . . . . . . . . 54
			7.1 Trust Relationship and Authorization . . . . . . . . . . . 54
			7.1.1 Peer-to-Peer Trust Relationship . . . . . . . . . . . 55
			7.1.2 Intra-Domain Trust Relationship . . . . . . . . . . . 56
			7.1.3 End-to-Middle Trust Relationship . . . . . . . . . . . 57
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47		8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 59
	8.1 Normative References . . . . . . . . . . . . . . . . . . . . 47
	8.2 Informative References . . . . . . . . . . . . . . . . . . . 47
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 49		9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 60
	A. Problems and Challenges . . . . . . . . . . . . . . . . . . . 51		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 61
	A.1 Missing Network-to-Network Trust Relationship . . . . . . 51		10.1 Normative References . . . . . . . . . . . . . . . . . . . . 61
	A.2 Relationship with routing . . . . . . . . . . . . . . . . 52		10.2 Informative References . . . . . . . . . . . . . . . . . . . 61
	A.3 Affected Parts of the Network . . . . . . . . . . . . . . 53
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 64
			A. Problems and Challenges . . . . . . . . . . . . . . . . . . . 65
			A.1 Missing Network-to-Network Trust Relationship . . . . . . 65
			A.2 Relationship with routing . . . . . . . . . . . . . . . . 66
			A.3 Affected Parts of the Network . . . . . . . . . . . . . . 66
	A.4 NSIS backward compatibility with NSIS unaware NAT and		A.4 NSIS backward compatibility with NSIS unaware NAT and
	Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 53		Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 66
	A.5 Authentication and Authorization . . . . . . . . . . . . . 54		A.5 Authentication and Authorization . . . . . . . . . . . . . 67
	A.6 Directional Properties . . . . . . . . . . . . . . . . . . 54		A.6 Directional Properties . . . . . . . . . . . . . . . . . . 67
	A.7 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 54		A.7 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 68
	A.8 NTLP/NSLP NAT Support . . . . . . . . . . . . . . . . . . 55		A.8 NTLP/NSLP NAT Support . . . . . . . . . . . . . . . . . . 68
	A.9 Combining Middlebox and QoS signaling . . . . . . . . . . 55		A.9 Combining Middlebox and QoS signaling . . . . . . . . . . 68
	A.10 Inability to know the scenario . . . . . . . . . . . . . . 55		A.10 Inability to know the scenario . . . . . . . . . . . . . . 69
	B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 57		B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 70
	Intellectual Property and Copyright Statements . . . . . . . . 58		Intellectual Property and Copyright Statements . . . . . . . . 71
	1. Introduction		1. Introduction
	Firewalls and Network Address Translators (NAT) have been both used		Firewalls and Network Address Translators (NAT) have both been used
	throughout the Internet for many years and they will be present in		throughout the Internet for many years, and they will remain present
	future. Using Firewalls brings security to networks and in times of		for the foreseeable future. Firewalls are used to protect networks
	IPv4 address depletion NATs virtually extend IP address space. In		against certain types of attacks from the outside, and in times of
	general, both types may be obstacles to many applications, since they		IPv4 address depletion, NATs virtually extend the IP address space.
	only allow specific applications to traverse them (i.e., HTTP traffic		Both types of devices may be obstacles to many applications, since
	or in general client/server applications). Other applications, for		they only allow traffic created by a limited set of applications to
	instance, IP telephony or any other peer-to-peer application, with		traverse them (e.g., most HTTP traffic, and client/server
	more dynamic properties suffer from Firewalls and NATs so that they		applications), due to the rather static properties of those
	do not work at all. Therefore, many applications cannot traverse		protocols. Other applications, such as IP telephony and most other
	Firewall or NATs.		peer-to-peer applications with more dynamic properties, create
			traffic which is unable to traverse NATs and Firewalls unassisted.
			In practice, the traffic from many applications cannot traverse
			Firewalls or NATs, even if they work autonomously in an attempt to
			restore the transparency of the network.
	Several solutions to enable any application to traverse those boxes		Several solutions to enable applications to traverse such entities
	have been proposed and are currently used. Typically, application		have been proposed and are currently in use. Typically, application
	level gateways (ALG) have been integrated and so configuring		level gateways (ALG) have been integrated with the Firewall or NAT to
	Firewalls and NATs dynamically. Another approach is middlebox		configure the Firewall or NAT dynamically. Another approach is
	communication (MIDCOM, currently under standardization at the IETF).		middlebox communication (MIDCOM, currently under standardization at
	In this approach Firewall and NAT external ALGs configure them via		the IETF). In this approach, ALGs external to the Firewall or NAT
	the MIDCOM protocol [7]. Several other work around solutions are		configure the corresponding entity via the MIDCOM protocol [7].
	available as well, see STUN [32] and [31]. However, all of these		Several other work-around solutions are available as well, such as
	approaches introduce other problems that are hard to solve; like		STUN [35] and TURN [37]. However, all of these approaches introduce
	dependencies on certain NAT implementations or dependency on		other problems that are hard to solve, such as dependencies on the
	topology.		type of NAT implementation (full-cone, symmetric, ...), or
			dependencies on a certain network topology.
	NAT and Firewall (NATFW) signaling share a property with Quality of		NAT and Firewall (NATFW) signaling share a property with Quality of
	Service (QoS) signaling, i.e., in both cases it is required to reach		Service (QoS) signaling. Namely, both require that any device on the
	any device on the data path that is involved in QoS or NATFW		data path that is involved in QoS or NATFW treatment of data packets
	treatment of data packets. For both, NATFW and QoS, signaling		is reached. For both, NATFW and QoS, signaling travels path-coupled,
	travels path-coupled, meaning that the signaling messages follow		meaning that the signaling messages follow exactly the same path that
	exactly the same path as the data packets do. RSVP [14] is an		the data packets take. RSVP [14] is an example of a current QoS
	example for a QoS signaling protocol.		signaling protocol that is path-coupled.
	This memo defines a path-coupled signaling protocol in the framework		This memo defines a path-coupled signaling protocol for NAT and
	of NSIS for NAT and Firewall configuration, called the NATFW NSIS		Firewall configuration within the framework of NSIS, called the NATFW
	Signaling Layer Protocol (NSLP). The general framework of NSIS is		NSIS Signaling Layer Protocol (NSLP). The general requirements for
	outlined in [1] and introduces the split between NSIS transport layer		NSIS are defined in [2]. The general framework of NSIS is outlined
	and NSIS signaling layer. The transport of NSLP messages is handled		in [1]. It introduces the split between an NSIS transport layer and
	by NSIS Network Transport Layer Protocol (NTLP, see [3]) and takes		an NSIS signaling layer. The transport of NSLP messages is handled
	care about NSLP message transport. The signaling logic for QoS and		by an NSIS Network Transport Layer Protocol (NTLP, with GIMPS [3]
	NATFW signaling is implemented in the different NSLPs. The QoS NSLP		being the implementation of the abstract NTLP). The signaling logic
	is defined in [4], furthermore the general requirements for NSIS are		for QoS and NATFW signaling is implemented in the different NSLPs.
	defined in [2].
	There is a series of related documents to NATFW NSLP discussing		The QoS NSLP is defined in [4], while the NATFW NSLP is defined in
	several other aspects of path-coupled NATFW signaling, including		this document.
	security [20], migration [17], intrarealm signaling [18], and
	inter-working with SIP [19].
	The NATFW NSLP allows requesting the configuration of NATs and/or		The NATFW NSLP is designed to request the configuration of NATs and/
	Firewalls along the data path to enable data flows to traverse these		or Firewalls along the data path to enable data flows to traverse
	devices without being obstructed. A simplified example: A source		these devices without being obstructed. A simplified example: A
	host sends a NATFW NSLP signaling message towards its data		source host sends a NATFW NSLP signaling message towards its data
	destination. This message follows the data path and every NATFW NSLP		destination. This message follows the data path. Every NATFW NSLP
	NAT/Firewall along the data path intercepts these messages, processes		NAT/Firewall along the data path intercepts these messages, processes
	it and configures itself accordingly. Afterwards, the actual data		them, and configures itself accordingly. Afterwards, the actual data
	flow can traverse every configured Firewall/NAT.		flow can traverse every configured Firewall/NAT.
	NATFW NSLP runs in two different modes, one is the path directed mode		NATFW NSLP runs in two different modes, one is the CREATE mode in
	where Firewalls and NATs are configured along the data path as		which state at firewalls and NATs is created. In the above example,
	pointed out in the above example. The second one is the reserve		this takes place in the direction from the data sender to the data
	mode, where NATs are detected by the NSLP/NTLP within the network and		receiver. The other mode is the RESERVE mode. In this mode, NATs
	a public reachable IP address and port number are reserved. This		are discovered by the NSLP/NTLP signaling messages, and a publicly
	reserve mode enables hosts located behind NATs to receive data		reachable IP address and a port number are reserved at each NAT.
	originated in the public Internet on the reverse data path. Both		This mode enables hosts located in a private addressing realm
	modes create NATFW NSLP and NTLP state in the network. The NSLP		delimited by a NAT to receive data originated in the public network.
	state is maintained via a soft-state mechanism. State includes not		Both modes create NATFW NSLP and NTLP state in network entities.
	only signaling state, but as well as NAT bindings and Firewall rules.		NTLP state allows signaling messages to travel in the forward
	This state is maintained via a lifetime and must be kept alive via a		(downstream ) and the reverse (upstream) direction along the path
	lifetime extension mechanism if needed. Two signaling messages are		between an NAT/Firewall NSLP sender and a corresponding receiver.
	used for deleting state explicitly and extending state's lifetime.		NAT bindings and firewall rules are NAT/Firewall specific state.
	In general, all NATFW NSLP signaling messages are exchanged		This state is managed using a soft-state mechanism, i.e., it expires
	end-to-end.		unless it is refreshed every now and then by a certain message. If
			state is to be deleted explicitly before it automatically expires,
	Traversal of non NATFW NSLPs or the NTLP is out of scope of this		another message can be used for that. To find out which state is
	document. Furthermore, only Firewalls and NATs are considered in		currently installed in NSIS NAT/Firewall nodes, a query message can
	this document, any other device, for instance IPSec security gateway,		be used at any time.
	is out of scope.
	Section 2 describes the network environment for NATFW NSLP signaling		Section 2 describes the network environment for NATFW NSLP signaling,
	and highlights the required trust relationship/ authorization.		highlighting the trust relationships and authorization required.
	Section 3 defines the NATFW signaling protocol with its message		Section 3 defines the NATFW signaling protocol. Section 5 defines
	components, message formats, and protocol operations. The remaining		the messages and and message components. In the remaining parts of
	document refers in Section 4 to transition issues and security		the main body of the document, Section 6 covers transition issues,
	considerations are handled in [20]. Currently unsolved problems and		while Section 7 addresses security considerations, with more
	challenges are listed and discussed in Appendix A. Please note that		extensive discussions of security issues currently being contained in
	readers familiar with possible locations of Firewalls and NAT in		[20]. Currently unsolved problems and challenges are listed and
	networks can safely skip Section 2.		discussed in Appendix A. Please note that readers familiar with
			Firewalls and NATs and their possible location within networks can
			safely skip Section 2.
	1.1 Terminology and Abbreviations		1.1 Terminology and Abbreviations
	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 RFC 2119.		document are to be interpreted as described in RFC 2119.
	This document uses terms defined in [2]. Furthermore, these		This document uses a number of terms defined in [2]. The following
	following terms are used:		additional terms are used:
	o NSIS NAT Forwarding State: The term "NSIS NAT Forwarding State" in		o NSIS NAT Forwarding State: This term refers to a state used to
	this context refers to a state used to forward the NSIS signaling		forward the NSIS signaling message beyond the targeted destination
	message beyond the targeted destination address; that state is		address.
	typically used when the NSIS Responder address is not known		o Policy rule: A policy rule is "a basic building block of a
	o Sender-/Receiver Initiated Signaling		policy-based system. It is the binding of a set of actions to a
	Sender-initiated: NAT bindings and Firewall rules are created		set of conditions - where the conditions are evaluated to
	immediately when the "path" message hits the NSIS nodes. With		determine whether the actions are performed" [38]. In the context
	"path" message we refer to the signaling message traveling from		of NSIS NATFW NSLP, the condition is a specification of a set of
	the data sender towards the data receiver.		packets to which rules are applied. The set of actions always
	Receiver-initiated: NAT bindings and Firewall rules are created		contains just a single element per rule, and is limited to either
	when the "reserve" message returns from the other end. With		action "reserved", "deny" or action "allow".
	"reserve" message we refer to a signaling message on the		o Firewall: A packet filtering device that matches packets against a
	reverse path, this means from the receiver to the sender (i.e.
	backwards routed).
	Note that these definitions have nothing to do with number of
	roundtrips, who performs authorization etc.
	o Policy rule: In general, a policy rule is "a basic building block
	of a policy-based system. It is the binding of a set of actions
	to a set of conditions - where the conditions are evaluated to
	determine whether the actions are performed." [RFC3198]. In the
	context of NSIS NATFW NSLP the condition is a specification of a
	set of packets to which rules are applied. The set of actions
	always contains just a single element per rule, and is limited to
	either action "reserved" or action "enable".
	o Firewall: A packet filtering device that matches packet against a
	set of policy rules and applies the actions. In the context of		set of policy rules and applies the actions. In the context of
	NSIS NATFW NSLP we refer to this device as Firewall.		NSIS NATFW NSLP we refer to this device as Firewall.
	o Network Address Translator: Network Address Translation is a		o Network Address Translator: Network Address Translation is a
	method by which IP addresses are mapped from one realm to another,		method by which IP addresses are mapped from one realm to another,
	in an attempt to provide transparent routing to hosts (see [9]).		in an attempt to provide transparent routing between hosts (see
	Network Address Translators are devices that perform this method.		[8]). Network Address Translators are devices that perform this
	o Middlebox: from [12]: "A middlebox is defined as any intermediate		method.
	device performing functions other than the normal, standard		o Middlebox: "A middlebox is defined as any intermediate device
	functions of an IP router on the datagram path between a source		performing functions other than the normal, standard functions of
	host and a destination host". The term middlebox in context of		an IP router on the datagram path between a source host and a
	this document and in NSIS refers to Firewalls and NATs only.		destination host" [12]. In the context of this document and in
	Other types of middlebox are currently outside the scope.		NSIS, the term middlebox refers to Firewalls and NATs only. Other
			types of middlebox are currently outside the scope.
	o Security Gateway: IPsec based gateways.		o Security Gateway: IPsec based gateways.
	o NSIS Initiator (NI): the signaling entity, which makes the		o NSIS Initiator (NI): The signaling entity that makes a resource
	resource request, usually as a result of user application request.		request, usually as a result of user application request.
	o NSIS Responder (NR): the signaling entity , which acts as the		o NSIS Responder (NR): The signaling entity that acts as the final
	final destination for the signaling and can optionally interact		destination for the signaling. It can optionally interact with
	with applications as well.		applications as well.
	o NSIS Forwarder (NF): the signaling entity between an NI and NR		o NSIS Forwarder (NF): A signaling entity between an NI and an NR
	which propagates NSIS signaling further through the network.		which propagates NSIS signaling further through the network.
			o Receiver (DR or R): The node in the network that is receiving the
	o Receiver (DR or R): the node in the network, which is receiving
	the data packets of a flow.
	o Sender (DS or S): the node in the network, which is sending the
	data packets of a flow.		data packets of a flow.
	o NATFW NSLP session: Application layer flow of information for		o Sender (DS or S): The node in the network that is sending the data
	which some network control state information is to be manipulated		packets of a flow.
			o NATFW NSLP session: An application layer flow of information for
			which some network control state information is to be manipulated
	or monitored (as defined in [1]). The control state for NATFW		or monitored (as defined in [1]). The control state for NATFW
	NSLP is NSLP state and associated policy rules at the middlebox.		NSLP consists of NSLP state and associated policy rules at a
	o NSIS peer or peer: NSIS node with which a NSIS adjacency has been		middlebox.
	created as defined in [3].		o NSIS peer or peer: An NSIS node with which an NSIS adjacency has
	o Edge NAT: By edge NAT we refer to the NAT device, which is		been created as defined in [3].
	reachable from outside and has a globally routable IP address.
	o Public Network: Definition according to [8] is "A Global or Public		o Edge NAT: An edge NAT is a NAT device that is reachable from the
	Network is an address realm with unique network addresses assigned		public Internet and that has a globally routable IP address.
	by Internet Assigned Numbers Authority (IANA) or an equivalent		o Edge Firewall: An edge Firewall is a Firewall device that is
	address registry. This network is also referred as External		located on the demarcation line of an administrative domain.
	network during NAT discussions."		o Public Network: "A Global or Public Network is an address realm
	o Private/Local Network: Definition according to [8] is " A private		with unique network addresses assigned by Internet Assigned
	network is an address realm independent of external network		Numbers Authority (IANA) or an equivalent address registry. This
	addresses. Private network may also be referred alternately as		network is also referred as External network during NAT
	Local Network. Transparent routing between hosts in private realm		discussions" [8].
	and external realm is facilitated by a NAT router." IP address		o Private/Local Network: "A private network is an address realm
	space allocation for private networks is recommended in [33]		independent of external network addresses. Private network may
			also be referred alternately as Local Network. Transparent
			routing between hosts in private realm and external realm is
			facilitated by a NAT router" [8]. IP address space allocation for
			private networks is recommended in [36]
	o Public/Global IP address: An IP address located in the public		o Public/Global IP address: An IP address located in the public
	network.		network according to Section 2.7 of [8].
	o Private/Local IP address: An IP address located in the private		o Private/Local IP address: An IP address located in the private
	network.		network according to Section 2.8 of [8].
			o Initial CREATE: A CREATE message creating a new session.
	1.2 Middleboxes		1.2 Middleboxes
	The term middlebox raises different expectations about functionality		The term middlebox covers a range of devices which intercept the flow
	provided by such a device. Middleboxes in the scope of this memo are		of packets between end hosts and perform actions other than standard
	Firewalls that filter data packets against their set of filter rules		forwarding expected in an IP router. As such, middleboxes fall into
	and NATs that translate addresses from one address realm to another		a number of categories with a wide range of functionality not all of
	address realm. Other types of middleboxes, for instance QoS traffic		which is pertinent to the NATFW NSLP. Middlebox categories in the
	shapers and security gateways, are out of scope.		scope of this memo are Firewalls that filter data packets against a
			set of filter rules, and NATs that translate packet addresses from
			one address realm to another address realm. Other categories of
			middleboxes, such as QoS traffic shapers and security gateways, are
			out of scope.
	The term NAT used in this document is placeholder for a range of		The term NAT used in this document is placeholder for a range of
	different NAT flavors. We consider those types of NATs:		different NAT flavors. We consider these types of NATs:
	o traditional NAT (basic NAT and NAPT)		o traditional NAT (basic NAT and NAPT)
	o Bi-directional NAT		o Bi-directional NAT
	o Twice-NAT		o Twice-NAT
	o Multihomed NAT		o Multihomed NAT
	For a detailed discussion about each NAT type please see [8].		For definitions and a detailed discussion about the characteristics
			of each NAT type please see [8].
	Both types of middleboxes use policy rules for decision on data		Both types of middleboxes under consideration here use policy rules
	packet treatment. Policy rules consist of a 5-tuple and an		to make a decision on data packet treatment. Policy rules consist of
	associated action. Data packets matching this 5-tuple experience the		a flow identifier (which is typically a 5-tuple) and an associated
	policy rule action. A 5-tuple consists of:		action; data packets matching the flow identifier are subjected to
	o Source IP address and port number		the policy rule action. A 5-tuple selector matches the following
	o Destination IP address and port number		fields of a packet to configured values:
	o Transport protocol		o Source and destination IP addresses
	Actions for Firewalls are usually:		o Transport protocol number
	o Allow: forward data packet		o Transport source and destination port numbers
	o Deny: block data packet and discard it
	o Other actions like logging, diverting, etc
	Actions for NATs are (amongst many others):
	o Change source IP address and port number to a global routeable IP
	address and port number.
	o Change destination IP address and port number to a private IP
	address and port number.
	The exact implementation of policy rules and mapping to Firewall rule		For further examples of flow identifiers see Section 5.1 of [3].
	sets and NAT bindings or sessions at the middlebox is an
	implementation issue and thus out of scope of this document.
	Some devices entitled as Firewalls only accept traffic after		Actions for Firewalls are usually one or more of:
	cryptographic verification (i.e. IPsec protected data traffic).		o Allow: forward data packet
	Particularly for network access scenarios either link layer or		o Deny: block data packet and discard it
	network layer data protection is common. Hence we do not address		o Other actions like logging, diverting, duplicating, etc
	these types of devices (referred as security gateways) since per-flow
	signaling is rather uncommon in this environment. For a discussion
	of network access authentication and associated scenarios the reader
	is referred to the PANA working group (see [26]).
	Discovering security gateways, which was also mentioned as an		Actions for NATs include (amongst many others):
	application for NSIS signaling, for the purpose of executing an IKE		o Change source IP address and transport port number to a globally
	to create an IPsec SA, is already solved without requiring NSIS.		routeable IP address and associated port number.
			o Change destination IP address and transport port number to a
			private IP address and associated port number.
	In mobility scenarios an often experienced problem is the traversal		1.3 Non-Goals
	of a security gateway at the edge of the corporate network. Network
	administrators often rely on the policy that only authenticated data
	traffic is allowed to enter the network. A problem statement for the
	traversal of these security gateways in the context of Mobile IP can
	be found at [25]).
	Other proposals for path-coupled NAT and Firewall traversal like RSVP		Traversal of non-NSIS and non-NATFW NSLP aware NATs and Firewalls
	and CASP are described in [27] and [28].		is outside the scope of this document.
			Only Firewalls and NATs are considered in this document, any other
			types of devices, for instance IPSec security gateway, are out of
			scope.
			The exact implementation of policy rules and their mapping to
			firewall rule sets and NAT bindings or sessions at the middlebox
			is an implementation issue and thus out of scope of this document.
			Some devices categorized as firewalls only accept traffic after
			cryptographic verification (i.e., IPsec protected data traffic).
			Particularly for network access scenarios, either link layer or
			network layer data protection is common. Hence we do not address
			these types of devices (referred to as security gateways) since
			per-flow signaling is rather uncommon in this environment.
			Discovering security gateways, which was also mentioned as an
			application for NSIS signaling, for the purpose of executing an
			IKE to create an IPsec SA, is outside the scope of this document.
			In mobility scenarios, a common problem is the traversal of a
			security gateway at the edge of a corporate network. Network
			administrators allow only authenticated data to enter the network.
			A problem statement for the traversal of these security gateways
			in the context of Mobile IP can be found in [28]). This topic is
			not within the scope of the present document.
	1.3 General Scenario for NATFW Traversal		1.4 General Scenario for NATFW Traversal
	The purpose of NSIS NATFW signaling is to enable any communication		The purpose of NSIS NATFW signaling is to enable communication
	between endpoints across networks even in presence of middleboxes.		between endpoints across networks even in the presence of NAT and
	It is expected that those middleboxes be configured in such a way		Firewall middleboxes. It is assumed that these middleboxes will be
	that NSIS NATFW signaling messages itself are allowed to traverse		statically configured in such a way that NSIS NATFW signaling
	them. NSIS NATFW NSLP signaling is used to install such policy rules		messages themselves are allowed to traverse them. NSIS NATFW NSLP
	in all middleboxes along the data path. Firewalls are configured to		signaling is used to dynamically install additional policy rules in
	forward data packets matching the policy rule provided by the NSLP		all NATFW middleboxes along the data path. Firewalls are configured
			to forward data packets matching the policy rule provided by the NSLP
	signaling. NATs are configured to translate data packets matching		signaling. NATs are configured to translate data packets matching
	the policy rule provided by the NSLP signaling.		the policy rule provided by the NSLP signaling.
	The basic high-level picture of NSIS usage is that endhosts are		The basic high-level picture of NSIS usage is that end hosts are
	located behind middleboxes (NAT/FW in Figure 1). Applications		located behind middleboxes (NAT/FW in Figure 1). Applications
	located at these endhosts try to establish communication between them		located at these end hosts try to establish communication with
	and use NSIS NATFW NSLP signaling to establish policy rules on a data		corresponding applications on other such end hosts. They trigger the
	path, which allows the said data to travel from the sender to the		NSIS entity at the local host to provide for middlebox traversal
	receiver unobstructed. The applications can somehow trigger		along the prospective data path (e.g., via an API call). The NSIS
	middlebox traversal (e.g. via an API call) at the NSIS entity at the		entity in turn uses NSIS NATFW NSLP signaling to establish policy
	local host.		rules along the data path, allowing the data to travel from the
			sender to the receiver unobstructed.
	Application Application Server (0, 1, or more) Application		Application Application Server (0, 1, or more) Application
	+----+ +----+ +----+		+----+ +----+ +----+
	| +------------------------+ +------------------------+ |		| +------------------------+ +------------------------+ |
	+-+--+ +----+ +-+--+		+-+--+ +----+ +-+--+
	| |		| |
	| NSIS Entities NSIS Entities |		| NSIS Entities NSIS Entities |
	+-+--+ +----+ +-----+ +-+--+		+-+--+ +----+ +-----+ +-+--+
	| +--------+ +----------------------------+ +-----+ |		| +--------+ +----------------------------+ +-----+ |
	skipping to change at page 9, line 39 ¶		skipping to change at page 10, line 44 ¶
	| | //// \\\\\ | |		| | //// \\\\\ | |
	+-+--+ +-+--+ |/ | +-+--+ +-+--+		+-+--+ +-+--+ |/ | +-+--+ +-+--+
	| | | | | Internet | | | | |		| | | | | Internet | | | | |
	| +--------+ +-----+ +----+ +-----+ |		| +--------+ +-----+ +----+ +-----+ |
	+----+ +----+ |\ | +----+ +----+		+----+ +----+ |\ | +----+ +----+
	\\\\ /////		\\\\ /////
	sender NAT/FW (1+) ------ NATFW (1+) receiver		sender NAT/FW (1+) ------ NATFW (1+) receiver
	Figure 1: Generic View on NSIS in a NAT / Firewall case		Figure 1: Generic View on NSIS in a NAT / Firewall case
	For running NATFW signaling it is necessary that each Firewall and		For end-to-end NATFW signaling, it is necessary that each firewall
	each NAT involved in the signaling communication runs an NSIS NATFW		and each NAT along the path between the data sender and the data
	entity. There might be several NATs and FWs in various possible		receiver implement the NSIS NATFW NSLP. There might be several NATs
	combinations on a path between two hosts. The reader is referred to		and FWs in various possible combinations on a path between two hosts.
	Section 2.1 where different scenarios are presented.		Section 2 presents a number of likely scenarios with different
			combinations of NATs and firewalls.
	2. Network Environment
	2.1 Network Scenarios for Protocol Functionality		2. Network Deployment Scenarios using NATFW NSLP
	This section introduces several scenarios for middleboxes in the		This section introduces several scenarios for middlebox placement
	Internet. Middleboxes are located at different locations, i.e. at		within IP networks. Middleboxes are typically found at various
	Enterprise network borders, within enterprise networks, mobile phone		different locations, including at Enterprise network borders, within
	network gateways, etc. In general, middleboxes are placed more		enterprise networks, as mobile phone network gateways, etc. Usually,
	towards the edge of networks and less in network cores. Those		middleboxes are placed rather towards the edge of networks than in
	middleboxes are not only either Firewall or NAT and any other type of		network cores. Firewalls and NATs may be found at these locations
	combination is possible. Thus, combined Firewall and NATs are		either alone, or they may be combined; other categories of
	available.		middleboxes may also be found at such locations, possibly combined
			with the NATs and/or Firewalls. To reduce the number of network
			elements needed, combined Firewall and NATs have been made available.
	NSIS initiators (NI) are sending NSIS NATFW NSLP signaling messages		NSIS initiators (NI) send NSIS NATFW NSLP signaling messages via the
	via the regular data path to the NSIS responder (NR). On the data		regular data path to the NSIS responder (NR). On the data path,
	path NATFW NSLP signaling messages reach different NSIS peers that		NATFW NSLP signaling messages reach different NSIS peers that
	have the NATFW NSLP implemented. Each NATFW NSLP node processes the		implement the NATFW NSLP. Each NATFW NSLP node processes the
	signaling messages according to Section 3 and installs, if necessary,		signaling messages according to Section 3 and, if necessary, installs
	policy rules for subsequent data packets.		policy rules for subsequent data packets.
	Each following section introduces a different scenario for a		Each of the following sub-sections introduces a different scenario
	different set of middleboxes and their ordering within the topology.		for a different set of middleboxes and their ordering within the
	It is assumed that each middlebox implements the NSIS NATFW NSLP		topology. It is assumed that each middlebox implements the NSIS
	signaling protocol.		NATFW NSLP signaling protocol.
	2.1.1 Firewall traversal		2.1 Firewall Traversal
	This section describes a scenario with Firewalls only and NATs are		This section describes a scenario with Firewalls only; NATs are not
	not involved. Both end hosts are behind a Firewall that is connected		involved. Each end host is behind a Firewall. The Firewalls are
	via the public Internet. Figure 2 shows the topology. The part		connected via the public Internet. Figure 2 shows the topology. The
	labeled "public" is the Internet connection both Firewalls.		part labeled "public" is the Internet connecting both Firewalls.
	+----+ //----\\ +----+		+----+ //----\\ +----+
	NI -----| FW |---| |------| FW |--- NR		NI -----| FW |---| |------| FW |--- NR
	+----+ \\----// +----+		+----+ \\----// +----+
	private public private		private public private
	FW: Firewall		FW: Firewall
	NI: NSIS Initiator		NI: NSIS Initiator
	NR: NSIS Responder		NR: NSIS Responder
	Figure 2: Firewall Traversal Scenario		Figure 2: Firewall Traversal Scenario
	Each Firewall on-path must provide traversal service for NATFW NSLP		Each Firewall on the data path must provide traversal service for
	in order to permit the NSIS message to reach the other end host. All		NATFW NSLP in order to permit the NSIS message to reach the other end
	Firewalls process NSIS signaling and establish appropriate policy		host. All Firewalls process NSIS signaling and establish appropriate
	rules, so that the required data packet flow can traverse them.		policy rules, so that the required data packet flow can traverse
			them.
	2.1.2 NAT with two private Networks		2.2 NAT with two private Networks
	Figure 3 shows a scenario with NATs at both ends of the network.		Figure 3 shows a scenario with NATs at both ends of the network.
	Therefore, each application instance, NSIS initiator and NSIS		Therefore, each application instance, NSIS initiator and NSIS
	responder, are behind NATs. The outermost NAT at each side is		responder, are behind NATs. The outermost NAT at each side is
	connected to the public Internet. The NATs are labeled as MB (for		connected to the public Internet. The NATs are generically labeled
	middlebox), since those devices implement at least NAT-only, but can		as MB (for middlebox), since those devices definitely implement NAT
	implement Firewalling as well.		functionality, but can implement firewall functionality as well.
	Only two middleboxes MB are shown in Figure 3 at each side, but in		Only two middleboxes MB are shown in Figure 3 at each side, but in
	general more than one MB on each side must be considered.		general, any number of MBs on each side must be considered.
	+----+ +----+ //----\\ +----+ +----+		+----+ +----+ //----\\ +----+ +----+
	NI --| MB |-----| MB |---| |---| MB |-----| MB |--- NR		NI --| MB |-----| MB |---| |---| MB |-----| MB |--- NR
	+----+ +----+ \\----// +----+ +----+		+----+ +----+ \\----// +----+ +----+
	private public private		private public private
	MB: Middlebox		MB: Middlebox
	NI: NSIS Initiator		NI: NSIS Initiator
	NR: NSIS Responder		NR: NSIS Responder
	Figure 3: NAT with two private networks Scenario		Figure 3: NAT with two Private Networks Scenario
	Signaling traffic from NI to NR has to traverse all four middleboxes		Signaling traffic from NI to NR has to traverse all the middleboxes
	on the path and all four middleboxes must be configured properly to		on the path, and all the middleboxes must be configured properly to
	allow NSIS signaling to traverse. The NATFW signaling must configure		allow NSIS signaling to traverse them. The NATFW signaling must
	all middleboxes and consider any address translation in further		configure all middleboxes and consider any address translation that
	signaling. The sender (NI) has to know the IP address of the		will result from this configuration in further signaling. The sender
	receiver (NR) in advance, otherwise he cannot send a single NSIS		(NI) has to know the IP address of the receiver (NR) in advance,
	signaling message towards the responder. Note that this IP address		otherwise it will not be possible to send any NSIS signaling messages
	is not the private IP address of the responder. Instead a NAT		towards the responder. Note that this IP address is not the private
	binding (including a public IP address) has to be obtained from the		IP address of the responder. Instead a NAT binding (including a
	NAT that subsequently allows packets hitting the NAT to be forwarded		public IP address) has to be previously installed on the NAT that
	to the receiver within the private address realm. This generally		subsequently allows packets reaching the NAT to be forwarded to the
	requires further support from an application layer protocol for the		receiver within the private address realm. This generally requires
	purpose of discovering and exchanging information. The receiver		further support from an application layer protocol for the purpose of
	might have a number of ways to learn its public IP address and port		discovering and exchanging information. The receiver might have a
	number and might need to signal this information to the sender using		number of ways to learn its public IP address and port number and
	the application level signaling protocol.		might need to signal this information to the sender using the
			application level signaling protocol.
	2.1.3 NAT with private network on sender side		2.3 NAT with Private Network on Sender Side
	This scenario shows an application instance at the sending node that		This scenario shows an application instance at the sending node that
	is behind one or more NATs (shown as MB). The receiver is located in		is behind one or more NATs (shown as generic MB, see discussion in
	the public Internet.		Section 2.2). The receiver is located in the public Internet.
	+----+ +----+ //----\\		+----+ +----+ //----\\
	NI --| MB |-----| MB |---| |--- NR		NI --| MB |-----| MB |---| |--- NR
	+----+ +----+ \\----//		+----+ +----+ \\----//
	private public		private public
	MB: Middlebox		MB: Middlebox
	NI: NSIS Initiator		NI: NSIS Initiator
	NR: NSIS Responder		NR: NSIS Responder
	Figure 4: NAT with private network on sender scenario		Figure 4: NAT with Private Network on Sender Side Scenario
	The traffic from NI to NR has to traverse only middleboxes on the		The traffic from NI to NR has to traverse middleboxes only on the
	sender's side. The receiver has a public IP address. The NI sends		sender's side. The receiver has a public IP address. The NI sends
	its signaling message directly to the address of the NSIS responder.		its signaling message directly to the address of the NSIS responder.
	Middleboxes along the path intercept the signaling messages and		Middleboxes along the path intercept the signaling messages and
	configure the policy rules accordingly.		configure the policy rules accordingly.
	Note that the data sender does not necessarily know whether the		Note that the data sender does not necessarily know whether the
	receiver is behind a NAT or not, hence, it is the receiving side that		receiver is behind a NAT or not, hence, it is the receiving side that
	has to detect whether itself is behind a NAT or not. As described in		has to detect whether itself is behind a NAT or not. As described in
	Section 3.2.2 NSIS can also provide help for this procedure.		Section 3.3.2 NSIS can also provide help for this procedure.
	2.1.4 NAT with private network on receiver side		2.4 NAT with Private Network on Receiver Side Scenario
	The application instance receiving data is behind one or more NATs.		The application instance receiving data is behind one or more NATs
			shown as MB (see discussion in Section 2.2).
	//----\\ +----+ +----+		//----\\ +----+ +----+
	NI ---| |---| MB |-----| MB |--- NR		NI ---| |---| MB |-----| MB |--- NR
	\\----// +----+ +----+		\\----// +----+ +----+
	public private		public private
	MB: Middlebox		MB: Middlebox
	NI: NSIS Initiator		NI: NSIS Initiator
	NR: NSIS Responder		NR: NSIS Responder
	Figure 5: NAT with private network on receiver Scenario		Figure 5: NAT with Private Network on Receiver Scenario
	Initially, the NSIS responder must determine its public reachable IP		Initially, the NSIS responder must determine its public reachable IP
	address at the external middlebox and notify the NSIS initiator about		address at the external middlebox and notify the NSIS initiator about
	this address. One possibility is that an application level protocol		this address. One possibility is that an application level protocol
	is used, meaning that the public IP address is signaled via this		is used, meaning that the public IP address is signaled via this
	protocol to the NI. Afterwards the NI can start its signaling		protocol to the NI. Afterwards the NI can start its signaling
	towards the NR and so establishing the path via the both middleboxes		towards the NR and so establishing the path via the middleboxes in
	MB.		the receiver side private network.
	This scenario describes the use case for the reserve mode of the		This scenario describes the use case for the RESERVE mode of the
	NATFW NSLP.		NATFW NSLP.
	2.1.5 Both End Hosts behind twice-NATs		2.5 Both End Hosts behind twice-NATs
	This is a special case, where the main problem is to detect that both		This is a special case, where the main problem consists of detecting
	nodes are logically within the same address space, also behind a		that both end hosts are logically within the same address space, but
	twice-NAT (see [8] for discussion about twice-NAT functionality).		are also in two partitions of the address realm on either side of a
			twice-NAT (see [8] for a discussion of twice-NAT functionality).
	Sender and receiver are both within a private address realm and		Sender and receiver are both within a single private address realm
	potentially have overlapping IP addresses. Figure 6 shows the		but the two partitions potentially have overlapping IP address
	ordering of NATs. This is a common configuration in several		ranges. Figure 6 shows the arrangement of NATs. This is a common
	networks, particularly after the merging of companies that have used		configuration in networks, particularly after the merging of
	the same address space, thus having overlapping addresses in many		companies that have used the same private address space, resulting in
	cases.		overlapping address ranges.
	public		public
	+----+ +----+ //----\\		+----+ +----+ //----\\
	NI --| MB |--+--| MB |---| |		NI --| MB |--+--| MB |---| |
	+----+ | +----+ \\----//		+----+ | +----+ \\----//
	|		|
	| +----+		| +----+
	+--| MB |------------ NR		+--| MB |------------ NR
	+----+		+----+
	private		private
	MB: Middlebox		MB: Middlebox
	NI: NSIS Initiator		NI: NSIS Initiator
	NR: NSIS Responder		NR: NSIS Responder
	Figure 6: NAT to public, sender and receiver behind twice-NAT		Figure 6: NAT to Public, Sender and Receiver on either side of a
	Scenario		twice-NAT Scenario
	The middleboxes shown in Figure 6 are twice-NATs, i.e. they map IP		The middleboxes shown in Figure 6 are twice-NATs, i.e., they map IP
	addresses and port numbers on both sides, at private and public		addresses and port numbers on both sides, at private and public
	interfaces.		interfaces.
	This scenario requires assistance of application level entities, like		This scenario requires assistance of application level entities, such
	DNS server. Those application level gateways must handle request		as a DNS server. The application level gateways must handle requests
	that are based on symbolic names and configure the middleboxes so		that are based on symbolic names, and configure the middleboxes so
	that data packets are correctly forwarded from NI to NR. The		that data packets are correctly forwarded from NI to NR. The
	configuration of those middleboxes may require other middlebox		configuration of those middleboxes may require other middlebox
	communication protocols, like MIDCOM [7]. NSIS signaling is not		communication protocols, like MIDCOM [7]. NSIS signaling is not
	required in the twice-NAT only case, since the middleboxes of type		required in the twice-NAT only case, since the middleboxes of the
	twice-NAT are configured by other means. Nevertheless, NSIS		twice-NAT type are normally configured by other means. Nevertheless,
	signaling might by useful when there are Firewalls on path. In this		NSIS signaling might by useful when there are Firewalls on path. In
	case NSIS will not configure any policy rule at twice-NATs, but will		this case NSIS will not configure any policy rule at twice-NATs, but
	configure policy rules at the intermediate Firewalls. The NSIS		will configure policy rules at the Firewalls on the path. The NSIS
	signaling protocol must be at least robust enough to survive this		signaling protocol must be at least robust enough to survive this
	scenario.		scenario.
	2.1.6 Both End Hosts behind same NAT		2.6 Both End Hosts Behind Same NAT
	When NSIS initiator and NSIS responder are behind the same NAT (thus		When NSIS initiator and NSIS responder are behind the same NAT (thus
	being in the same address realm, see Figure 7), they are most likely		being in the same address realm, see Figure 7), they are most likely
	not aware of this fact. As in Section 2.1.4 the NSIS responder must		not aware of this fact. As in Section 2.4 the NSIS responder must
	determine its public IP address in advance and transfer it to the		determine its public IP address in advance and transfer it to the
	NSIS initiator. Afterwards, the NSIS initiator can start sending the		NSIS initiator. Afterwards, the NSIS initiator can start sending the
	signaling messages to the responder's public IP address. During this		signaling messages to the responder's public IP address. During this
	process, a public IP address will be allocated for the NSIS initiator		process, a public IP address will be allocated for the NSIS initiator
	at the same middlebox as for the responder. Now, the NSIS signaling		at the same middlebox as for the responder. Now, the NSIS signaling
	and the subsequent data packets will traverse the NAT two times: from		and the subsequent data packets will traverse the NAT twice: from
	initiator to public IP address of responder (first time) and from		initiator to public IP address of responder (first time) and from
	public IP address of responder to responder (second time). This is		public IP address of responder to responder (second time). This is
	the worst case, both sender and receiver obtain a public IP address		the worst case in which both sender and receiver obtain a public IP
	at the NAT and the communication path is not optimal anymore.		address at the NAT, and the communication path is certainly not
			optimal in this case.
	NI public		NI public
	\ +----+ //----\\		\ +----+ //----\\
	+-| MB |----| |		+-| MB |----| |
	/ +----+ \\----//		/ +----+ \\----//
	NR		NR
	private		private
	MB: Middlebox		MB: Middlebox
	NI: NSIS Initiator		NI: NSIS Initiator
	NR: NSIS Responder		NR: NSIS Responder
	Figure 7: NAT to public, both host behind same NAT		Figure 7: NAT to Public, Both Hosts Behind Same NAT
	NSIS NATFW signaling protocol should support mechanisms to detect		The NSIS NATFW signaling protocol should support mechanisms to detect
	such a scenario. The signaling should directly by exchanged between		such a scenario. The signaling should be exchanged directly between
	NI and NR without involving the middlebox.		NI and NR without involving the middlebox.
	2.1.7 IPv4/v6 NAT with two private networks		2.7 IPv4/v6 NAT with two Private Networks
	This scenario combines the usage case mentioned in Section 2.1.2		This scenario combines the use case described in Section 2.2 with the
	with the IPv4 to IPv6 transition scenario, i.e. using Network		IPv4 to IPv6 transition scenario involving address and protocol
	Address and Protocol Translators (NAT-PT, [11]).		translation, i.e., using Network Address and Protocol Translators
			(NAT-PT, [11]).
	The difference to the other scenarios is the use of IPv6 to IPv4 (and		The difference from the other scenarios is the use of IPv6 to IPv4
	vice versa) address and protocol translation. Additionally, the base		(and vice versa) address and protocol translation. Additionally, the
	NTLP must take care of this case for its own functionality of		base NTLP must support transport of messages in mixed IPv4 and IPv6
	forwarding messages between NSIS peers.		networks where some NSIS peers provide translation.
	+----+ +----+ //---\\ +----+ //---\\ +----+ +----+		+----+ +----+ //---\\ +----+ //---\\ +----+ +----+
	NI --| MB |--| MB |--| |--| MB |-| |--| MB |--| MB |-- NR		NI --| MB |--| MB |--| |--| MB |-| |--| MB |--| MB |-- NR
	+----+ +----+ \\---// +----+ \\---// +----+ +----+		+----+ +----+ \\---// +----+ \\---// +----+ +----+
	private public public private		private public public private
	IPv4 IPv6		IPv4 IPv6
	MB: Middlebox		MB: Middlebox
	NI: NSIS Initiator		NI: NSIS Initiator
	NR: NSIS Responder		NR: NSIS Responder
	Figure 8: IPv4/v6 NAT with two private networks		Figure 8: IPv4/v6 NAT with two Private Networks
	This scenario needs the same type of application level support as		This scenario needs the same type of application level support as
	described in Section 2.1.5 and so those issues of twice-NATs apply		described in Section 2.5, and so the issues relating to twice-NATs
	here as well.		apply here as well.
	2.1.8 Multihomed Network with NAT		2.8 Multihomed Network with NAT
	The previous chapters sketched network topologies where NAT and		The previous sub-sections sketched network topologies where several
	Firewalls are ordered sequentially on the path. This chapter		NATs and/or Firewalls are ordered sequentially on the path. This
	describes a multihomed scenario with two NATs to the Internet.		section describes a multihomed scenario with two NATs placed on
			alternative paths to the public network.
	+----+		+----+
	NI -------| MB |\		NI -------| MB |\
	\ +----+ \ //---\\		\ +----+ \ //---\\
	\ -| |-- NR		\ -| |-- NR
	\ \\---//		\ \\---//
	\ +----+ |		\ +----+ |
	--| MB |-------+		--| MB |-------+
	+----+		+----+
	private		private
	private public		private public
	MB: Middlebox		MB: Middlebox
	NI: NSIS Initiator		NI: NSIS Initiator
	NR: NSIS Responder		NR: NSIS Responder
	Figure 9: Multihomed Network with two NATs		Figure 9: Multihomed Network with Two NATs
	Depending on the destination the one or the other middlebox is used
	for the data flow. Which middlebox is used depends on local routing
	decisions. NATFW NSLP must be able to handle this situation proper,
	see Section 3.2.2 for a more elaborated discussion of this topic with
	respect to NATs.
	2.2 Trust Relationship and Authorization
	Trust relationships and authorization are very important for the
	protocol machinery. Trust and authorization are closely related to
	each other in the sense that a certain degree of trust is required to
	authorize a particular action. For any action (e.g. "create/delete
	/prolong policy rules" then authorization is very important due to
	the nature of middleboxes.
	It is particularly not surprising that different degrees of required
	authorization in a QoS signaling environment and middlebox signaling
	exist. As elaborated in [23], establishment of a financial
	relationship is very important for QoS signaling, whereas for
	middlebox signaling is not directly of interest. For middlebox
	signaling a stronger or weaker degree of authorization might be
	needed.
	Different trust relationships that appear in middlebox signaling
	environments are described in the subsequent sections. Peer-to-peer
	trust relationships are those, which are used in QoS signaling today
	and seem to be the simplest. However, there are reasons to believe
	that this is not the only type of trust relationship found in today's
	networks.
	2.2.1 Peer-to-Peer Trust Relationship
	Starting with the simplest scenario it is assumed that neighboring
	nodes trust each other. The required security association to
	authenticate and to protect a signaling message is either available
	(manual configuration) or dynamically established with the help of an
	authentication and key exchange protocol. If nodes are located
	closely together it is assumed that security association
	establishment is easier than establishing it between far distant
	node. It is, however, difficult to describe this relationship
	generally due to the different usage scenarios and environments.
	Authorization heavily depends on the participating entities but for
	this scenario it is assumed that neighboring entities trust each
	other (at least for the purpose of policy rule creation, maintenance
	and deletion). Note that Figure 10 does not illustrate the trust
	relationship between the end host and the access network.
	+------------------------+ +-------------------------+
	| | | |
	| Network A | | Network B |
	| | | |
	| +---------+ +---------+ |
	| +-///-+ Middle- +---///////----+ Middle- +-///-+ |
	| | | box 1 | Trust | box 2 | | |
	| | +---------+ Relationship +---------+ | |
	| | | | | |
	| | | | | |
	| | | | | |
	| | Trust | | Trust | |
	| | Relationship | | Relationship | |
	| | | | | |
	| | | | | |
	| | | | | |
	| +--+---+ | | +--+---+ |
	| | Host | | | | Host | |
	| | A | | | | B | |
	| +------+ | | +------+ |
	+------------------------+ +-------------------------+
	Figure 10: Peer-to-Peer Trust Relationship
	2.2.2 Intra-Domain Trust Relationship
	In larger corporations often more than one middlebox is used to
	protect different departments. In many cases the entire enterprise
	is controlled by a security department, which gives instructions to
	the department administrators. In such a scenario a peer-to-peer
	trust-relationship might be prevalent. Sometimes it might be
	necessary to preserve authentication and authorization information
	within the network. As a possible solution a centralized approach
	could be used whereby an interaction between the individual
	middleboxes and a central entity (for example a policy decision point
	- PDP) takes place. As an alternative individual middleboxes could
	exchange the authorization decision to another middlebox within the
	same trust domain. Individual middleboxes within an administrative
	domain should exploit their trust relationship instead of requesting
	authentication and authorization of the signaling initiator again and
	again. Thereby complex protocol interaction is avoided. This
	provides both a performance improvement without a security
	disadvantage since a single administrative domain can be seen as a
	single entity. Figure 11 illustrates a network structure, which uses
	a centralized entity.
	+-----------------------------------------------------------+
	| |
	| Network A |
	| |
	| |
	| +---------+ +---------+
	| +----///--------+ Middle- +------///------++ Middle- +---
	| | | box 2 | | box 2 |
	| | +----+----+ +----+----+
	| | | | |
	| +----+----+ | | |
	| | Middle- +--------+ +---------+ | |
	| | box 1 | | | | |
	| +----+----+ | | | |
	| | | | | |
	| - | | | |
	| - | +----+-----+ | |
	| | | | Policy | | |
	| +--+---+ +-----------+ Decision +----------+ |
	| | Host | | Point | |
	| | A | +----------+ |
	| +------+ |
	+-----------------------------------------------------------+
	Figure 11: Intra-domain Trust Relationship
	2.2.3 End-to-Middle Trust Relationship
	In some scenarios a simple peer-to-peer trust relationship between		Depending on the destination or load balancing requirements, either
	participating nodes is not sufficient. Network B might require		one or the other middlebox is used for the data flow. Which
	additional authorization of the signaling message initiator. If		middlebox is used depends on local policy or routing decisions.
	authentication and authorization information is not attached to the		NATFW NSLP must be able to handle this situation properly, see
	initial signaling message then the signaling message arriving at		Section 3.3.2 for an expanded discussion of this topic with respect
	Middlebox 2 would cause an error message to be created, which		to NATs.
	indicates the additional authorization requirement. In many cases
	the signaling message initiator is already aware of the additionally
	required authorization before the signaling message exchange is
	executed. Replay protection is a requirement for authentication to
	the non-neighboring middlebox, which might be difficult to accomplish
	without adding additional roundtrips to the signaling protocol (e.g.
	by adding a challenge/response type of message exchange).
	Figure 12 shows the slightly more complex trust relationships in this		3. Protocol Description
	scenario.
	+----------------------+ +--------------------------+		This section defines messages, objects, and protocol semantics for
	| | | |		the NATFW NSLP. Section 3.1 introduces the base constituent element
	| Network A | | Network B |		of a session state, the policy rule. Section 3.2 introduces the
	| | | |		protocol and the protocol behavior is defined in Section 3.3.
	| | Trust | |		Section 5 defines the syntax of the messages and objects.
	| | Relationship | |
	| +---------+ +---------+ |
	| +-///-+ Middle- +---///////----+ Middle- +-///-+ |
	| | | box 1 | +-------+ box 2 | | |
	| | +---------+ | +---------+ | |
	| | | | | | |
	| |Trust | | | | |
	| |Relationship | | | | |
	| | | | | Trust | |
	| | | | | Relationship| |
	| | | | | | |
	| | | | | | |
	| | | | | | |
	| | | | | | |
	| +--+---+ | | | +--+---+ |
	| | Host +----///----+------+ | | Host | |
	| | A | |Trust | | B | |
	| +------+ |Relationship | +------+ |
	+----------------------+ +--------------------------+
	Figure 12: End-to-Middle Trust Relationship		3.1 Policy Rules
	3. Protocol Description		Policy rules, bounded to a session, are the building block of
			middlebox devices considered in the NATFW NSLP. For Firewalls the
			policy rule consists usually of a 5-tuple, source/destination
			address, transport protocol, and source/destination port number, plus
			an action like allow or deny. For NATs the policy rule consists of
			action 'translate this address to realms address pool' and further
			mapping information, that might be in the most simply case internal
			IP address and external IP address.
	The protocol description section defines the NSIS NATFW NSLP with its		Policy rules are usually carried in one piece in signaling
	messages, objects, and the protocol semantics. Section 3.1		applications. In NSIS the policy rule is divided into the filter
	introduces the protocol and Section 3.3 defines the syntax of the		specification, an allow or deny action, and additional information.
	messages and objects. The protocol behavior is defined in Section		The filter specification is carried within NTLP's message routing
	3.2.		information (MRI) and additional information is carried in NSLP's
			objects. Additional information is, for example, the lifetime of a
			policy rule or session.
	3.1 Basic protocol overview		3.2 Basic protocol overview
	The NSIS Signaling Layer Protocol (NSLP) for NAT and FW traversal is		The NSIS NATFW NSLP is carried over the NSIS Transport Layer Protocol
	carried over the NSIS Transport Layer Protocol (NTLP) defined in [3].		(NTLP) defined in [3]. NATFW NSLP messages are initiated by the NSIS
	NATFW NSLP messages are initiated by the NSIS initiator (NI), handled		initiator (NI), handled by NSIS forwarders (NF) and finally processed
	by NSIS forwarders (NF) and finally processed by the NSIS responder		by the NSIS responder (NR). It is required that at least NI and NR
	(NR). It is required that at least NI and NR implement this NSLP,		implement this NSLP, intermediate NF only implement this NSLP when
	intermediate NF only implement this NSLP when they provide middlebox		they provide middlebox functions. NSIS forwarders that do not have
	functions. Forwarders that do not have any NATFW NSLP functions just		any NATFW NSLP functions just forward these packets when they have no
	forward these messages; those forwarders implement NTLP and one or		interest (which is expected to happen in most cases).
	more other NSLPs.
	A Data Sender (DS) that is intending to send data to a Data Receiver		A Data Sender (DS), intending to send data to a Data Receiver (DR)
	(DR) must start its NATFW NSLP signaling. So the NI at the data		must first start its NATFW NSLP signaling. In the next step, the NI
	sender (DS) starts NSLP signaling towards the address of data		at the data sender (DS) starts NSLP signaling towards the address of
	receiver DR (see Figure 13).		data receiver DR (see Figure 10). Although the above NATFW NSLP
			usage is expected to be the most common, this specification does not
			prevent scenarios where the data sender and NI reside on different
			hosts.
	+-------+ +-------+ +-------+ +-------+		+-------+ +-------+ +-------+ +-------+
	| DS/NI |<~~~| MB1/ |<~~~| MB2/ |<~~~| DR/NR |		| DS/NI |<~~~| MB1/ |<~~~| MB2/ |<~~~| DR/NR |
	| |--->| NF1 |--->| NF2 |--->| |		| |--->| NF1 |--->| NF2 |--->| |
	+-------+ +-------+ +-------+ +-------+		+-------+ +-------+ +-------+ +-------+
	========================================>		========================================>
	Data Traffic Direction		Data Traffic Direction
	---> : NATFW NSLP request signaling		---> : NATFW NSLP request signaling
	~~~> : NATFW NSLP response signaling		~~~> : NATFW NSLP response signaling
	DS/NI : Data sender and NSIS initiator		DS/NI : Data sender and NSIS initiator
	DR/NR : Data receiver and NSIS responder		DR/NR : Data receiver and NSIS responder
	MB1 : Middlebox 1 and NSIS forwarder 1		MB1 : Middlebox 1 and NSIS forwarder 1
	MB2 : Middlebox 2 and NSIS forwarder 2		MB2 : Middlebox 2 and NSIS forwarder 2
	Figure 13: General NSIS signaling		Figure 10: General NSIS signaling
	The NSLP request messages are processed each time a NF with NATFW		The sequence of NSLP events is as follows:
	NSLP support is passed. Those nodes process the message, check local		o NSLP request messages are processed each time a NF with NATFW NSLP
	policies for authorization and authentication, possibly create policy		support is passed. These nodes process the message, check local
	rules, and forward the signaling message to the next NSIS node. The		policies for authorization and authentication, possibly create
	request message is forwarded until it reaches the NSIS responder.		policy rules, and forward the signaling message to the next NSIS
	NSIS responders will check received messages and process those if		node. The request message is forwarded until it reaches the NSIS
	applicable. NSIS responders generate response messages and sent them		responder.
	back to the NI via the same chain of NFs. The response message is		o NSIS responders will check received messages and process them if
	processed at each NI forwarder implementing NATFW NSLP. The Data		applicable. NSIS responders generate response messages and send
	Sender can start sending its data flow to the Data Receiver, when the		them hop-by-hop back to the NI via the same chain of NFs
	signaling was successful, meaning that NI has received a successful		(traversal of the same NF chain is guaranteed through the
	response.		established reverse message routing state in the NTLP).
			o The response message is processed at each NF implementing NATFW
			NSLP.
			o Once the NI has received a successful response, the Data Sender
			can start sending its data flow to the Data Receiver.
	In general, NATFW NSLP signaling follows the data path from DS to DR.		NATFW NSLP signaling follows the data path from DS to DR, this
	This enables communication between both hosts for scenarios with only		enables communication between both hosts for scenarios with only
	Firewalls on the data path or NATs on sender side. For scenarios		Firewalls on the data path or NATs on sender side. For scenarios
	with NATs on the receiver side certain problems arise, see also		with NATs on the receiver side certain problems arise, see also
	Section 2.		Section 2.
	When Data receiver (DR) and Data Sender (DS) are located in different		When the NR and the NI are located in different address realms and
	address realms and DR is behind a NAT, DS cannot signal to DR		the NR is behind a NAT, the NI cannot signal to the NR directly. The
	directly. DR is not reachable from DS and thus no NATFW signaling		NR is not reachable from the NIs and thus no NATFW signaling messages
	can be sent to DR's address. Therefore, DR must first determine an		can be sent to the DR's address. Therefore, the NR must first obtain
	address at a NAT that is reachable for DS, for instance DR must		a NAT binding that is reachable for the NI. Once the NR has
	determine its public IP address. Once DR has determined a public		determined a public IP address, it forwards this information to the
	address it forwards this to DS via a separate mechanism, which may be		DS via a separate protocol (such as SIP). This application layer
	application level signaling like SIP. This application level		signaling, out of scope of the NATFW NSLP, may involve third parties
	signaling may involve third parties that assist in exchanging this		that assist in exchanging these messages.
	information. This separate mechanism is out of scope of NATFW NSLP.
	NATFW NSLP signaling supports this public address fixing with this		NATFW NSLP signaling supports this scenario by using the RESERVE mode
	mechanism:		of operation :
	o First, DR determines a public address by signaling on the reverse		1. The NR determines a public address by signaling on the reverse
	path (DR towards DS) and thus making itself available to other		path (NR towards NI) and thus making itself available to other
	hosts. This process of determining a public addresses is called		hosts. This process of determining a public addresses is called
	reservation. This way DR reserves publicly reachable addresses		reservation. This way DR reserves publicly reachable addresses
	and ports, but this address/port cannot be used by data traffic at		and ports, but this address/port cannot be used by data traffic
	this point of time.		at this point of time.
	o Second, DS is signaling directly to DR as DS would do if there is		2. The NI signals directly the NR as NI would do if there is no NAT
	no NAT in between, and so creating policy rules at middleboxes.		in between, and creates policy rules at middleboxes. Note, that
	Note, that the reservation mode will make reservations only,		the reservation mode will make reservations only, which will be
	which will be "activated" by the signaling from DS towards DR.		"activated" by the signaling from NI towards NR. The first mode
	The first mode is detailed in the Section 3.2.2		is detailed in the Section 3.3.2
	The protocol works on a soft-state basis, meaning that that whatever		The protocol works on a soft-state basis, meaning that whatever state
	state is installed or reserved on a middlebox, it will expire, and		is installed or reserved on a middlebox, it will expire, and thus be
	thus be de-installed/ forgotten after a certain period of time. To		de-installed/ forgotten after a certain period of time. To prevent
	prevent this, the involved boxes will have to specifically request a		this, the NATFW nodes involved will have to specifically request a
	session extension. An explicit NATFW NSLP state deletion message is		session extension. An explicit NATFW NSLP state deletion capability
	also provided by the protocol.		is also provided by the protocol.
	Middleboxes should report back in case of error, so that appropriate		Middleboxes should return an error in case of a failure, such that
	measures and debugging can be performed.		appropriate actions can be taken; this ability would allow debugging
			and error recovery. Error messages could be sent upstream (for
			errors related to received messages as well as asynchronous error
			notification messages) towards the NI as well as downstream towards
			the NR (case of asynchronous error notification messages).
	The next sections define the NATFW NSLP message types and formats,		The next sections define the NATFW NSLP message types and formats,
	protocol operations, and policy rule operations.		protocol operations, and policy rule operations.
	3.2 Protocol Operations		3.3 Protocol Operations
	This section defines the protocol operations, how to create sessions,		This section defines the protocol operations, how to create sessions,
	maintain them, and how to reserve addresses.		maintain them, and how to reserve addresses. All the protocols
			messages require C-mode handling by the NTLP and cannot be
			piggybacked to D-mode NTLP messages used during the NTLP path
			discovery/refresh phase. The protocol messages NTLP usage is
			described in more details within Section 5.
	3.2.1 Creating Sessions		The protocol uses six messages:
			o CREATE: a request message used for creating, changing, refreshing
			and deleting NATFW NSLP sessions.
			o RESERVE-EXTERNAL-ADDRESS (REA): a request message used for
			reserving an external address
			o RESPONSE: used to response to CREATE, REA and QUERY messages with
			Success or Error information
			o QUERY: a request message used by authorized NATFW NEs for querying
			NATFW on installed stated
			o NOTIFY: an asynchronous message used by NATFW NEs to alert
			upstream and/or downstream NATFW NEs about specific events (mainly
			failures).
			o TRIGGER: a message sent upstream to trigger CREATE messages to be
			sent.
			The following sections will present the semantics of these messages
			by exhibiting their impact on the protocol state machine.
			3.3.1 Creating Sessions
	Allowing two hosts to exchange data even in the presence of		Allowing two hosts to exchange data even in the presence of
	middleboxes is realized in the NATFW NSLP by the 'create session'		middleboxes is realized in the NATFW NSLP by the 'CREATE ' request
	request message. The data sender generates a 'create session'		message. The data sender generates a CREATE message as defined in
	message as defined in Section 3.4.2 and handles it to the NTLP. The		Section 5.4.1 and hands it to the NTLP. The NTLP forwards the whole
	NTLP forwards the whole message on the basis of the flow routing		message on the basis of the message routing information towards the
	information towards DR. Each NSIS forwarders along the path that is		NR. Each NSIS forwarder along the path that is implementing NATFW
	implementing NATFW NSLP process the NSLP message, this is done NSLP		NSLP, processes the NSLP message. Forwarding is thus managed NSLP
	hop-by-hop. Finally, the message is approaching DR, DR can accept		hop-by-hop but may pass transparently through NSIS forwarders which
	the request or reject it. DR generates a response to the request,		do not contain NATFW NSLP functionality and non-NSIS aware routers
	this response is transported hop by hop towards (XXX terminology) DS.		between NSLP hop waypoints. When the message reaches the NR, the NR
	NATFW NSLP forwarders may reject requests at any time. Figure 14		can accept the request or reject it. NR generates a response to the
			request and this response is transported hop-by-hop towards the NI.
			NATFW NSLP forwarders may reject requests at any time. Figure 11
	sketches the message flow between NI (DS), a NF (NAT), and NR (DR).		sketches the message flow between NI (DS), a NF (NAT), and NR (DR).
	NI Private Network NF Public Internet NR		NI Private Network NF Public Internet NR
	| | |		| | |
	| Create | |		| CREATE | |
	|----------------------------->| |		|----------------------------->| |
	| | |		| | |
	| Error (if necessary) | |		| RESPONSE[Error](if necessary)| |
	|<-----------------------------| Create |		|<-----------------------------| CREATE |
	| |--------------------------->|		| |--------------------------->|
	| | |		| | |
	| | Path Succeeded/Error |		| | RESPONSE[Success/Error] |
	| Path Succeeded/Error |<---------------------------|		| RESPONSE[Success/Error] |<---------------------------|
	|<-----------------------------| |		|<-----------------------------| |
	| | |		| | |
	| | |		| | |
	Figure 14: Creation message flow		Figure 11: Creation message flow
	Processing of 'create session' messages is differently per NSIS node:		Since the CREATE message is used for several purposes within the
	o NSLP initiator: NI only generate 'create session' messages and		lifetime of a session, there are several processing rules for NATFW
	handle them over to the NTLP. After receiving a 'path succeeded'		NEs when generating and receiving CREATE messages. The different
	the data path is configured and the NI can start sending its data		processing methods depend not only if the CREATE is used to create,
	to NR. After receiving an 'error' message the NI MAY try to		modify, refresh or delete a session but also on the node at which the
	generate the 'create session' message again or give up, depending		processing happens. For an initial CREATE message the processing of
	on the error condition.		CREATE messages is different for every NSIS node type:
	o NSLP forwarder: NSLP forwarders receiving 'create session'		o NSLP initiator: NI only generates initial CREATE messages and
	messages MUST first check authentication and authorization before		hands them over to the NTLP. After receiving a successful
	any further processing is executed. The NF SHOULD check with its		response, the data path is configured and the DS can start
	local policies if he can accept the desired policy rule given by		sending its data to the DR. After receiving an 'error' response
	NTLP's flow routing information. Further processing depends on		message the NI MAY try to generate the CREATE message again or
	the middlebox type:		give up, depending on the error condition.
	* NAT: When the 'create session' message is received at the		o NATFW NSLP forwarder: NFs receiving an initial CREATE message
	public side a network external node is trying to open a NAT		MUST first check authentication and authorization before any
	binding. First, it looks for a reservation made in advance by		further processing is executed. The NF SHOULD check with its
	means of 'reserve external address' that matches the		local policies if it can accept the desired policy rule given the
	destination address/port of the flow routing information		combination of the NTLP's 'Message-Routing-Information' (MRI) [3]
	provided by the NTLP. If there is no reservation made in		(the flow description information) and the CREATE payload
	advance the NSLP SHOULD return an error message of type 'no		(behavior to be enforced on the packet stream). The NSLP message
	reservation found' and discard the request. If there is a		processing depends on the middlebox type:
	reservation, NSLP stores the data sender's address as part of		* NAT: When the initial CREATE message is received at the public
	the policy rule to be loaded and forwards the message with the		side of the NAT, it looks for a reservation made in advance, by
	address set to the internal address of the next NSIS node.		using a REA message Section 3.3.2 , that matches the
	When the 'create session' message is received at the private		destination address/port of the MRI provided by the NTLP. If
	side the NAT binding is reserved, but not activated. The NSLP		no reservation had been made in advance the NSLP SHOULD return
	message is forwarded to next hop with source address set to the		an error response message of type 'no reservation found' and
	NAT's external address.		discard the request. If there is a reservation, NSLP stores
	* Firewall: When the 'create session' message is received the		the data sender's address as part of the policy rule to be
	NSLP just remembers the requested policy rule, but does not		loaded and forwards the message with the address set to the
	install any policy rule. Afterwards, the message is forwarded		internal (private in most cases) address of the next NSIS node.
	to the next NSLP hop.		When the initial CREATE message, for a new session, is received
			at the private side the NAT binding is reserved, but not
			activated. The NSLP message is forwarded to next hop with
			source address set to the NAT's external address from the newly
			reserved binding.
			* Firewall: When the initial CREATE message is received the NSLP
			just remembers the requested policy rule, but does not install
			any policy rule. Afterwards, the message is forwarded to the
			next NSLP hop. There is a difference between requests from
			trusted (authorized NIs) and un-trusted (un-authorized NIs);
			requests from trusted NIs will be pre-authorized, whereas
			requests from un-trusted NIs will not be pre-authorized. This
			difference is required to speed-up the protocol operations as
			well as for the proxy mode usage (please refer to Section 3.4
			and [17]).
	* Combined NAT and Firewall: Processing at combined Firewall and		* Combined NAT and Firewall: Processing at combined Firewall and
	NAT middleboxes is the same as in the NAT case. No policy		NAT middleboxes is the same as in the NAT case. No policy
	rules are installed. Implementations MUST take care about the		rules are installed. Implementations MUST take into account
	order of Firewall and NAT functions within the device. Order		the order of packet processing in the Firewall and NAT
	of functions is to be interpreted as how packets experience the		functions within the device. This will be referred to as
	treatment of those functions.		'order of functions' and is generally different depending on
	o NSLP receiver: NRs receiving 'create session' messages MUST reply		whether the packet arrives at the external or internal side of
	with a 'path succeeded' message if they accept the request		the middlebox.
	message. Otherwise they SHOULD generate an error message. Both		o NSLP receiver: NRs receiving initial CREATE messages MUST reply
	messages are sent back NSLP hop-by-hop towards NI.		with a 'success' (response object has success information)
			RESPONSE message if they accept the CREATE request message.
			Otherwise they SHOULD generate a RESPONSE message with an error
			code. RESPONSE messages are sent back NSLP hop-by-hop towards the
			NI, independently of the response codes, either success or error.
	Policy rules at middleboxes MUST be only installed upon receiving a		Policy rules at middleboxes MUST be only installed upon receiving a
	successful response of type 'path succeeded'. This is a		successful response. This is a countermeasure to several problems,
	countermeasure to several problems, for instance, loaded policy rules		for example wastage of resources due to loading policy rules at
	at intermediate NF without reaching the actual NR.		intermediate NF when the CREATE message does not reach the final the
			NR for some reason.
	3.2.2 Reserving External Addresses		3.3.2 Reserving External Addresses
	NSIS signaling is intended to travel end-to-end, even in the presence		NSIS signaling is intended to travel end-to-end, even in the presence
	of NATs and Firewalls on-path. This works well in cases where the		of NATs and Firewalls on-path. This works well in cases where the
	data sender is itself behind a NAT and (covered by Section 3.2.1).		data sender is itself behind a NAT as described in Section 3.3.1.
	For scenarios where the data receiver is located behind a NAT and it		For scenarios where the data receiver is located behind a NAT and it
	needs to receive data flows from outside its own network (see Figure		needs to receive data flows from outside its own network (see Figure
	5) it is more troublesome. NSIS signaling, as well as subsequent		5) the problem is more troublesome. NSIS signaling, as well as
	data flows, are directed to a particular destination IP address that		subsequent data flows, are directed to a particular destination IP
	must be known in advance and reachable.		address that must be known in advance and reachable.
	+-------------+ AS-Data Receiver Communication		+-------------+ AS-Data Receiver Communication
	+-------->| Application |<-----------------------------+		+-------->| Application |<-----------------------------+
	| | Server | |		| | Server | |
	| +-------------+ |		| +-------------+ |
	| IP(R-NAT_B) |		| IP(R-NAT_B) |
	| NSIS Signaling Message +-------+--+		| NSIS Signaling Message +-------+--+
	| +------------------------------------------>| NAT/NAPT |		| +------------------------------------------>| NAT/NAPT |
	| | | B |		| | | B |
	| | +-------+--+		| | +-------+--+
	skipping to change at page 25, line 41 ¶		skipping to change at page 24, line 30 ¶
	| | |		| | |
	| | |		| | |
	| | |		| | |
	| | |		| | |
	v | IP(R) v		v | IP(R) v
	+--------+ +---------+		+--------+ +---------+
	| Data | | Data |		| Data | | Data |
	| Sender | | Receiver|		| Sender | | Receiver|
	+--------+ +---------+		+--------+ +---------+
	Figure 15: The Data Receiver behind NAT problem		Figure 12: The Data Receiver behind NAT problem
	Figure 15 describes a typical message communication in a peer-to-peer		Figure 12 describes a typical message communication in a peer-to-peer
	networking environment whereby the two end points learn of each		networking environment whereby the two end points learn of each
	others existence with the help of a third party (referred as		others existence with the help of a third party (referred as
	Application Server). The communication with the application server		Application Server). The communication between the application
	and the two end points (data sender and data receivers) serves a		server each of the two end points (data sender and data receiver)
	number of functions. As one of the most important functions it		enables the two end hosts to learn each others IP address. The
	enables the two end hosts to learn the IP address of each other. The
	approach described in this memo supports this peer-to-peer approach,		approach described in this memo supports this peer-to-peer approach,
	but is not limited to it.		but is not limited to it.
	Some sort of communication between the data sender/data receiver and		Some sort of communication between the data sender/data receiver and
	a third party is typically necessary (independently of NSIS). NSIS		a third party is typically necessary (independently of NSIS). NSIS
	signaling messages cannot be used to communicate application level		signaling messages cannot be used to communicate application level
	relevant end point identifiers (in the generic case at least) as a		relevant end point identifiers (in the generic case at least) as a
	replacement for the communication with the application server.		replacement for the communication with the application server.
	If the data receiver is behind a NAT then an NSIS signaling message		If the data receiver is behind a NAT then an NSIS signaling message
	will be addressed to the IP address allocated at the NAT (if there		will be addressed to the IP address allocated at the NAT (if there
	was one allocated). If no corresponding NSIS NAT Forwarding State at		was one allocated). If no corresponding NSIS NAT Forwarding State at
	NAT/NAPT B exists (binding IP(R-NAT B) <-> IP(R)) then the signaling		NAT/NAPT B exists (binding IP(R-NAT B) <-> IP(R)) then the signaling
	message will terminate at the NAT device (most likely without proper		message will terminate at the NAT device (most likely without proper
	response message). The signaling message transmitted by the data		response message). The signaling message transmitted by the data
	sender cannot install the NAT binding or NSIS NAT Forwarding State		sender cannot install the NAT binding or NSIS NAT Forwarding State
	"on-the-fly" since this would assume that the data sender knows the		"on-the-fly" since this would assume that the data sender knows the
	topology at the data receiver side (i.e. the number and the		topology at the data receiver side (i.e., the number and the
	arrangement of the NAT and the private IP address(es) of the data		arrangement of the NAT and the private IP address(es) of the data
	receiver). The primary goal of path-coupled middlebox communication		receiver). The primary goal of path-coupled middlebox communication
	was not to force end hosts to have this type of topology knowledge.		was not to force end hosts to have this type of topology knowledge.
	Public Internet Private Address		Public Internet Private Address
	Space		Space
	Edge		Edge
	NI(DS) NAT NAT NR(DR)		NI(DS) NAT NAT NR(DR)
	NR+ NI+		NR+ NI+
	| | | |		| | | |
	| | | |		| | | |
	| | | |		| | | |
	| | Reserve | Reserve |		| | REA | REA |
	| |<---------|<----------------|		| |<----------------------|<----------------------|
	| | | |		| | | |
	| | Return | ext addr/Error |		| |RESPONSE[Success/Error]|RESPONSE[Success/Error]|
	| |--------->|---------------->|		| |---------------------->|---------------------->|
	| | | |		| | | |
	| | | |		| | | |
	====================================================>		============================================================>
	Data Traffic Direction		Data Traffic Direction
	Figure 16: Reservation message flow		Figure 13: Reservation message flow
	Figure 16 shows the message flow for reserving an external address/		Figure 13 shows the message flow for reserving an external address/
	port at a NAT. In this case the roles of the different NSIS entities		port at a NAT. In this case the roles of the different NSIS entities
	are:		are:
	o The actual data receiver (DR) is the NSIS initiator (NI+) for the		o The data receiver (DR) for the anticipated data traffic is the
	'reserved external address' message, but the NSIS responder (NR)		NSIS initiator (NI+) for the RESERVE-EXTERNAL-ADDRESS (REA)
	for 'create session' messages following later.		message, but becomes the NSIS responder (NR) for following CREATE
			messages.
	o The actual data sender (DS) will be the NSIS initiator (NI) for		o The actual data sender (DS) will be the NSIS initiator (NI) for
	later 'create session' messages and may be the NSIS target of the		later CREATE messages and may be the NSIS target of the signaling
	signaling (NR+).		(NR+).
	o The actual target of the 'reserved external address' message may		o The actual target of the REA message may be an arbitrary address,
	be an arbitrary address NR+.		the Opportunistic Address (OA) that would force the message to get
			intercepted by the far outmost NAT in the network. .
	The data receiver DR starts to signal an 'reserve external address'
	message into the "wrong direction". By "wrong" we refer to the usual
	behavior of path-coupled signaling where the data sender starts
	signaling in order to tackle with routing asymmetry. The data
	receiver would typically return signaling messages to the data sender
	in the reverse direction by utilizing state created at nodes along
	the path (i.e. to reverse route signaling messages). In case of
	establishing NAT bindings (and NSIS NAT Forwarding State) the
	direction does not matter since the data path is modified through
	route pinning due to the external NAT address. Subsequent NSIS
	messages (and also data traffic) will travel through the same NAT
	boxes. The signaling target address selection for this message is
	discussed in Section 3.2.10.
	The signaling message creates NSIS NAT Forwarding State at		The NI+ agent (could be on the data receiver DR or on any other host
	intermediate NSIS NAT node(s). Furthermore it has to be ensured that		within he private network) sends a the REA message targeted to the
	the edge NAT device is discovered as part of this process. The end		Opportunistic Address (OA). The OA selection for this message is
	host cannot be assumed to know this device - instead the NAT box		discussed in Section 3.8. The message routing for the REA message is
	itself is assumed to know that it has such a capability. Forwarding		in the reverse direction to the normal message routing used for
	of the 'reserve external address' message beyond this entity is not		path-coupled signaling where the signaling is sent downstream (as
	necessary, and should be prohibited as it provides information on		opposed to upstream in this case). When establishing NAT bindings
	internal hosts capabilities.		(and NSIS NAT Forwarding State) the direction does not matter since
			the data path is modified through route pinning due to the external
			NAT address. Subsequent NSIS messages (and also data traffic) will
			travel through the same NAT boxes.
	The edge NAT device is responding with a 'return external address'		The REA signaling message creates NSIS NAT Forwarding State at any
	message containing the public reachable IP address/port number.		intermediate NSIS NAT node(s) encountered. Furthermore it has to be
			ensured that the edge NAT device is discovered as part of this
			process. The end host cannot be assumed to know this device -
			instead the NAT box itself is assumed to know that it is located at
			the outer perimeter of the private network. Forwarding of the REA '
			message beyond this entity is not necessary, and should be prohibited
			as it provides information on the capabilities of internal hosts.
	Processing of 'reserve external address' messages is differently per		The edge NAT device responds to the REA message with a RESPONSE
	NSIS node:		message containing a success object carrying the public reachable IP
	o NSLP initiator: NI+ only generate 'reserve external address'		address/port number.
	messages and should never receive them.
	o NSLP forwarder: NSLP forwarders receiving 'reserve external
	address' messages MUST first check authentication and
	authorization before any further processing is executed. The NF
	SHOULD check with its local policies if he can accept the desired
	policy rule given by NTLP's flow routing information. Further
	processing depends on the middlebox type:
	* NAT: NATs check whether the message is received at the public		Processing of REA messages is specific to the NSIS node type:
	address or at the private address. If received at the public		o NSLP initiator: NI+ only generate REA messages and should never
	address a NF MAY generate an error message of type 'requested		receive them.
	external address from outside'. If received at the private		o NSLP forwarder: NSLP forwarders receiving REA messages MUST first
	address, an IP address/port is reserved. In the case it is an		check authentication and authorization before any further
	edge-NAT, the NSLP message is not forwarded anymore and a		processing is executed. The NF SHOULD check with its local
	response of type 'return external address' is generated. If it		policies if it can accept the desired policy rule given by NTLP's
	is not an edge-NAT, the NSLP message is forwarded further.		message routing information (MRI). Further processing depends on
			the middlebox type:
			* NAT: NATs check whether the message is received at the
			external (public in most cases) address or at the internal
			(private) address. If received at the internal address a NF
			MAY generate a RESPONSE message with an error of type 'REA
			received from outside'. If received at the internal address,
			an IP address/port is reserved. In the case it is an edge-NAT,
			the NSLP message is not forwarded anymore and a RESPONSE
			message with the external address and port information is
			generated. If it is not an edge-NAT, the NSLP message is
			forwarded further with the translated IP address/port (if
			required by the NI+).
	* Firewall: Firewalls MUST not change their configuration upon a		* Firewall: Firewalls MUST not change their configuration upon a
	'reserve external address' message. They simply MUST forward		REA message. They simply MUST forward the message and MUST
	the message and MUST keep NTLP state. Firewalls that are		keep NTLP state. Firewalls that are configured as
	configured as edge-Firewalls (XXX, do definition!) MAY return		edge-Firewalls MAY return an error of type 'no NAT here'.
	an error of type 'no NAT here'.
	* Combined NAT and Firewall: Processing at combined Firewall and		* Combined NAT and Firewall: Processing at combined Firewall and
	NAT middleboxes is the same as in the NAT case.		NAT middleboxes is the same as in the NAT case.
	o NSLP receiver: This type of message should never be received by		o NSLP receiver: This type of message should never be received by
	any NR and it SHOULD be discarded silently.		any NR and it SHOULD be discarded silently.
	Processing of 'return external address' messages is differently per		Processing of a RESPONSE message with an external address object is
	NSIS node:		different for every NSIS node type:
	o NSLP initiator: Upon receiving a 'return external address'		o NSLP initiator: Upon receiving a RESPONSE message with an
	message the NI+ can use the obtained IP address and port number		external address object, the NI+ can use the IP address and port
	for further application signaling.		pairs carried for further application signaling.
	o NSLP forwarder: NFs simply forward this message as long as they		o NSLP forwarder: NFs simply forward this message as long as they
	keep state for the requested reservation.		keep state for the requested reservation.
	o NSIS responder: This type of message should never be received by		o NSIS responder: This type of message should never be received by
	any NR and it SHOULD be discarded silently.		an NR and it SHOULD be discarded silently.
			o Edge-NATs: This type of message should never be received by any
	3.2.3 Reserving External Addresses and Create Session		Edge-NAT and it SHOULD be discarded silently.
	Some migration scenarios need specialized support to cope with the
	situation where the receiving side is running NSIS only. End-to-end
	signaling is going to fail without NSIS support at both sides. For
	this the 'create-reverse' signaling mode is supported. In this case,
	a DR can signal towards the DS like in the 'reserve external address'
	message scenario. The message is forwarded until it reaches the
	edge-NAT and retrieves a public IP address and port number. Unlike
	in the 'reserve external address' no 'return external address'
	response message is created, the forwarding of the request message
	stops and a 'create session' message is generated by the edge-NAT.
	This request message is sent towards DR with DS as source address and
	follows the regular processing orders as 'create session' messages
	do. The exact definition of this mode is to be done.
	3.2.4 Prolonging Sessions		3.3.3 NATFW Session refresh
	NATFW NSLP sessions are maintained on a soft-state base. After a		NATFW NSLP sessions are maintained on a soft-state base. After a
	certain timeout sessions and corresponding policy rules are removed		certain timeout, sessions and corresponding policy rules are removed
	automatically by the middlebox, if they are not refreshed by a		automatically by the middlebox, if they are not refreshed. The
	prolong session message. NI is sending prolong message towards NR		protocol uses a CREATE message to refresh sessions. Even if used for
	and each NSIS forwarder maintaining state for the given session ID		refresh purposes the CREATE message requires to be responded back, to
	extends the lifetime of the session. Extending lifetime of a session		allow the intermediate NFs to propose a refresh period that would
	is calculated as current local time plus lifetime. Section 3.2.7 is		align to their local policies. The NI sends CREATE messages destined
	defining the process of calculating lifetimes in detail.		for the NR. Upon reception by each NSIS forwarder, the state for the
			given session ID is extended by the session refresh period, a period
			of time calculated based on a proposed refresh message period.
			Extending lifetime of a session is calculated as current local time
			plus proposed lifetime value (session refresh period). Section 3.5
			defines the process of calculating lifetimes in detail.
	NI Public Internet NAT Private address NR		NI Public Internet NAT Private address NR
	| | space |		| | space |
	| Prolong | |		| CREATE[lifetime > 0] | |
	|----------------------------->| |		|----------------------------->| |
	| | |		| | |
	| Error (if necessary) | |		| RESPONSE[Error] (if needed) | |
	|<-----------------------------| Prolong |		|<-----------------------------| CREATE[lifetime > 0] |
	| |--------------------------->|		| |--------------------------->|
	| | |		| | |
	| | Error (if necessary) |		| | RESPONSE[Success/Error] |
	| Error (if necessary) |<---------------------------|		| RESPONSE[Success/Error] |<---------------------------|
	|<-----------------------------| |		|<-----------------------------| |
	| | |		| | |
	| | |		| | |
	Figure 17: Prolongation message flow		Figure 14: State Refresh Message Flow
	Processing of 'prolong session' messages is differently per NSIS		Processing of session refresh CREATE messages is different for every
	node:		NSIS node type:
	o NSLP initiator: NI can generate 'prolong session' messages before		o NSLP initiator: NI can generate session refresh CREATE messages
	the session times out.		before the session times out. The rate at which the refresh
	o NSLP forwarder: NSLP forwarders receiving 'prolong session'		CREATE messages are sent and their relation to the session state
	messages MUST first check authentication and authorization before		lifetime are further discussed in Section 3.5. The message
	any further processing is executed. The NF SHOULD check with its		routing information and the extended flow information object MUST
	local policies if he can accept the desired lifetime extension for		be set equal to the values of the initial CREATE request message.
			o NSLP forwarder: NSLP forwarders receiving session refresh messages
			MUST first check authentication and authorization before any
			further processing is executed. The NF SHOULD check with its
			local policies if it can accept the desired lifetime extension for
	the session referred by the session ID. Processing of this		the session referred by the session ID. Processing of this
	message is independent of the middlebox type.		message is independent of the middlebox type.
	o NSLP responder: NIs accepting this prolong message generate a		o NSLP responder: NRs accepting this session refresh CREATE message
	'path succeeded' message.		generate a RESPONSE message with response object set to success.
	3.2.5 Deleting Sessions		3.3.4 Deleting Sessions
	NATFW NSLP sessions may be deleted at any time. NSLP initiators can		NATFW NSLP sessions may be deleted at any time. NSLP initiators can
	trigger this deletion via the 'delete session' message, as shown in		trigger this deletion by using a CREATE messages with a lifetime
	Figure 17.		value set to 0, as shown in Figure 15.
	NI Public Internet NAT Private address NR		NI Public Internet NAT Private address NR
	| | space |		| | space |
	| Delete | |		| CREATE[lifetime=0] | |
	|----------------------------->| |		|----------------------------->| |
	| | |		| | |
	| | Delete |		| | CREATE[lifetime=0] |
	| |--------------------------->|		| |--------------------------->|
	| | |		| | |
	Figure 18: Delete message flow		Figure 15: Delete message flow
	NSLP nodes receiving this message MUST delete the session		NSLP nodes receiving this message MUST delete the session
	immediately. Corresponding policy rules to this particular session		immediately. Corresponding policy rules to this particular session
	MUST be deleted immediately, too. This message is forwarded until it		MUST be deleted immediately, too. This message is forwarded until it
	reaches the final NR. The 'delete' message does not generate any		reaches the final NR. The CREATE request message with a lifetime
	response, neither positive nor negative, since there is no NSIS state		value of 0, does not generate any response, neither positive nor
	left at the nodes along the path.		negative, since there is no NSIS state left at the nodes along the
			path.
	3.2.6 Authorization		3.3.5 Reporting Asynchronous Events
	Authorization and security issues are currently discussed in a		NATFW NSLP forwarders and NATFW NSLP responders must have the ability
	different document and will be included after reaching consensus (		to report asynchronous events to other NATFW NSLP nodes, especially
	[20]).		reporting back to the NATFW NSLP initiator. Such asynchronous events
			may be premature session termination, changes in local polices, or
			any other reason that indicates change of the NATFW NSLP session
			state. Currently, only asynchronous session termination is defined
			as event, but other events may be defined in later versions of this
			memo.
	3.2.7 Calculation of Lifetimes		NFs and NRs may generate NOTIFY messages upon asynchronous events,
			with a response object indicating the reason of the event. There are
			two suggested mode of operations:
			1. NOTIFY messages are sent hop-by-hop upstream towards NI. Those
			NOTIFY messages may be sent downstream towards NR, if generated
			by a NF, if needed. TBD: Should there be a way to configure
			whether NOTIFY messages are sent downstream, too?
			2. During session creation, via CREATE or REA, NIs may insert a
			special 'notify address' object into the NSLP message, indicating
			a node's address that should be notified about this event. TBD:
			When this object is used, is it desired to send the NOTIFY to
			both, NI and the other node? Sending to both could end up in one
			asynchronous event generating three messages: NOTIFY to NI
			(upstream), NOTIFY to NR (downstream), and NOTIFY to notify
			address.
			Processing is different for every NATFW NSLP node type and only
			defined for asynchronous session termination events:
	NATFW NSLP sessions, and the corresponding policy rules possibly		o NSLP initiator: NIs receiving NOTIFY messages MUST first check for
	installed, are maintained via soft-state. Each session is assigned a		authentication and authorization. After successfully doing so,
	lifetime and they are kept alive as long as the lifetime is valid.		NIs MUST remove the NSLP session as indicated by the NOTIFY
	After the expiration of the lifetime sessions and policy rules MUST		message. NIs MUST NOT generate NOTIFY messages.
	be removed automatically and resources bound to them should be freed		o NSLP forwarder: NFs receiving NOTIFY messages MUST first check for
	as well. Session lifetime is kept at every NATFW NSLP node. The		authentication and authorization. After successfully doing so,
	NSLP forwarders and NSLP responder are not responsible for triggering		NFs MUST remove the NSLP session and corresponding policy rules
	lifetime prolongination messages (see Section 3.2.4), this is the		immediately and MUST forward the NOTIFY message. NFs occurring an
	task of the NSIS initiator.		asynchronous event generate NOTIFY messages and set the response
			object to 'session termination' code. NOTIFY messages are sent
			hop-by-hop upstream towards NI (This depends on above mentioned
			design choice).
			o NSLP responder: NRs may generate NOTIFY messages. NRs receiving
			NOTIFY messages MUST first check for authentication and
			authorization. After successfully doing so, NRs MUST remove the
			NSLP session immediately. NRs occurring an asynchronous event
			generate NOTIFY messages and set the response object to 'session
			termination' code. NOTIFY messages are sent hop-by-hop upstream
			towards NI (This depends on above mentioned design choice).
	NSIS initiator MUST choose a lifetime value before they can sent any		3.3.6 QUERY capabilities within the NATFW NSLP protocol
	message (except 'delete session' messages) to other NSLP nodes. This
	lifetime value should consider application's needs, i.e., duration in
	terms of minutes or hours, and networking needs, i.e., values in the
	range less than 30 seconds may not be useful. This requested
	lifetime value is placed in the 'lifetime object' of the NSLP message
	and messages are forwarded to the next NATFW NSLP node.
	NATFW NSLP forwarders processing the request message along the path		The NATFW NSLP provides query capabilities that could be used by:
	MAY lower the request lifetime given to fit their needs and/or local		o A session owner to track the session state, this would be used for
	policy. NATFW forwarders MUST NOT increase the lifetime value; they		diagnosis when no data packets were received and the policy rule
	MAY reject the requested lifetime immediately and MUST generate an		was supposed to be created on the NATFW NFs.
	error response message of type 'lifetime too big' upon rejection.		o A superuser to track user activities, detect misbehaving users and
	The NSLP request message is forwarded until it reaches the NSLP		blocking them from using the NATFW NSLP on the NATFW NFs within
	responder. NSLP responder MAY reject the requested lifetime value		the network. When doing so it is recommended that the QUERY
	and MUST generate an error response message of type 'lifetime too		message be scoped to the limits of the administrative domain.
	big' upon rejection. NSLP responder MAY lower the requested lifetime
	as well to a granted lifetime. NSLP responders generate their		The QUERY message could be used to query the following information:
	appropriate response message for the received request message, sets		o Session information: session id, flow source, destination and
	the lifetime value to the above granted lifetime and sends the		status of the state listed in best status to worst status: up,
	message back hop-by-hop towards NSLP initiator.		high traffic (used to detect DOS attack or unexpected traffic
			rate), pending, down. The status of the policy rule indicate
			sufficient diagnosis information, in case more diagnosis
			information is required it could be provided by the NATFW NF logs.
			Session status is only provided by an NF if no session status was
			provided in the QUERY message or the NF's session status is worst
			than the one provided by the queried upstream NEs. The Session
			information could be retrieved by sending a QUERY against a
			specific session id, a flow source and destination or user
			identifier with session id or flow source and destination.
			o User identifiers: the query would be used by a super-user to track
			activities of a suspected user, the query would return all the
			suspected user active sessions
			QUERY message processing is different for every NATFW NSLP node type:
			o NSLP initiator: NIs only generate QUERY messages, but never with
			session status information, in case received QUERY messages MUST
			be discarded.
			o NSLP forwarder: NFs receiving QUERY messages MUST first check for
			authentication and authorization. After successfully doing so,
			NFs will behave differently depending on the QUERY.
			* if the QUERY is about a specific session: if it contains a
			session status the NF compares it to the current local session
			status; if no session status is provided in the QUERY message
			the NF will insert its own session status in the QUERY message.
			If the current local session status is worst, it will
			incorporate its own session status field in the QUERY message.
			Every NF will provide the flow description in case it was not
			inside the QUERY.
			* if the QUERY is about a specific user, the NF will gather all
			the user's sessions and provide a list of them.
			Once the message processing is done, if the message was not scoped
			then NF will forward the QUERY message to the next downstream
			node.
			o NSLP responder: NRs (any node being the destination of the
			message)receiving QUERY messages MUST first check for
			authentication and authorization. After successfully doing so,
			NRs must process the message as the NFs and respond with a
			RESPONSE message to the NI. The RESPONSE message will travel
			along the established reverse path Message Routing State.
			Responses to QUERY messages are processed differently for every NATFW
			NSLP node type:
			o NSLP initiator: NIs receiving RESPONSEs to QUERY messages MUST
			first check for authentication and authorization. After
			successfully doing so, the objects within the RESPONSE messages
			are provided up to the application layers and the session state
			remains as it was unless the application triggers NATFW NSLP state
			changes.
			o NSLP forwarder: NFs receiving RESPONSEs to QUERY messages MUST
			first check for authentication and authorization. After
			successfully doing so, NFs forward the message upstream without
			any interpretation.
			o NSLP responder: if an NR received a RESPONSE to QUERY message it
			MUST discard it.
			3.3.7 QUERY Message semantics
			From a semantics perspective, the QUERY messages may require the
			following information incorporated within the messages:
			o Session ID
			o User ID
			o Flow source (address and port) and destination (address and port),
			in case the flow doesn't use a transport protocol a protocol
			number would be used with another identifier (SPI for IPsec)
			QUERY responses should provide the following information:
			o List of active sessions associated to a user
			o Related information to a session: session ID, flow description and
			policy rule state information
			3.4 NATFW NSLP proxy mode of operation
			3.4.1 Reserving External Addresses and triggering Create messages
			Some migration scenarios need specialized support to cope with cases
			where only the receiving side is running NSIS. End-to-end signaling
			is going to fail without NSIS support at both data sender and data
			receiver, unless the NATFW NSLP also gives the NR the ability to
			install sessions. In this case, a NR can signal towards the
			Opportunistic Address as is done in the standard REA message handling
			scenario Section 3.3.2. The message is forwarded until it reaches
			the edge-NAT and retrieves a public IP address and port number.
			Unlike the standard REA message handling case no RESPONSE message is
			sent. Instead a CREATE message is generated by the edge-NAT. This
			CREATE request message is sent towards NR with DS as source address
			(if the source address is known, otherwise the edge NAT address is
			used as source address) and thereafter follows the regular processing
			rules as for CREATE messages sent by the NI.
			DS Public Internet NAT Private address NR
			No NI | space
			| | REA[CREATE] |
			| |<------------------------- |
			| | CREATE |
			| | ------------------------> |
			| | RESPONSE[Error/Success] |
			| | ---------------------- > |
			| | |
			| | |
			Figure 16: REA Triggering Sending of CREATE Message
			This behavior requires within the REA message an indication to the
			edge NAT if either a RESPONSE message or a CREATE message should be
			used. In addition when the CREATE message is requested (as opposed
			to a RESPONSE message) the REA message the data sender address. A
			slight variant, shown in Figure 17 , could also be handled by
			requesting within the REA message that a RESPONSE message needs to be
			sent on the existing pinned down path as well as a CREATE message
			on a newly discovered path between the Edge NAT and the NR. This
			variant would allow the handling of asymmetric routes, which could go
			through internal firewalls, within the local network.
			DS Public Internet NAT Private address NR
			No NI | space
			| | REA[CREATE, DISC] |
			| |<------------------------- |
			| | RESPONSE[Error/Success] |
			| | ---------------------- > |
			| | CREATE |
			| | ------------------------> |
			| | RESPONSE[Error/Success] |
			| | ---------------------- > |
			| | |
			| | |
			Figure 17: REA Triggering Sending of CREATE Message on Separate
			Reverse Path
			In case a CREATE message is received from the far end NI and relates
			the installed session, that CREATE message would have precedence over
			the previous CREATE. The CREATE sent by the NI would allow to have a
			more granular policy rule as only the data sender could send data
			whereas in the REA triggered CREATE message any data source can send
			packets to the data receiver. The edge NAT is not aware of the
			applications context for which the CREATE messages were required.
			Hence it is up to the NR to inform the Edge NAT if there was a
			possibility to reduce the number of accepted data sources to the real
			data sender, as well as to inform the Edge NAT to refresh the
			established session.
			For that purpose the NR will send TRIGGER messages, to the edge NAT
			that responded to the REA message. These messages are sent upon
			reception, from the user application, of further information on the
			Data Sender (either explicit information or implied information such
			as data sender address data reception address and same for the
			transport port). The TRIGGER messages would be sent periodically to
			the Edge NAT that responded to the REA. The TRIGGER messages would
			be sent until either a CREATE message is received from the far-end or
			when the user application no longer needs the NSIS session. Figure
			18 shows how TRIGGER messages would be used after the message
			sequences of Figure 16 or Figure 17. In case a CREATE message is
			received from the far end NI and relates to the installed session,
			that CREATE message would have precedence over the triggered CREATE
			messages. TRIGGER messages do not require to be responded back with
			a RESPONSE message on the existing established reverse path. The
			benefits of using REA triggering a CREATE and then using the TRIGGER
			messages are that an end-host doesnt need to know if the far-end
			support the NSIS protocol.
			Foo.com Public Internet Bar.com
			DS NAT Firewall NR
			No NI | | TRIGGER[DSinfo]
			TRIGGER[DSinfo]<-------------|
			<-------------| |
			|CREATE |
			|----------->|CREATE |
			| |-------------->|
			| | RESPONSE[SUCCESS]
			| | <-------------|
			RESPONSE[SUCCESS] |
			|<-----------| |
			Refresh period expiry |
			or updates to Data Sender information
			| |
			| | TRIGGER[DSinfo]
			TRIGGER[DSinfo]<-------------|
			<-------------| |
			|CREATE |
			|----------->|CREATE |
			| |-------------->|
			| | RESPONSE[SUCCESS]
			| | <-------------|
			RESPONSE[SUCCESS] |
			|<-----------| |
			Figure 18: TRIGGER message usage
			3.4.2 Using CREATE messages to Trigger Reverse Path CREATE Messages
			In certain network deployments, where a NATFW NE might not be
			available on the end-host (Figure 19) or the NSIS messages are
			scoped (Figure 20) implicitly or explicitly with a scoping object, a
			CREATE message could be used to trigger another CREATE message sent
			by the last NF terminating the CREATE message. There are two options
			for this mode:
			o The returning CREATE message could follow the established reverse
			path using GIMPS routing state ([3],Section 3.4.2.1)
			o Trigger the GIMPS layer to discover the reverse path, which would
			require that the first CREATE message provides the message target
			address (Section 3.4.2.2).
			3.4.2.1 CREATE Responses Sent on Previously Pinned Down Reverse Path
			Public NI/NR
			Host foo.com FW Internet FW bar.com Host
			foo | | bar
			| | | CREATE[CREATE, NoNR] |
			| | |<------------------------- |
			| | | |
			| | CREATE[CREATE] | |
			| ,|<-----------------+ |
			| ' | | |
			| ' | CREATE[] | |
			| `'|--------------- ->| |
			| | | CREATE[] |
			| | | ------------------------->|
			| | | RESPONSE[Success/Error] |
			| | | <------------------------ |
			| |RESPONSE[Success/Error]| |
			| | <----------------|
			Figure 19: CREATE triggering CREATE Message Sending with no Scoping
			and using Existing Reverse Path State
			In Figure 19, the first CREATE indicates that if the message can not
			reach its destination, a CREATE message should be sent back to the NI
			by the last reached NATFW NE. As in Section 3.4.1 this mode of
			operation requires that the CREATE message indicate the type of
			required response which in this case is a CREATE message. However
			this response type is subject to a condition: only if the NR can not
			respond. This conditional behavior requires a specific flag to
			indicate it. In this example, the NI does not require that the last
			NATFW NF responds via a different reverse path than that already
			pinned down.
			Public NI/NR
			Host foo.com FW Internet FW bar.com Host
			foo | | bar
			| | | CREATE[CREATE,Scope] |
			| | |<------------------------- |
			| | | |
			| | | CREATE/RESPONSE[Error] |
			| | | ------------------------->|
			| | | RESPONSE[Success/Error] |
			| | | <------------------------ |
			Figure 20: CREATE Triggering CREATE Message Sending with Scoping and
			using Existing Reverse Path State
			In Figure 20, the first CREATE indicates that once the end of the
			scope is reached, the last NATFW NSLP will respond with a CREATE
			message (if the first CREATE request was successful). As in Section
			3.4.1, this mode of operation requires that the CREATE message
			indicate the type of response required which in this case is a CREATE
			message. As the CREATE needs to terminate at a scope end, the scope
			need to be provided within the CREATE message. In this example, the
			NI doesnt require that the last NATFW NF responds via a different
			reverse path than the already pinned down.
			3.4.2.2 CREATE Responses Sent on Separately Established Reverse Path
			In certain network topologies, where several NATFW NSLP are deployed
			on alternate paths, it is better to minimize asymmetric route issues
			that could occur when sending the CREATE message on the existing
			pinned down reverse path.
			Foo.com Public Internet Bar.com
			2-RESPONSE1
			/-------------|---------------------
			/ --> FW1-NF --------------------- \
			V / 1-CREATE1[CREATE,DISC,NoNR]| \ \
			Host Foo/ | | NF3-NF Host Bar
			NI/NR ^ | | |^
			\ \ | 3-CREATE2 | ||
			\ \--- FW2-NF --------------------------|
			\----/ \--------------------------
			| 4-RESPONSE2 |
			Figure 21: CREATE Triggering Sending of CREATE Message with Scoping
			and Using Separate Reverse path
			To minimize the asymmetric route problem, the node responding with a
			CREATE message would request the NTLP to rediscover the reverse path.
			A RESPONSE message would be sent on the existing pinned down reverse
			path (Step 2 in Figure 21), and a CREATE would be sent on a newly
			discovered reverse path (Step 3 in Figure 21). Upon reception of the
			latter message, the initiating NI will respond with a RESPONSE
			message (Step 4 in Figure 21) as is done for the normal CREATE
			message operations (Section 3.3.1). The CREATE message would need to
			indicate to the last NATFW NF that a CREATE must be sent on a
			separately discovered path and that a RESPONSE message needs to be
			sent on the established pinned down reverse path. The new CREATE
			message need to indicate to the NI that this session is bound to the
			previous session. In addition the first message should indicate that
			the last available NATFW NF will need to terminate the message and
			start the above procedures (similar to Figure 19). The model could
			also be applied when a scope is used, instead of terminating on the
			last NATFW NF, the message will terminate on the end of the scope.
			3.5 Calculation of Session Lifetime
			NATFW NSLP sessions, and the corresponding policy rules which may
			have been installed, are maintained via soft-state mechanism. Each
			session is assigned a lifetime and the session is kept alive as long
			as the lifetime is valid. After the expiration of the lifetime,
			sessions and policy rules MUST be removed automatically and resources
			bound to them should be freed as well. Session lifetime is kept at
			every NATFW NSLP node. The NSLP forwarders and NSLP responder are
			not responsible for triggering lifetime extension refresh messages
			(see Section 3.3.3): this is the task of the NSIS initiator.
			NSIS initiator MUST choose a session lifetime (expressed in seconds)
			value before sending any message (except 'delete session' messages)
			to other NSLP nodes. The session lifetime value is calculated based
			on:
			o The number of lost refresh messages to cope with
			o The end to end delay between the NI and NR
			o Network vulnerability due to session hijacking ([21]). Session
			hijacking is made easier when the NI does not remove explicitly
			the session.
			o The user application's data exchange duration, in terms of
			seconds, minutes or hours and networking needs. This duration is
			modeled as M x R, with R the message refresh period (in seconds)
			and M a multiple of R.
			As opposed to the NTLP Message Routing state [3] lifetime, the NSLP
			session lifetime doesnt require to have a small value since the NSLP
			state refresh is not handling routing changes but security related
			concerns. [14] provides a good algorithm to calculate the session
			lifetime as well as how to avoid refresh message synchronization
			within the network. [14] recommends:
			1. The refresh message timer to be randomly set to a value in the
			range [0.5R, 1.5R].
			2. To avoid premature loss of state, L (with L being the session
			lifetime) must satisfy L >= (K + 0.5)*1.5*R, where K is a small
			integer. Then in the worst case, K-1 successive messages may be
			lost without state being deleted. Currently K = 3 is suggested
			as the default. However, it may be necessary to set a larger K
			value for hops with high loss rate. Other algorithms could be
			used to define the relation between the session lifetime and the
			refresh message period, the provided algorithm is only listed as
			an example.
			This requested lifetime value is placed in the 'lifetime' object of
			the NSLP message and messages are forwarded to the next NATFW NSLP
			node.
			NATFW NFs processing the request message along the path MAY change
			the requested lifetime to fit their needs and/or local policy. If an
			NF changes the lifetime value it must also indicate the corresponding
			refresh message period. NFs MUST NOT increase the lifetime value
			unless the lifetime value was below their acceptable range; they MAY
			reject the requested lifetime immediately and MUST generate an error
			response message of type 'lifetime too big' upon rejection. The NSLP
			request message is forwarded until it reaches the NSLP responder.
			NSLP responder MAY reject the requested lifetime value and MUST
			generate an error response message of type 'lifetime too big' upon
			rejection. The NSLP responder MAY also lower the requested lifetime
			to an acceptable value (based on its local policies). NSLP
			responders generate their appropriate response message for the
			received request message, sets the lifetime value to the above
			granted lifetime and sends the message back hop-by-hop towards NSLP
			initiator.
	Each NSLP forwarder processes the response message, reads and stores		Each NSLP forwarder processes the response message, reads and stores
	the granted lifetime value. The forwarders SHOULD accept the granted		the granted lifetime value. The forwarders SHOULD accept the granted
	lifetime, as long as the value is equal or lower than the requested		lifetime, as long as the value is within the tolerable lifetime range
	lifetime. They MAY reject the lifetime and generate a 'lifetime not		defined in their local policies. They MAY reject the lifetime and
	acceptable' error response message. Figure 19 shows the procedure		generate a 'lifetime not acceptable' error response message. Figure
	with an example, where an initiator requests 60 minutes lifetime in		22 shows the procedure with an example, where an initiator requests
	'create session' message and the lifetime is shortened along the path		60 seconds lifetime in the CREATE message and the lifetime is
	by the forwarder to 20 minutes and by the responder to 5 minutes.		shortened along the path by the forwarder to 20 seconds and by the
			responder to 15 seconds.
	+-------+ CREATE(lt=60m) +-----------+ CREATE(lt=20m) +--------+		+-------+ CREATE(lt=60s) +-----------+ CREATE(lt=20s) +--------+
	| |---------------->| NSLP |---------------->| |		| |---------------->| NSLP |---------------->| |
	| NI | | | | NR |		| NI | | | | NR |
	| |<----------------| forwarder |<----------------| |		| |<----------------| forwarder |<----------------| |
	+-------+ OK(lt=5m) +-----------+ OK(lt=5m) +--------+		+-------+ RESPONSE(lt=15s +-----------+ RESPONSE(lt=15s +--------+
			MRR=3s) MRR=3s)
	lt = lifetime
	CREATE = 'create session' message
	OK = 'path succeeded' message
	Figure 19: Lifetime Calculation Example
	3.2.8 Middlebox Resource		lt = lifetime
			MRR = Message Refresh Rate
	This section needs to be done and should describe how to map flow		Figure 22: Lifetime Calculation Example
	routing information to middlebox policy rules. Further, this section
	should clarify wildcarding. XXX
	3.2.9 De-Multiplexing at NATs		3.6 Middlebox Resource
	Section 3.2.2 describes how NSIS nodes behind NATs can obtain a		TBD: This section needs to be done and should describe how to map
	public reachable IP address and port number at a NAT. The		flow routing information to middlebox policy rules. Further, this
	information IP address/port number can be transmitted via a signaling		section should clarify wildcarding.
	protocol and/or third party to the communication partner that would
	like to send data towards. However, NSIS signaling flows are sent
	towards the address of the NAT at which this particular IP address
	and port number is allocated. The NATFW NSLP forwarder at this NAT
	needs to know how the incoming NSLP requests are related to reserved
	addresses, meaning how to de-multiplex incoming requests.
	Two options for de-multiplexing incoming NSLP requests are:		3.7 De-Multiplexing at NATs
	1. Based on flow routing information, like protocol number and TCP
	port numbers.
	2. Based on NSIS session IDs.
	Approach 2) would require that both NSIS ends, initiator and		Section 3.3.2 describes how NSIS nodes behind NATs can obtain a
	responder, use the same session ID in NSIS signaling. Since session		publicly reachable IP address and port number at a NAT. The
	IDs are usually generated randomly, application level signaling would		information IP address/port number can then be transmitted via a
	have to be adapted to carry NSIS session IDs used during reservation		signaling protocol and/or third party to the communication partner
	to the other end (the NSIS initiator sending the 'create session'		that would like to send data towards hosts behind the NAT. However,
	message). This approach SHOULD NOT be used.		NSIS signaling flows are sent towards the address of the NAT at which
			this particular IP address and port number is allocated. The NATFW
			NSLP forwarder at this NAT needs to know how the incoming NSLP
			requests are related to reserved addresses, meaning how to
			de-multiplex incoming requests.
	Approach 1) uses information stored at NATs (like mapping of public		The de-multiplexing method uses information stored at NATs (such as
	IP address to private, transport protocol, port numbers) and		mapping of public IP address to private, transport protocol, port
	information given by NTLP's flow routing information to de-multiplex		numbers) and information given by NTLP's flow routing information.
	NSIS messages. This approach is RECOMMENDED.
	3.2.10 Selecting Destination IP addresses for REA		3.8 Selecting Opportunistic Addresses for REA
	Request messages of type 'reserve external address' do need, as any		REA do need, as any other message type as well, a final destination
	other message type as well, a final destination IP address to reach.		IP address to reach. But as many applications do not provide a
	But as many applications do not provide a destination IP address at		destination IP address in the first place, there is a need to choose
	the first place, there is a need to choose a destination address for		a destination address for REA messages. This destination address can
	the 'reserve external address' messages. This destination can be the		be the final target, but for applications which do not provide an
	final target, but for the mentioned type of application, the		upfront address, the destination address has to be chosen
	destination address can be arbitrary. Taking the "correct"		independently. Choosing the 'correct' destination IP address may be
	destination IP address might be difficult and there is no right		difficult and it is possible there is no 'right answer'. [19] shows
	answer. [19] shows choices for SIP and this section provides some		choices for SIP and this section provides some hints about choosing a
	hints about choosing a good destination IP address in general.		good destination IP address.
	1. Public IP address of the data sender:		1. Public IP address of the data sender:
	* Assumption:		* Assumption:
	+ The data receiver already learned the IP address of the		+ The data receiver already learned the IP address of the
	data sender (e.g. via a third party).		data sender (e.g., via a third party).
	* Problems:		* Problems:
	+ The data sender might also be behind a NAT. In this case		+ The data sender might also be behind a NAT. In this case
	the public IP address of the data receiver is the IP		the public IP address of the data receiver is the IP
	address allocated at this NAT.		address allocated at this NAT.
	+ Due to routing asymmetry it might be possible that the		+ Due to routing asymmetry it might be possible that the
	routes taken by a) the data sender and the application		routes taken by a) the data sender and the application
	server b) the data sender and NAT B might be different. As		server b) the data sender and NAT B might be different,
	a consequence it might be necessary to advertise a new (and		this could happen in a network deployment such as in Figure
	different) external IP address with SIP after using NSIS to		12. As a consequence it might be necessary to advertise a
	establish a NAT binding.		new (and different) external IP address within the
			application (which may or may not allow that) after using
			NSIS to establish a NAT binding.
	2. Public IP address of the data receiver (allocated at NAT B):		2. Public IP address of the data receiver (allocated at NAT B):
	* Assumption:		* Assumption:
	+ The data receiver already learned his externally visible IP		+ The data receiver already learned his externally visible IP
	address (e.g. based on the third party communication).		address (e.g., based on the third party communication).
	* Problems:		* Problems:
	+ Communication with a third party is required.		+ Communication with a third party is required.
	3. IP address at the Application Server:		3. IP address of the Application Server:
	* Assumption:		* Assumption:
	+ An application server (or a different third party) is		+ An application server (or a different third party) is
	available.		available.
	* Problems:		* Problems:
	+ If the NSIS signaling message is not terminated at the NAT		+ If the NSIS signaling message is not terminated at the NAT
	of the local network then an NSIS unaware application		of the local network then an NSIS unaware application
	server might discard the message.		server might discard the message.
	+ Routing might not be optimal since the route between a) the		+ Routing might not be optimal since the route between a) the
	data receiver and the application server b) the data		data receiver and the application server b) the data
	receiver and the data sender might be different.		receiver and the data sender might be different.
	3.3 NATFW NSLP Messages Components		4. NATFW NSLP NTLP Requirements
			The NATFW NSLP requires the following capabilities from the NTLP:
			o Ability to detect that the NSIS Responder does not support NATFW
			NSLP. This capability is key to launching the proxy mode behavior
			as described in Section 3.4 and [17].
			o Detection of NATs and their support of the NSIS NATFW NSLP. If
			the NTLP discovers that the NSIS host is behind an NSIS aware NAT,
			the NR will send REA messages to the opportunistic address. If
			the NTLP discovers that the NSIS host is behind a NAT that does
			not support NSIS then the NSIS host will need to use a separate
			NAT traversal mechanism.
			o Message origin authentication and message integrity protection
			o Transport of information used for correlation purposes between the
			NSIS protocol suite and user application layers. This requirement
			allows NSLP NATFW to check that the message was solicited by prior
			application message exchanges before an NTLP messaging association
			is established between an NR and the upstream NF.
			o Detection of routing changes
			o Protection against malicious announcement of fake path changes,
			this is needed to mitigate a threat discussed in section 7 of [21]
			5. NATFW NSLP Message Components
	A NATFW NSLP message consists of a NSLP header and one or more		A NATFW NSLP message consists of a NSLP header and one or more
	objects following the header. The NSLP header is common for all		objects following the header. The NSLP header is common for all
	NSLPs and objects are Type-Length-Value (TLV) encoded using big		NSLPs and objects are Type-Length-Value (TLV) encoded using big
	endian (network ordered) binary data representations. Header and		endian (network ordered) binary data representations. Header and
	objects are bound to 32 bits and objects that do not fall into 32		objects are aligned to 32 bit boundaries and object lengths that are
	bits boundaries must be padded to 32 bits.		not multiples of 32 bits must be padded to the next higher 32 bit
			multiple.
	The whole NSLP message is carried in a NTLP message.		The whole NSLP message is carried as payload of a NTLP message.
	Note that the notation 0x is used to indicate hexadecimal numbers.		Note that the notation 0x is used to indicate hexadecimal numbers.
	3.3.1 NSLP Header		5.1 NSLP Header
	The NSLP header is common to all NSLPs and is the first part of all		The NSLP header is common to all NSLPs and is the first part of all
	NSLP messages. It contains two fields, the NSLP message type and a		NSLP messages. It contains two fields, the NSLP message type and a
	reserved field. The total length is 32 bits. The layout of the NSLP		reserved field. The total length is 32 bits. The layout of the NSLP
	header is defined by Figure 20.		header is defined by Figure 23.
	0 16 31		0 16 31
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| NSLP message type | reserved |		| NSLP message type | reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 20: Common NSLP header		Figure 23: Common NSLP header
	The reserved field MUST be set to zero in the NATFW NSLP header		The reserved field MUST be set to zero in the NATFW NSLP header
	before sending and MUST be ignored during processing the header.		before sending and MUST be ignored during processing of the header.
	Note that other NSLPs use this field as flag field.		Note that other NSLPs use this field as a flag field.
	3.3.2 NSLP message types		5.2 NSLP message types
	The message types identify requests and responses. Defined messages		The message types identify requests and responses. Defined messages
	types for requests are:		types for requests are:
	o 0x0101 : create		o 0x0101 : CREATE
	o 0x0102 : reserve		o 0x0102 : RESERVE-EXTERNAL-ADDRESS(REA)
	o 0x0103 : reserve-create		o 0x0103 : QUERY
	o 0x0104 : prolong		o 0x0104 : NOTIFY
	o 0x0105 : delete		o 0x0105 : RESPONSE
	Defined message types for responses are:		o 0x0106 : TRIGGER
	o 0x0201 : path_succeed		Defined message types for responses are (TBD):
	o 0x0202 : path_deleted
	o 0x0203 : ret_ext_addr
	o 0x0204 : error
	3.3.3 NSLP Objects		o TBD
	NATFW NSLP objects use a common header format defined by Figure 21.		5.3 NSLP Objects
			NATFW NSLP objects use a common header format defined by Figure 24.
	Objects are Type-Length-Value (TLV) encoded using big endian (network		Objects are Type-Length-Value (TLV) encoded using big endian (network
	ordered) binary data representations. The object header contains two		ordered) binary data representations. The object header contains two
	fields, the NSLP object type and the object length. Its total length		fields, the NSLP object type and the object length. Its total length
	is 32 bits.		is 32 bits.
			Note that all objects MUST be padded always to 32 bits.
	0 16 31		0 16 31
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| NSLP object type | NSLP object length |		| NSLP object type | NSLP object length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 21: Common NSLP object header		Figure 24: Common NSLP object header
	The length is the total length of the object without the object		The length is the total length of the object without the object
	header. The unit is bytes. The particular values of type and length		header. The unit is a word, consisting of 4 bytes. The particular
	for each NSLP object are listed in the subsequent chapters that		values of type and length for each NSLP object are listed in the
	define the NSLP objects.		subsequent sections that define the NSLP objects.
	3.3.3.1 Session ID Object
	The session ID object carries an identifier for the session of the
	signaled flow. The only field is the session ID of 16 bytes length.
	0 16 31
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 0x0001 | 16 bytes |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |
	// 16 bytes session id //
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 22: Session ID object
	The session ID is generated in random way by the NSIS initiator.		TBD: Processing of unknown options is currently subject to
			discussions within the working group. It is proposed to extend the
			NSLP object header with some bits that indicate treatment of unknown
			options. The compatibility bits (CP) are coded into two 2 bits and
			determine the action to take upon receiving an unknown option. The
			applied behavior based on the CP bits is:
			00 - Abort processing and report error
			01 - Ignore object and do not forward
			10 - Ignore object and do forward
			All other combinations MUST NOT be set and objects carrying these
			other CP bit combinations MUST discarded.
	3.3.3.2 Session Lifetime Object		5.3.1 Session Lifetime Object
	The session lifetime object carries the requested or granted lifetime		The session lifetime object carries the requested or granted lifetime
	of a NATFW NSLP session measured in seconds. The object consists		of a NATFW NSLP session measured in seconds. The object consists
	only of the 4 bytes lifetime field.		only of the 4 bytes lifetime field.
	0 16 31		0 16 31
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 0x0002 | 4 bytes |		| OID_NATFW_LT | 0x0001 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| NATFW NSLP session lifetime |		| NATFW NSLP session lifetime |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 23: Lifetime object		Figure 25: Lifetime object
	3.3.3.3 External Address Object		5.3.2 External Address Object
	The external address objects can be included in ret_ext_addr		The external address objects can be included in RESPONSE messages
	responses (Section 3.4.9) only. It contains the external IP address		(Section 5.4.4) only. It contains the external IP address and port
	and port number allocated at the edge-NAT. Note that this address/		number allocated at the edge-NAT. Two fields are defined, the
	port may be either reserved or reserve-create. Two fields are		external IP address, and the external port number. For IPv4 the
	defined, the external IP address, and the external port number. For		object with value OID_NATFW_IPv4 is defined. It has a length of 8
	IPv4 the object with value 0x0010 is defined. It has a length of 8		bytes and is shown in Figure 26.
	bytes and is shown in Figure 24.
	0 16 31		0 16 31
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 0x0010 | 8 bytes |		| OID_NATFW_IPv4 | 0x0002 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| port number | reserved |		| port number | reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| IPv4 address |		| IPv4 address |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 24: External Address Object for IPv4 addresses		Figure 26: External Address Object for IPv4 addresses
	For IPv6 the object with value 0x0011 is defined. It has a length of		For IPv6 the object with value OID_NATFW_IPv6 is defined. It has a
	20 bytes and is shown in Figure 25.		length of 20 bytes and is shown in Figure 27.
	0 16 31		0 16 31
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 0x0011 | 20 bytes |		| OID_NATFW_IPv6 | 0x0005 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| port number | reserved |		| port number | reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	+ +		+ +
	| |		| |
	+ IPv6 address +		+ IPv6 address +
	| |		| |
	+ +		+ +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 25: External Address Object for IPv6 addresses		Figure 27: External Address Object for IPv6 addresses
	3.3.3.4 Extended Flow Information Object		5.3.3 Extended Flow Information Object
	In general, flow information is kept at the NTLP level during		In general, flow information is kept at the NTLP level during
	signaling. Nevertheless, some additional information may be required		signaling. The message routing information of the NTLP carries all
	for NSLP operations. The 'extended flow information' object carries		necessary information. Nevertheless, some additional information may
	this additional information about number of subsequent port numbers		be required for NSLP operations. The 'extended flow information'
	that should be allocated at middleboxes.		object carries this additional information about action to be taken
			on the installed policy rules and subsequent numbers of policy rules.
	These fields are defined for the policy rule object:		These fields are defined for the policy rule object:
			o Rule action: This field indicates the action for the policy rule
			to be activated. Allow values are 'allow' (0x01) and 'deny'
			(0x02)
	o Number of ports: This field gives the number of ports that should		o Number of ports: This field gives the number of ports that should
	be allocated beginnig at the port given in NTLP's flow routing		be allocated beginning at the port given in NTLP's message routing
	information.		information.
	0 16 31		0 16 31
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 0x0011 | 4 bytes |		| OID_NATFW_FLOW | 0x0001 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| number of ports | reserved |		| rule action | number of ports |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 26: Extended Flow Information		Figure 28: Extended Flow Information
	3.3.3.5 Error Object		5.3.4 Response Code Object
	The error object carries the reason for an error. It has only one		This object carries the response code, which may be indications for
	field, the error code, and is 2 bytes long.		either a successful request or failed request depending on the value
			of the 'response code' field.
	0 16 31		0 16 31
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| 0x0002 | 4 bytes |		| OID_NATFW_RESPONSE | 0x0001 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| error code | reserved |		| response code |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 27: Error		Figure 29: Response Code Object
	TBD: Define error clases and define the error coded. Possible
	classes are:
			TBD: Define response classes, success codes and error codes.
			Possible error classes are:
	o Policy rule errors		o Policy rule errors
	o Authentication and Authorization errors		o Authentication and Authorization errors
	o NAT		o NAT
	Currently in this memo defined errors:		Currently in this memo defined errors:
	o lifetime too big		o lifetime too big
	o lifetime not acceptable		o lifetime not acceptable
	o no NAT here		o no NAT here
	o no reservation found		o no reservation found
	o requested external address from outside		o requested external address from outside
	3.4 Message Formats		5.3.5 Response Type Object
			The response type object indicates that a specific response is needed
			to the NSLP responder.
			0 16 31
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| OID_NATFW_RESP_TYPE | 0x0001 |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			|C|S|L| reserved |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Source IP address |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 30: Response Type Object
			If the C bit is set to 1 the required response is a CREATE request
			message, otherwise a RESPONSE message. If the S bit is set to 1 the
			scoping object MUST be used. If the L bit is set to 1 the CREATE
			request message is ONLY sent if the message does not reach its
			target, even though the if the C bit is set.
			The source IP address is optional and may be set to a zero IP address
			or to a real IP address. If set to a real address, NATFW NSLP uses
			this address as assumed data sender's address.
			5.3.6 Message Sequence Number Object
			XXX Text is missing.
			0 16 31
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| OID_NATFW_MSN | 0x0001 |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| message sequence number |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 31: Message Sequence Number Object
			5.3.7 Scoping Object
			The scoping object determines the allowed scope for the particular
			message.
			0 16 31
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| OID_NATFW_SCOPE | 0x0001 |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| message scope |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 32: Scoping Object
			These 'message scope' values are allowed: region, single hop.
			5.3.8 Bound Session ID Object
			This object carries a session ID and is used for QUERY messages only.
			0 16 31
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| OID_NATFW_BID | 0x0001 |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| bound session ID |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 33: Bound Session ID Object
			5.3.9 Notify Target Object
			This object carries the IP address of the notify target node. TBD:
			Details on this, like IPv6 version etc.
			0 16 31
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| OID_NATFW_NOTIFY_TGT | 0x0001 |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| notify nodes' IPv4 address |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 34: Notify Target Object
			5.4 Message Formats
	This section defines the content of each NATFW NSLP message type.		This section defines the content of each NATFW NSLP message type.
	The message types are defined in Section 3.3.2. First, the request		The message types are defined in Section 5.2. First, the request
	messages are defined with their respective objects to be included in		messages are defined with their respective objects to be included in
	the message. Second, the response messages are defined with their		the message. Second, the response messages are defined with their
	respective objects to be included.		respective objects to be included.
	Basically, each message is constructed of NSLP header and one or more		Basically, each message is constructed of NSLP header and one or more
	NSLP objects. The order of objects is not defined, meaning that		NSLP objects. The order of objects is not defined, meaning that
	objects may occur in any sequence.		objects may occur in any sequence. Objects are marked either with
			mandatory [M] or optional [O]. Where [M] implies that this
			particular object MUST be included within the message and where [O]
			implies that this particular object is OPTIONAL within the message.
	Each section elaborates the required settings and parameters to be		Each section elaborates the required settings and parameters to be
	set by the NSLP at the NTLP, for instance, how the flow routing		set by the NSLP for the NTLP, for instance, how the message routing
	information is set.		information is set.
	3.4.1 Policy Rules		5.4.1 CREATE
	Policy rules are the building block of middlebox devices considered
	in the NATFW NSLP. For Firewalls the policy rule consists usually of
	a 5-tuple, source/destination address, transport protocol, and
	source/destination port number, plus an action like allow or deny.
	Other actions are available depending on the implementation of the
	Firewall, but NATFW NSLP uses only allow action, since a default to
	deny policy at the middlebox is assumed. For NATs the policy rule
	consists of action 'map this another address realm' and further
	mapping information, that might be in the most simply case internal
	IP address and external IP address.
	Policy rules are usually carried in one piece in signaling
	applications. In NSIS the policy rule is divided into the filter
	specification, an implicit allow action, and additional information.
	The filter specification is carried within NTLP's flow routing
	information and additional information is carried in NSLP's objects.
	Additional information is for instance the lifetime of a policy rule
	or session.
	3.4.2 Create Session (CRS)
	The create session request message is used to create NSLP sessions		The CREATE request message is used to create NSLP sessions and to
	and at middleboxes to create policy rules.		create policy rules. Furthermore, CREATE messages are used to
			refresh sessions and to delete them.
	The create session messages carries these objects:		The CREATE message carries these objects:
	o Session ID object		o Lifetime object [M]
	o Lifetime object		o Extended flow information object [M]
			o Message sequence number object [M]
			o Respose type object [O]
			o Scoping object[O]
			o Notify target [O]
	The flow routing information in the NTLP MUST be set to DS as source		The message routing information in the NTLP MUST be set to DS as
	address and DR as destination address. All other parameters MUST be		source address and DR as destination address. All other parameters
	set according the required policy rule.		MUST be set according the required policy rule. When the CREATE
			messages is received by a node operating in proxy mode Section 3.4
			the NI address is the NR address from the message that triggered the
			CREATE to be sent, if that address is not valid (wildcarded) the
			proxy node address is used instead. The NR address would be the NI's
			address provided by the message routing information of the message
			that triggered the CREATE.
	3.4.3 Reserve External Address (REA)		5.4.2 RESERVE-EXTERNAL-ADDRESS (REA)
	The reserve external address (REA) request message is used to lookup		The RESERVE-EXTERNAL-ADDRESS (REA) request message is used to target
	a NAT and to allocated an external IP address and possibly port		a NAT and to allocated an external IP address and possibly port
	number, so that the initiator of the REA request has a public		number, so that the initiator of the REA request has a public
	reachable IP address/port number.		reachable IP address/port number.
	The REA request message carries these objects:		The REA request message carries these objects:
	o Session ID object		o Lifetime object [M]
	o Lifetime object		o Message sequence number object [M]
			o Response type object [M]
			o Scoping object [M]
			o Extended flow information [O]
	The REA message needs special NTLP treatment. First of all, REA		The REA message needs special NTLP treatment. First of all, REA
	messages travel the wrong way, from the DR towards DS. Second, the		messages travel the wrong way, from the DR towards DS. Second, the
	DS' address used during the signaling may be not the actual DS (see		DS' address used during the signaling may be not the actual DS (see
	Section 3.2.10). Therefore, the NTLP flow routing information is set		Section 3.8). Therefore, the NTLP flow routing information is set to
	to DR as initiator and DS as responders, a special field is given in		DR as initiator and DS as responders, a special field is given in the
	the NTLP: The signaling destination.		NTLP: The signaling destination.
	3.4.4 Reserve-Create (REC)		5.4.3 TRIGGER
	XXX This is a proposal for a new message to support the reservation		The TRIGGER request message is used in proxy mode operation. XXX
	and simultaneous/implicit create message generation.
	The reserve-create message carries these objects:		The TRIGGER request message carries these objects:
	o Session ID object		o Lifetime object [M]
	o Lifetime object		o Message sequence number object [M]
			o Response type object [M]
			o Scoping object [M]
			o Extended flow information [O]
	NTLP issues: TBD.		XXX
	3.4.5 Prolong Session (PLS)		5.4.4 RESPONSE
	The prolong request message is used to prolong (extend) the lifetime		RESPONSE messages are responses to CREATE, REA, and QUERY messages.
	of a NATFW NSLP and policy rules at middleboxes.
	The prolong session message carries these objects:		The RESPONSE message carries these objects:
			o Lifetime object [M]
			o Response object [M]
			o External address object ([M] for success responses to REA)
	o Session ID object		This message is routed upstream.
	o Lifetime object
	The flow routing information in the NTLP MUST be set to DS as source		5.4.5 QUERY
	address and DR as destination address. All other parameters MUST be
	set according the required policy rule.
	3.4.6 Delete Session (DLS)		QUERY messages are used for diagnosis purposes.
	The delete request message is used to delete NATFW NSLP sessions.		The QUERY message carries these objects:
			o Response object [M]
			o Message sequence number object [M]
			o Scoping object [M]
			o Bound session ID [O]
	The delete session message carries these objects:		This message is routed downstream.
	o Session ID object
	The flow routing information in the NTLP MUST be set to DS as source		5.4.6 NOTIFY
	address and DR as destination address. All other parameters MUST be
	set according the required policy rule.
	3.4.7 Path Succeeded (PS)		The NOTIFY messages is used to report asynchronous events happening
			along the signaled path to other NATFW NSLP nodes.
	The path succeeded response message is used to acknowledge a		The NOTIFY message carries this object:
	successful create and prolong.		o Response code object with NOTIFY code [M].
	The path succeeded message carries these objects:		The message routing information in the NTLP MUST be set to DS as
	o Session ID object		source address and DR as destination address, forwarding direction is
	o lifetime object		upstream (Note that Section 5.4.6 discusses some design options
			regarding the message transport). The session id object must be set
			to the corresponding session that is effected by this asynchronous
			event.
	This message is routed on the reverse path.		6. NSIS NAT and Firewall Transition Issues
	3.4.8 Path Deleted (PD)		NSIS NAT and Firewall transition issues are premature and will be
			addressed in a separate draft (see [17]). An update of this section
			will be based on consensus.
	The path deleted response message is used to acknowledge a successful		7. Security Considerations
	delete request message.
	The path deleted message carries this object:		Security is of major concern particularly in case of Firewall
	o Session ID object		traversal. Security threats for NSIS signaling in general have been
			described in [6] and they are applicable to this document. [21]
			extends this threat investigtion by considering NATFW NSLP specific
			threats. Based on the identified threats a list of security
			requirements have been defined. As an important requirement for
			security protection it is necessary to provide
			o data origin authentication
			o replay protection
			o integrity protection and
			o optionally confidentiality protection
			between neighboring NATFW NSLP nodes.
	This message is routed on the reverse path.		To consider the aspect of authentication and key exchange we aim to
			reuse the mechanisms provided in [3] between neighboring nodes.
	3.4.9 Return External Address (RA)		Some scenarios also demand security between non-neighboring nodes but
			this aspect is still in discussions. A possible commonality with the
			QoS NSLP has been identified and CMS [24] has been investigated as a
			possible candidate for security protection between non-neighboring
			entities. Note that this aspect also includes some more
			sophisticated user authentication mechanisms, as described in [23].
			With regard to end-to-end security the need for a binding between an
			NSIS signaling session and application layer session has been
			described in Section 3.3 of [6].
	The return external address response message is sent back as a		In order to solicit feedback from the IETF community on some hard
	positive result of reserve external address request. It contains the		security problems for path-coupled NATFW signaling a more detailed
	reserved external IP address and port number.		description in [22] is available.
	The path succeeded message carries these objects:		The NATFW NSLP is a protocol which may involve a number of NSIS nodes
	o Session ID object		and is, as such, not a two-party protocol. This fact requires more
	o Lifetime object		thoughts about scenarios, trust relationships and authorization
	o External address object (either IPv4 or IPv6 type)		mechanisms. This section lists a few scenarios relevant for security
			and illustrates possible trust reationships which have an impact to
			authorization. More problematic scenarios are described in Appendix
			A.
	This message is routed on the reverse path.		7.1 Trust Relationship and Authorization
	3.4.10 Error Response (ER)		Trust relationships and authorization are very important for the
			protocol machinery. Trust and authorization are closely related to
			each other in the sense that a certain degree of trust is required to
			authorize a particular action. For any action (e.g. "create/delete
			/prolong policy rules), authorization is very important due to the
			nature of middleboxes.
	The error response message is sent back by any NSIS node involved in		Different types of trust relationships may affect different
	the session that occurs an error condition.		categories of middleboxes. As explained in [26], establishment of a
			financial relationship is typically very important for QoS signaling,
			whereas financial relationships are less directly of interest for
			NATFW middlebox signaling. It is therefore not particularly
			surprising that there are differences in the nature and level of
			authorization likely to be required in a QoS signaling environment
			and in NATFW middlebox signaling. For NATFW middlebox signaling, a
			stronger or weaker degree of authorization might be needed.
			Typically NATFW signaling requires authorization to configure and
			traverse particular nodes or networks which may derive indirectly
			from a financial relationship. This is a more 'absolute' situation
			either the usage is allowed or not, and the effect on both network
			owner and network user is 'binary'.
	The error message carries these objects:		Different trust relationships that appear in middlebox signaling
	o Session ID object		environments are described in the subsequent sub-sections. QoS
	o Error object		signaling today uses peer-to-peer trust relationships. They are
			simplest kind of trust relationships. However, there are reasons to
			believe that this is not the only type of trust relationship found in
			today's networks.
	This message is routed on the reverse path.		7.1.1 Peer-to-Peer Trust Relationship
	4. NSIS NAT and Firewall transitions issues		Starting with the simplest scenario, it is assumed that neighboring
			nodes trust each other. The required security association to
			authenticate and to protect a signaling message is either available
			(after manual configuration), or has been dynamically established
			with the help of an authentication and key exchange protocol. If
			nodes are located closely together, it is assumed that security
			association establishment is easier than establishing it between
			distant nodes. It is, however, difficult to describe this
			relationship generally due to the different usage scenarios and
			environments. Authorization heavily depends on the participating
			entities, but for this scenario, it is assumed that neighboring
			entities trust each other (at least for the purpose of policy rule
			creation, maintenance, and deletion). Note that Figure 35 does not
			illustrate the trust relationship between the end host and the access
			network.
	NSIS NAT and Firewall transition issues are premature and will be		+------------------------+ +-------------------------+
	addressed in a separate draft (see [17]). An update of this section		| | | |
	will be based on consensus.		| Network A | | Network B |
			| | | |
			| +---------+ +---------+ |
			| +-///-+ Middle- +---///////----+ Middle- +-///-+ |
			| | | box 1 | Trust | box 2 | | |
			| | +---------+ Relationship +---------+ | |
			| | | | | |
			| | | | | |
			| | | | | |
			| | Trust | | Trust | |
			| | Relationship | | Relationship | |
			| | | | | |
			| | | | | |
			| | | | | |
			| +--+---+ | | +--+---+ |
			| | Host | | | | Host | |
			| | A | | | | B | |
			| +------+ | | +------+ |
			+------------------------+ +-------------------------+
	5. Security Considerations		Figure 35: Peer-to-Peer Trust Relationship
	Security is of major concern particularly in case of Firewall		7.1.2 Intra-Domain Trust Relationship
	traversal. Generic threats for NSIS signaling have been discussed in
	[6] and are applicable here as well. It is necessary to provide
	proper signaling message protection and proper authorization. Note
	that the NAT is likely to be co-located with a Firewall and might
	therefore require packet filters to be changed in order to allow the
	signaling message to process and to traverse. This section aims to
	raise some items for further discussion and illustrates the problems
	the authors faced when creating a security solution for the NAT/
	Firewall NSLP.
	Installing packet filters provides some security, but has some		In larger corporations, often more than one middlebox is used to
	weaknesses, which heavily depend on the type of packet filter		protect or serve different departments. In many cases, the entire
	installed. A packet filter cannot prevent an adversary to inject		enterprise is controlled by a security department, which gives
	traffic (due to the IP spoofing capabilities). This type of attack		instructions to the department administrators. In such a scenario, a
	might not be particular helpful if the packet filter is a standard 5		peer-to-peer trust-relationship might be prevalent. Sometimes it
	tuple which is very restrictive. If packet filter installation,		might be necessary to preserve authentication and authorization
	however, allows specifying a rule, which restricts only the source IP		information within the network. As a possible solution, a
	address, then IP spoofing allows transmitting traffic to an arbitrary		centralized approach could be used, whereby an interaction between
	address. NSIS aims to provide path-coupled signaling and therefore		the individual middleboxes and a central entity (for example a policy
	an adversary is somewhat restricted in the location from which		decision point - PDP) takes place. As an alternative, individual
	attacks can be performed. Some trust is therefore assumed from nodes		middleboxes could exchange the authorization decision with another
	and networks along the path.		middlebox within the same trust domain. Individual middleboxes
			within an administrative domain should exploit their trust
			relationship instead of requesting authentication and authorization
			of the signaling initiator again and again. Thereby complex protocol
			interactions are avoided. This provides both a performance
			improvement without a security disadvantage since a single
			administrative domain can be seen as a single entity. Figure 36
			illustrates a network structure which uses a centralized entity.
	Without doubts there is a dependency on the security provided by the		+-----------------------------------------------------------+
	NTLP. Section Appendix A and Section 2.2 motivates some trust		| |
	relationship and authorization scenarios. These scenarios deserve a		| Network A |
	discussion since some of them (particularly one with a missing		| |
	network-to-network trust relationship) is different to what is know		| |
	from QoS signaling. To address some of these trust relationships and		| +---------+ +---------+
	authorization issues requires security mechanisms between		| +----///--------+ Middle- +------///------++ Middle- +---
	non-neighboring nodes at the NSLP layer. For the group of authors it		| | | box 2 | | box 2 |
	seems that peer-to-peer and end-to-middle security needs to be		| | +----+----+ +----+----+
	provided. An NSLP security mechanism between neighboring NSLP peers		| | | | |
	might be necessary if security mechanisms at the NTLP do not provide		| +----+----+ | | |
	adequate protection mechanisms. This issue is, however, still in		| | Middle- +--------+ +---------+ | |
	discussion.		| | box 1 | | | | |
			| +----+----+ | | | |
			| | | | | |
			| - | | | |
			| - | +----+-----+ | |
			| | | | Policy | | |
			| +--+---+ +-----------+ Decision +----------+ |
			| | Host | | Point | |
			| | A | +----------+ |
			| +------+ |
			+-----------------------------------------------------------+
	As a design goal it seems to be favorable to reuse existing		Figure 36: Intra-domain Trust Relationship
	mechanisms to the best extend possible. In most cases it is
	necessary to carry the objects for end-to-middle as NSLP payloads
	since the presence of NATs might prevent direct communication. Three
	security mechanisms have to be considered in more detail in a future
	version of this document: CMS [21] and Identity Representation for
	RSVP [15]. The authors believe that CMS more suitable (since it
	provides much more functionality). The details deserve further
	discussion and implementation experience.
	With regard to signal between two end hosts even though the receiver		7.1.3 End-to-Middle Trust Relationship
	is behind a NAT this proposal suggests creating state by the data
	receiver first. This allows NSIS signaling messages to traverse a
	NAT at the receiver side (due to the established state at this NAT
	box) and simplifies security handling. To achieve this behavior it
	is required to install NSIS NTLP and NSLP state. Furthermore, it is
	envisioned to associate the two signaling parts (one part from the
	data sender to the NAT and the other part from the NAT to the data
	receiver) with the help of the Session Identifier. As such, the
	discussion in [15] is relevant for this document.
	Another interesting property of this protocol proposal is to prevent		In some scenarios, a simple peer-to-peer trust relationship between
	Denial of Service attacks against NAT boxes whereby an adversary		participating nodes is not sufficient. Network B might require
	allocates NAT bindings with the help of data packets. Since these		additional authorization of the signaling message initiator. If
	data packets do not provide any type of authentication and are not		authentication and authorization information is not attached to the
	authorized any adversary is able to mount such an attack. This		initial signaling message then the signaling message arriving at
	attack has been mentioned at several places in the literature		Middlebox 2 would result in an error message being created, which
	already and is particularly harmful if no NAPT functionality is used		indicates the additional authorization requirement. In many cases
	(i.e. if a new NAT binding consumes one IP address of a pool of IP		the signaling message initiator is already aware of the additionally
	addresses). Using the protocol described in this document additional		required authorization before the signaling message exchange is
	security can be achieved and more fairness can be provided.		executed. Replay protection is a requirement for authentication to
			the non-neighboring middlebox, which might be difficult to accomplish
			without adding additional roundtrips to the signaling protocol (e.g.,
			by adding a challenge/response type of message exchange).
	6. Open Issues		Figure 37 shows the slightly more complex trust relationships in this
			scenario.
	At least the following issues require further discussion:		+----------------------+ +--------------------------+
	o Option processing rules in presence of unknown options.		| | | |
	o Terminology w.r.t. the term wrong way.		| Network A | | Network B |
	o NTLP: New object and semantics for REA.		| | | |
	o NTLP and NATFW NSLP interaction		| | Trust | |
	o List of NTLP transport modes per NSLP message		| | Relationship | |
	o Routing Change detection		| +---------+ +---------+ |
	o Query message, definition of semantics needed		| +-///-+ Middle- +---///////----+ Middle- +-///-+ |
	o Is there a need for a QoS NSLP RSN like object/mechanism in NATFW		| | | box 1 | +-------+ box 2 | | |
	NSLP?		| | +---------+ | +---------+ | |
	o Add IANA considerations section.		| | | | | | |
	o re-work security considerations.		| |Trust | | | | |
	o Query message: Syntax and semantics.		| |Relationship | | | | |
	o Add text about asynchronous messages.		| | | | | Trust | |
	o Anycast address for REA.		| | | | | Relationship| |
	o Check common formats with QoS NSLP		| | | | | | |
	o Change length field of objects to long words as unit?		| | | | | | |
	o Variable length for session id?		| | | | | | |
	o Meaning of 0 as session ID.		| | | | | | |
	o Extended flow object: Needs refinement		| +--+---+ | | | +--+---+ |
			| | Host +----///----+------+ | | Host | |
			| | A | |Trust | | B | |
			| +------+ |Relationship | +------+ |
			+----------------------+ +--------------------------+
	7. Contributors		Figure 37: End-to-Middle Trust Relationship
			Finally it should be noted that installing packet filters provides
			some security, but also has some weaknesses, which heavily depend on
			the type of packet filter installed. A packet filter cannot prevent
			an adversary to inject traffic (due to the IP spoofing capabilities).
			This type of attack might not be particular helpful if the packet
			filter is a standard 5 tuple which is very restrictive. If packet
			filter installation, however, allows specifying a rule, which
			restricts only the source IP address, then IP spoofing allows
			transmitting traffic to an arbitrary address. NSIS aims to provide
			path-coupled signaling and therefore an adversary is somewhat
			restricted in the location from which attacks can be performed. Some
			trust is therefore assumed from nodes and networks along the path.
			8. Open Issues
			The NATFW NSLP has a series of related documents discussing several
			other aspects of path-coupled NATFW signaling, including security
			[22], migration (i.e., traversal of nsis unaware NATs) [17],
			intra-realm signaling [18], and inter-working with SIP [19].
			Summaries of the outcomes from these documents may be added,
			depending on WG feedback, to a later version of this draft.
			A more detailed list of open issue can be found at: http://
			nsis.srmr.co.uk/cgi-bin/roundup.cgi/nsis-natfw-issues/index
			9. Contributors
	A number of individuals have contributed to this draft. Since it was		A number of individuals have contributed to this draft. Since it was
	not possible to list them all in the authors section, it was decided		not possible to list them all in the authors section, it was decided
	to split it and move Marcus Brunner and Henning Schulzrinne into the		to split it and move Marcus Brunner and Henning Schulzrinne into the
	contributors section. Separating into two groups was done without		contributors section. Separating into two groups was done without
	treating any one of them better (or worse) than others.		treating any one of them better (or worse) than others.
	8. References		10. References
	8.1 Normative References		10.1 Normative References
	[1] Hancock et al, R., "Next Steps in Signaling: Framework", DRAFT		[1] Hancock et al, R., "Next Steps in Signaling: Framework", DRAFT
	draft-ietf-nsis-fw-05.txt, October 2003.		draft-ietf-nsis-fw-05.txt, October 2003.
	[2] Brunner et al., M., "Requirements for Signaling Protocols",		[2] Brunner et al., M., "Requirements for Signaling Protocols",
	DRAFT draft-ietf-nsis-req-09.txt, October 2003.		DRAFT draft-ietf-nsis-req-09.txt, October 2003.
	[3] Schulzrinne, H. and R. Hancock, "GIMPS: General Internet		[3] Schulzrinne, H. and R. Hancock, "GIMPS: General Internet
	Messaging Protocol for Signaling", DRAFT		Messaging Protocol for Signaling", DRAFT
	draft-ietf-nsis-ntlp-00.txt, October 2003.		draft-ietf-nsis-ntlp-02.txt, October 2003.
	[4] Van den Bosch, S., Karagiannis, G. and A. McDonald, "NSLP for		[4] Van den Bosch, S., Karagiannis, G. and A. McDonald, "NSLP for
	Quality-of-Service signaling", DRAFT		Quality-of-Service signaling", DRAFT
	draft-ietf-nsis-qos-nslp-03.txt, May 2004.		draft-ietf-nsis-qos-nslp-03.txt, May 2004.
	[5] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.		[5] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.
	[6] Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS",		[6] Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS",
	DRAFT draft-ietf-nsis-threats-01.txt, January 2003.		DRAFT draft-ietf-nsis-threats-01.txt, January 2003.
	[7] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A.		[7] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A.
	Rayhan, "Middlebox communication architecture and framework",		Rayhan, "Middlebox communication architecture and framework",
	RFC 3303, August 2002.		RFC 3303, August 2002.
	8.2 Informative References		10.2 Informative References
	[8] Srisuresh, P. and M. Holdrege, "IP Network Address Translator		[8] Srisuresh, P. and M. Holdrege, "IP Network Address Translator
	(NAT) Terminology and Considerations, RFC 2663", August 1999.		(NAT) Terminology and Considerations, RFC 2663", August 1999.
	[9] Srisuresh, P. and M. Holdrege, "Network Address Translator		[9] Srisuresh, P. and M. Holdrege, "Network Address Translator
	(NAT)Terminology and Considerations, RFC 2663".		(NAT)Terminology and Considerations, RFC 2663".
	[10] Srisuresh, P. and E. Egevang, "Traditional IP Network Address		[10] Srisuresh, P. and E. Egevang, "Traditional IP Network Address
	Translator (Traditional NAT), RFC 3022", January 2001.		Translator (Traditional NAT), RFC 3022", January 2001.
	skipping to change at page 48, line 32 ¶		skipping to change at page 62, line 32 ¶
	Tschofenig, "NATFirewall NSLP Intra-realm considerations",		Tschofenig, "NATFirewall NSLP Intra-realm considerations",
	DRAFT draft-aoun-nsis-nslp-natfw-intrarealm-00.txt, Februar		DRAFT draft-aoun-nsis-nslp-natfw-intrarealm-00.txt, Februar
	2004.		2004.
	[19] Martin, M., Brunner, M. and M. Stiemerling, "SIP NSIS		[19] Martin, M., Brunner, M. and M. Stiemerling, "SIP NSIS
	Interactions for NAT/Firewall Traversal", DRAFT		Interactions for NAT/Firewall Traversal", DRAFT
	draft-martin-nsis-nslp-natfw-sip-00.txt, Februar 2004.		draft-martin-nsis-nslp-natfw-sip-00.txt, Februar 2004.
	[20] Martin, M., Brunner, M., Stiemerling, M., Girao, J. and C.		[20] Martin, M., Brunner, M., Stiemerling, M., Girao, J. and C.
	Aoun, "A NSIS NAT/Firewall NSLP Security Infrastructure", DRAFT		Aoun, "A NSIS NAT/Firewall NSLP Security Infrastructure", DRAFT
	draft-martin-nsis-nslp-natfw-security-01.txt, Februar 2004.		draft-martin-nsis-nslp-natfw-security-01.txt, February 2004.
	[21] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369,		[21] Fessi, A., Brunner, M., Stiemerling, M., Thiruvengadam, S.,
			Tschofenig, H. and C. Aoun, "Security Threats for the NAT/
			Firewall NSLP", DRAFT draft-fessi-nsis-natfw-threats-01.txt,
			July 2004.
			[22] Tschofenig, H., "Path-coupled NAT/Firewall Signaling Security
			Problems", draft-tschofenig-nsis-natfw-security-problems-00.txt
			(work in progress), July 2004.
			[23] Tschofenig, H. and J. Kross, "Extended QoS Authorization for
			the QoS NSLP", draft-tschofenig-nsis-qos-ext-authz-00.txt (work
			in progress), July 2004.
			[24] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369,
	August 2002.		August 2002.
	[22] Manner, J., Suihko, T., Kojo, M., Liljeberg, M. and K.		[25] Manner, J., Suihko, T., Kojo, M., Liljeberg, M. and K.
	Raatikainen, "Localized RSVP", DRAFT draft-manner-lrsvp-00.txt,		Raatikainen, "Localized RSVP", DRAFT draft-manner-lrsvp-00.txt,
	November 2002.		November 2002.
	[23] Tschofenig, H., Buechli, M., Van den Bosch, S. and H.		[26] Tschofenig, H., Buechli, M., Van den Bosch, S. and H.
	Schulzrinne, "NSIS Authentication, Authorization and Accounting		Schulzrinne, "NSIS Authentication, Authorization and Accounting
	Issues", March 2003.		Issues", March 2003.
	[24] Amini, L. and H. Schulzrinne, "Observations from router-level		[27] Amini, L. and H. Schulzrinne, "Observations from router-level
	internet traces", DIMACS Workshop on Internet and WWW		internet traces", DIMACS Workshop on Internet and WWW
	Measurement, Mapping and Modelin Jersey) , Februar 2002.		Measurement, Mapping and Modelin Jersey) , Februar 2002.
	[25] Adrangi, F. and H. Levkowetz, "Problem Statement: Mobile IPv4		[28] Adrangi, F. and H. Levkowetz, "Problem Statement: Mobile IPv4
	Traversal of VPN Gateways",		Traversal of VPN Gateways",
	draft-ietf-mobileip-vpn-problem-statement-req-02.txt (work in		draft-ietf-mobileip-vpn-problem-statement-req-02.txt (work in
	progress), April 2003.		progress), April 2003.
	[26] Ohba, Y., Das, S., Patil, P., Soliman, H. and A. Yegin,		[29] Ohba, Y., Das, S., Patil, P., Soliman, H. and A. Yegin,
	"Problem Space and Usage Scenarios for PANA",		"Problem Space and Usage Scenarios for PANA",
	draft-ietf-pana-usage-scenarios-06 (work in progress), April		draft-ietf-pana-usage-scenarios-06 (work in progress), April
	2003.		2003.
	[27] Shore, M., "The TIST (Topology-Insensitive Service Traversal)		[30] Shore, M., "The TIST (Topology-Insensitive Service Traversal)
	Protocol", DRAFT draft-shore-tist-prot-00.txt, May 2002.		Protocol", DRAFT draft-shore-tist-prot-00.txt, May 2002.
	[28] Tschofenig, H., Schulzrinne, H. and C. Aoun, "A Firewall/NAT		[31] Tschofenig, H., Schulzrinne, H. and C. Aoun, "A Firewall/NAT
	Traversal Client for CASP", DRAFT		Traversal Client for CASP", DRAFT
	draft-tschofenig-nsis-casp-midcom-01.txt, March 2003.		draft-tschofenig-nsis-casp-midcom-01.txt, March 2003.
	[29] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,		[32] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
	Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:		Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
	Session Initiation Protocol", RFC 3261, June 2002.		Session Initiation Protocol", RFC 3261, June 2002.
	[30] Brunner, M., Stiemerling, M., Martin, M., Tschofenig, H. and H.		[33] Brunner, M., Stiemerling, M., Martin, M., Tschofenig, H. and H.
	Schulzrinne, "NSIS NAT/FW NSLP: Problem Statement and		Schulzrinne, "NSIS NAT/FW NSLP: Problem Statement and
	Framework", DRAFT draft-brunner-nsis-midcom-ps-00.txt, June		Framework", DRAFT draft-brunner-nsis-midcom-ps-00.txt, June
	2003.		2003.
	[31] Ford, B., Srisuresh, P. and D. Kegel, "Peer-to-Peer(P2P)		[34] Ford, B., Srisuresh, P. and D. Kegel, "Peer-to-Peer(P2P)
	communication Network Address Translators(NAT)", DRAFT		communication Network Address Translators(NAT)", DRAFT
	draft-ford-midcom-p2p-02.txt, March 2004.		draft-ford-midcom-p2p-02.txt, March 2004.
	[32] Rosenberg et al, J., "STUN - Simple Traversal of User Datagram		[35] Rosenberg et al, J., "STUN - Simple Traversal of User Datagram
	Protocol (UDP) Through Network Address Translators (NATs)", RFC		Protocol (UDP) Through Network Address Translators (NATs)", RFC
	3489, March 2003.		3489, March 2003.
	[33] Rekhter et al, Y., "Address Allocation for Private Internets",		[36] Rekhter et al, Y., "Address Allocation for Private Internets",
	RFC 1918, February 1996.		RFC 1918, February 1996.
			[37] Rosenberg, J., "Traversal Using Relay NAT (TURN)",
			draft-rosenberg-midcom-turn-04 (work in progress), February
			2004.
			[38] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M.,
			Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S.
			Waldbusser, "Terminology for Policy-Based Management", RFC
			3198, November 2001.
	Authors' Addresses		Authors' Addresses
	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@netlab.nec.de		EMail: stiemerling@netlab.nec.de
	URI:		URI:
	Hannes Tschoefenig		Hannes Tschofenig
	Siemens AG		Siemens AG
	Otto-Hahn-Ring 6		Otto-Hahn-Ring 6
	Munich 81739		Munich 81739
	Germany		Germany
	Phone:		Phone:
	EMail: Hannes.Tschofenig@siemens.com		EMail: Hannes.Tschofenig@siemens.com
	URI:		URI:
	Miquel Martin		Miquel Martin
	skipping to change at page 50, line 27 ¶		skipping to change at page 64, line 44 ¶
	Kurfuersten-Anlage 36		Kurfuersten-Anlage 36
	Heidelberg 69115		Heidelberg 69115
	Germany		Germany
	Phone: +49 (0) 6221 905 11 16		Phone: +49 (0) 6221 905 11 16
	EMail: miquel.martin@netlab.nec.de		EMail: miquel.martin@netlab.nec.de
	URI:		URI:
	Cedric Aoun		Cedric Aoun
	Nortel Networks		Nortel Networks
	France		France
	EMail: cedric.aoun@nortelnetworks.com		EMail: cedric.aoun@nortelnetworks.com
	Appendix A. Problems and Challenges		Appendix A. Problems and Challenges
	This section describes a number of problems that have to be addressed		This section describes a number of problems that have to be addressed
	for NSIS NAT/Firewall. Issues presented here are subject to further		for NSIS NAT/Firewall. Issues presented here are subject to further
	discussions. These issues might be also of relevance to other NSLP		discussions. These issues might be also of relevance to other NSLP
	protocols.		protocols.
	A.1 Missing Network-to-Network Trust Relationship		A.1 Missing Network-to-Network Trust Relationship
	Peer-to-peer trust relationship, as shown in Figure 10, is a very		Peer-to-peer trust relationship, as shown in Figure 35, is a very
	convenient assumption that allows simplified signaling message		convenient assumption that allows simplified signaling message
	processing. However, it might not always be applicable, especially		processing. However, it might not always be applicable, especially
	between two arbitrary access networks (over a core network where		between two arbitrary access networks (over a core network where
	signaling messages are not interpreted). Possibly peer-to-peer trust		signaling messages are not interpreted). Possibly peer-to-peer trust
	relationship does not exist because of the large number of networks		relationship does not exist because of the large number of networks
	and the unwillingness of administrators to have other network		and the unwillingness of administrators to have other network
	operators to create holes in their Firewalls without proper		operators to create holes in their Firewalls without proper
	authorization. Hence in the following scenario we assume a somewhat		authorization.
	different message processing and show three possible approaches to
	tackle the problem. None of these three approaches is without
	drawbacks or constraining assumptions.
	+----------------------+ +--------------------------+		+----------------------+ +--------------------------+
	| | | |		| | | |
	| Network A | | Network B |		| Network A | | Network B |
	| | | |		| | | |
	| +---------+ Missing +---------+ |		| +---------+ Missing +---------+ |
	| +-///-+ Middle- | Trust | Middle- +-///-+ |		| +-///-+ Middle- | Trust | Middle- +-///-+ |
	| | | box 1 | Relation- | box 2 | | |		| | | box 1 | Relation- | box 2 | | |
	| | +---------+ ship +---------+ | |		| | +---------+ ship +---------+ | |
	| | | or | | |		| | | or | | |
	skipping to change at page 52, line 27 ¶		skipping to change at page 65, line 46 ¶
	| | Relationship | | Relationship | |		| | Relationship | | Relationship | |
	| | | | | |		| | | | | |
	| | | | | |		| | | | | |
	| | | | | |		| | | | | |
	| +--+---+ | | +--+---+ |		| +--+---+ | | +--+---+ |
	| | Host | | | | Host | |		| | Host | | | | Host | |
	| | A | | | | B | |		| | A | | | | B | |
	| +------+ | | +------+ |		| +------+ | | +------+ |
	+----------------------+ +--------------------------+		+----------------------+ +--------------------------+
	Figure 28: Missing Network-to-Network Trust Relationship		Figure 38: Missing Network-to-Network Trust Relationship
	Figure 28 illustrates a problem whereby an external node is not		Figure 38 illustrates a problem whereby an external node is not
	allowed to manipulate (create, delete, query, etc.) packet filters at		allowed to manipulate (create, delete, query, etc.) packet filters at
	a Firewall. Opening pinholes is only allowed for internal nodes or		a Firewall. Opening pinholes is only allowed for internal nodes or
	with a certain authorization permission. Hence the solution		with a certain authorization permission. Hence the solution
	alternatives in Section 3.2.2 focus on establishing the necessary		alternatives in Section 3.3.2 focus on establishing the necessary
	trust with cooperation of internal nodes.		trust with cooperation of internal nodes.
	A.2 Relationship with routing		A.2 Relationship with routing
	The data path is following the "normal" routes. The NAT/FW devices		The data path is following the "normal" routes. The NAT/FW devices
	along the data path are those providing the service. In this case		along the data path are those providing the service. In this case
	the service is something like "open a pinhole" or even more general		the service is something like "open a pinhole" or even more general
	"allow for connectivity between two communication partners". The		"allow for connectivity between two communication partners". The
	benefit of using path-coupled signaling is that the NSIS NATFW NSLP		benefit of using path-coupled signaling is that the NSIS NATFW NSLP
	does not need to determine what middleboxes or in what order the data		does not need to determine what middleboxes or in what order the data
	skipping to change at page 53, line 4 ¶		skipping to change at page 66, line 24 ¶
	benefit of using path-coupled signaling is that the NSIS NATFW NSLP		benefit of using path-coupled signaling is that the NSIS NATFW NSLP
	does not need to determine what middleboxes or in what order the data		does not need to determine what middleboxes or in what order the data
	flow will go through.		flow will go through.
	Creating NAT bindings modifies the path of data packets between two		Creating NAT bindings modifies the path of data packets between two
	end points. Without NATs involved, packets flow from endhost to		end points. Without NATs involved, packets flow from endhost to
	endhost following the path given by the routing. With NATs involved,		endhost following the path given by the routing. With NATs involved,
	this end-to-end flow is not directly possible, because of separated		this end-to-end flow is not directly possible, because of separated
	address realms. Thus, data packets flow towards the external IP		address realms. Thus, data packets flow towards the external IP
	address at a NAT (external IP address may be a public IP address).		address at a NAT (external IP address may be a public IP address).
	Other NSIS NSLPs, for instance QoS NSLP, which do not interfere with		Other NSIS NSLPs, for instance QoS NSLP, which do not interfere with
	routing - instead they only follow the path of the data packets.		routing - instead they only follow the path of the data packets.
	A.3 Affected Parts of the Network		A.3 Affected Parts of the Network
	NATs and Firewalls are usually located at the edge of the network,		NATs and Firewalls are usually located at the edge of the network,
	whereby other signaling applications affect all nodes along the path.		whereby other signaling applications affect all nodes along the path.
	One typical example is QoS signaling where all networks along the		One typical example is QoS signaling where all networks along the
	path must provide QoS in order to achieve true end-to-end QoS. In		path must provide QoS in order to achieve true end-to-end QoS. In
	the NAT/Firewall case, only some of the domains/nodes are affected		the NAT/Firewall case, only some of the domains/nodes are affected
	(typically access networks), whereas most parts of the networks and		(typically access networks), whereas most parts of the networks and
	nodes are unaffected (e.g. the core network).		nodes are unaffected (e.g., the core network).
	This fact raises some questions. Should an NSIS NTLP node intercept		This fact raises some questions. Should an NSIS NTLP node intercept
	every signaling message independently of the upper layer signaling		every signaling message independently of the upper layer signaling
	application or should it be possible to make the discovery procedure		application or should it be possible to make the discovery procedure
	more intelligent to skip nodes. These questions are also related to		more intelligent to skip nodes. These questions are also related to
	the question whether NSIS NAT/FW should be combined with other NSIS		the question whether NSIS NAT/FW should be combined with other NSIS
	signaling applications.		signaling applications.
	A.4 NSIS backward compatibility with NSIS unaware NAT and Firewalls		A.4 NSIS backward compatibility with NSIS unaware NAT and Firewalls
	skipping to change at page 55, line 9 ¶		skipping to change at page 68, line 29 ¶
	A.7 Addressing		A.7 Addressing
	A more general problem of NATs is the addressing of the end-point.		A more general problem of NATs is the addressing of the end-point.
	NSIS signaling message have to be addressed to the other end host to		NSIS signaling message have to be addressed to the other end host to
	follow data packets subsequently sent. Therefore, a public IP		follow data packets subsequently sent. Therefore, a public IP
	address of the receiver has to be known prior to sending an NSIS		address of the receiver has to be known prior to sending an NSIS
	message. When NSIS signaling messages contain IP addresses of the		message. When NSIS signaling messages contain IP addresses of the
	sender and the receiver in the signaling message payloads, then an		sender and the receiver in the signaling message payloads, then an
	NSIS entity must modify them. This is one of the cases, where a NSIS		NSIS entity must modify them. This is one of the cases, where a NSIS
	aware NATs is also helpful for other types of signaling applications		aware NATs is also helpful for other types of signaling applications
	e.g. QoS signaling.		e.g., QoS signaling.
	A.8 NTLP/NSLP NAT Support		A.8 NTLP/NSLP NAT Support
	It must be possible for NSIS NATs along the path to change NTLP and/		It must be possible for NSIS NATs along the path to change NTLP and/
	or NSLP message payloads, which carry IP address and port		or NSLP message payloads, which carry IP address and port
	information. This functionality includes the support of providing		information. This functionality includes the support of providing
	mid-session and mid-path modification of these payloads. As a		mid-session and mid-path modification of these payloads. As a
	consequence these payloads must not be reordered, integrity protected		consequence these payloads must not be reordered, integrity protected
	and/or encrypted in a non peer-to-peer fashion (e.g. end-to-middle,		and/or encrypted in a non peer-to-peer fashion (e.g., end-to-middle,
	end-to-end protection). Ideally these mutable payloads must be		end-to-end protection). Ideally these mutable payloads must be
	marked (e.g. a protected flag) to assist NATs in their effort of		marked (e.g., a protected flag) to assist NATs in their effort of
	adjusting these payloads.		adjusting these payloads.
	A.9 Combining Middlebox and QoS signaling		A.9 Combining Middlebox and QoS signaling
	In many cases, middlebox and QoS signaling has to be combined at		In many cases, middlebox and QoS signaling has to be combined at
	least logically. Hence, it was suggested to combine them into a		least logically. Hence, it was suggested to combine them into a
	single signaling message or to tie them together with the help of		single signaling message or to tie them together with the help of
	some sort of data connection identifier, later on referred as Session		some sort of data connection identifier, later on referred as Session
	ID. This, however, has some disadvantages such as:		ID. This, however, has some disadvantages such as:
	- NAT/FW NSLP signaling affects a much small number of NSIS nodes		- NAT/FW NSLP signaling affects a much small number of NSIS nodes
	along the path (for example compared to the QoS signaling).		along the path (for example compared to the QoS signaling).
	- NAT/FW signaling might show different signaling patterns (e.g.		- NAT/FW signaling might show different signaling patterns (e.g.,
	required end-to-middle communication).		required end-to-middle communication).
	- The refresh interval is likely to be different.		- The refresh interval is likely to be different.
	- The number of error cases increase as different signaling		- The number of error cases increase as different signaling
	applications are combined into a single message. The combination of		applications are combined into a single message. The combination of
	error cases has to be considered.		error cases has to be considered.
	A.10 Inability to know the scenario		A.10 Inability to know the scenario
	In Section 2.1 a number of different scenarios are presented. Data		In Section 2 a number of different scenarios are presented. Data
	receiver and sender may be located behind zero, one, or more		receiver and sender may be located behind zero, one, or more
	Firewalls and NATs. Depending on the scenario, different signaling		Firewalls and NATs. Depending on the scenario, different signaling
	approaches have to be taken. For instance, data receiver with no		approaches have to be taken. For instance, data receiver with no
	NAT and Firewall can receive any sort of data and signaling without		NAT and Firewall can receive any sort of data and signaling without
	any further action. Data receivers behind a NAT must first obtain a		any further action. Data receivers behind a NAT must first obtain a
	public IP address before any signaling can happen. The scenario		public IP address before any signaling can happen. The scenario
	might even change over time with moving networks, ad-hoc networks or		might even change over time with moving networks, ad-hoc networks or
	with mobility.		with mobility.
	NSIS signaling must assume the worst case and cannot put		NSIS signaling must assume the worst case and cannot put
	skipping to change at page 57, line 7 ¶		skipping to change at page 70, line 7 ¶
	"discovery" periodically such that the NSIS entity at the end host		"discovery" periodically such that the NSIS entity at the end host
	has enough information to decide which scenario is currently		has enough information to decide which scenario is currently
	applicable. This additional messaging, which might not be necessary		applicable. This additional messaging, which might not be necessary
	in all cases, requires additional performance, bandwidth and adds		in all cases, requires additional performance, bandwidth and adds
	complexity. Additional, information by the user can provide		complexity. Additional, information by the user can provide
	information to assist this "discovery" process, but cannot replace		information to assist this "discovery" process, but cannot replace
	it.		it.
	Appendix B. Acknowledgments		Appendix B. Acknowledgments
	We would like to acknowledge Vishal Sankhla and Joao Girao for their		We would like to acknowledge: Vishal Sankhla and Joao Girao for their
	input to this draft.		input to this draft; and Reinaldo Penno for his comments on the
			initial version of the document. Furthermore, we would like thank
			Elwyn Davis for his valuable help and input.
	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. 313 change blocks.
	1260 lines changed or deleted		1794 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/