< draft-wing-behave-nat-control-stun-usage-02.txt		draft-wing-behave-nat-control-stun-usage-03.txt >
	BEHAVE D. Wing		BEHAVE D. Wing
	Internet-Draft J. Rosenberg		Internet-Draft J. Rosenberg
	Intended status: Standards Track Cisco Systems		Intended status: Standards Track Cisco Systems
	Expires: December 2, 2007 May 31, 2007		Expires: January 9, 2008 H. Tschofenig
			Nokia Siemens Networks
			July 8, 2007
	Discovering, Querying, and Controlling Firewalls and NATs using STUN		Discovering, Querying, and Controlling Firewalls and NATs using STUN
	draft-wing-behave-nat-control-stun-usage-02		draft-wing-behave-nat-control-stun-usage-03
	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 34 ¶		skipping to change at page 1, line 36 ¶
	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 December 2, 2007.		This Internet-Draft will expire on January 9, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	Simple Traversal Underneath NAT (STUN) is a mechanism for traversing		Simple Traversal Underneath NAT (STUN) is a mechanism for traversing
	NATs. STUN requests are transmitted through a NAT to external STUN		NATs. STUN requests are transmitted through a NAT to external STUN
	servers. While this works very well, its two primary drawbacks are		servers. While this works very well, its two primary drawbacks are
	the inability to modify the properties of a NAT binding and the need		the inability to modify the properties of a NAT binding and the need
	to query a public STUN server for every new NAT binding (e.g., every		to query a public STUN server for every new NAT binding (e.g., every
	phone call). These drawbacks require frequent messages which present		phone call). These drawbacks require frequent messages which present
	a load on servers (like SIP servers and STUN servers) and are bad for		a load on servers (like SIP servers and STUN servers) and are bad for
	low speed access networks, such as cellular access.		low speed access networks, such as cellular access.
	This document describes several mechanisms to discover NATs and		This document describes two mechanisms to discover NATs and firewalls
	firewalls and a method to query and control them. With these		and a mechanism to query and control them. With these mechanisms,
	changes, binding discovery and keepalive traffic can be reduced to		binding discovery and keepalive traffic can be reduced to involve
	involve only the necessary NATs or firewalls. At the same time,		only the necessary NATs or firewalls. At the same time, backwards
	backwards compatibility with NATs and firewalls that do not support		compatibility with NATs and firewalls that do not support this
	this document is retrained.		document is retained, which allows for incremental deployment of
			these mechanisms.
	This document is discussed on the BEHAVE mailing list,		This document is discussed on the SAFE mailing list,
	<https://www1.ietf.org/mailman/listinfo/behave>, in anticipation of a		<http://www1.ietf.org/mailman/listinfo/safe>.
	BoF at IETF69 in Chicago.
			Terminology
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in [RFC2119].
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Conventions Used in this Document . . . . . . . . . . . . . . 5		3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5
	4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5		4. Discovery of Middleboxes (NATs and Firewalls) . . . . . . . . 6
	5. Discovery of Middleboxes . . . . . . . . . . . . . . . . . . . 6		4.1. Outside-In . . . . . . . . . . . . . . . . . . . . . . . . 6
	5.1. Outside-In . . . . . . . . . . . . . . . . . . . . . . . . 7		4.1.1. Nested NATs . . . . . . . . . . . . . . . . . . . . . 8
	5.1.1. Nested NATs . . . . . . . . . . . . . . . . . . . . . 11		4.2. Tagging . . . . . . . . . . . . . . . . . . . . . . . . . 10
	5.1.2. XOR-INTERNAL-ADDRESS Attribute . . . . . . . . . . . . 12		5. Query and Control . . . . . . . . . . . . . . . . . . . . . . 11
	5.1.3. Interacting with Legacy NATs . . . . . . . . . . . . . 13		5.1. Client Procedures . . . . . . . . . . . . . . . . . . . . 11
	5.2. Inside-Out . . . . . . . . . . . . . . . . . . . . . . . . 13		5.2. Server Procedures . . . . . . . . . . . . . . . . . . . . 11
	5.2.1. DEFAULT-ROUTE Attribute . . . . . . . . . . . . . . . 14		6. New Attributes . . . . . . . . . . . . . . . . . . . . . . . . 12
	5.3. Tagging . . . . . . . . . . . . . . . . . . . . . . . . . 14		6.1. REFRESH-INTERVAL Attribute . . . . . . . . . . . . . . . . 12
	5.3.1. PLEASE-TAG Attribute . . . . . . . . . . . . . . . . . 15		6.2. XOR-INTERNAL-ADDRESS Attribute . . . . . . . . . . . . . . 12
	5.3.2. TAG Attribute . . . . . . . . . . . . . . . . . . . . 16		6.3. PLEASE-TAG Attribute . . . . . . . . . . . . . . . . . . . 13
	6. Query and Control . . . . . . . . . . . . . . . . . . . . . . 17		6.4. TAG Attribute . . . . . . . . . . . . . . . . . . . . . . 13
	6.1. REFRESH-INTERVAL Attribute . . . . . . . . . . . . . . . . 17		6.5. BOOTNONCE Attribute . . . . . . . . . . . . . . . . . . . 14
	6.2. Client Procedures . . . . . . . . . . . . . . . . . . . . 17		7. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	6.3. Server Procedures . . . . . . . . . . . . . . . . . . . . 18		7.1. Simple Security Model . . . . . . . . . . . . . . . . . . 15
	7. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 19		7.2. Incremental Deployment . . . . . . . . . . . . . . . . . . 15
	7.1. Simple Security Model . . . . . . . . . . . . . . . . . . 19		7.3. Optimize SIP-Outbound . . . . . . . . . . . . . . . . . . 15
	7.2. Incremental Deployment . . . . . . . . . . . . . . . . . . 19		7.4. Optimize ICE . . . . . . . . . . . . . . . . . . . . . . . 16
	7.3. Optimize SIP-Outbound . . . . . . . . . . . . . . . . . . 19		7.4.1. Candidate Gathering . . . . . . . . . . . . . . . . . 16
	7.4. Optimize ICE . . . . . . . . . . . . . . . . . . . . . . . 19		7.4.2. Keepalive . . . . . . . . . . . . . . . . . . . . . . 16
	7.4.1. Candidate Gathering . . . . . . . . . . . . . . . . . 20		7.4.3. Learning STUN Servers without Configuration . . . . . 16
	7.4.2. Keepalive . . . . . . . . . . . . . . . . . . . . . . 20		8. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 17
	7.4.3. Learning STUN Servers without Configuration . . . . . 20		8.1. Overlapping IP Addresses with Nested NATs . . . . . . . . 17
	8. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 21		8.2. Address Dependent NAT on Path . . . . . . . . . . . . . . 17
	8.1. Overlapping IP Addresses with Nested NATs . . . . . . . . 21		8.3. Address Dependent Filtering . . . . . . . . . . . . . . . 18
	8.2. Address Dependent NAT on Path . . . . . . . . . . . . . . 21		8.4. Interacting with Legacy NATs . . . . . . . . . . . . . . . 18
	8.3. Address Dependent Filtering . . . . . . . . . . . . . . . 22		9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 22		9.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 19
	9.1. Authorization and Resource Exhaustion . . . . . . . . . . 23		9.2. Resource Exhaustion . . . . . . . . . . . . . . . . . . . 19
	9.2. Comparison to Other NAT Control Techniques . . . . . . . . 23		9.3. Comparison to Other NAT Control Techniques . . . . . . . . 19
	9.3. Rogue STUN Server . . . . . . . . . . . . . . . . . . . . 23		9.4. Rogue STUN Server . . . . . . . . . . . . . . . . . . . . 20
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24		10. Open Issues and Discussion Points . . . . . . . . . . . . . . 20
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24		12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
	12.1. Normative References . . . . . . . . . . . . . . . . . . . 24		13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
	12.2. Informational References . . . . . . . . . . . . . . . . . 25		13.1. Normative References . . . . . . . . . . . . . . . . . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26		13.2. Informational References . . . . . . . . . . . . . . . . . 23
			Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 24
			A.1. Changes between -03 and 02 . . . . . . . . . . . . . . . . 24
			Appendix B. Block Diagram of Internal NAT Operation . . . . . . . 24
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
	Intellectual Property and Copyright Statements . . . . . . . . . . 27		Intellectual Property and Copyright Statements . . . . . . . . . . 27
	1. Introduction		1. Introduction
	Two common usages of STUN ([I-D.ietf-behave-rfc3489bis],[RFC3489])		Two common usages of Simple Traversal Underneath NAT (STUN)
	are Binding Discovery and NAT Keepalive. The Binding Discovery usage		([I-D.ietf-behave-rfc3489bis],[RFC3489]) are Binding Discovery and
	allows a STUN client to learn its public IP address (from the		NAT Keepalive. The Binding Discovery usage allows a STUN client to
	perspective of the STUN server it contacted) and the NAT keepalive		learn its public IP address (from the perspective of the STUN server
	usage allows a STUN client to keep an active NAT binding alive.		it contacted) and the NAT keepalive usage allows a STUN client to
	Unlike some other techniques (e.g., UPnP [UPnP], MIDCOM [RFC3303],		keep an active NAT binding alive. Unlike some other techniques
	Bonjour [Bonjour]), STUN does not interact directly with the NAT.		(e.g., UPnP [UPnP], MIDCOM [RFC3303], Bonjour [Bonjour]), STUN does
	Because STUN doesn't interact directly with the NAT, STUN cannot		not interact directly with the NAT. Thus, STUN cannot request
	request additional services from the NAT such as longer lifetimes		additional services from the NAT, such as longer lifetimes which
	(which would reduce keepalive messages), and each new NAT binding		would reduce keepalive messages. Furthermore, allocating new NAT
	(e.g., each phone call) requires communicating with the STUN server		bindings (e.g., each phone call) requires communication with a STUN
	on the Internet.		server located somewhere on the Internet.
	This paper describes three mechanisms for the STUN client to discover		This document describes three mechanisms for the STUN client to
	NATs and firewalls that are on path with its STUN server. After		discover NATs and firewalls that are on path with its STUN server.
	discovering the NATs and firewalls, the STUN client can query and		After discovering the NATs and firewalls, the STUN client can query
	control those devices using STUN. The STUN client needs to only ask		and control those devices using STUN. The STUN client needs to only
	those STUN servers (embedded in the NATs and firewalls) for public IP		ask those STUN servers (embedded in the NATs and firewalls) for
	addresses and UDP ports, thereby offloading that traffic from the		public IP addresses and UDP ports, thereby offloading that traffic
	STUN server on the Internet. Additionally, the STUN client can ask		from the STUN server on the Internet. Additionally, the STUN client
	the NAT's embedded STUN server to extend the NAT binding for the		can ask the NAT's embedded STUN server to extend the NAT binding for
	flow, and the STUN client can learn the IP address of the next-		the flow, and the STUN client can learn the IP address of the next-
	outermost NAT. By repeating this procedure with the next-outermost		outermost NAT. By repeating this procedure with the next-outermost
	NAT, all of the NATs along that path can have their bindings		NAT, all of the NATs along that path can have their bindings
	extended. By learning all of the STUN servers on the path between		extended. By learning all of the STUN servers on the path between
	the public Internet and itself, an endpoint can optimize the path of		the public Internet and itself, an endpoint can optimize the path of
	peer-to-peer communications.		peer-to-peer communications.
	2. Motivation		2. Motivation
	There are a number of problems with existing NAT traversal techniques		There are a number of problems with existing NAT traversal
	such as STUN [RFC3489], [UPnP], and [Bonjour]):		techniques, such as STUN [RFC3489], [UPnP], and [Bonjour]):
	nested NATs:		nested NATs:
	Today, many ISPs provide their subscribers with modems that have		Today, many ISPs provide their subscribers with modems that have
	embedded NATs, often with only one physical Ethernet port. These		embedded NATs, often with only one physical Ethernet port. These
	subscribers then install NATs behind those devices to provide		subscribers then install NATs behind those devices to provide
	additional features, such as wireless access. Another example is		additional features, such as wireless access. Another example is
	a NAT in the basement of an apartment building or a campus		a NAT in the basement of an apartment building or a campus
	dormitory, which combined with a NAT within the home or dormitory		dormitory, which combined with a NAT within the home or dormitory
	room also result in nested NATs. In both of these situations,		room also result in nested NATs. In both of these situations,
	UPnP and Bonjour no longer function at all, as those protocols can		UPnP and Bonjour no longer function at all, as those protocols can
	only control the first NAT closest to the host. STUN continues to		only control the first NAT closest to the host. STUN continues to
	function, but is unable to optimize network traffic behind those		function, but is unable to optimize network traffic behind those
	nested NATs (e.g., traffic that stays within the same house or		nested NATs (e.g., traffic that stays within the same house or
	within the same apartment building).		within the same apartment building).
	One technique to avoid nested NATs is to disable one of the NATs		One technique to avoid nested NATs is to disable one of the NATs,
	if it obtains an RFC1918 address on its WAN interface. This		if it obtains an RFC 1918 address on its WAN interface. This
	merely sidesteps the problem. This technique is also ineffective		merely sidesteps the problem. This technique is also ineffective
	if the ISP is NATting its subscribers and the ISP restricts each		if the ISP is NATting its subscribers and the ISP restricts each
	subscriber to one IP address.		subscriber to one IP address.
	The technique described in this paper allows optimization of the		The technique described in this document allows optimization of
	traffic behind those NATs so that the traffic can traverse the		the traffic behind those NATs so that the traffic can traverse the
	fewest NATs possible.		fewest NATs possible.
	chattiness:		chattiness:
	To perform its binding discovery, a STUN client communicates to a		To perform its binding discovery, a STUN client communicates to a
	server on the Internet. This consumes bandwidth across the user's		server on the Internet. This consumes bandwidth across the user's
	access network which in some cases is bandwidth constrained (e.g.,		access network, which in some cases is bandwidth constrained
	wireless, satellite). STUN's chattiness is often cited as a		(e.g., wireless, satellite). STUN's chattiness is often cited as
	reason to use other NAT traversal techniques such as UPnP or		a reason to use other NAT traversal techniques such as UPnP or
	Bonjour.		Bonjour.
	The technique described in this paper provides a significant		The technique described in this document provides a significant
	reduction in STUN's chattiness, to the point that the only time a		reduction in STUN's chattiness, to the point that the only time a
	STUN client needs to communicate with the STUN server on the		STUN client needs to communicate with the STUN server on the
	public Internet is when the STUN client is initialized.		public Internet is when the STUN client is initialized.
	incremental deployment:		incremental deployment:
	Many other NAT traversal techniques require the endpoint and its		Many other NAT traversal techniques require the endpoint and its
	NAT to both support the new feature or else NAT traversal isn't		NAT to both support the new feature or else NAT traversal is not
	possible at all.		possible at all.
	The technique described in this paper allows incremental		The technique described in this document allows incremental
	deployment of local endpoints and their NATs that support STUN		deployment of local endpoints and NATs that support STUN Control.
	Control. If the local endpoint, or its NATs, don't support the		If the local endpoint, or its NATs, does not support the STUN
	STUN Control functionality, normal STUN and ICE		Control functionality, then STUN (see
	[I-D.ietf-mmusic-ice] procedures are used to traverse the NATs		[I-D.ietf-behave-rfc3489bis]) and ICE [I-D.ietf-mmusic-ice]
	without the optimizations described in this paper.		procedures are used to traverse the NATs without the optimizations
			described in this document.
	3. Conventions Used in this Document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].
	4. Overview of Operation		3. Overview of Operation
	This document describes three functions, which are all implemented		This document describes three functions, which are all implemented
	using the STUN protocol:		using the STUN protocol:
	Discovery of Middleboxes (NATs and Firewalls):		Discovery of Middleboxes (NATs and Firewalls):
	This document describes three techniques to find NATs or		This document describes two techniques for finding NATs or
	firewalls. The first technique uses STUN to find the outer-most		firewalls (see Section 4). These two approaches are:
	NAT and works itself towards the host. The second technique
	requests on-path firewalls or NATs to append their IP address to a		Outside-In:
	STUN packet. The third technique sends a STUN packet to the		Uses STUN to find the outer-most NAT and works itself towards
	default router (which, in a small network, is often your NAT).		the host.
	This is described in Section 5.
			Tagging:
			Send a STUN Request packet to your STUN server, and asks for
			compliant firewalls along the path to indicate their presence
			by adding an IP address to the STUN Response packet.
	Querying Discovered Middleboxes:		Querying Discovered Middleboxes:
	After discovering a NAT or a firewall, it's useful to determine		After discovering a NAT or a firewall, it is useful to determine
	characteristics of the NAT binding or the firewall pinhole. Two		characteristics of the NAT binding or the firewall pinhole. Two
	of the most useful things to learn is the duration the NAT binding		of the most useful things to learn is the duration the NAT binding
	or firewall pinhole will remain open if there is no traffic, and		or firewall pinhole will remain open if there is no traffic, and
	the filtering applied to that binding or pinhole. This is		the filtering applied to that binding or pinhole. This is
	described in Section 6.		described in Section 5.
	Discussion Point: After discovering NATs and firewalls,
	querying those devices might also be done with a middlebox
	control protocol (e.g., by using standard or slightly modified
	versions of SIMCO [RFC4540], UPnP, MIDCOM, or Bonjour). This
	is open for discussion as this document is scoped within the
	IETF.
	Controlling Discovered Middleboxes		Controlling Discovered Middleboxes:
	A NAT or firewall might default to a more restrictive behavior		A NAT or a firewall might default to a more restrictive behavior
	than desired by an application (e.g., aggressive timeout,		than desired by an application (e.g., aggressive timeout,
	filtering). Requesting the NAT or firewall to change its default		filtering). Requesting the NAT or firewall to change its default
	behavior is useful for traffic optimization (e.g., reduce		behavior is useful for traffic optimization (e.g., reduce
	keepalive traffic) and network optimization (e.g., adjust filters		keepalive traffic) and network optimization (e.g., adjust filters
	to eliminate the need for a media relay		to eliminate the need for a media relay device
	device[I-D.ietf-behave-turn]). This is described in Section 6.		[I-D.ietf-behave-turn]). A discussion of this functionality can
			be found in Section 5.
	Discussion Point: After discovering NATs and firewalls,
	controlling those devices might also be done with a middlebox
	control protocol (e.g., by using standard or slightly modified
	versions of SIMCO, UPnP, MIDCOM, or Bonjour). This is open for
	discussion as this document is scoped within the IETF.
	5. Discovery of Middleboxes		4. Discovery of Middleboxes (NATs and Firewalls)
	There are three techniques to discover a middlebox (a NAT or a		This document investigates two techniques to discover a NAT and a
	firewall): outside-in, inside-out (useful when the outer-most NAT		firewall: outside-in and by tagging.
	device doesn't support STUN Control), or by tagging (useful for
	firewalls).
	These techniques can be combined in useful ways. For example, if		Ideally, a single technique could be selected as an outcome of the
	your inner-most NAT supports STUN Control, and your public STUN		standardization process. However, it is possible to combine these
	server returns the same IP address and port as your inner-most NAT,		two techniques.
	you know you don't have a NAT between your inner-most NAT and the
	STUN server. Otherwise, you know there is a NAT between your inner-
	most NAT and the STUN server (e.g., an ISP-supplied device or whoever
	is providing your Internet service). Knowing this allows optimizing
	NAT keepalives.
	5.1. Outside-In		4.1. Outside-In
	When a STUN client sends a STUN Request to a STUN server, it receives		When a STUN client sends a STUN Request to a STUN server, it receives
	a STUN Response which indicates the IP address and UDP port seen by		a STUN Response that indicates the IP address and UDP port seen by
	the STUN server. If the IP address and UDP port differs from the IP		the STUN server. If the IP address and UDP port differs from the IP
	address and UDP port of the socket used to send the request, the STUN		address and UDP port of the socket used to send the request, the STUN
	client knows there is at least one NAT between itself and the STUN		client knows there is at least one NAT between itself and the STUN
	server, and knows the 'public' IP address of that NAT. For example,		server, and knows the 'public' IP address (and port) allocated by the
	in the following diagram, the STUN client learns the public IP		outermost NAT. For example, in the following diagram, the STUN
	address of its NAT is 192.0.2.1:		client learns the public IP address of its NAT is 192.0.2.1:
	+--------+ +---------------+		+--------+ +---------------+
	| STUN | | 192.0.2.1 +--------+		| STUN | | 192.0.2.1 +--------+
	| Client +-------------+ +---<Internet>---+ STUN |		| Client +-------------+ +---<Internet>---+ STUN |
	| 10.1.1.2/4193 10.1.1.1 | | Server |		| 10.1.1.2/4193 10.1.1.1 | | Server |
	+--------+ | | +--------+		+--------+ | | +--------+
	| NAT with |		| NAT with |
	| Embedded STUN |		| Embedded STUN |
	| Server |		| Server |
	+---------------+		+---------------+
	Figure 1: One NAT with embedded STUN server		Figure 1: One NAT with embedded STUN server
	Internally, the NAT can be diagrammed to function like this, where
	the NAT operation occurs before the STUN server:
	|
	| outside interface
	|
	+---------+---------------+
	| | |
	| | +--------+ |
	| |----+ STUN | |
	| | | Server | |
	| | +--------+ |
	| | |
	| +-------+-------------+ |
	| | NAT Function | |
	| +-------+-------------+ |
	| | |
	+---------+---------------+
	|
	| inside interface
	|
	|
	Figure 2: Block Diagram of Internal NAT Operation
	After learning the public IP address of its outer-most NAT, the STUN		After learning the public IP address of its outer-most NAT, the STUN
	client attempts to communicate with the STUN server embedded in that		client attempts to communicate with the STUN server embedded in that
	outer-most NAT. The STUN client does this by first obtaining a		outer-most NAT. The STUN client does this by sending a STUN Binding
	shared secret, over a TLS connection, to the NAT's public IP address		Request to the NAT's public IP address. The NAT will return a STUN
	(192.0.2.1 in the figure above). After obtaining a shared secret, it		Binding Response message including the XOR-INTERNAL-ADDRESS
	sends a STUN Binding Request to the NAT's public IP address. The NAT		attribute, which will indicate the IP address and UDP port seen on
	will return a STUN Binding Response message including the XOR-		the *internal* side of the NAT for that translation (see Figure 14 in
	INTERNAL-ADDRESS attribute, which will indicate the IP address and		Appendix B). In the example above, the IP address and UDP port
	UDP port seen on the *internal* side of the NAT for that translation.		indicated in XOR-INTERNAL-ADDRESS are the same as that used by the
	In the example above, the IP address and UDP port indicated in XOR-		STUN client (10.1.1.2/4193), which indicates there are no other NATs
	INTERNAL-ADDRESS are the same as that used by the STUN client		between the STUN client and that outer-most NAT.
	(10.1.1.2/4193), which indicates there are no other NATs between the
	STUN client and that outer-most NAT.
	STUN Client NAT STUN Server
	| | |
	1. |-----TLS/TCP----------------------------->| }
	2. |-----Shared Secret Request (TLS)--------->| }
	3. |<----Shared Secret Response (TLS)---------| } normal STUN
	4. |-----TCP connection closed--------------->| } behavior
	5. |-----Binding Request (UDP)--------------->| }
	6. |<----Binding Response (UDP)---------------| }
	| | |
	7. |-----TLS/TCP------------------>| | }
	8. |--Shared Secret Request (TLS)->| | }
	9. |<-Shared Secret Response (TLS)-| | } NAT Control
	10. |--TCP connection closed------->| | } STUN Usage
	11. |--Binding Request (UDP)------->| | }
	12. |<-Binding Response (UDP)-------| | }
	| | |
	Figure 3: Communication Flow
	In the call flow above, steps 1-6 are normal STUN behavior
	[I-D.ietf-behave-rfc3489bis]:
	1: STUN client initiates a TLS-over-TCP connection to its STUN
	server on the Internet.
	2: Using that connection, the STUN client sends Shared Secret		STUN Client NAT STUN Server
	Request to that STUN server.		| | |
			1. |-----Binding Request (UDP)--------------->|
			2. |<----Binding Response (UDP)---------------|
			| | |
			3. |--Binding Request (UDP)------->| |
			4. |<-Binding Response (UDP)-------| |
			| | |
	3: Using that connection, the STUN server sends Shared Secret		Figure 2: Communication Flow
	Response. This contains the STUN username the client should use
	for subsequent queries to this STUN server, and the STUN password
	that will be used to integrity-protect subsequent STUN messages
	with this STUN server.
	4: TCP connection is closed.		In the call flow above, steps 1 and 2 correspond to the STUN behavior
			described in [I-D.ietf-behave-rfc3489bis]:
	5: STUN client sends UDP Binding Request to its STUN server on the		1: The STUN client sends a UDP Binding Request to its STUN server
	Internet, using the STUN username obtained from that STUN server		that is located on the Internet.
	(from step 3).
	6: STUN server responds with UDP Binding Response, integrity		2: The STUN server on the Internet responds with a UDP Binding
	protected with the STUN password (from step 3). The STUN client		Response.
	now knows the public IP address of its outer-most NAT. This is
	used in the next step.
	The next steps are the additional steps performed by a STUN client		The next steps are the additional steps performed by a STUN client
	that has implemented the NAT Control STUN Usage:		that has implemented the STUN Control functionality:
	7: STUN client initiates a TLS-over-TCP connection to the STUN
	server embedded in its outer-most NAT.
	8: Using that connection, the STUN client sends Shared Secret
	Request to that STUN server.
	9: Using that connection, the STUN server sends Shared Secret
	Response. This contains the STUN username the client should use
	for subsequent queries to this STUN server, and the STUN
	password that will be used to integrity-protect subsequent STUN
	messages with this STUN server.
	10: TCP connection is closed.
	11: STUN client sends UDP Binding Request to the STUN server		3: The STUN client sends a UDP Binding Request to the IP address
	embedded in its outer-most NAT, using the STUN username obtained		learned from the STUN server on the Internet. This will be
	from that STUN server (from step 10).		received by the STUN server embedded in the outer-most NAT.
	12: STUN server responds with UDP Binding Response, integrity		4: The STUN server (embedded in the NAT) responds with a UDP Binding
	protected with the STUN password (from step 10).		Response.
	The response obtained in the message 12 contains the XOR-MAPPED-		The response obtained in message (4) contains the XOR-MAPPED-ADDRESS
	ADDRESS attribute which will have the same value as when the STUN		attribute, which will have the same value as when the STUN server on
	server on the Internet responded (in step 6). The STUN client can		the Internet responded (in step 2). The STUN client can perform
	perform steps 11-12 for any new UDP communication (e.g., for every		steps (3) and (4) for any new UDP communication, without needing to
	new phone call), without needing to repeat steps 1-10. This meets		repeat steps (1) and (2). This meets the desire to reduce
	the desire to reduce chattiness.		chattiness. The STUN client also only needs to send keepalives
			towards the outer-most NAT's IP address, as well (reduces chatter for
			SIP outbound [I-D.ietf-sip-outbound]).
	The response obtained in message 12 will also contain the XOR-		The response obtained in message (4) will also contain the XOR-
	INTERNAL-ADDRESS, which allows the STUN client to repeat steps 7-12		INTERNAL-ADDRESS, which allows the STUN client to repeat steps (3)
	in order to query or control those on-path NATs between itself and		and (4) in order to query or control those on-path NATs between
	its STUN server on the Internet. This is described in detail in		itself and its STUN server on the Internet. This is described in
	section Section 5.1.1. This functionality meets the need to optimize		detail in Section 4.1.1. This functionality meets the need to
	traffic between nested NATs, without requiring configuration of		optimize traffic between nested NATs, without requiring configuration
	intermediate STUN servers.		of intermediate STUN servers.
	The STUN client can request each NAT to increase the binding		The STUN client can request each NAT to increase the binding
	lifetime, as described in Section 6.1. The STUN client receives		lifetime, as described in Section 6.1. The STUN client receives
	positive confirmation that the binding lifetime has been extended,		positive confirmation that the binding lifetime has been extended,
	allowing the STUN client to significantly reduces its NAT keepalive		allowing the STUN client to significantly reduces its NAT keepalive
	traffic. Additionally, as long as the NAT complies with [RFC4787],		traffic. Additionally, as long as the NAT complies with [RFC4787]
	the STUN client's keepalive traffic need only be sent to the outer-		(which is indicated by its support of this document), the STUN
	most NAT's IP address. This functionality meets the need to reduce		client's keepalive traffic need only be sent to the outer-most NAT's
	STUN's chattiness.		IP address. This functionality meets the need to reduce STUN's
			chattiness.
	5.1.1. Nested NATs		4.1.1. Nested NATs
	Nested NATs are controlled individually. The nested NATs are		Nested NATs are controlled individually. The nested NATs are
	discovered, from outer-most NAT to the inner-most NAT, using the XOR-		discovered, from outer-most NAT to the inner-most NAT, using the XOR-
	INTERNAL-ADDRESS attribute.		INTERNAL-ADDRESS attribute.
	The following diagram shows how a STUN client iterates over the NATs		The example in Figure 3 shows how a STUN client iterates over the
	to communicate with all of the NATs in the path. First, the STUN		NATs to communicate with all of the NATs in the path.
	client would learn the outer-most NAT's IP address by performing the
	steps above. In the case below, however, the IP address and UDP port
	indicated by the XOR-INTERNAL-ADDRESS will not be the STUN client's
	own IP address and UDP port -- rather, it's the IP address and UDP
	port on the *outer* side of the NAT-B -- 10.1.1.2.
	Because of this, the STUN client repeats the procedure and sends
	another STUN Binding Request to that newly-learned address (the
	*outer* side of NAT-B). NAT-B will respond with a STUN Binding
	Response containing the XOR-INTERNAL-ADDRESS attribute, which will
	match the STUN client's IP address and UDP port. The STUN client
	knows there are no other NATs between itself and NAT-B, and finishes.
	The following figure shows two nested NATs:		The following figure shows two nested NATs:
	+------+ +--------+ +--------+		+------+ +--------+ +--------+
	| 192.168.1.2 | 10.1.1.2 | 192.0.2.1 +-----------+		| 192.168.1.2 | 10.1.1.2 | 192.0.2.1 +-----------+
	| STUN +------+ NAT-B +-----+ NAT-A +---<Internet>---+STUN Server|		| STUN +------+ NAT-B +-----+ NAT-A +---<Internet>---+STUN Server|
	|Client| 192.168.1.1 | 10.1.1.1 | +-----------+		|Client| 192.168.1.1 | 10.1.1.1 | +-----------+
	+------+ +--------+ +--------+		+------+ +--------+ +--------+
	Figure 4: Two nested NATs with embedded STUN servers		Figure 3: Two nested NATs with embedded STUN servers
			First, the STUN client would learn the outer-most NAT's IP address by
			performing the steps shown in Figure 2. In the case below, however,
			the IP address and UDP port indicated by the XOR-INTERNAL-ADDRESS
			will not be the STUN client's own IP address and UDP port -- rather,
			it is the IP address and UDP port on the *outer* side of the NAT-B --
			10.1.1.2.
			Because of this, the STUN client repeats the procedure and sends
			another STUN Binding Request to that newly-learned address (the
			*outer* side of NAT-B). NAT-B will respond with a STUN Binding
			Response containing the XOR-INTERNAL-ADDRESS attribute, which will
			match the STUN client's IP address and UDP port. The STUN client
			knows there are no other NATs between itself and NAT-B, and finishes.
	The message flow with two nested NATs is shown below:		The message flow with two nested NATs is shown below:
	STUN Client NAT-B NAT-A STUN Server		STUN Client NAT-B NAT-A STUN Server
	| | | |		| | | |
	1. |-----TLS/TCP----------------------------->| }		1. |-----Binding Request (UDP)--------------->|
	2. |-----Shared Secret Request (TLS)--------->| }		2. |<----Binding Response (UDP)---------------|
	3. |<----Shared Secret Response (TLS)---------| } normal STUN
	4. |-----TCP connection closed--------------->| } behavior
	5. |-----Binding Request (UDP)--------------->| }
	6. |<----Binding Response (UDP)---------------| }
	| | | |		| | | |
	7. |-----TLS/TCP------------------>| | }		3. |--Binding Request (UDP)------->| | }
	8. |--Shared Secret Request (TLS)->| | }		4. |<-Binding Response (UDP)-------| | } NAT Control
	9. |<-Shared Secret Response (TLS)-| | }
	10. |--TCP connection closed------->| | }
	11. |--Binding Request (UDP)------->| | }
	12. |<-Binding Response (UDP)-------| | } NAT Control
	| | | | } STUN Usage		| | | | } STUN Usage
	13. |-----TLS/TCP--------->| | | }		5. |--Binding Req (UDP)-->| | | }
	14. |--Sh. Sec. Req (TLS)->| | | }		6. |<-Binding Resp (UDP)--| | | }
	15. |<-Sh. Sec. Resp (TLS)-| | | }
	16. |-TCP conn. closed---->| | | }
	17. |--Binding Req (UDP)-->| | | }
	18. |<-Binding Resp (UDP)--| | | }
	| | | |		| | | |
	Figure 5: Message Flow for Outside-In with Two NATs		Figure 4: Message Flow for Outside-In with Two NATs
	Once a shared secret has been obtained with each of the on-path NATs,		Once a shared secret has been obtained with each of the on-path NATs,
	the STUN client no longer needs the TLS/TCP connection -- all		the STUN client no longer needs the TLS/TCP connection -- all
	subsequent bindings for individual UDP streams (that is, for each		subsequent bindings for individual UDP streams (that is, for each
	subsequent call) are obtained by just sending a Binding Request to		subsequent call) are obtained by just sending a Binding Request to
	each of the NATs. By sending a Binding Request to both NAT-A and		each of the NATs. By sending a Binding Request to both NAT-A and
	NAT-B, the STUN client has the opportunity to optimize the packet		NAT-B, the STUN client has the opportunity to optimize the packet
	flow if their UDP peer is also behind the same NAT.		flow if their UDP peer is also behind the same NAT.
	5.1.2. XOR-INTERNAL-ADDRESS Attribute		4.2. Tagging
	This attribute MUST be present in a Binding Response and may be used		To discover an on-path firewall, the PLEASE-TAG attribute is used
	in other responses as well. This attribute is necessary to allow a		with a STUN Binding Request (a STUN packet sent to UDP/3478) message.
	STUN client to 'walk backwards' and communicate directly with all of		A firewall would inspect bypassing Binding Request messages and
	the STUN-aware NATs along the path.		determine whether there is a PLEASE-TAG attribute. When the firewall
			sees the associated Binding Response, the firewall appends a TAG
			attribute as the last attribute of the Binding Response. This TAG
			attribute contains the firewall's management IP address and UDP port.
			Each on-path firewall would be able to insert its own TAG attribute.
			In this way, the STUN Response would contain a pointer to each of the
			on-path firewalls between the client and that STUN server.
	The format of the XOR-INTERNAL-ADDRESS attribute is:		Motivation for developing the Tagging mechanism: The Outside-In
			discovery technique (Section 4.1) uses the public IP address of
			the NAT to find the outer-most NAT that supports STUN Control.
			Firewalls do not translate packets and hence a different technique
			is needed to identify firewalls.
	0 1 2 3		Note that tagging is similar to how NSIS
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		[I-D.ietf-nsis-nslp-natfw], TIST [I-D.shore-tist-prot], and NLS
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		[I-D.shore-nls-tl] function.
	|x x x x x x x x| Family | X-Port |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| X-Address (32 bits or 128 bits) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 6: XOR-INTERNAL-ADDRESS Attribute		This figure shows how tagging functions.
	The meaning of Family, X-Port, and X-Address are exactly as in		STUN Client firewall STUN Server
	[I-D.ietf-behave-rfc3489bis]. The length of X-Address depends on the		| | |
	address family (IPv4 or IPv6).		1. |--Binding Request->|------------------>|
			2. | |<-Binding Response-|
			3. | [inserts tag] |
			4. |<-Binding Response-| |
			5. [firewall discovered] | |
	5.1.3. Interacting with Legacy NATs		Figure 5: Tagging Message Flow
	There will be cases where the STUN client attempts to communicate		1. A Binding Request, containing the PLEASE-TAG attribute, is sent
	with an on-path NAT which does not support the outside-in usage		to the IP address of the STUN server that is located somewhere on
	described in Section 5.1. There are two cases:		the Internet. This is seen by the firewall, and the firewall
			remembers the STUN transaction id, and permits the STUN Binding
			Request packet.
	o the NAT does not run a STUN server on its public interface (this		2. When the firewall observes a STUN Binding Response packet it
	will be the most common)		checks its cache for the previously stored STUN transaction id.
	o the NAT does run a STUN server on its public interface, but		If a previous STUN transaction id was found then the firewall
	doesn't return the XOR-INTERNAL-ADDRESS attribute defined in this		inserts the TAG attribute, which contains the firewall's
	document		management address.
	In both cases the optimizations described in this section won't be		3. The firewall sends the (modified) STUN Binding Response towards
	available to the STUN client. This is no worse than the condition		the STUN client.
	today. This allows incremental upgrades of applications and NATs
	that implement the technique described in this document. In such a
	situation, the STUN client might implement the inside-out technique,
	described in Section 5.2.
	5.2. Inside-Out		4. The STUN client has now discovered the firewall, and can query it
			or control it.
	[[Discussion Point: This is being included as a discussion item.		5. Query and Control
	Traditional traceroute provides similar functionality, and in many
	cases traceroute survives traversing over a NAT that doesn't support
	STUN Control. However, traceroute has significant disadvantages
	(induces a load on intermediate devices to return ICMP error
	messages, and those ICMP messages are routinely or inadvertently
	filtered). Unlike the Inside-Out technique described below,
	traceroute doesn't rely on the default route.]]
	The STUN client sends a STUN request to UDP/3478 of the IP address of		This section describes how to use STUN to query and control a NAT
	its default router. If there is a STUN server listening there, it		that was discovered using the technique described in Section 4.
	will respond, and will indicate its default route via the new
	DEFAULT-ROUTE attribute. With that information, the STUN client can
	discover the next-outermost NAT by repeating the procedure.
	5.2.1. DEFAULT-ROUTE Attribute		5.1. Client Procedures
	The DEFAULT-ROUTE attribute contains the XOR'd default route, which		After discovering on-path NATs and firewalls with the procedure
	is useful for finding the next-outer device.		described in Section 4, the STUN client begins querying and
			controlling those devices.
	The format of the DEFAULT-ROUTE attribute is:		To modify an existing NAT mapping's attributes, or to request a new
			NAT mapping for a new UDP port, the STUN client can now send a STUN
			Binding Request to the IP address of address of the respective NAT or
			firewall (at STUN UDP port (3478)).
	0 1 2 3		Client produces for handling the BOOTNONCE attribute can be found in
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		Section 6.5.
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| X-Address (32 bits) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 7: DEFAULT-ROUTE Attribute		5.2. Server Procedures
	The meaning of X-Address is exactly as in		When receiving a STUN Binding Request the STUN controlled NAT will
	[I-D.ietf-behave-rfc3489bis].		respond with a STUN Binding Response containing an XOR-MAPPED-ADDRESS
			attribute (which points at the NAT's public IP address and port --
			just as if the STUN Binding Request had been sent to a STUN server on
			the public Internet) and an XOR-INTERNAL-ADDRESS attribute (which
			points to the source IP address and UDP port the packet STUN Binding
			Request packet had prior to being NATted).
	5.3. Tagging		For example, looking at Figure 1, the XOR-INTERNAL-ADDRESS is the
			IP address and UDP port prior to the NAPT operation. If there is
			only one NAT, as shown in Figure 1, XOR-INTERNAL-ADDRESS would
			contain the STUN client's own IP address and UDP port. If there
			are multiple NATs, XOR-INTERNAL-ADDRESS would indicate the IP
			address of the next NAT (that is, the next NAT closer to the STUN
			client).
	The Outside-In discovery technique (Section 5.1) uses the public IP		When receiving a STUN Binding Request the STUN controlled firewall
	address of the NAT to find the outer-most NAT that supports STUN		will respond with a STUN Binding Response containing an XOR-MAPPED-
	Control. Firewalls do not normally put their IP address into		ADDRESS attribute (which points at the public IP address and port)
	packets, so a different technique is needed to identify firewalls.		and an XOR-INTERNAL-ADDRESS attribute (which points to the source IP
			address of the interface and UDP port where the packet STUN Binding
			Request packet was received, i.e., the internal interface.
	To discover an on-path firewall, the PLEASE-TAG attribute is used		Server produces for handling the BOOTNONCE attribute can be found in
	with a normal STUN Binding Request usage. A firewall sees the normal		Section 6.5.
	Binding Request usage (a STUN packet sent to UDP/3478) with the
	PLEASE-TAG attribute. When the firewall sees the associated Binding
	Response, the firewall appends a TAG attribute as the last attribute
	of the Binding Response. This TAG attribute contains the firewall's
	management IP address and UDP port. Each on-path firewall would be
	able to insert its own TAG attribute. In this way, the STUN Response
	would contain pointer to each of the on-path firewalls between the
	client and that STUN server.
	Note: Tagging is similar to how NSIS [I-D.ietf-nsis-nslp-natfw],		STUN Binding Requests, which arrived from its public interface(s),
	TIST [I-D.shore-tist-prot], and NLS [I-D.shore-nls-tl] function.		MAY be handled as if the server is not listening on that port (e.g.,
			return an ICMP error) -- this specification does not need them.
	Discussion Point: Tagging would also be useful for the		6. New Attributes
	Connectivity Check usage (which is used by ICE), especially
	considering that a different firewall may be traversed for media
	than for the initial Binding Discovery usage. In such a
	situation, the new on-path firewall's policy might not allow a
	binding request to leave the network or allow a binding response
	to return. In this case, the firewall would need to indicate its
	presence to the STUN client in another way. An ICMP error message
	may be appropriate, and an ICMP extension [RFC4884] could indicate
	the firewall is controllable.
	This figure shows how tagging functions.		6.1. REFRESH-INTERVAL Attribute
	STUN Client firewall STUN Server		In a STUN request per [I-D.ietf-behave-rfc3489bis], the REFRESH-
	| | |		INTERVAL attribute indicates the number of milliseconds that the
	1. |--Binding Request->|------------------>|		client wants the NAT binding (or firewall pinhole) to be opened.
	2. | |<-Binding Response-|		When the NAT Keepalive usage is being used, the server may become
	3. | [inserts tag] |		overloaded with keepalive messages (Binding Requests or other
	4. |<-Binding Response-| |		application-level keepalive messages). The REFRESH-INTERVAL provies
	5. [firewall discovered] | |		a mechanism for the client to learn and adjust the NAT's binding
			lifetime and thus reduce the frequency of client-initiated keepalive
			messages.
	Figure 8: Tagging Message Flow		In a STUN response, the same attribute indicates how long the STUN
			controlled NAT (or a STUN controlled firewall) is willing to allocate
			the binding (or to create the pinhole).
	1. Binding Request, containing PLEASE-TAG attribute, is sent to the		REFRESH-INTERVAL is specified as an unsigned 32 bit integer, and
	IP address of the STUN server. This is seen by the firewall, and		represents an interval measured in milliseconds (thus the maximum
	the firewall remembers the STUN transaction id, and permits the		value is approximately 50 days). This attribute can be present in
	STUN Binding Request packet.		Binding Requests and in Binding Responses.
	2. The STUN Binding Response packet is seen by the firewall.		6.2. XOR-INTERNAL-ADDRESS Attribute
	3. The firewall inserts the TAG attribute, which contains the		This attribute MUST be present in a Binding Response and is necessary
	firewall's management address.		to allow a STUN client to perform the outside-in discovery technique,
			in order to discover all of the STUN Control-aware NATs along the
			path.
	4. The firewall sends the (modified) STUN Binding Response towards		The format of the XOR-INTERNAL-ADDRESS attribute is:
	the STUN client.
	5. The STUN client has now discovered the firewall, and can query it		0 1 2 3
	or control it.		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			|x x x x x x x x| Family | X-Port |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| X-Address (32 bits or 128 bits) |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	5.3.1. PLEASE-TAG Attribute		Figure 6: XOR-INTERNAL-ADDRESS Attribute
			The meaning of Family, X-Port, and X-Address are exactly as in
			[I-D.ietf-behave-rfc3489bis]. The length of X-Address depends on the
			address family (IPv4 or IPv6).
			6.3. PLEASE-TAG Attribute
	If a STUN client wants to discover on-path firewalls, it MUST include		If a STUN client wants to discover on-path firewalls, it MUST include
	this attribute in its Binding Response when performing the Binding		this attribute in its Binding Response when performing the Binding
	Discovery usage.		Discovery usage.
	STUN servers are not expected to understand this attribute; if they		STUN servers are not expected to understand this attribute; if they
	return this attribute as an unknown attribute, it does not affect the		return this attribute as an unknown attribute, it does not affect the
	operation described in this document.		operation described in this document.
	The format of the PLEASE-TAG attribute is:		The format of the PLEASE-TAG attribute is:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Mech |x x x x x x x x x x x x x x x x x x x x x x x x x x x x x|		|Mech.|x x x x x x x x x x x x x x x x x x x x x x x x x x x x x|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 9: PLEASE-TAG Attribute		Figure 7: PLEASE-TAG Attribute
	The 3-bit Mechanism field indicates the control mechanism desired.		The 3-bit Mechanism field indicates the control mechanism desired.
	Currently, the only defined mechanism is STUN Control, and is		Currently, the only defined mechanism is STUN Control, and is
	indicated with all zeros. The intent of this field is to allow		indicated with all zeros. The intent of this field is to allow
	additional control mechanisms (e.g., UPnP, Bonjour, MIDCOM).		additional control mechanisms (e.g., UPnP, Bonjour, MIDCOM).
	5.3.2. TAG Attribute		6.4. TAG Attribute
	The TAG attribute contains the XOR'd management transport address of		The TAG attribute contains the XOR'd management transport address of
	the middlebox (typically a firewall, although a NAT may find this		the middlebox. Typically, a firewall as well as a NAT may find this
	technique useful as well).		technique useful as well.
	A middlebox MUST append this attribute as the last attribute of a		If the associated STUN Request contained the PLEASE-TAG attribute, a
	STUN response, and only if the associated STUN request (with the same		middlebox MUST append this attribute as the last attribute of the
	transaction-id) contained the PLEASE-TAG attribute.		STUN Response (with that same transaction-id). After appending this
			attribute, the STUN length field MUST be also be adjusted.
	The format of the TAG attribute is:		The format of the TAG attribute is:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Mech.|x x x x x| Family | X-Port |		|Mech.|M|x x x x| Family | X-Port |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| X-Address (32 bits or 128 bit) |		| X-Address (32 bits or 128 bit) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 10: TAG Attribute		Figure 8: TAG Attribute
	The 3-bit Mechanism field indicates the control mechanism supported		Mech: The 3-bit Mechanism field indicates the control mechanism
	on the described port. Currently, the only defined mechanism is STUN		supported on the described port. Currently, the only defined
	Control, and is indicated with 0x0. The intent of this field is to		mechanism is STUN Control, and is indicated with 0x0. The intent of
	allow additional control mechanisms (e.g., UPnP, Bonjour, MIDCOM).		this field is to allow additional control mechanisms (e.g., UPnP,
			Bonjour, MIDCOM).
			The one-bit M field indicates if this firewall permits Mobility
			Header packets to flow through it ([RFC3775]).
	The meaning of Family, X-Port, and X-Address are exactly as in		The meaning of Family, X-Port, and X-Address are exactly as in
	[I-D.ietf-behave-rfc3489bis]. The length of X-Address depends on the		[I-D.ietf-behave-rfc3489bis]. The length of X-Address depends on the
	address family (IPv4 or IPv6).		address family (IPv4 or IPv6).
	6. Query and Control		6.5. BOOTNONCE Attribute
	This section describes how to use STUN to query and control a NAT
	that was discovered using the technique described in Section 5.
	6.1. REFRESH-INTERVAL Attribute
	In a STUN request, the REFRESH-INTERVAL attribute indicates the
	number of milliseconds that the client wants the NAT binding (or
	firewall pinhole) to be opened. In a STUN response, the same
	attribute indicates the length of time of that NAT binding (or
	firewall pinhole).
	REFRESH-INTERVAL is specified as an unsigned 32 bit integer, and
	represents an interval measured in milliseconds (thus the maximum
	value is approximately 50 days). This attribute can be present in
	Binding Requests and in Binding Responses. In a request, the value
	0xFFFF means it's a query and the refresh interval isn't actually
	changed.
	6.2. Client Procedures
	After discovering on-path NATs and firewalls, the STUN client begins
	querying and controlling those devices. The STUN client first
	performs the Shared Secret Usage (as described in
	[I-D.ietf-behave-rfc3489bis]) with the NAT or firewall it discovered.
	After performing that usage, the STUN client now has a STUN USERNAME
	and PASSWORD. The username and password are used, thereafter, for
	all subsequent messages between the STUN client and this NAT's STUN
	server. This procedure might be done, for example, when the STUN
	client first initializes such as upon bootup or initialization of the
	application.
	If subsequent messages from that STUN server fail authentication, the
	STUN client MUST re-obtain its IP address from a public STUN server,
	not from its outer-most NAT (see section Section 9.3).
	To modify an existing NAT mapping's attributes, or to request a new
	NAT mapping for a new UDP port, the STUN client can now send a STUN
	Binding Request to the IP address of address in its outer-most NAT's
	STUN UDP port (3478). The NAT's STUN server will respond with a STUN
	Binding Response containing an XOR-MAPPED-ADDRESS attribute (which
	points at the NAT's public IP address and port -- just as if the STUN
	Binding Request had been sent to a STUN server on the public
	Internet) and an XOR-INTERNAL-ADDRESS attribute (which points to the
	source IP address and UDP port the packet STUN Binding Request packet
	had prior to being NATted).
	6.3. Server Procedures		The BOOTNONCE attribute protects against the attack described in
			Section 9.4.
	The server should listen for STUN Shared Secret Requests and STUN		Client procedures: The STUN client expects each NAT to return the
	Binding Requests on the STUN UDP and TCP ports (UDP/3478, TCP/3478)		same BOOTNONCE value each time that NAT is contacted. If a NAT
	on its public IP address(es) and its private IP address(es), and		returns a different value, the STUN client MUST NOT use any
	accept such STUN packets from hosts connected to its private		information returned in the Binding Response and MUST re-run the NAT
	interface(s). STUN Binding Requests which arrived from its public		Control procedures from the beginning (i.e., obtain its public IP
	interface(s) MAY be handled as if the server isn't listening on that		address from the STUN server on the Internet). This would only occur
	port (e.g., return an ICMP error) -- this specification does not need		if an attack is in progress or if the NAT rebooted. If the NAT
	them.		rebooted, it is good practice to re-run the NAT Control procedures
			anyway, as the network topology could be different as well.
	After receiving a STUN Shared Secret Request, the NAT follows the		Server procedures: This attribute's value is a hash of the STUN
	procedures described in the Short-Term Usage section of		client's IP address and a value that is randomly-generated each time
	[I-D.ietf-behave-rfc3489bis]. The embedded STUN server MUST store		the NAT is initialized. The STUN client's IP address is included in
	that username and password so long as any NAT bindings, created or		this hash to thwart an attacker attaching to the NAT's internal
	adjusted with that same STUN username, have active mappings on the		network and learning the BOOTNONCE value.
	NAT, and for 60 seconds thereafter (to allow the STUN client to
	obtain a new binding).
	After receiving a STUN Binding Request containing the REFRESH-		The format of the BOOTNONCE attribute is:
	INTERVAL attribute, the server SHOULD authenticate the request using
	the USERNAME attribute and the previously-shared STUN password (this
	is to defend against resource starvation attacks, see Section 9.1).
	If authenticated, the new binding's lifetime can be maximized against
	the NAT's configured sanity check and the lifetime indicated in the
	REFRESH-INTERVAL attribute of the STUN Binding Response.
	In addition to its other attributes, the Binding Response MUST		0 1 2 3
	contain the XOR-MAPPED-ADDRESS and XOR-INTERNAL-ADDRESS attributes.		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	The XOR-MAPPED-ADDRESS contains the public IP address and UDP port		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	for this binding, which is shared with the intended peer. The XOR-		| Boot Nonce value (32 bits) |
	INTERNAL-ADDRESS contains the IP address and UDP port of the STUN		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Binding Request prior to the NAT translation, which is used by the
	STUN client to walk backwards through nested NATs (Section 5.1)
	For example, looking at Figure 1, the XOR-INTERNAL-ADDRESS is the		Figure 9: BOOTNONCE Attribute
	IP address and UDP port prior to the NAPT operation. If there is
	only one NAT, as shown in Figure 1, XOR-INTERNAL-ADDRESS would
	contain the STUN client's own IP address and UDP port. If there
	are multiple NATs, XOR-INTERNAL-ADDRESS would indicate the IP
	address of the next NAT (that is, the next NAT closer to the STUN
	client). Iterating over this procedure allows the STUN client to
	find all of the NATs along the path.
	7. Benefits		7. Benefits
	7.1. Simple Security Model		7.1. Simple Security Model
	Unlike other middlebox control techniques which have relatively		Unlike other middlebox control techniques which have relatively
	complex security models because a separate control channel is used,		complex security models because a separate control channel is used,
	STUN Control's is simple. It's simple because only the flow being		STUN Control's is simple. It's simple because only the flow being
	used can be controlled (e.g., have its NAT timeout queried or		used can be controlled (e.g., have its NAT timeout queried or
	extended). Other flows cannot be created, queried, or controlled via		extended). Other flows cannot be created, queried, or controlled via
	STUN Control.		STUN Control.
	7.2. Incremental Deployment		7.2. Incremental Deployment
	NAT Control can be incrementally deployed. If the outer-most NAT		NAT Control can be incrementally deployed. If the outer-most NAT
	does not support it, the STUN client behaves as normal. In this		does not support it, the STUN client behaves as normal. In this
	case, the STUN client might benefit from attempting inside-out		case, the tagging procedure described in Section 4.2, will still
	procedure described in Section 5.2, and still gain some		allow to gain some optimizations. Where the outer-most STUN NAT does
	optimizations. Where the outer-most STUN NAT does support it, the		support it, the STUN client can gain some significant optimizations
	STUN client can gain some significant optimizations as described in		as described in the following sections.
	the following sections.
	Likewise, there is no change required to applications if NATs are		Likewise, there is no change required to applications if NATs are
	deployed which support NAT Control: such applications will be		deployed which support NAT Control: such applications will be
	unaware of the additional functionality in the NAT, and will not be		unaware of the additional functionality in the NAT, and will not be
	subject to any worse security risks due to the additional		subject to any worse security risks due to the additional
	functionality in the NAT.		functionality in the NAT.
	7.3. Optimize SIP-Outbound		7.3. Optimize SIP-Outbound
	In sip-outbound [I-D.ietf-sip-outbound], the SIP proxy is also the		In SIP outbound [I-D.ietf-sip-outbound], the SIP proxy is also the
	STUN server. STUN Control as described in this document enables two		STUN server. STUN Control as described in this document enables two
	optimizations of SIP-Outbound's keepalive mechanism:		optimizations of SIP-Outbound's keepalive mechanism:
	1. STUN keepalive messages need only be sent to the outer-most NAT,		1. STUN keepalive messages need only be sent to the outer-most NAT,
	rather than across the access link to the SIP proxy, which vastly		rather than across the access link to the SIP proxy, which vastly
	reduces the traffic to the SIP proxy, and;		reduces the traffic to the SIP proxy, and;
	2. all of the on-path NATs can explicitly indicate their timeouts,		2. all of the on-path NATs can explicitly indicate their timeouts,
	reducing the frequency of keepalive messages.		reducing the frequency of keepalive messages.
	skipping to change at page 21, line 21 ¶		skipping to change at page 17, line 33 ¶
	be unable to detect the presence of NAT-A if NAT-A assigns the same		be unable to detect the presence of NAT-A if NAT-A assigns the same
	UDP port. For example, in the following figure, NAT-A and NAT-B are		UDP port. For example, in the following figure, NAT-A and NAT-B are
	both using 10.1.1.x as their 'private' network.		both using 10.1.1.x as their 'private' network.
	+------+ +--------+ +--------+		+------+ +--------+ +--------+
	| 10.1.1.2 | 10.1.1.2 | 192.0.2.1		| 10.1.1.2 | 10.1.1.2 | 192.0.2.1
	| STUN +-------+ NAT-A +-----+ NAT-B +------<Internet>		| STUN +-------+ NAT-A +-----+ NAT-B +------<Internet>
	|client| 10.1.1.1 | 10.1.1.1 |		|client| 10.1.1.1 | 10.1.1.1 |
	+------+ +--------+ +--------+		+------+ +--------+ +--------+
	Figure 12: Overlapping Addresses with Nested NATs		Figure 11: Overlapping Addresses with Nested NATs
	When this situation occurs, the STUN client can only learn the outer-		When this situation occurs, the STUN client can only learn the outer-
	most address. This isn't a problem -- the STUN client is still able		most address. This is not a problem -- the STUN client is still able
	to communicate with the outer-most NAT and is still able to avoid		to communicate with the outer-most NAT and is still able to avoid
	consuming access network bandwidth and avoid communicating with the		consuming access network bandwidth and avoid communicating with the
	public STUN server. All that is lost is the ability to optimize		public STUN server. All that is lost is the ability to optimize
	paths within the private network that has overlapped addresses.		paths within the private network that has overlapped addresses.
	Of course when such an overlap occurs the end host (STUN client)		Of course when such an overlap occurs the end host (STUN client)
	cannot successfully establish bi-directional communication with hosts		cannot successfully establish bi-directional communication with hosts
	in the overlapped network, anyway.		in the overlapped network, anyway.
	8.2. Address Dependent NAT on Path		8.2. Address Dependent NAT on Path
	In order to utilize the mechanisms described in this document, a STUN		In order to utilize the mechanisms described in this document, a STUN
	Request is sent from the same source IP address and source port as		Request is sent from the same source IP address and source port as
	the original STUN Binding Discovery message, but is sent to a		the original STUN Binding Discovery message, but is sent to a
	different destination IP address -- it is sent to the IP address of		different destination IP address -- it is sent to the IP address of
	an on-path NAT. If there is an on-path NAT, between the STUN client		an on-path NAT. If there is an on-path NAT, between the STUN client
	and the STUN server, with 'address dependent' or 'address and port-		and the STUN server, with 'address dependent' or 'address and port-
	dependent' mapping behavior (as described in section 4.1 of		dependent' mapping behavior (as described in Section 4.1 of
	[RFC4787]), that NAT will prevent a STUN client from taking advantage		[RFC4787]), that NAT will prevent a STUN client from taking advantage
	of the technique described in this document. When this occurs, the		of the technique described in this document. When this occurs, the
	ports indicated by XOR-MAPPED-ADDRESS from the public STUN server and		ports indicated by XOR-MAPPED-ADDRESS from the public STUN server and
	the NAT's embedded STUN server will differ.		the NAT's embedded STUN server will differ.
	An example of such a topology is shown in the following figure:		An example of such a topology is shown in the following figure:
	+------+ +--------+ +--------+		+------+ +--------+ +--------+
	| STUN | | 10.1.1.2 | 192.0.2.1		| STUN | | 10.1.1.2 | 192.0.2.1
	|client+-----+ NAT-A +---+ NAT-B +------<Internet>		|client+-----+ NAT-A +---+ NAT-B +------<Internet>
	skipping to change at page 22, line 21 ¶		skipping to change at page 18, line 28 ¶
	+------+ +--------+ +--------+		+------+ +--------+ +--------+
	In this figure, NAT-A is a NAT that has address dependent mapping.		In this figure, NAT-A is a NAT that has address dependent mapping.
	Thus, when the STUN client sends a STUN Binding Request to 192.0.2.1		Thus, when the STUN client sends a STUN Binding Request to 192.0.2.1
	on UDP/3478, NAT-A will choose a new public UDP port for that		on UDP/3478, NAT-A will choose a new public UDP port for that
	communication. NAT-B will function normally, returning a different		communication. NAT-B will function normally, returning a different
	port in its XOR-MAPPED-ADDRESS, which indicates to the STUN client		port in its XOR-MAPPED-ADDRESS, which indicates to the STUN client
	that a symmetric NAT exists between the STUN client and the STUN		that a symmetric NAT exists between the STUN client and the STUN
	server it just queried (NAT-B, in this example).		server it just queried (NAT-B, in this example).
	Figure 13: Address Dependant NAT on Path		Figure 12: Address Dependant NAT on Path
	Open issue: We could resolve this problem by introducing a new
	STUN attribute which indicates the UDP port the STUN client wants
	to control. However, this changes the security properties of NAT
	Control, so this seems undesirable.
	Open issue: When the STUN client detects this situation, should
	we recommend it abandon the NAT Control usage, and revert to
	operation as if it doesn't support the NAT Control usage?
	8.3. Address Dependent Filtering		8.3. Address Dependent Filtering
	If there is an NAT along the path that has address dependent		If there is an NAT along the path that has address dependent
	filtering (as described in section 5 of [RFC4787]), and the STUN		filtering (as described in section 5 of [RFC4787]), and the STUN
	client sends a STUN packet directly to any of the on-path NATs public		client sends a STUN packet directly to any of the on-path NATs public
	addresses, the address-dependent filtering NAT will filter packets		addresses, the address-dependent filtering NAT will filter packets
	from the remote peer. Thus, after communicating with all of the on-		from the remote peer. Thus, after communicating with all of the on-
	path NATs the STUN client MUST send a UDP packet to the remote peer,		path NATs the STUN client MUST send a UDP packet to the remote peer,
	if the remote peer is known.		if the remote peer is known.
	Discussion: How many filter entries are in address dependent		8.4. Interacting with Legacy NATs
	filtering NATs? If only one, this does become a real limitation
	if NATs are nested; if they're not nested, the outer-most NAT can		There will be cases where the STUN client attempts to communicate
	avoid overwriting its own address in its address dependent filter.		with an on-path NAT, which does not support the outside-in usage.
			There are two cases:
			o the NAT does not run a STUN server on its public interface (this
			will be the most common)
			o the NAT does run a STUN server on its public interface, but does
			not return the XOR-INTERNAL-ADDRESS attribute defined in this
			document
			In both cases the optimizations described in this section will not be
			available to the STUN client. This is no worse than the condition
			today. This allows incremental upgrades of applications and NATs
			that implement the technique described in this document.
	9. Security Considerations		9. Security Considerations
	This security considerations section will be expanded in a subsequent		This security considerations section will be expanded in a subsequent
	version of this document. So far, the authors have identified the		version of this document. So far, the authors have identified the
	following considerations:		following considerations:
	9.1. Authorization and Resource Exhaustion		9.1. Authorization
	Only hosts that are 'inside' a NAT, which a NAT is already providing		Only hosts that are 'inside' a NAT, which a NAT is already providing
	services for, can query or adjust the timeout of a NAT mapping.		services for, can query or adjust the timeout of a NAT mapping.
			A discussion of additional authorization mechanisms that might be
			needed for firewall traversal can be found at
			[I-D.wing-session-auth].
			9.2. Resource Exhaustion
	A malicious STUN client could ask for absurdly long NAT bindings		A malicious STUN client could ask for absurdly long NAT bindings
	(days) for many UDP sessions, which would exhaust the resources in		(days) for many UDP sessions, which would exhaust the resources in
	the NAT. The same attack is possible (without considering this		the NAT. The same attack is possible (without considering this
	document and without considering STUN or other UNSAF [RFC3424] NAT		document and without considering STUN or other UNSAF [RFC3424] NAT
	traversal techniques) -- a malicious TCP client can open many TCP		traversal techniques) -- a malicious TCP (or UDP) client can open
	connections, and keep them open, causing resource exhaustion in the		many TCP (or UDP) connections, and keep them open, causing resource
	NAT. One way to thwart such an attack is to challenge the STUN		exhaustion in the NAT.
	client with a nonce, which is already part of the STUN specification.
	By doing this, a NAT can provide DoS protection similar to what it
	could do for TCP today.
	9.2. Comparison to Other NAT Control Techniques		9.3. Comparison to Other NAT Control Techniques
	Like UPnP, Bonjour, and host-initiated MIDCOM, the STUN usage		Like UPnP, Bonjour, and host-initiated MIDCOM, the STUN usage
	described in this document allows a host to learn its public IP		described in this document allows a host to learn its public IP
	address and UDP port mapping, and to request a specific lifetime for		address and UDP port mapping, and to request a specific lifetime for
	that mapping.		that mapping.
	However, unlike those technologies, the NAT Control usage described		However, unlike those technologies, the NAT Control usage described
	in this document only allows each UDP port on the host to create and		in this document only allows each UDP port on the host to create and
	adjust the mapping timeout of its own NAT mappings. Specifically, an		adjust the mapping timeout of its own NAT mappings. Specifically, an
	application on a host can only adjust the duration of a NAT bindings		application on a host can only adjust the duration of a NAT bindings
	for itself, and not for another application on that same host, and		for itself, and not for another application on that same host, and
	not for other hosts. This provides security advantages over other		not for other hosts. This provides security advantages over other
	NAT control mechanisms where malicious software on a host can		NAT control mechanisms where malicious software on a host can
	surreptitiously create NAT mappings to another application or to		surreptitiously create NAT mappings to another application or to
	another host.		another host.
	9.3. Rogue STUN Server		9.4. Rogue STUN Server
	As described in Section 7, a STUN client can learn its outer-most NAT		Using the mechanisms described in this document, a STUN client learns
	runs an embedded STUN server. However, without the STUN client's		the public IP addresses of its NATs which support the mechanisms
	knowledge, the outer-most NAT may acquire a new IP address. This		described in this document. However, without the STUN client's
	could occur when the NAT moves to a new mobile network or its DHCP		knowledge, those NATs may acquire a new IP address (e.g., DHCP lease
	lease expires. When the NAT acquires a new IP address, the STUN		expiration, a moving network). When any of those NAT acquire a new
	client will send a STUN Binding Request to the NAT's prior public IP		IP address without the STUN client's knowledge, the STUN client will
	address, which will be routed to the NAT's previous address.		send a STUN Binding Request to the NAT's previous public IP address.
			If an attacker were to run a rogue STUN server on that address, the
			attacker will have effectively compromised the STUN server, as
			described in Section 12.2.1 of [RFC3489]. The attacker, upon
			receiving STUN Binding Requests, will reply with STUN Binding
			Responses indicating an IP address the attacker controls. The
			attacker will thus ensure access to whatever media stream is being
			established by the STUN client (e.g., RTP traffic). When such an
			attack occurs, the STUN client is unable to distinguish the
			attacker's replies from legitimate replies from the STUN server
			embedded in the STUN client's NAT.
	If an attacker runs a rogue STUN server on that address, the attacker		To defend against this attack, the STUN server embedded in the NAT
	has effectively compromised the STUN server (the attacked described		returns a BOOTNONCE value. The STUN client validates that it
	in section 12.2.1 of [RFC3489]). The attacker will send STUN Binding		receives the same BOOTNONCE value in each STUN Binding Response from
	Responses indicating his IP address, which will be indistinguishable,		that NAT.
	to the STUN client, from the behavior of the legitimate STUN server.
	To defend against this attack, the STUN client and STUN server obtain		A weakness of this approach is that an attacker can learn the
	a short-term password as described in section Section 6.2.		BOOTNONCE value if the attacker is able to connect to the NAT's
			internal network prior to initiating the attack; this is plausible if
			the internal network has no security (e.g., public WiFi network).
			For this reason, it is RECOMMENDED that the BOOTNONCE value is hashed
			with the STUN client's IP address. Doing so means the attacker must
			acquire the same IP address as the victim from behind the NAT (to
			learn the BOOTNONCE), and must also acquire the NAT's previous public
			IP address.
	10. IANA Considerations		10. Open Issues and Discussion Points
	This section registers one new STUN attribute per the procedures in		o Discussion Point: After discovering NATs and firewalls,
			controlling those devices might also be done with a middlebox
			control protocol (e.g., by using standard or slightly modified
			versions of SIMCO, UPnP, MIDCOM, or Bonjour). This is open for
			discussion as this document is scoped within the IETF.
			o Discussion Point: Tagging would also be useful for the
			Connectivity Check usage (which is used by ICE), especially
			considering that a different firewall may be traversed for media
			than for the initial Binding Discovery usage. In such a
			situation, the new on-path firewall's policy might not allow a
			binding request to leave the network or allow a binding response
			to return. In this case, the firewall would need to indicate its
			presence to the STUN client in another way. An ICMP error message
			may be appropriate, and an ICMP extension [RFC4884] could indicate
			the firewall is controllable.
			o Open issue: We could resolve the problem of address dependant
			NATs along the path by introducing a new STUN attribute which
			indicates the UDP port the STUN client wants to control. However,
			this changes the security properties of STUN Control, so this
			seems undesirable.
			Open issue: When the STUN client detects an address dependant
			NAT, should we recommend it abandon the STUN Control usage, and
			revert to operation as if it doesn't support the STUN Control
			usage?
			o Open issue: How many filter entries are in address dependent
			filtering NATs? If only one, this does become a real limitation
			if NATs are nested; if they're not nested, the outer-most NAT can
			avoid overwriting its own address in its address dependent filter.
			o Discussion: One way to thwart a resource consumption attack is to
			challenge the STUN client. This would allow the STUN server to
			delay the establishment of resources before a return-routability
			test is performed. This functionality is currently not provided
			by this specification. The NONCE attribute
			[I-D.ietf-behave-rfc3489bis] could be useful to provide this
			function. However, the mere sending of a UDP packet across a NAT
			creates a binding (for ~2 minutes), and there isn't a return-
			routability check for that.
			o The inside-out discovery technique was removed with version -03 of
			this document. The procedure worked as follows: The STUN client
			sends a STUN request to UDP/3478 of the IP address of its default
			router. If there is a STUN server listening there, it will
			respond, and will indicate its default route via the new DEFAULT-
			ROUTE attribute. With that information, the STUN client can
			discover the next-outermost NAT by repeating the procedure. More
			feedback is needed to determine whether the functionality is
			needed.
			11. IANA Considerations
			This section registers new STUN attributes per the procedures in
	[I-D.ietf-behave-rfc3489bis]:		[I-D.ietf-behave-rfc3489bis]:
	Mandatory range:		Mandatory range:
	0x0028 XOR-INTERNAL-ADDRESS		0x0029 XOR-INTERNAL-ADDRESS
			0x00.. BOOTNONCE
	Optional range:		Optional range:
			0x8024 REFRESH-INTERVAL
	0x80.. PLEASE-TAG		0x80.. PLEASE-TAG
	0x80.. TAG		0x80.. TAG
	11. Acknowledgements		12. Acknowledgements
	Thanks to Remi Denis-Courmont, Markus Isomaki, Cullen Jennings, and		Thanks to Remi Denis-Courmont, Bajko Gabor, Markus Isomaki, Cullen
	Philip Matthews for their suggestions which have improved this		Jennings, and Philip Matthews for their suggestions which have
	document.		improved this document.
	12. References		13. References
	12.1. Normative References		13.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[I-D.ietf-behave-rfc3489bis]		[I-D.ietf-behave-rfc3489bis]
	Rosenberg, J., "Session Traversal Utilities for (NAT)		Rosenberg, J., "Session Traversal Utilities for (NAT)
	(STUN)", draft-ietf-behave-rfc3489bis-06 (work in		(STUN)", draft-ietf-behave-rfc3489bis-06 (work in
	progress), March 2007.		progress), March 2007.
	[RFC4787] Audet, F. and C. Jennings, "Network Address Translation		[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
	(NAT) Behavioral Requirements for Unicast UDP", BCP 127,		(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
	RFC 4787, January 2007.		RFC 4787, January 2007.
	[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,		[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
	"STUN - Simple Traversal of User Datagram Protocol (UDP)		"STUN - Simple Traversal of User Datagram Protocol (UDP)
	Through Network Address Translators (NATs)", RFC 3489,		Through Network Address Translators (NATs)", RFC 3489,
	March 2003.		March 2003.
	12.2. Informational References		[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
			in IPv6", RFC 3775, June 2004.
			13.2. Informational References
	[I-D.ietf-behave-turn]		[I-D.ietf-behave-turn]
	Rosenberg, J., "Obtaining Relay Addresses from Simple		Rosenberg, J., "Obtaining Relay Addresses from Simple
	Traversal Underneath NAT (STUN)",		Traversal Underneath NAT (STUN)",
	draft-ietf-behave-turn-03 (work in progress), March 2007.		draft-ietf-behave-turn-03 (work in progress), March 2007.
	[UPnP] UPnP Forum, "Universal Plug and Play", 2000,		[UPnP] UPnP Forum, "Universal Plug and Play", 2000,
	<http://www.upnp.org>.		<http://www.upnp.org>.
	[Bonjour] Apple Computer, "Bonjour", 2005,		[Bonjour] Apple Computer, "Bonjour", 2005,
	<http://www.apple.com/macosx/features/bonjour/>.		<http://www.apple.com/macosx/features/bonjour/>.
	[RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and		[RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and
	A. Rayhan, "Middlebox communication architecture and		A. Rayhan, "Middlebox communication architecture and
	framework", RFC 3303, August 2002.		framework", RFC 3303, August 2002.
	[I-D.ietf-mmusic-ice]		[I-D.ietf-mmusic-ice]
	Rosenberg, J., "Interactive Connectivity Establishment		Rosenberg, J., "Interactive Connectivity Establishment
	(ICE): A Methodology for Network Address Translator (NAT)		(ICE): A Protocol for Network Address Translator (NAT)
	Traversal for Offer/Answer Protocols",		Traversal for Offer/Answer Protocols",
	draft-ietf-mmusic-ice-15 (work in progress), March 2007.		draft-ietf-mmusic-ice-16 (work in progress), June 2007.
	[I-D.ietf-sip-outbound]		[I-D.ietf-sip-outbound]
	Jennings, C. and R. Mahy, "Managing Client Initiated		Jennings, C. and R. Mahy, "Managing Client Initiated
	Connections in the Session Initiation Protocol (SIP)",		Connections in the Session Initiation Protocol (SIP)",
	draft-ietf-sip-outbound-08 (work in progress), March 2007.		draft-ietf-sip-outbound-09 (work in progress), June 2007.
	[I-D.ietf-nsis-nslp-natfw]		[I-D.ietf-nsis-nslp-natfw]
	Stiemerling, M., "NAT/Firewall NSIS Signaling Layer		Stiemerling, M., "NAT/Firewall NSIS Signaling Layer
	Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-14 (work in		Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-14 (work in
	progress), March 2007.		progress), March 2007.
	[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro,		[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro,
	"Extended ICMP to Support Multi-Part Messages", RFC 4884,		"Extended ICMP to Support Multi-Part Messages", RFC 4884,
	April 2007.		April 2007.
	[I-D.shore-tist-prot]		[I-D.shore-tist-prot]
	Shore, M., "The TIST (Topology-Insensitive Service		Shore, M., "The TIST (Topology-Insensitive Service
	Traversal) Protocol", draft-shore-tist-prot-00 (work in		Traversal) Protocol", draft-shore-tist-prot-00 (work in
	progress), May 2002.		progress), May 2002.
	[I-D.shore-nls-tl]		[I-D.shore-nls-tl]
	Shore, M., "Network-Layer Signaling: Transport Layer",		Shore, M., "Network-Layer Signaling: Transport Layer",
	draft-shore-nls-tl-04 (work in progress), May 2007.		draft-shore-nls-tl-05 (work in progress), June 2007.
	[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral		[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
	Self-Address Fixing (UNSAF) Across Network Address		Self-Address Fixing (UNSAF) Across Network Address
	Translation", RFC 3424, November 2002.		Translation", RFC 3424, November 2002.
	[RFC4540] Stiemerling, M., Quittek, J., and C. Cadar, "NEC's Simple		[I-D.wing-session-auth]
	Middlebox Configuration (SIMCO) Protocol Version 3.0",		Wing, D., "Media Session Authorization",
	RFC 4540, May 2006.		draft-wing-session-auth-00 (work in progress),
			February 2006.
			Appendix A. Changes
			A.1. Changes between -03 and 02
			o Removed TLS from normal STUN operation (as few use it, and ICE
			makes it unnecessary anyway)
			o BOOTNONCE attribute replaces STUN Control's previous use of TLS.
			o Added "MIP-capable" bit to TAG attribute
			o Removed "inside-out" discovery technique.
			Appendix B. Block Diagram of Internal NAT Operation
			Internally, the NAT can be diagrammed to function like this, where
			the NAT operation occurs before the STUN server:
			|
			| outside interface
			|
			+---------+---------------+
			| | |
			| | +--------+ |
			| |----+ STUN | |
			| | | Server | |
			| | +--------+ |
			| | |
			| +-------+-------------+ |
			| | NAT Function | |
			| +-------+-------------+ |
			| | |
			+---------+---------------+
			|
			| inside interface
			|
			|
			Figure 14: Block Diagram of Internal NAT Operation
	Authors' Addresses		Authors' Addresses
	Dan Wing		Dan Wing
	Cisco Systems		Cisco Systems, Inc.
	170 West Tasman Drive		170 West Tasman Drive
	San Jose, CA 95134		San Jose, CA 95134
	USA		USA
	Email: dwing@cisco.com		Email: dwing@cisco.com
	Jonathan Rosenberg		Jonathan Rosenberg
	Cisco Systems		Cisco Systems, Inc.
	600 Lanidex Plaza		Edison, NJ 07054
	Parsippany, NJ 07054
	USA		USA
	Email: jdrosen@cisco.com		Email: jdrosen@cisco.com
			Hannes Tschofenig
			Nokia Siemens Networks
			Otto-Hahn-Ring 6
			Munich, Bavaria 81739
			Germany
			Email: Hannes.Tschofenig@nsn.com
			URI: http://www.tschofenig.com
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
End of changes. 128 change blocks.
	559 lines changed or deleted		564 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/