< draft-ietf-nsis-nslp-natfw-14.txt		draft-ietf-nsis-nslp-natfw-15.txt >
	NSIS Working Group M. Stiemerling		NSIS Working Group M. Stiemerling
	Internet-Draft NEC		Internet-Draft NEC
	Intended status: Standards Track H. Tschofenig		Intended status: Standards Track H. Tschofenig
	Expires: September 6, 2007 Siemens		Expires: January 10, 2008 NSN
	C. Aoun		C. Aoun
	E. Davies		E. Davies
	Folly Consulting		Folly Consulting
	March 5, 2007		July 9, 2007
	NAT/Firewall NSIS Signaling Layer Protocol (NSLP)		NAT/Firewall NSIS Signaling Layer Protocol (NSLP)
	draft-ietf-nsis-nslp-natfw-14.txt		draft-ietf-nsis-nslp-natfw-15.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		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 becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	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
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 38 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on September 6, 2007.		This Internet-Draft will expire on January 10, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	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 (NATs) and firewalls. This NSLP allows		Network Address Translators (NATs) and firewalls. This NSLP allows
	hosts to signal on the data path for NATs and firewalls to be		hosts to signal on the data path for NATs and firewalls to be
	configured according to the needs of the application data flows. It		configured according to the needs of the application data flows. It
	enables hosts behind NATs to obtain a public reachable address and		enables hosts behind NATs to obtain a public reachable address and
	hosts behind firewalls to receive data traffic. The overall		hosts behind firewalls to receive data traffic. The overall
	architecture is given by the framework and requirements defined by		architecture is given by the framework and requirements defined by
	the Next Steps in Signaling (NSIS) working group. The network		the Next Steps in Signaling (NSIS) working group. The network
	scenarios, the protocol itself, and examples for path-coupled		scenarios, the protocol itself, and examples for path-coupled
	signaling are given in this memo.		signaling are given in this memo.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
	1.1. Terminology and Abbreviations . . . . . . . . . . . . . . 7		1.1. Terminology and Abbreviations . . . . . . . . . . . . . . 7
	1.2. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 10		1.2. Middleboxes . . . . . . . . . . . . . . . . . . . . . . . 10
	1.3. General Scenario for NATFW Traversal . . . . . . . . . . 11		1.3. General Scenario for NATFW Traversal . . . . . . . . . . . 11
	2. Network Deployment Scenarios using the NATFW NSLP . . . . . . 13		2. Network Deployment Scenarios using the NATFW NSLP . . . . . . 13
	2.1. Firewall Traversal . . . . . . . . . . . . . . . . . . . 13		2.1. Firewall Traversal . . . . . . . . . . . . . . . . . . . . 13
	2.2. NAT with two private Networks . . . . . . . . . . . . . . 14		2.2. NAT with two private Networks . . . . . . . . . . . . . . 14
	2.3. NAT with Private Network on Sender Side . . . . . . . . . 15		2.3. NAT with Private Network on Sender Side . . . . . . . . . 15
	2.4. NAT with Private Network on Receiver Side Scenario . . . 15		2.4. NAT with Private Network on Receiver Side Scenario . . . . 15
	2.5. Both End Hosts behind twice-NATs . . . . . . . . . . . . 16		2.5. Both End Hosts behind twice-NATs . . . . . . . . . . . . . 16
	2.6. Both End Hosts Behind Same NAT . . . . . . . . . . . . . 17		2.6. Both End Hosts Behind Same NAT . . . . . . . . . . . . . . 17
	2.7. Multihomed Network with NAT . . . . . . . . . . . . . . . 18		2.7. Multihomed Network with NAT . . . . . . . . . . . . . . . 18
	2.8. Multihomed Network with Firewall . . . . . . . . . . . . 19		2.8. Multihomed Network with Firewall . . . . . . . . . . . . . 19
	3. Protocol Description . . . . . . . . . . . . . . . . . . . . 20		3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 20
	3.1. Policy Rules . . . . . . . . . . . . . . . . . . . . . . 20		3.1. Policy Rules . . . . . . . . . . . . . . . . . . . . . . . 20
	3.2. Basic Protocol Overview . . . . . . . . . . . . . . . . . 21		3.2. Basic Protocol Overview . . . . . . . . . . . . . . . . . 21
	3.2.1. Message Types . . . . . . . . . . . . . . . . . . . . 25		3.2.1. Message Types . . . . . . . . . . . . . . . . . . . . 25
	3.2.2. Classification of RESPONSE Messages . . . . . . . . . 25		3.2.2. Classification of RESPONSE Messages . . . . . . . . . 25
	3.2.3. NATFW NSLP Signaling Sessions . . . . . . . . . . . . 26		3.2.3. NATFW NSLP Signaling Sessions . . . . . . . . . . . . 26
	3.3. Basic Message Processing . . . . . . . . . . . . . . . . 27		3.3. Basic Message Processing . . . . . . . . . . . . . . . . . 27
	3.4. Calculation of Signaling Session Lifetime . . . . . . . . 27		3.4. Calculation of Signaling Session Lifetime . . . . . . . . 27
	3.5. Message Sequencing . . . . . . . . . . . . . . . . . . . 30		3.5. Message Sequencing . . . . . . . . . . . . . . . . . . . . 30
	3.6. Authentication, Authorization, and Policy Decisions . . . 31		3.6. Authentication, Authorization, and Policy Decisions . . . 31
	3.7. Protocol Operations . . . . . . . . . . . . . . . . . . . 32		3.7. Protocol Operations . . . . . . . . . . . . . . . . . . . 32
	3.7.1. Creating Signaling Sessions . . . . . . . . . . . . . 32		3.7.1. Creating Signaling Sessions . . . . . . . . . . . . . 32
	3.7.2. Reserving External Addresses . . . . . . . . . . . . 35		3.7.2. Reserving External Addresses . . . . . . . . . . . . . 35
	3.7.3. NATFW NSLP Signaling Session Refresh . . . . . . . . 42		3.7.3. NATFW NSLP Signaling Session Refresh . . . . . . . . . 42
	3.7.4. Deleting Signaling Sessions . . . . . . . . . . . . . 43		3.7.4. Deleting Signaling Sessions . . . . . . . . . . . . . 43
	3.7.5. Reporting Asynchronous Events . . . . . . . . . . . . 44		3.7.5. Reporting Asynchronous Events . . . . . . . . . . . . 44
	3.7.6. Proxy Mode of Operation . . . . . . . . . . . . . . . 46		3.7.6. Proxy Mode of Operation . . . . . . . . . . . . . . . 46
	3.8. De-Multiplexing at NATs . . . . . . . . . . . . . . . . . 49		3.8. De-Multiplexing at NATs . . . . . . . . . . . . . . . . . 49
	3.9. Reacting to Route Changes . . . . . . . . . . . . . . . . 51		3.9. Reacting to Route Changes . . . . . . . . . . . . . . . . 51
	3.10. Updating Policy Rules . . . . . . . . . . . . . . . . . . 51		3.10. Updating Policy Rules . . . . . . . . . . . . . . . . . . 51
	4. NATFW NSLP Message Components . . . . . . . . . . . . . . . . 53		4. NATFW NSLP Message Components . . . . . . . . . . . . . . . . 53
	4.1. NSLP Header . . . . . . . . . . . . . . . . . . . . . . . 53		4.1. NSLP Header . . . . . . . . . . . . . . . . . . . . . . . 53
	4.2. NSLP Objects . . . . . . . . . . . . . . . . . . . . . . 54		4.2. NSLP Objects . . . . . . . . . . . . . . . . . . . . . . . 54
	4.2.1. Signaling Session Lifetime Object . . . . . . . . . . 55		4.2.1. Signaling Session Lifetime Object . . . . . . . . . . 55
	4.2.2. External Address Object . . . . . . . . . . . . . . . 55		4.2.2. External Address Object . . . . . . . . . . . . . . . 55
	4.2.3. Extended Flow Information Object . . . . . . . . . . 56		4.2.3. Extended Flow Information Object . . . . . . . . . . . 56
	4.2.4. Information Code Object . . . . . . . . . . . . . . . 57		4.2.4. Information Code Object . . . . . . . . . . . . . . . 57
	4.2.5. Nonce Object . . . . . . . . . . . . . . . . . . . . 60		4.2.5. Nonce Object . . . . . . . . . . . . . . . . . . . . . 60
	4.2.6. Message Sequence Number Object . . . . . . . . . . . 60		4.2.6. Message Sequence Number Object . . . . . . . . . . . . 60
	4.2.7. Data Terminal Information Object . . . . . . . . . . 61		4.2.7. Data Terminal Information Object . . . . . . . . . . . 61
	4.2.8. ICMP Types Object . . . . . . . . . . . . . . . . . . 62		4.2.8. ICMP Types Object . . . . . . . . . . . . . . . . . . 62
	4.3. Message Formats . . . . . . . . . . . . . . . . . . . . . 63		4.3. Message Formats . . . . . . . . . . . . . . . . . . . . . 63
	4.3.1. CREATE . . . . . . . . . . . . . . . . . . . . . . . 64		4.3.1. CREATE . . . . . . . . . . . . . . . . . . . . . . . . 64
	4.3.2. EXTERNAL (EXT) . . . . . . . . . . . . . . . . . . . 64		4.3.2. EXTERNAL (EXT) . . . . . . . . . . . . . . . . . . . . 64
	4.3.3. RESPONSE . . . . . . . . . . . . . . . . . . . . . . 65		4.3.3. RESPONSE . . . . . . . . . . . . . . . . . . . . . . . 65
	4.3.4. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . 65		4.3.4. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . 65
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 67		5. Security Considerations . . . . . . . . . . . . . . . . . . . 67
	5.1. Authorization Framework . . . . . . . . . . . . . . . . . 67		5.1. Authorization Framework . . . . . . . . . . . . . . . . . 67
	5.1.1. Peer-to-Peer Relationship . . . . . . . . . . . . . . 67		5.1.1. Peer-to-Peer Relationship . . . . . . . . . . . . . . 67
	5.1.2. Intra-Domain Relationship . . . . . . . . . . . . . . 68		5.1.2. Intra-Domain Relationship . . . . . . . . . . . . . . 68
	5.1.3. End-to-Middle Relationship . . . . . . . . . . . . . 69		5.1.3. End-to-Middle Relationship . . . . . . . . . . . . . . 69
	5.2. Security Threats and Requirements . . . . . . . . . . . . 70		5.2. Security Framework for the NAT/Firewall NSLP . . . . . . . 70
	5.2.1. Data Sender (DS) behind a firewall . . . . . . . . . 70		5.2.1. Security Protection between neighboring NATFW NSLP
	5.2.2. Data Sender (DS) behind a NAT . . . . . . . . . . . . 71		Nodes . . . . . . . . . . . . . . . . . . . . . . . . 70
	5.2.3. Data Receiver (DR) behind a firewall . . . . . . . . 71		5.2.2. Security Protection between non-neighboring NATFW
	5.2.4. Data Receiver (DR) behind a NAT . . . . . . . . . . . 73		NSLP Nodes . . . . . . . . . . . . . . . . . . . . . . 71
	5.2.5. NSLP Message Injection . . . . . . . . . . . . . . . 74
	5.3. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 75
	5.3.1. Flooding with CREATE messages from outside . . . . . 75
	5.3.2. Flooding with EXT messages from inside . . . . . . . 76
	5.4. Man-in-the-Middle Attacks . . . . . . . . . . . . . . . . 76
	5.5. Message Modification by non-NSIS on-path node . . . . . . 77
	5.6. Message Modification by malicious NSIS node . . . . . . . 77
	5.7. Signaling Session Ownership . . . . . . . . . . . . . . . 78
	5.7.1. Misuse of Mobility in a NAT Handling Scenario . . . . 78
	5.8. Misuse of unreleased signaling sessions . . . . . . . . . 79
	5.9. Data Traffic Injection . . . . . . . . . . . . . . . . . 81
	5.10. Eavesdropping and Traffic Analysis . . . . . . . . . . . 81
	5.11. Security Framework for the NAT/Firewall NSLP . . . . . . 81
	5.11.1. Security Protection between neighboring NATFW NSLP
	Nodes . . . . . . . . . . . . . . . . . . . . . . . . 82
	5.11.2. Security Protection between non-neighboring NATFW
	NSLP Nodes . . . . . . . . . . . . . . . . . . . . . 82
	6. IAB Considerations on UNSAF . . . . . . . . . . . . . . . . . 85		6. IAB Considerations on UNSAF . . . . . . . . . . . . . . . . . 73
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 86		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 74
	8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 88		8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 76
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 89		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 77
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 90		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 78
	10.1. Normative References . . . . . . . . . . . . . . . . . . 90		10.1. Normative References . . . . . . . . . . . . . . . . . . . 78
	10.2. Informative References . . . . . . . . . . . . . . . . . 90		10.2. Informative References . . . . . . . . . . . . . . . . . . 78
	Appendix A. Selecting Signaling Destination Addresses for EXT . 92		Appendix A. Selecting Signaling Destination Addresses for EXT . . 80
	Appendix B. Applicability Statement on Data Receivers behind		Appendix B. Applicability Statement on Data Receivers behind
	Firewalls . . . . . . . . . . . . . . . . . . . . . 93		Firewalls . . . . . . . . . . . . . . . . . . . . . . 81
	Appendix C. Firewall and NAT Resources . . . . . . . . . . . . . 95		Appendix C. Firewall and NAT Resources . . . . . . . . . . . . . 83
	C.1. Wildcarding of Policy Rules . . . . . . . . . . . . . . . 95		C.1. Wildcarding of Policy Rules . . . . . . . . . . . . . . . 83
	C.2. Mapping to Firewall Rules . . . . . . . . . . . . . . . . 95		C.2. Mapping to Firewall Rules . . . . . . . . . . . . . . . . 83
	C.3. Mapping to NAT Bindings . . . . . . . . . . . . . . . . . 96		C.3. Mapping to NAT Bindings . . . . . . . . . . . . . . . . . 84
	C.4. NSLP Handling of Twice-NAT . . . . . . . . . . . . . . . 96		C.4. NSLP Handling of Twice-NAT . . . . . . . . . . . . . . . . 84
	Appendix D. Assigned Numbers for Testing . . . . . . . . . . . . 98		Appendix D. Assigned Numbers for Testing . . . . . . . . . . . . 86
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 99		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 87
	Intellectual Property and Copyright Statements . . . . . . . . . 100		Intellectual Property and Copyright Statements . . . . . . . . . . 88
	1. Introduction		1. Introduction
	Firewalls and Network Address Translators (NAT) have both been used		Firewalls and Network Address Translators (NAT) have both been used
	throughout the Internet for many years, and they will remain present		throughout the Internet for many years, and they will remain present
	for the foreseeable future. Firewalls are used to protect networks		for the foreseeable future. Firewalls are used to protect networks
	against certain types of attacks from internal networks and the		against certain types of attacks from internal networks and the
	Internet, whereas NATs provide a virtual extension of the IP address		Internet, whereas NATs provide a virtual extension of the IP address
	space. Both types of devices may be obstacles to some applications,		space. Both types of devices may be obstacles to some applications,
	since they only allow traffic created by a limited set of		since they only allow traffic created by a limited set of
	skipping to change at page 5, line 43 ¶		skipping to change at page 5, line 43 ¶
	the type of NAT implementation (full-cone, symmetric, etc), or		the type of NAT implementation (full-cone, symmetric, etc), or
	dependencies on certain network topologies.		dependencies on certain network topologies.
	NAT and firewall (NATFW) signaling shares a property with Quality of		NAT and firewall (NATFW) signaling shares a property with Quality of
	Service (QoS) signaling. The signaling of both must reach any device		Service (QoS) signaling. The signaling of both must reach any device
	on the data path that is involved in, respectively, NATFW or QoS		on the data path that is involved in, respectively, NATFW or QoS
	treatment of data packets. This means, that for both, NATFW and QoS,		treatment of data packets. This means, that for both, NATFW and QoS,
	it is convenient if signaling travels path-coupled, meaning that the		it is convenient if signaling travels path-coupled, meaning that the
	signaling messages follow exactly the same path that the data packets		signaling messages follow exactly the same path that the data packets
	take. RSVP [11] is an example of a current QoS signaling protocol		take. RSVP [11] is an example of a current QoS signaling protocol
	that is path-coupled. [22] proposes the use of RSVP as firewall		that is path-coupled. [21] proposes the use of RSVP as firewall
	signaling protocol but does not include NATs.		signaling protocol but does not include NATs.
	This memo defines a path-coupled signaling protocol for NAT and		This memo defines a path-coupled signaling protocol for NAT and
	firewall configuration within the framework of NSIS, called the NATFW		firewall configuration within the framework of NSIS, called the NATFW
	NSIS Signaling Layer Protocol (NSLP). The general requirements for		NSIS Signaling Layer Protocol (NSLP). The general requirements for
	NSIS are defined in [5] and the general framework of NSIS is outlined		NSIS are defined in [5] and the general framework of NSIS is outlined
	in [4]. It introduces the split between an NSIS transport layer and		in [4]. It introduces the split between an NSIS transport layer and
	an NSIS signaling layer. The transport of NSLP messages is handled		an NSIS signaling layer. The transport of NSLP messages is handled
	by an NSIS Network Transport Layer Protocol (NTLP, with General		by an NSIS Network Transport Layer Protocol (NTLP, with General
	Internet Signaling Transport (GIST) [2] being the implementation of		Internet Signaling Transport (GIST) [2] being the implementation of
	skipping to change at page 67, line 16 ¶		skipping to change at page 67, line 16 ¶
	Security is of major concern particularly in case of firewall		Security is of major concern particularly in case of firewall
	traversal. This section provides security considerations for the		traversal. This section provides security considerations for the
	NAT/firewall traversal and is organized as follows.		NAT/firewall traversal and is organized as follows.
	In Section 5.1 we describe the participating entities relate to each		In Section 5.1 we describe the participating entities relate to each
	other from a security point of view. This subsection also motivates		other from a security point of view. This subsection also motivates
	a particular authorization model.		a particular authorization model.
	Security threats that focus on NSIS in general are described in [8]		Security threats that focus on NSIS in general are described in [8]
	and they are applicable to this document as well. In Section 5.2 we		and they are applicable to this document as well.
	extend this threat investigation by considering NATFW NSLP specific
	threats in more detail. Based on the investigated security threats
	we derive security requirements.
	Finally, we illustrate how the security requirements that were		Finally, we illustrate how the security requirements that were
	created based on the security threats can be fulfilled by specific		created based on the security threats can be fulfilled by specific
	security mechanisms. These aspects will be elaborated in		security mechanisms. These aspects will be elaborated in
	Section 5.11.		Section 5.2.
	5.1. Authorization Framework		5.1. Authorization Framework
	The NATFW NSLP is a protocol which may involve a number of NSIS nodes		The NATFW NSLP is a protocol which may involve a number of NSIS nodes
	and is, as such, not a two-party protocol. Figure 1 and Figure 2 of		and is, as such, not a two-party protocol. Figure 1 and Figure 2 of
	[8] already depict the possible set of communication patterns. In		[8] already depict the possible set of communication patterns. In
	this section we will re-evaluate these communication patters with		this section we will re-evaluate these communication patters with
	respect to the NATFW NSLP protocol interaction.		respect to the NATFW NSLP protocol interaction.
	The security solutions for providing authorization have a direct		The security solutions for providing authorization have a direct
	impact on the treatment of different NSLPs. As it can be seen from		impact on the treatment of different NSLPs. As it can be seen from
	the QoS NSLP [6] and the corresponding Diameter QoS work [20]		the QoS NSLP [6] and the corresponding Diameter QoS work [19]
	accounting and charging seems to play an important role for QoS		accounting and charging seems to play an important role for QoS
	reservations, whereas monetary aspects might only indirectly effect		reservations, whereas monetary aspects might only indirectly effect
	authorization decisions for NAT and firewall signaling. Hence, there		authorization decisions for NAT and firewall signaling. Hence, there
	are differences in the semantic of authorization handling between QoS		are differences in the semantic of authorization handling between QoS
	and NATFW signaling. A NATFW aware node will most likely want to		and NATFW signaling. A NATFW aware node will most likely want to
	authorize the entity (e.g., user or machine) requesting the		authorize the entity (e.g., user or machine) requesting the
	establishment of pinholes or NAT bindings. The outcome of the		establishment of pinholes or NAT bindings. The outcome of the
	authorization decision is either allowed or disallowed whereas a QoS		authorization decision is either allowed or disallowed whereas a QoS
	authorization decision might indicate that a different set of QoS		authorization decision might indicate that a different set of QoS
	parameters is authorization (see [20] as an example).		parameters is authorization (see [19] as an example).
	5.1.1. Peer-to-Peer Relationship		5.1.1. Peer-to-Peer Relationship
	Starting with the simplest scenario, it is assumed that neighboring		Starting with the simplest scenario, it is assumed that neighboring
	nodes are able to authenticate each other and to establish keying		nodes are able to authenticate each other and to establish keying
	material to protect the signaling message communication. The nodes		material to protect the signaling message communication. The nodes
	will have to authorize each other, additionally to the		will have to authorize each other, additionally to the
	authentication. We use the term 'Security Context' as a placeholder		authentication. We use the term 'Security Context' as a placeholder
	for referring to the entire security procedure, the necessary		for referring to the entire security procedure, the necessary
	infrastructure that needs to be in place in order for this to work		infrastructure that needs to be in place in order for this to work
	skipping to change at page 70, line 28 ¶		skipping to change at page 70, line 25 ¶
	| |Context | | | Context |		| |Context | | | Context |
	| | | | | | |		| | | | | | |
	| +--+---+ | | | +--+---+ |		| +--+---+ | | | +--+---+ |
	| | Host +----///----+------+ | | Host | |		| | Host +----///----+------+ | | Host | |
	| | A | | Security | | B | |		| | A | | Security | | B | |
	| +------+ | Context | +------+ |		| +------+ | Context | +------+ |
	+--------------------+ +---------------------+		+--------------------+ +---------------------+
	Figure 32: End-to-Middle Relationship		Figure 32: End-to-Middle Relationship
	5.2. Security Threats and Requirements		5.2. Security Framework for the NAT/Firewall NSLP
	This section describes NATFW specific security threats and
	requirements.
	5.2.1. Data Sender (DS) behind a firewall
	+------------------------------+
	| |
	| +-----+ create +-----+
	| | DS | --------------> | FW |
	| +-----+ +-----+
	| |
	+------------------------------+
	DS behind a firewall
	DS sends a CREATE message to request the traversal of a data flow.
	The following attacks are possible:
	o DS could open a firewall pinhole with a source address different
	from its own host.
	o DS could open firewall pinholes for incoming data flows that are
	not supposed to enter the network.
	o DS could request installation of any policy rules and allow all
	traffic go through.
	SECURITY REQUIREMENT: The middlebox MUST authenticate and authorize
	the neighboring NAT/FW NSLP node requesting an action.
	Authentication and authorization of the initiator SHOULD be
	provided to NATs and firewalls along the path.
	5.2.2. Data Sender (DS) behind a NAT
	The case 'DS behind a NAT' is analogous to the case 'DS behind a
	firewall'.
	Figure 34 illustrates such a scenario:
	+------------------------------+
	| |
	| +------+ CREATE |
	| | NI_1 | ------\ +-----+ CREATE +-----+
	| +------+ \------> | NAT |-------->| MB |
	| +-----+ +-----+
	| +------+ |
	| | NI_2 | |
	| +------+ |
	+------------------------------+
	Figure 34: Several NIs behind a NAT
	In this case the middlebox MB does not know who is the NSIS Initiator
	since both NI_1 and NI_2 are behind a NAT (which is also NSIS aware).
	Authentication needs to be provided by other means such as the NSLP
	or the application layer.
	SECURITY REQUIREMENT: The middlebox MUST authenticate and ensure
	that the neighboring NAT/FW NSLP node is authorized to request an
	action. Authentication and authorization of the initiator (which
	is the DR in this scenario) to the non-neighboring middleboxes
	SHOULD be provided.
	5.2.3. Data Receiver (DR) behind a firewall
	In this case a CREATE message comes from an entity DS outside the
	network towards the DR inside the network.
	+------------------------------+
	| |
	+-----+ CREATE +-----+ CREATE +-----+ |
	| DS | -------------> | FW | -------------> | DR | |
	+-----+ <------------- +-----+ <------------- +-----+ |
	successful RESPONSE | successful RESPONSE |
	| |
	+------------------------------+
	DR behind a firewall
	Since policy rules at middleboxes must only be installed after
	receiving a successful response it is necessary that the middlebox
	waits until the Data Receiver DR confirms the request of the Data
	Sender DS with a successful RESPONSE message.
	This confirmation implies that the data receiver is expecting the
	data flow.
	At this point we differentiate two cases:
	1. DR knows the (publicly reachable) IP address and port number of
	the DS (for instance because of some previous application layer
	signaling) and is expecting the data flow.
	2. DR might be expecting the data flow (for instance because of some
	previous application layer signaling) but does not know the
	(publicly reachable) IP address of the Data Sender DS.
	For the second case, Figure 36 illustrates a possible attack: an
	adversary Mallory M could be sniffing the application layer signaling
	and thus knows the address and port number where DR is expecting the
	data flow. Thus it could pretend to be DS and send a CREATE message
	towards DR with the data flow description (M -> DR). Since DR does
	not know the IP address of DS, it is not able to recognize that the
	request is coming from the "wrong guy". It will send a success
	RESPONSE message back and the middlebox will install policy rules
	that will allow Mallory M to inject its data into the network.
	Application Layer signaling
	<------------------------------------>
	/ \
	/ +-----------------\------------+
	/ | \ |
	+-----+ +-----+ +-----+ |
	| DS | -> | FW | | DR | |
	+-----+ / +-----+ +-----+ |
	CREATE / | |
	+-----+ / +-------------------------------+
	| M |----------
	+-----+
	Figure 36: DR behind a firewall with an adversary
	Network administrators will probably not rely on a DR to check the IP
	address of the DS. Thus we have to assume the worst case with an
	attack such as in Figure 36. Many operators might not allow NSIS
	signaling message to traverse the firewall in Figure 36 without
	having the DR to interact with the FW first.
	SECURITY REQUIREMENT: No requirements are created by this scenario.
	5.2.4. Data Receiver (DR) behind a NAT
	When a data receiver DR behind a NAT sends a EXTERNAL (EXT) message
	to get a public reachable address, this address can be used as a
	contact address by an arbitrary data sender, if the DR was unable to
	restrict the future data sender. The NAT reserves an external
	address and port number and sends them back to DR. The NAT adds an
	address mapping entry in its reservation list which links the public
	and private addresses as follows:
	(DR_ext <=> DR_int) (accept data from any IP address, i.e.,
	wildcard).
	The NAT sends a RESPONSE message with the external address' object
	back to the DR with the address DR_ext. DR informs DS about the
	public address that it has recently received, for instance, by means
	of application layer signaling.
	When a data sender sends a CREATE message towards DR_ext then the
	message will be forwarded to the DR. The data receiver might want to
	update the NAT binding stored at the edge-NAT to make it more
	restrictive.
	We assume that the adversary Mallory M obtains the contact address
	(i.e., external address and port) allocated at the NAT possibly by
	eavesdropping on the application layer signaling and sends a CREATE
	message. As a consequence Mallory would be able to communicate with
	DR (if M is authorized by the edge-NAT and if the DR accepts CREATE
	and returns a RESPONSE.
	Application Layer signaling
	<------------------------------------------>
	/ \
	/ +----------------------\-------+
	v | EXT v |
	+-----+ +-----+ <----------- +-----+ |
	| DS | -> | NAT | -----------> | DR | |
	+-----+ / +-----+ DR_external +-----+ |
	CREATE / | |
	+-----+ / +-------------------------------+
	| M |----------
	+-----+
	DR behind a NAT with an adversary
	SECURITY REQUIREMENT: The DR MUST be able to specify which data
	sender is allowed to traverse the NAT in order to be forwarded to
	DR's address.
	5.2.5. NSLP Message Injection
	Malicious hosts, located either off-path or on-path, could inject
	arbitrary NATFW NSLP messages into the signaling path. These
	problems apply when no proper authorization and authentication scheme
	is available.
	By injecting a bogus CREATE message with NATFW NSLP signaling session
	lifetime set to zero, a malicious host could try to teardown NATFW
	NSLP signaling session state partially or completely on a data path,
	causing a service interruption.
	By injecting a bogus responses or NOTIFY message, for instance, NATFW
	NSLP signaling session timeout, a malicious host could try to
	teardown NATFW NSLP signaling session state as well. This could
	affect the data path partially or totally, causing a service
	interruption.
	SECURITY REQUIREMENT: Messages, such as NOTIFY, can be misused by
	malicious hosts, and therefore MUST be authorized by the
	respective NATFW NLSP entities.
	5.3. Denial-of-Service Attacks
	In this section we describe several ways how an adversary could
	launch a Denial of service (DoS) attack on networks running NSIS for
	middlebox configuration to exhaust their resources.
	5.3.1. Flooding with CREATE messages from outside
	5.3.1.1. Attacks due to NSLP state
	A CREATE message requests the NSLP to store state information such as
	a NAT binding or a policy rule.
	The policy rules requested in the CREATE message will be installed at
	the arrival of a confirmation from the Data Receiver with a success
	RESPONSE message. A successful RESPONSE message includes the session
	ID. So the NSLP looks up the NATFW NSLP signaling session and
	installs the requested policy rules.
	An adversary could launch a DoS attack with an arbitrary number of
	CREATE messages. For each of these messages the middlebox needs to
	store state information such as the policy rules to be loaded, i.e.,
	the middlebox could run out of memory. This kind of attack is also
	mentioned in [8] Section 4.8.
	SECURITY REQUIREMENT: A NAT/FW NSLP node MUST authorize the
	establishment of state information.
	5.3.1.2. Attacks due to authentication complexity
	This kind of attack is possible if authentication is based on
	mechanisms that require computing power, for example, digital
	signatures.
	For a more detailed treatment of this kind of attack, the reader is
	encouraged to see [8].
	SECURITY REQUIREMENT: A NAT/FW NSLP node MUST NOT introduce new
	denial of service attacks based on authentication or key exchange
	mechanisms.
	5.3.1.3. Attacking Endpoints
	The NATFW NSLP requires firewalls to forward NSLP messages, a
	malicious node may keep sending NSLP messages to a target. This may
	consume the access network resources of the victim, drain the battery
	of the victim's terminal and may force the victim to pay for the
	received although undesired data.
	This threat may be more particularly be relevant in networks where
	access link is a limited resource, for instance in cellular networks,
	and where the terminal capacities are limited.
	SECURITY REQUIREMENT: A NATFW NSLP node MUST be configurable to
	block unauthorized signaling messages.
	5.3.2. Flooding with EXT messages from inside
	Although we are more concerned with possible attacks from outside the
	network, we need also to consider possible attacks from inside the
	network.
	An adversary inside the network could send arbitrary EXTERNAL
	messages. At a certain point the NAT will run out of port numbers
	and the access for other users to the outside will be disabled.
	SECURITY REQUIREMENT: The NAT/FW NSLP node MUST authorize state
	creation for the EXTERNAL message. Furthermore, the NAT/FW NSLP
	implementation MUST prevent denial of service attacks involving
	the allocation of an arbitrary number of NAT bindings or the
	installation of a large number of packet filters.
	5.4. Man-in-the-Middle Attacks
	Figure 38 illustrates a possible man-in-the-middle attack using the
	EXTERNAL (EXT) message. This message travels from DR towards the
	public Internet. The message might not be intercepted because there
	are no NSIS aware middleboxes.
	Imagine such an NSIS signaling message is then intercepted by an
	adversary Mallory (M). M returns a faked RESPONSE message whereby
	the adversary pretends that a NAT binding was created. This NAT
	binding is returned with the RESPONSE message. Mallory might insert
	it own IP address in the response, the IP address of a third party or
	the address of a black hole. In the first case, the DR thinks that
	the address of Mallory M is its public address and will inform the DS
	about it. As a consequence, the DS will send the data traffic to
	Mallory M.
	The data traffic from the DS to the DR will re-directed to Mallory M.
	M will be able to read, modify or block the data traffic (if the end-
	to-end communication itself does not experience protection).
	Eavesdropping and modification is only possible if the data traffic
	is itself unprotected.
	+-----+ +-----+ +-----+
	| DS | | M | | DR |
	+-----+ +-----+ +-----+
	| | |
	| | EXT |
	| | <------------------ |
	| | |
	| | RESPONSE |
	| | ------------------> |
	| | |
	| data traffic | |
	|===============>| data traffic |
	| |====================>|
	Figure 38: MITM attack using the EXTERNAL message
	SECURITY REQUIREMENT: Mutual authentication between neighboring
	NATFW NSLP MUST be provided. To ensure that only legitimate nodes
	along the path act as NSIS entities the initiator MUST authorize
	the responder. In the example in Figure 38 the firewall FW must
	perform an authorization with the neighboring entities.
	5.5. Message Modification by non-NSIS on-path node
	An unauthorized on-path node along the path towards the destination
	could easily modify, inject or just drop an NSIS message. It could
	also hijack or disrupt the communication.
	SECURITY REQUIREMENT: Message integrity, replay protection and data
	origin authentication between neighboring NAT/FW NSLPs MUST be
	provided.
	5.6. Message Modification by malicious NSIS node
	Message modification by an NSIS node that became malicious is more
	serious. An adversary could easily create arbitrary pinholes or NAT
	bindings. For example:
	o NATs need to modify the source/destination of the data flow in the
	'create session' message.
	o Each middlebox along the path may change the requested lifetime in
	the CREATE message to fit their needs and/or local policy.
	SECURITY REQUIREMENT: Malicious NSIS NATs and firewalls will not be
	addressed by this specification.
	5.7. Signaling Session Ownership
	Section 4.10 in [8] describes a threat where an adversary is able to
	modify or delete previously installed state information at NATFW NSLP
	nodes along the path. An adversary therefore needs to know NATFW
	NSLP signaling session specific information, such as the NATFW NSLP
	signaling session identifier and MRI information.
	SECURITY REQUIREMENT: Off-path adversaries MUST NOT be able to
	modify or delete sessions without proper authorization.
	5.7.1. Misuse of Mobility in a NAT Handling Scenario
	Another kind of NATFW NSLP signaling session modification is related
	to mobility scenarios. The NSIS protocol suite offers interworking
	with mobility protocol and a mobile node might need to update state
	along NATFW NSLP nodes.
	Whenever a host behind a NAT initiates a data transfer, it is
	assigned an external IP and port number. In typical mobility
	scenarios, the DR might also obtain a new address according to the
	topology and it should convey its new IP address to the NAT. The NAT
	is assumed to modify these NAT bindings based on the new IP address
	conveyed by the end host.
	Public Private Address
	Internet space
	+----------+ +----------+
	+----------| NAT |------------------|End host |
	| | | |
	+----------+ +----------+
	|
	| +----------+
	\--------------------|Malicious |
	|End host |
	+----------+
	data traffic
	<========================
	Figure 39: Misuse of mobility in NAT binding
	A NAT binding can be changed with the help of NSIS signaling. When a
	DR moves to a new location and obtains a new IP address, it sends an
	NSIS signaling message to modify the NAT binding. It would use the
	Session-ID and the new flow-id to update the state. The NAT updates
	the binding and the DR continues to receive the data traffic.
	Consider the scenario in Figure 39 where an the end host(DR) and the
	adversary are behind a NAT. The adversary pretending that it is the
	end host could generate a spurious signaling message to update the
	state at the NAT. This could be done for these purposes:
	o Redirecting packets to the attacker as in Figure 40.
	o Third party flooding by redirecting packets to arbitrary hosts
	o Service disruption by redirecting to non-existing hosts
	+----------+ +----------+ +----------+
	| NAT | |End host | |Malicious |
	| | | | |End host |
	+----------+ +----------+ +----------+
	| | |
	| Data Traffic | |
	|--------->----------| |
	| | Spurious |
	| | NAT binding update |
	|---------<----------+--------<------------|
	| | |
	| Data Traffic | |
	|--------->----------+-------->------------|
	| | |
	Figure 40: Connection Hijacking
	SECURITY REQUIREMENT: A NAT/FW signaling message MUST be
	authenticated, integrity and replay protected between neighboring
	NAT/FW NSLP nodes. The NSIS NATFW NSLP aware NAT MUST authorize
	the end host to insure that the messages are indeed belonging to
	the previously established NATFW NSLP signaling session.
	5.8. Misuse of unreleased signaling sessions
	Assume that DS (N1) initiates NATFW NSLP signaling session with DR
	(N2) through a series of middleboxes as in Figure 41. When the DS is
	sending data to DR, it might happen that the DR disconnects from the
	network (crashes or moves out of the network in mobility scenarios).
	In such cases, it is possible that another node N3 (which recently
	entered the network protected by the same firewall) is assigned the
	same IP address that was previously allocated to N2. The DS could
	take advantage of the firewall policies installed already, if the
	refresh interval time is very high. The DS can flood the node (N3),
	which will consume the access network resources of the victim forcing
	it to pay for unwanted traffic as shown in Figure 42. Note that here
	we make the assumption that the data receiver has to pay for
	receiving data packets.
	Public Internet
	+--------------------------+
	| |
	+-------+ CREATE +---+-----+ +-------+ |
	| |-------------->------| |---->---| | |
	| N1 |--------------<------| FW |----<---| N2 | |
	| | successful RESPONSE | | | | |
	| |==============>======| |====>===| | |
	+-------+ Data Traffic +---+-----+ +-------+ |
	| |
	+--------------------------+
	Figure 41: Before mobility
	Public Internet
	+--------------------------+
	| |
	+-------+ +---+-----+ +-------+ |
	| | | | | | |
	| N1 |==============>======| FW |====>===| N3 | |
	| | Data Traffic | | | | |
	+-------+ +---+-----+ +-------+ |
	| |
	+--------------------------+
	Figure 42: After mobility
	Also, this threat is valid for the other direction as well. The DS
	which is communicating with the DR may disconnect from the network
	and this IP address may be assigned to a new node that had recently
	entered the network. This new node could pretend to be the DS and
	send data traffic to the DR in conformance with the firewall policies
	and cause service disruption.
	SECURITY REQUIREMENT: In order to allow firewalls to verify that a
	legitimate end host indeed transmitted data traffic it is
	necessary to provide data origin authentication. This is,
	however, outside the scope of this document. Hence, there are no
	security requirements imposed by this threat, which will be
	addressed by the NATFW NSLP.
	5.9. Data Traffic Injection
	In some environments, such as enterprise networks, it is still common
	to perform authorization for access to a service based on the source
	IP address of the service requester. There is no doubt that this
	practice by itself represents a security weakness. Using IP spoofing
	an adversary is able to reach the target machines if they match,
	using the existing firewall rules.
	The adversary is able to inject its own data traffic in conformance
	with the firewall policies simultaneously along with the genuine DS.
	SECURITY REQUIREMENT: Since IP spoofing is a general limitation of
	non-cryptographic packet filters no countermeasures need to be
	taken by the NAT/FW NSLP. Techniques such as ingress filtering
	(see [19]) and, if necessary, data origin authentication (such as
	provided with IPsec based VPNs) can help mitigate this threat.
	This aspect is, however, outside the scope of this document.
	5.10. Eavesdropping and Traffic Analysis
	By collecting NSLP messages, an adversary is able to learn policy
	rules for packet filters and knows which ports are open. It can use
	this information to inject its own data traffic due to the IP
	spoofing capability already mentioned in Section 5.9. An on-path
	adversary could also observe the data traffic and he could conclude
	that it is possible to traverse a firewall.
	An adversary could learn authorization tokens included in CREATE
	messages and use them to launch replay-attacks or to create a NATFW
	NSLP signaling session with its own address as source address. This
	threat is discussed in the respective document suggesting the usage
	of authorization token in the NSIS protocol suite.
	SECURITY REQUIREMENT: The threat of eavesdropping itself does not
	mandate the usage of confidentiality protection since an adversary
	can also eavesdrop on data traffic. In the context of a
	particular security solutions (e.g., authorization tokens) it MAY
	be necessary to offer confidentiality protection. The latter
	aspect is outside the scope of this document.
	5.11. Security Framework for the NAT/Firewall NSLP
	Based on the identified threats a list of security requirements has		The following list of security requirements has been created to
	been created.		ensure proper secure operation of the NATFW NSLP.
	5.11.1. Security Protection between neighboring NATFW NSLP Nodes		5.2.1. Security Protection between neighboring NATFW NSLP Nodes
	Based on the analyzed threats it is necessary to provide, between		Based on the analyzed threats it is RECOMMENDED to provide, between
	neighboring NATFW NSLP nodes, the following mechanism:		neighboring NATFW NSLP nodes, the following mechanism:
	o data origin authentication		o data origin authentication
	o replay protection		o replay protection
	o integrity protection and		o integrity protection and
	o optionally confidentiality protection		o optionally confidentiality protection
	To consider the aspect of authentication and key exchange the		It is RECOMMENDED to use the authentication and key exchange security
	security mechanisms provided in [2] between neighboring nodes MUST be		mechanisms provided in [2] between neighboring nodes when sending
	enabled when sending NATFW signaling messages. The proposed security		NATFW signaling messages. The proposed security mechanisms of GIST
	mechanisms at GIST provide support for authentication and key		provide support for authentication and key exchange in addition to
	exchange in addition to denial of service protection. Depending on		denial of service protection. Depending on the chosen security
	the chosen security protocol, support for multiple authentication		protocol, support for multiple authentication protocols might be
	protocols might be provided. If security between neighboring nodes		provided. If security between neighboring nodes is desired than the
	is desired then the usage of C-MODE for the delivery of data packets		usage of C-MODE for the delivery of data packets and the usage of
	and the usage of D-MODE only to discover the next NATFW NSLP aware		D-MODE only to discover the next NATFW NSLP aware node along the path
	node along the path is demanded. Almost all security threats at the		is highly RECOMMENDED. Almost all security threats at the NATFW NSLP
	NATFW NSLP layer can be prevented by using a mutually authenticated		layer can be prevented by using a mutually authenticated Transport
	Transport Layer secured connection and by relying on authorization by		Layer secured connection and by relying on authorization by the
	the neighboring NATFW NSLP entities.		neighboring NATFW NSLP entities.
	The NATFW NSLP relies an established security association between		The NATFW NSLP relies on an established security association between
	neighboring peers to prevent unauthorized nodes to modify or delete		neighboring peers to prevent unauthorized nodes to modify or delete
	installed state. Between non-neighboring nodes the session ID (SID)		installed state. Between non-neighboring nodes the session ID (SID)
	carried in the NTLP is used to show ownership of a NATFW NSLP		carried in the NTLP is used to show ownership of a NATFW NSLP
	signaling session. The session ID MUST be generated in a random way		signaling session. The session ID MUST be generated in a random way
	and thereby prevent an off-path adversary to mount targeted attacks.		and thereby prevent an off-path adversary to mount targeted attacks.
	Hence, an adversary would have to learn the randomly generated		Hence, an adversary would have to learn the randomly generated
	Session ID to perform an attack. In a mobility environment a former		session ID to perform an attack. In a mobility environment a former
	on-path node that is now off-path can perform an attack. The cost-		on-path node that is now off-path can perform an attack. Messages
	benefit tradeoff to counter this attack does not seem to be high		for a particular NATFW NSLP signaling session are handled by the NTLP
	enough to provide a solution. Messages for a particular NATFW NSLP		to the NATFW NSLP for further processing. Messages carrying a
	signaling session are handled by the NTLP to the NATFW NSLP for		different session ID not associated with any NATFW NSLP are subject
	further processing. Messages carrying a different session ID not		to the regular processing for new NATFW NSLP signaling sessions.
	associated with any NATFW NSLP are subject to the regular processing
	for new NATFW NSLP signaling sessions.
	5.11.2. Security Protection between non-neighboring NATFW NSLP Nodes		5.2.2. Security Protection between non-neighboring NATFW NSLP Nodes
	Based on the security threats and the listed requirements it was		Based on the security threats and the listed requirements it was
	noted that some threats also demand authentication and authorization		noted that some threats also demand authentication and authorization
	of a NATFW signaling entity (including the initiator) towards a non-		of a NATFW signaling entity (including the initiator) towards a non-
	neighboring node. This mechanism mainly demands entity		neighboring node. This mechanism mainly demands entity
	authentication. Additionally, security protection of certain		authentication. Additionally, security protection of certain
	payloads may be required between non-neighboring signaling entities		payloads may be required between non-neighboring signaling entities
	and the Cryptographic Message Syntax (CMS) [14] migh be a potential		and the Cryptographic Message Syntax (CMS) [14] migh be a potential
	solution. Payload protection using CMS is not described in this		solution. Payload protection using CMS is not described in this
	document. The most important information exchanged at the NATFW NSLP		document. The most important information exchanged at the NATFW NSLP
	skipping to change at page 83, line 22 ¶		skipping to change at page 71, line 45 ¶
	multiple NSIS NATFW NSLP hops since this information might change		multiple NSIS NATFW NSLP hops since this information might change
	depending on the capability of each individual NATFW NSLP node.		depending on the capability of each individual NATFW NSLP node.
	Some scenarios might also benefit from the usage of authorization		Some scenarios might also benefit from the usage of authorization
	tokens. Their purpose is to associate two different signaling		tokens. Their purpose is to associate two different signaling
	protocols (e.g., SIP and NSIS) and their authorization decision.		protocols (e.g., SIP and NSIS) and their authorization decision.
	These tokens are obtained by non-NSIS protocols, such as SIP or as		These tokens are obtained by non-NSIS protocols, such as SIP or as
	part of network access authentication. When a NAT or firewall along		part of network access authentication. When a NAT or firewall along
	the path receives the token it might be verified locally or passed to		the path receives the token it might be verified locally or passed to
	the AAA infrastructure. Examples of authorization tokens can be		the AAA infrastructure. Examples of authorization tokens can be
	found in RFC 3520 [17] and RFC 3521 [18]. Figure 43 shows an example		found in RFC 3520 [17] and RFC 3521 [18]. Figure 33 shows an example
	of this protocol interaction.		of this protocol interaction.
	An authorization token is provided by the SIP proxy, which acts as		An authorization token is provided by the SIP proxy, which acts as
	the assertion generating entity and gets delivered to the end host		the assertion generating entity and gets delivered to the end host
	with proper authentication and authorization. When the NATFW		with proper authentication and authorization. When the NATFW
	signaling message is transmitted towards the network, the		signaling message is transmitted towards the network, the
	authorization token is attached to the signaling messages to refer to		authorization token is attached to the signaling messages to refer to
	the previous authorization decision. The assertion verifying entity		the previous authorization decision. The assertion verifying entity
	needs to process the token or it might be necessary to interact with		needs to process the token or it might be necessary to interact with
	the assertion granting entity using HTTP (or other protocols). As a		the assertion granting entity using HTTP (or other protocols). As a
	skipping to change at page 84, line 29 ¶		skipping to change at page 72, line 36 ¶
	| | | v |v		| | | v |v
	| v | +----------------+		| v | +----------------+
	| +------------+ | | +------------+ |		| +------------+ | | +------------+ |
	| | Protocol | | NSIS NATFW CREATE + | | Assertion | |		| | Protocol | | NSIS NATFW CREATE + | | Assertion | |
	| | using authz| | Assertion/Artifact | | Verifying | |		| | using authz| | Assertion/Artifact | | Verifying | |
	| | assertion | | ----------------------- | | Entity | |		| | assertion | | ----------------------- | | Entity | |
	| +------------+ | | +------------+ |		| +------------+ | | +------------+ |
	| Entity Alice | <---------------------- | Entity Bob |		| Entity Alice | <---------------------- | Entity Bob |
	+----------------+ RESPONSE +----------------+		+----------------+ RESPONSE +----------------+
	Figure 43: Authorization Token Usage		Figure 33: Authorization Token Usage
	Threats against the usage of authorization tokens have been mentioned		Threats against the usage of authorization tokens have been mentioned
	in [8] and also in Section 5.2. Hence, it is required to provide		in [8]. Hence, it is required to provide confidentiality protection
	confidentiality protection to avoid allowing an eavesdropper to learn		to avoid allowing an eavesdropper to learn the token and to use it in
	the token and to use it in another NATFW NSLP signaling session		another NATFW NSLP signaling session (replay attack). The token
	(replay attack). The token itself also needs to be protected against		itself also needs to be protected against tempering.
	tempering.
	To harmonize the usage of authorization tokens in NSLPs a separate		To harmonize the usage of authorization tokens in NSLPs a separate
	document is available, see [21].		document is available, see [20].
	6. IAB Considerations on UNSAF		6. IAB Considerations on UNSAF
	UNilateral Self-Address Fixing (UNSAF) is described in [12] as a		UNilateral Self-Address Fixing (UNSAF) is described in [12] as a
	process at originating endpoints that attempt to determine or fix the		process at originating endpoints that attempt to determine or fix the
	address (and port) by which they are known to another endpoint.		address (and port) by which they are known to another endpoint.
	UNSAF proposals, such as STUN [15] are considered as a general class		UNSAF proposals, such as STUN [15] are considered as a general class
	of workarounds for NAT traversal and as solutions for scenarios with		of workarounds for NAT traversal and as solutions for scenarios with
	no middlebox communication.		no middlebox communication.
	skipping to change at page 91, line 25 ¶		skipping to change at page 79, line 25 ¶
	Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J., and		Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J., and
	S. Waldbusser, "Terminology for Policy-Based Management",		S. Waldbusser, "Terminology for Policy-Based Management",
	RFC 3198, November 2001.		RFC 3198, November 2001.
	[17] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, "Session		[17] Hamer, L-N., Gage, B., Kosinski, B., and H. Shieh, "Session
	Authorization Policy Element", RFC 3520, April 2003.		Authorization Policy Element", RFC 3520, April 2003.
	[18] Hamer, L-N., Gage, B., and H. Shieh, "Framework for Session		[18] Hamer, L-N., Gage, B., and H. Shieh, "Framework for Session
	Set-up with Media Authorization", RFC 3521, April 2003.		Set-up with Media Authorization", RFC 3521, April 2003.
	[19] Ferguson, P. and D. Senie, "Network Ingress Filtering:		[19] Zorn, G., "Diameter Quality of Service Application",
	Defeating Denial of Service Attacks which employ IP Source		draft-ietf-dime-diameter-qos-00 (work in progress),
	Address Spoofing", BCP 38, RFC 2827, May 2000.		February 2007.
	[20] Alfano, F., "Diameter Quality of Service Application",
	draft-alfano-aaa-qosprot-05 (work in progress), October 2005.
	[21] Manner, J., "Authorization for NSIS Signaling Layer Protocols",		[20] Manner, J., "Authorization for NSIS Signaling Layer Protocols",
	draft-manner-nsis-nslp-auth-02 (work in progress),		draft-manner-nsis-nslp-auth-02 (work in progress),
	October 2006.		October 2006.
	[22] Roedig, U., Goertz, M., Karten, M., and R. Steinmetz, "RSVP as		[21] Roedig, U., Goertz, M., Karten, M., and R. Steinmetz, "RSVP as
	firewall Signalling Protocol", Proceedings of the 6th IEEE		firewall Signalling Protocol", Proceedings of the 6th IEEE
	Symposium on Computers and Communications, Hammamet,		Symposium on Computers and Communications, Hammamet,
	Tunisia pp. 57 to 62, IEEE Computer Society Press, July 2001.		Tunisia pp. 57 to 62, IEEE Computer Society Press, July 2001.
	Appendix A. Selecting Signaling Destination Addresses for EXT		Appendix A. Selecting Signaling Destination Addresses for EXT
	As with all other message types, EXT messages need a reachable IP		As with all other message types, EXT messages need a reachable IP
	address of the data sender on the GIST level. For the path-coupled		address of the data sender on the GIST level. For the path-coupled
	MRM the source-address of GIST is the reachable IP address (i.e., the		MRM the source-address of GIST is the reachable IP address (i.e., the
	real IP address of the data sender, or a wildcard). While this is		real IP address of the data sender, or a wildcard). While this is
	skipping to change at page 93, line 31 ¶		skipping to change at page 81, line 31 ¶
	+--+--+ / \		+--+--+ / \
	NI+-----| FW1 | (Internet )----NR+/NI/DS		NI+-----| FW1 | (Internet )----NR+/NI/DS
	NR +--+--+ \ /		NR +--+--+ \ /
	| +------+ `--+--'		| +------+ `--+--'
	+-------| EFW2 +----------+		+-------| EFW2 +----------+
	+------+		+------+
	~~~~~~~~~~~~~~~~~~~~~>		~~~~~~~~~~~~~~~~~~~~~>
	Signaling Flow		Signaling Flow
	Figure 44: Data receiver behind multiple, parallel located firewalls		Figure 34: Data receiver behind multiple, parallel located firewalls
	When a data receiver, and thus NR, is located in a network site that		When a data receiver, and thus NR, is located in a network site that
	is multihomed with several independently firewalled connections to		is multihomed with several independently firewalled connections to
	the public Internet (as shown in Figure 44), the specific firewall		the public Internet (as shown in Figure 34), the specific firewall
	through which the data traffic will be routed has to be ascertained.		through which the data traffic will be routed has to be ascertained.
	NATFW NSLP signaling messages sent from the NI+/NR during the EXT		NATFW NSLP signaling messages sent from the NI+/NR during the EXT
	message exchange towards the NR+ must be routed by the NTLP to the		message exchange towards the NR+ must be routed by the NTLP to the
	edge-firewall that will be passed by the data traffic as well. The		edge-firewall that will be passed by the data traffic as well. The
	NTLP would need to be aware about the routing within the Internet to		NTLP would need to be aware about the routing within the Internet to
	determine the path between DS and DR. Out of this, the NTLP could		determine the path between DS and DR. Out of this, the NTLP could
	determine which of the edge-firewalls, either EFW1 or EFW2, must be		determine which of the edge-firewalls, either EFW1 or EFW2, must be
	selected to forward the NATFW NSLP signaling. Signaling to the wrong		selected to forward the NATFW NSLP signaling. Signaling to the wrong
	edge-firewall, as shown in Figure 44, would install the NATFW NSLP		edge-firewall, as shown in Figure 34, would install the NATFW NSLP
	policy rules at the wrong device. This causes either a blocked data		policy rules at the wrong device. This causes either a blocked data
	flow (when the policy rule is 'allow') or an ongoing attack (when the		flow (when the policy rule is 'allow') or an ongoing attack (when the
	policy rule is 'deny'). Requiring the NTLP to know all about the		policy rule is 'deny'). Requiring the NTLP to know all about the
	routing within the Internet is definitely a tough challenge and		routing within the Internet is definitely a tough challenge and
	usually not possible. In such described case, the NTLP must		usually not possible. In such described case, the NTLP must
	basically give up and return an error to the NSLP level, indicating		basically give up and return an error to the NSLP level, indicating
	that the next hop discovery is not possible.		that the next hop discovery is not possible.
	Appendix C. Firewall and NAT Resources		Appendix C. Firewall and NAT Resources
	skipping to change at page 99, line 8 ¶		skipping to change at page 87, line 8 ¶
	o NATFW_DTINFO: 0x00F7		o NATFW_DTINFO: 0x00F7
	o NATFW_ICMP_TYPES: 0x00F9		o NATFW_ICMP_TYPES: 0x00F9
	1345		1345
	Authors' Addresses		Authors' Addresses
	Martin Stiemerling		Martin Stiemerling
	Network Laboratories, NEC Europe Ltd.		NEC Europe Ltd. and University of Goettingen
	Kurfuersten-Anlage 36		Kurfuersten-Anlage 36
	Heidelberg 69115		Heidelberg 69115
	Germany		Germany
	Phone: +49 (0) 6221 4342 113		Phone: +49 (0) 6221 4342 113
	Email: stiemerling@netlab.nec.de		Email: stiemerling@netlab.nec.de
	URI: http://www.stiemerling.org		URI: http://www.stiemerling.org
	Hannes Tschofenig		Hannes Tschofenig
	Siemens AG		Nokia Siemens Networks
	Otto-Hahn-Ring 6		Otto-Hahn-Ring 6
	Munich 81739		Munich 81739
	Germany		Germany
	Phone:		Phone:
	Email: Hannes.Tschofenig@siemens.com		Email: Hannes.Tschofenig@nsn.com
	URI: http://www.tschofenig.com		URI: http://www.tschofenig.com
	Cedric Aoun		Cedric Aoun
	Paris		Paris
	France		France
	Email: cedric@caoun.net		Email: cedric@caoun.net
	Elwyn Davies		Elwyn Davies
	Folly Consulting		Folly Consulting
End of changes. 47 change blocks.
	681 lines changed or deleted		129 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/