draft-ietf-mmusic-latching-08.txt		rfc7362.txt
	Network Working Group E. Ivov		Internet Engineering Task Force (IETF) E. Ivov
	Internet-Draft Jitsi		Request for Comments: 7362 Jitsi
	Intended status: Informational H. Kaplan		Category: Informational H. Kaplan
	Expires: December 19, 2014 Oracle		ISSN: 2070-1721 Oracle
	D. Wing		D. Wing
	Cisco		Cisco
	June 17, 2014		September 2014
	Latching: Hosted NAT Traversal (HNT) for Media in Real-Time		Latching: Hosted NAT Traversal (HNT)
	Communication		for Media in Real-Time Communication
	draft-ietf-mmusic-latching-08
	Abstract		Abstract
	This document describes behavior of signaling intermediaries in Real-		This document describes the behavior of signaling intermediaries in
	Time Communication (RTC) deployments, sometimes referred to as		Real-Time Communication (RTC) deployments, sometimes referred to as
	Session Border Controllers (SBCs), when performing Hosted NAT		Session Border Controllers (SBCs), when performing Hosted NAT
	Traversal (HNT). HNT is a set of mechanisms, such as media relaying		Traversal (HNT). HNT is a set of mechanisms, such as media relaying
	and latching, that such intermediaries use to enable other RTC		and latching, that such intermediaries use to enable other RTC
	devices behind NATs to communicate with each other.		devices behind NATs to communicate with each other.
	This document is non-normative, and is only written to explain HNT in		This document is non-normative and is only written to explain HNT in
	order to provide a reference to the IETF community, as well as an		order to provide a reference to the Internet community and an
	informative description to manufacturers, and users.		informative description to manufacturers and users.
	Latching, which is one of the components of the HNT components, has a		Latching, which is one of the HNT components, has a number of
	number of security issues covered here. Because of those, and unless		security issues covered here. Because of those, and unless all
	all security considerations explained here are taken into account and		security considerations explained here are taken into account and
	solved, the IETF advises against use of latching mechanism over the		solved, the IETF advises against use of the latching mechanism over
	Internet and recommends other solutions such as the Interactive		the Internet and recommends other solutions, such as the Interactive
	Connectivity Establishment (ICE) protocol.		Connectivity Establishment (ICE) protocol.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This document is not an Internet Standards Track specification; it is
	provisions of BCP 78 and BCP 79.		published for informational purposes.
	Internet-Drafts are working documents of the Internet Engineering		This document is a product of the Internet Engineering Task Force
	Task Force (IETF). Note that other groups may also distribute		(IETF). It represents the consensus of the IETF community. It has
	working documents as Internet-Drafts. The list of current Internet-		received public review and has been approved for publication by the
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Internet Engineering Steering Group (IESG). Not all documents
			approved by the IESG are a candidate for any level of Internet
			Standard; see Section 2 of RFC 5741.
	Internet-Drafts are draft documents valid for a maximum of six months		Information about the current status of this document, any errata,
	and may be updated, replaced, or obsoleted by other documents at any		and how to provide feedback on it may be obtained at
	time. It is inappropriate to use Internet-Drafts as reference		http://www.rfc-editor.org/info/rfc7362.
	material or to cite them other than as "work in progress."
	This Internet-Draft will expire on December 19, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 26		skipping to change at page 2, line 25
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Impact on Signaling . . . . . . . . . . . . . . . . . . . . . 5		3. Impact on Signaling . . . . . . . . . . . . . . . . . . . . . 5
	4. Media Behavior, Latching . . . . . . . . . . . . . . . . . . 6		4. Media Behavior and Latching . . . . . . . . . . . . . . . . . 6
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 11		5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13		7.1. Normative References . . . . . . . . . . . . . . . . . . 14
	8.1. Key References . . . . . . . . . . . . . . . . . . . . . 13		7.2. Informative References . . . . . . . . . . . . . . . . . 14
	8.2. Additional References . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
	1. Introduction		1. Introduction
	Network Address Translators (NATs) are widely used in the Internet by		Network Address Translators (NATs) are widely used in the Internet by
	consumers and organizations. Although specific NAT behaviors vary,		consumers and organizations. Although specific NAT behaviors vary,
	this document uses the term "NAT" for devices that map any IPv4 or		this document uses the term "NAT" for devices that map any IPv4 or
	IPv6 address and transport port number to another IPv4 or IPv6		IPv6 address and transport port number to another IPv4 or IPv6
	address and transport port number. This includes consumer NATs,		address and transport port number. This includes consumer NATs,
	Firewall-NATs, IPv4-IPv6 NATs, Carrier-Grade NATs (CGNs) [RFC6888],		firewall/NATs, IPv4-IPv6 NATs, Carrier-Grade NATs (CGNs) [RFC6888],
	etc.		etc.
	The Session Initiation Protocol (SIP) [RFC3261], and others that try		The Session Initiation Protocol (SIP) [RFC3261], and others that try
	to use a more direct path for media than with signaling, are		to use a more direct path for media than with signaling, are
	difficult to use across NATs. These protocols use IP addresses and		difficult to use across NATs. These protocols use IP addresses and
	transport port numbers encoded in bodies such as the Session		transport port numbers encoded in bodies such as the Session
	Description Protocol (SDP) [RFC4566] and, in the case of SIP, various		Description Protocol (SDP) [RFC4566] and, in the case of SIP, various
	header fields. Such addresses and ports are unusable unless all		header fields. Such addresses and ports are unusable unless all
	peers in a session are located behind the same NAT.		peers in a session are located behind the same NAT.
	Mechanisms such as Session Traversal Utilities for NAT (STUN)		Mechanisms such as Session Traversal Utilities for NAT (STUN)
	[RFC5389], Traversal Using Relays around NAT (TURN) [RFC5766], and		[RFC5389], Traversal Using Relays around NAT (TURN) [RFC5766], and
	Interactive Connectivity Establishment (ICE) [RFC5245] did not exist		Interactive Connectivity Establishment (ICE) [RFC5245] did not exist
	when protocols like SIP began being deployed. Some mechanisms, such		when protocols like SIP began being deployed. Some mechanisms, such
	as the early versions of STUN [RFC3489], had started appearing but		as the early versions of STUN [RFC3489], had started appearing, but
	they were unreliable and suffered a number of issues typical for		they were unreliable and suffered a number of issues typical for
	UNilateral Self-Address Fixing (UNSAF) and described in [RFC3424].		UNilateral Self-Address Fixing (UNSAF), as described in [RFC3424].
	For these and other reasons, Session Border Controllers (SBCs) that		For these and other reasons, Session Border Controllers (SBCs) that
	were already being used by SIP domains for other SIP and media-		were already being used by SIP domains for other SIP and media-
	related purposes began to use proprietary mechanisms to enable SIP		related purposes began to use proprietary mechanisms to enable SIP
	devices behind NATs to communicate across the NATs. These mechanisms		devices behind NATs to communicate across the NATs. These mechanisms
	are often transparent to endpoints and rely on a dynamic address and		are often transparent to endpoints and rely on a dynamic address and
	port discovery technique called "latching".		port discovery technique called "latching".
	The term often used for this behavior is Hosted NAT Traversal (HNT),		The term often used for this behavior is "Hosted NAT Traversal
	although a number of manufacturers sometimes use other names such as		(HNT)"; a number of manufacturers sometimes use other names such as
	"Far-end NAT Traversal" or "NAT assist" instead. The systems which		"Far-end NAT Traversal" or "NAT assist" instead. The systems that
	perform HNT are frequently SBCs as described in [RFC5853], although		perform HNT are frequently SBCs as described in [RFC5853], although
	other systems such as media gateways and "media proxies" sometimes		other systems such as media gateways and "media proxies" sometimes
	perform the same role. For the purposes of this document, all such		perform the same role. For the purposes of this document, all such
	systems are referred to as SBCs, and the NAT traversal behavior is		systems are referred to as SBCs and the NAT traversal behavior is
	called HNT.		called HNT.
	As of this document's creation time, a vast majority of SIP domains		At the time of this document's publication, a vast majority of SIP
	use HNT to enable SIP devices to communicate across NATs, despite the		domains use HNT to enable SIP devices to communicate across NATs
	publication of ICE. There are many reasons for this, but those		despite the publication of ICE. There are many reasons for this, but
	reasons are not relevant to this document's purpose and will not be		those reasons are not relevant to this document's purpose and will
	discussed. It is however worth pointing out that the current		not be discussed. It is, however, worth pointing out that the
	deployment levels of HNT and NATs make the complete extinction of		current deployment levels of HNT and NATs make the complete
	this practice highly unlikely in the foreseeable future.		extinction of this practice highly unlikely in the foreseeable
			future.
	The purpose of this document is to describe the mechanisms often used		The purpose of this document is to describe the mechanisms often used
	for HNT at the SDP and media layer, in order to aid understanding the		for HNT at the SDP and media layer in order to aid understanding the
	implications and limitations imposed by it. Although the mechanisms		implications and limitations imposed by it. Although the mechanisms
	used in HNT are well known in the community, publication in an IETF		used in HNT are well known in the community, publication in an IETF
	document is useful as a means of providing common terminology and a		document is useful as a means of providing common terminology and a
	reference for related documents.		reference for related documents.
	This document does not attempt to make a case for HNT or present it		This document does not attempt to make a case for HNT or present it
	as a solution that is somehow better than alternatives such as ICE.		as a solution that is somehow better than alternatives such as ICE.
	Due to the security issues presented in Section 5, the latching		Due to the security issues presented in Section 5, the latching
	mechanism is considered inappropriate for general use on the Internet		mechanism is considered inappropriate for general use on the Internet
	unless all security considerations are taken into account and solved.		unless all security considerations are taken into account and solved.
	The IETF is instead advising for the use of the Interactive		The IETF is instead advising for the use of the Interactive
	Connectivity Establishment [RFC5245] and Traversal Using Relays		Connectivity Establishment (ICE) [RFC5245] and Traversal Using Relays
	around NAT (TURN) [RFC5766] protocols.		around NAT (TURN) [RFC5766] protocols.
	It is also worth mentioning that there are purely signaling-layer		It is also worth mentioning that there are purely signaling-layer
	components of HNT as well. One such component is briefly described		components of HNT as well. One such component is briefly described
	for SIP in [RFC5853], but that is not the focus of this document.		for SIP in [RFC5853], but that is not the focus of this document.
	SIP uses numerous expressive primitives for message routing. As a		SIP uses numerous expressive primitives for message routing. As a
	result, the HNT component for SIP is typically more implementation-		result, the HNT component for SIP is typically more implementation-
	specific and deployment-specific than the SDP and media components.		specific and deployment-specific than the SDP and media components.
	For the purposes of this document it is hence assumed that signaling		For the purposes of this document it is hence assumed that signaling
	intermediaries handle traffic in a way that allows protocols such as		intermediaries handle traffic in a way that allows protocols such as
	SIP to function correctly across the NATs.		SIP to function correctly across the NATs.
	The rest of this document is going to focus primarily on use of HNT		The rest of this document focuses primarily on the use of HNT for
	for SIP. However, the mechanisms described here are relatively		SIP. However, the mechanisms described here are relatively generic
	generic and are often used with other protocols, such as XMPP		and are often used with other protocols such as the Extensible
	[RFC6120], Media Gateway Control Protocol (MGCP) [RFC3435], H.248/		Messaging and Presence Protocol (XMPP) [RFC6120], Media Gateway
	MEGACO [RFC5125], and H.323 [H.323].		Control Protocol (MGCP) [RFC3435], Megaco/H.248 [RFC5125], and H.323
			[H.323].
	2. Background		2. Background
	The general problems with NAT traversal for protocols such as SIP		The general problems with NAT traversal for protocols such as SIP
	are:		are:
	1. The addresses and port numbers encoded in SDP bodies (or their		1. The addresses and port numbers encoded in SDP bodies (or their
	equivalents) by NATed User Agents (UAs) are not usable across the		equivalents) by NATed User Agents (UAs) are not usable across the
	Internet, because they represent the private network addressing		Internet because they represent the private network addressing
	information of the UA rather than the addresses/ports that will		information of the UA rather than the addresses/ports that will
	be mapped to/from by the NAT.		be mapped to/from by the NAT.
	2. The policies inherent in NATs, and explicit in Firewalls, are		2. The policies inherent in NATs, and explicit in firewalls, are
	such that packets from outside the NAT cannot reach the UA until		such that packets from outside the NAT cannot reach the UA until
	the UA sends packets out first.		the UA sends packets out first.
	3. Some NATs apply endpoint dependent filtering on incoming packets,		3. Some NATs apply endpoint-dependent filtering on incoming packets,
	as described in [RFC4787] and thus a UA may only be able to		as described in [RFC4787]; thus, a UA may only be able to receive
	receive packets from the same remote peer IP:port as it sends		packets from the same remote peer IP:port as it sends packets out
	packets out to.		to.
	In order to overcome these issues, signaling intermediaries such as		In order to overcome these issues, signaling intermediaries such as
	SIP SBCs on the public side of the NATs perform HNT for both		SIP SBCs on the public side of the NATs perform HNT for both
	signaling and media. An example deployment model of HNT and SBCs is		signaling and media. An example deployment model of HNT and SBCs is
	shown in Figure 1.		shown in Figure 1.
	+-----+ +-----+		+-----+ +-----+
	| SBC |-------| SBC |		| SBC |-------| SBC |
	+-----+ +-----+		+-----+ +-----+
	/ \		/ \
	skipping to change at page 5, line 26		skipping to change at page 5, line 26
	/ \		/ \
	+------+ +------+		+------+ +------+
	| UA-A | | UA-B |		| UA-A | | UA-B |
	+------+ +------+		+------+ +------+
	Figure 1: Signaling and Media Flows in a Common Deployment Scenario		Figure 1: Signaling and Media Flows in a Common Deployment Scenario
	3. Impact on Signaling		3. Impact on Signaling
	Along with codec and other media-layer information, session		Along with codec and other media-layer information, session
	establishment signaling also conveys, potentially private and non-		establishment signaling also conveys potentially private and non-
	globally routable addressing information. Signaling intermediaries		globally routable addressing information. Signaling intermediaries
	would hence modify such information so that peer UAs are given the		would hence modify such information so that peer UAs are given the
	(public) addressing information of a media relay controlled by the		(public) addressing information of a media relay controlled by the
	intermediary.		intermediary.
	In typical deployments, the media relay and signaling intermediary		In typical deployments, the media relay and signaling intermediary
	(i.e., the SBC) are co-located, thereby sharing the same IP address.		(i.e., the SBC) are co-located, thereby sharing the same IP address.
	Also, the address of the media relay would typically belong to the		Also, the address of the media relay would typically belong to the
	same IP address family as the one used for signaling, as it is known		same IP address family as the one used for signaling (as it is known
	to work for that UA. In other words, signalling and media would		to work for that UA). In other words, signaling and media would both
	either both travel over IPv4 or IPv6.		travel over either IPv4 or IPv6.
	The port numbers introduced in the signaling by the intermediary are		The port numbers introduced in the signaling by the intermediary are
	typically allocated dynamically. Allocation strategies are entirely		typically allocated dynamically. Allocation strategies are entirely
	implementation dependent and they often vary from one product to the		implementation dependent and they often vary from one product to the
	next.		next.
	The offer/answer media negotiation model [RFC3264] is such that once		The offer/answer media negotiation model [RFC3264] is such that once
	an offer is sent, the generator of the offer needs to be prepared to		an offer is sent, the generator of the offer needs to be prepared to
	receive media on the advertised address/ports. In practice such		receive media on the advertised address/ports. In practice, such
	media may or may not be received, depending on the implementations		media may or may not be received depending on the implementations
	participating in a given session, local policies, and call scenario.		participating in a given session, local policies, and the call
	For example if a SIP SDP Offer originally came from a UA behind a		scenario. For example, if a SIP SDP offer originally came from a UA
	NAT, the SIP SBC cannot send media to it until an SDP Answer is given		behind a NAT, the SIP SBC cannot send media to it until an SDP answer
	to the UA and latching (Section 4) occurs. Another example is when a		is given to the UA and latching (Section 4) occurs. Another example
	SIP SBC sends an SDP Offer in a SIP INVITE to a residential		is, when a SIP SBC sends an SDP offer in a SIP INVITE to a
	customer's UA and receives back SDP in a 18x response, the SBC may		residential customer's UA and receives back SDP in a 18x response,
	decide, for policy reasons, not to send media to that customer UA		the SBC may decide, for policy reasons, not to send media to that
	until a SIP 200 response has been received (e.g., to prevent toll-		customer UA until a SIP 200 response has been received (e.g., to
	fraud).		prevent toll fraud).
	4. Media Behavior, Latching		4. Media Behavior and Latching
	An UA that is behind a NAT would stream media from an address and a		An UA that is behind a NAT would stream media from an address and a
	port number (an address:port tuple) that are only valid in its local		port number (an address:port tuple) that are only valid in its local
	network. Once packets cross the NAT, that address:port tuple will be		network. Once packets cross the NAT, that address:port tuple will be
	mapped to a public one. The UA however is not typically aware of the		mapped to a public one. The UA, however, is not typically aware of
	public mapping and would often advertise the private address:port		the public mapping and would often advertise the private address:port
	tuple in signaling. This way, while a session is still being setup,		tuple in signaling. This way, while a session is still being set up,
	the signaling intermediary is not yet aware what addresses and ports		the signaling intermediary is not yet aware what addresses and ports
	the caller and the callee would end up using for media traffic: it		the caller and the callee would end up using for media traffic: it
	has only seen them advertise the private addresses they use behind		has only seen them advertise the private addresses they use behind
	their respective NATs. Therefore media relays used in HNT would		their respective NATs. Therefore, media relays used in HNT would
	often use a mechanism called "latching".		often use a mechanism called "latching".
	Historically, "latching" only referred to the process by which SBCs		Historically, "latching" only referred to the process by which SBCs
	"latch" onto UDP packets from a given UA for security purposes, and		"latch" onto UDP packets from a given UA for security purposes, and
	"symmetric-latching" is when the latched address:port tuples are used		"symmetric-latching" is when the latched address:port tuples are used
	to send media back to the UA. Today most people talk about them both		to send media back to the UA. Today, most people talk about them
	as "latching", and thus this document does as well.		both as "latching"; thus, this document does as well.
	The latching mechanism works as follows:		The latching mechanism works as follows:
	1. After receiving an offer from Alice (UAC located behind a NAT), a		1. After receiving an offer from Alice (User Agent Client (UAC)
	signaling intermediary located on the public Internet would		located behind a NAT), a signaling intermediary located on the
	allocate a set of IP address:port tuples on a media relay. The		public Internet would allocate a set of IP address:port tuples on
	set would then be advertised to Bob (UAS) so that he would use		a media relay. The set would then be advertised to Bob (User
	those media relay address:port tuples for all media it wished to		Agent Server (UAS)) so that he would use those media relay
	send toward Alice (UAC).		address:port tuples for all media he wished to send toward Alice
			(UAC).
	2. Next, after receiving from Bob (UAS) an answer to its offer, the		2. Next, after receiving from Bob (UAS) an answer to its offer, the
	signaling server would allocate a second address:port set on the		signaling server would allocate a second address:port set on the
	media relay. In it's the answer to Alice (UAC) the SBC will		media relay. In its answer to Alice (UAC), the SBC will replace
	replace Bob's address:port with this second set. This way Alice		Bob's address:port with this second set. This way, Alice will
	will send media to this media relay address:port.		send media to this media relay address:port.
	3. The media relay receives the media packets on the allocated		3. The media relay receives the media packets on the allocated ports
	ports, and uses their respective source address:ports as a		and uses their respective source address:ports as a destination
	destination for all media bound in the opposite direction. In		for all media bound in the opposite direction. In other words,
	other words, it "latches" or locks on these source address:port		it "latches" or locks on these source address:port tuples.
	tuple.
	4. This way, when Alice (UAC) streams media toward the media relay,		4. This way, when Alice (UAC) streams media toward the media relay,
	it would be received on the second address:port tuple. The		it would be received on the second address:port tuple. The
	source address:port of her traffic would belong to the public		source address:port of her traffic would belong to the public
	interface of Alice's NAT and anything that the relay sends back		interface of Alice's NAT, and anything that the relay sends back
	to that address:port, would find its way to Alice.		to that address:port would find its way to Alice.
	5. Similarly the source of the media packets that Bob (UAS) is		5. Similarly, the source of the media packets that Bob (UAS) is
	sending would be latched upon and used for media going in that		sending would be latched upon and used for media going in that
	direction.		direction.
	6. Latching is usually done only once per peer and not allowed to		6. Latching is usually done only once per peer and not allowed to
	change or cause a re-latching until a new offer and answer get		change or cause a re-latching until a new offer and answer get
	exchanged (e.g., in a subsequent call or after a SIP peer has		exchanged (e.g., in a subsequent call or after a SIP peer has
	gone on and off hold). The reasons for such restrictions are		gone on and off hold). The reasons for such restrictions are
	mostly related to security: once a session has started a user		mostly related to security: once a session has started, a user
	agent is not expected to suddenly start streaming from a		agent is not expected to suddenly start streaming from a
	different port without sending a new offer first. A change may		different port without sending a new offer first. A change may
	indicate an attempt to hijack the session. In some cases		indicate an attempt to hijack the session. In some cases,
	however, a port change may be caused by a re-mapping in a NAT		however, a port change may be caused by a re-mapping in a NAT
	device standing between the SBC and the UA. More advanced SBCs		device standing between the SBC and the UA. More advanced SBCs
	may therefore allow some level of flexibility on the re-latching		may therefore allow some level of flexibility on the re-latching
	restrictions while carefully considering the potential security		restrictions while carefully considering the potential security
	implications of doing so.		implications of doing so.
	Figure 2 describes how latching occurs for SIP where HNT is provided		Figure 2 describes how latching occurs for SIP where HNT is provided
	by an SBC connected to two networks: 203.0.113/24 facing towards the		by an SBC connected to two networks: 203.0.113/24 facing towards the
	User Agent Client (UAC) network and 198.51.100/24 facing towards the		UAC network and 198.51.100/24 facing towards the UAS network.
	User Agent Server (UAS) network.
	192.0.2.1 192.0.2.9/203.0.113.4 198.51.100.33		192.0.2.1 192.0.2.9/203.0.113.4 198.51.100.33
	Alice NAT 203.0.113.9-SBC-198.51.100.2 Bob		Alice NAT 203.0.113.9-SBC-198.51.100.2 Bob
	------- --- --- -------		------- --- --- -------
	| | | |		| | | |
	1. |--SIP INVITE+offer c=192.0.2.1--->| |		1. |--SIP INVITE+offer c=192.0.2.1--->| |
	| | | |		| | | |
	2. | | (SBC allocates 198.51.100.2:22007 |		2. | | (SBC allocates 198.51.100.2:22007 |
	| | for inbound RTP from Bob) |		| | for inbound RTP from Bob) |
	| | | |		| | | |
	skipping to change at page 8, line 43		skipping to change at page 8, line 43
	| | | |		| | | |
	12. | | (SBC latches to |		12. | | (SBC latches to |
	| | source IP address and |		| | source IP address and |
	| | port seen at (11)) |		| | port seen at (11)) |
	| | | |		| | | |
	13. | | |<======= RTP ==========|		13. | | |<======= RTP ==========|
	| | |dest:198.51.100.2:22007|		| | |dest:198.51.100.2:22007|
	14. |<=====RTP, to latched address=====| |		14. |<=====RTP, to latched address=====| |
	| | | |		| | | |
	Figure 2: Latching by a SIP SBC across two interfaces		Figure 2: Latching by a SIP SBC across Two Interfaces
	While XMPP implementations often rely on ICE to handle NAT traversal,		While XMPP implementations often rely on ICE to handle NAT traversal,
	there are some that also support a non-ICE transport called XMPP		there are some that also support a non-ICE transport called XMPP
	Jingle Raw UDP Transport Method [XEP-0177]. Figure 3 describes how		Jingle Raw UDP Transport Method [XEP-0177]. Figure 3 describes how
	latching occurs for one such XMPP implementation where HNT is		latching occurs for one such XMPP implementation where HNT is
	provided by an XMPP server on the public internet.		provided by an XMPP server on the public Internet.
	192.0.2.1 192.0.2.9/203.0.113.4 203.0.113.9 198.51.100.8		192.0.2.1 192.0.2.9/203.0.113.4 203.0.113.9 198.51.100.8
	Romeo NAT XMPP Server Juliet		Romeo NAT XMPP Server Juliet
	----- --- --- -----		----- --- --- -----
	| | | |		| | | |
	1. |----session-initiate cand=192.0.2.1--->| |		1. |----session-initiate cand=192.0.2.1--->| |
	| | | |		| | | |
	2. |<------------ack-----------------------| |		2. |<------------ack-----------------------| |
	| | | |		| | | |
	3. | | (Server allocates 203.0.113.9:2200 |		3. | | (Server allocates 203.0.113.9:2200 |
	skipping to change at page 9, line 46		skipping to change at page 9, line 46
	| | | |		| | | |
	12. | | (XMPP server latches to |		12. | | (XMPP server latches to |
	| | src IP 203.0.113.4 and |		| | src IP 203.0.113.4 and |
	| | src port seen at (11)) |		| | src port seen at (11)) |
	| | | |		| | | |
	13. | | |<======= RTP ========|		13. | | |<======= RTP ========|
	| | |dest=203.0.113.9:2200|		| | |dest=203.0.113.9:2200|
	14. |<======RTP, to latched address=========| |		14. |<======RTP, to latched address=========| |
	| | | |		| | | |
	Figure 3: Latching by an XMPP server across two interfaces		Figure 3: Latching by an XMPP Server across Two Interfaces
	The above is a general description, and some details vary between		The above is a general description, and some details vary between
	implementations or configuration settings. For example, some		implementations or configuration settings. For example, some
	intermediaries perform additional logic before latching on received		intermediaries perform additional logic before latching on received
	packet source information to prevent malicious attacks or latching		packet source information to prevent malicious attacks or latching
	erroneously to previous media senders - often called "rogue-rtp" in		erroneously to previous media senders -- often called "rogue-rtp" in
	the industry.		the industry.
	It is worth pointing out that latching is not an exclusively "server		It is worth pointing out that latching is not exclusively a "server
	affair" and some clients may also use it in cases where they are		affair", and some clients may also use it in cases where they are
	configured with a public IP address and they are contacted by a NATed		configured with a public IP address and are contacted by a NATed
	client with no other NAT traversal means.		client with no other NAT traversal means.
	In order for latching to function correctly, the UA behind the NAT		In order for latching to function correctly, the UA behind the NAT
	needs to support symmetric RTP. That is, it needs to use the same		needs to support symmetric RTP. That is, it needs to use the same
	ports for sending data as the ones it listens on for inbound packets.		ports for sending data as the ones it listens on for inbound packets.
	Today this is the case for with, for example, almost all SIP and XMPP		Today, this is the case with almost all SIP and XMPP clients. Also,
	clients. Also UAs need to make sure they can begin sending media		UAs need to make sure they can begin sending media packets
	packets independently and without waiting for packets to arrive		independently without waiting for packets to arrive first. In
	first. In theory, it is possible that some UAs would not send		theory, it is possible that some UAs would not send packets out
	packets out first; for example if a SIP session begins in 'inactive'		first, for example, if a SIP session begins in 'inactive' or
	or 'recvonly' SDP mode from the UA behind the NAT. In practice,		'recvonly' SDP mode from the UA behind the NAT. In practice,
	however, SIP sessions from regular UAs (the kind that one could find		however, SIP sessions from regular UAs (the kind that one could find
	behind a NAT) virtually never begin an inactive or 'recvonly' mode,		behind a NAT) virtually never begin in 'inactive' or 'recvonly' mode,
	for obvious reasons. The media direction would also be problematic		for obvious reasons. The media direction would also be problematic
	if the SBC side indicated 'inactive' or 'sendonly' modes when it sent		if the SBC side indicated 'inactive' or 'sendonly' modes when it sent
	SDP to the UA. However SBCs providing HNT would always be configured		SDP to the UA. However, SBCs providing HNT would always be
	to avoid this.		configured to avoid this.
	Given that, in order for latching to work properly, media relays need		Given that, in order for latching to work properly, media relays need
	to begin receiving media before they start sending, it is possible		to begin receiving media before they start sending, it is possible
	for deadlocks to occur. This can happen when the UAC and the UAS in		for deadlocks to occur. This can happen when the UAC and the UAS in
	a session are connected to different signaling intermediaries that		a session are connected to different signaling intermediaries that
	both provide HNT. In this case the media relays controlled by the		both provide HNT. In this case, the media relays controlled by the
	signaling servers could end up each waiting upon the other to		signaling servers could end up each waiting upon the other to
	initiate the streaming. To prevent this relays would often attempt		initiate the streaming. To prevent this, relays would often attempt
	to start streaming toward the address:port tuples provided in the		to start streaming toward the address:port tuples provided in the
	offer/answer even before receiving any inbound traffic. If the		offer/answer even before receiving any inbound traffic. If the
	entity they are streaming to is another HNT performing server it		entity they are streaming to is another HNT performing server, it
	would have provided its relay's public address and ports and the		would have provided its relay's public address and ports, and the
	early stream would find its target.		early stream would find its target.
	Although many SBCs only support UDP-based media latching, and in		Although many SBCs only support UDP-based media latching (in
	particular RTP/RTCP, many SBCs support TCP-based media latching as		particular, RTP/RTCP), many SBCs support TCP-based media latching as
	well. TCP-based latching is more complicated, and involves forcing		well. TCP-based latching is more complicated; it involves forcing
	the UA behind the NAT to be the TCP client and sending the initial		the UA behind the NAT to be the TCP client and sending the initial
	SYN-flagged TCP packet to the SBC (i.e., be the 'active' mode side of		SYN-flagged TCP packet to the SBC (i.e., be the 'active' mode side of
	a TCP-based media session). If both UAs of a TCP-based media session		a TCP-based media session). If both UAs of a TCP-based media session
	are behind NATs, then SBCs typically force both UAs to be the TCP		are behind NATs, then SBCs typically force both UAs to be the TCP
	clients, and the SBC splices the TCP connections together. TCP		clients, and the SBC splices the TCP connections together. TCP
	splicing is a well-known technique, as described in [tcp-splicing].		splicing is a well-known technique, as described in [TCP-SPLICING].
	HNT and latching in particular are generally found to be working		HNT and latching, in particular, are generally found to work
	reliably but they do have obvious caveats. The first one usually		reliably, but they do have obvious caveats. The first one usually
	raised by IETF participants is that UAs are not aware of it		raised by IETF participants is that UAs are not aware of it
	occurring. This makes it impossible for the mechanism to be used		occurring. This makes it impossible for the mechanism to be used
	with protocols such as ICE that try various traversal techniques in		with protocols such as ICE that try various traversal techniques in
	an effort to choose the one that best suits a particular situation.		an effort to choose the one that best suits a particular situation.
	Overwriting address information in offers and answers may actually		Overwriting address information in offers and answers may actually
	completely prevent UAs from using ICE because of the ice-mismatch		completely prevent UAs from using ICE because of the ice-mismatch
	rules described in [RFC5245]		rules described in [RFC5245].
	The second issue raised by IETF participants is that it causes media		The second issue raised by IETF participants is that it causes media
	to go through a relay instead of directly over the IP-routed path		to go through a relay instead of directly over the IP-routed path
	between the two participating UAs. While this adds obvious drawbacks		between the two participating UAs. While this adds obvious drawbacks
	such as reduced scalability and often increased latency, it is also		such as reduced scalability and increased latency, it is also
	considered a benefit by SBC administrators: if a customer pays for		considered a benefit by SBC administrators: if a customer pays for
	"phone" service, for example, the media is what is truly being paid		"phone" service, for example, the media is what is truly being paid
	for, and the administrators usually like to be able to detect that		for, and the administrators usually like to be able to detect that
	media is flowing correctly, evaluate its quality, know if and why it		the media is flowing correctly, evaluate its quality, know if and why
	failed, etc. Also in some cases routing media through operator		it failed, etc. Also, in some cases, routing media through operator
	controlled relays may route media over paths explicitly optimized for		controlled relays may route media over paths explicitly optimized for
	media and hence offer better performance than regular Internet		media and hence offer better performance than regular Internet
	routing.		routing.
	5. Security Considerations		5. Security Considerations
	A common concern is that an SBC (or an XMPP server, all security		A common concern is that an SBC (or an XMPP server -- all security
	considerations apply to both) that implements HNT may latch to		considerations apply to both) that implements HNT may latch to
	incorrect and possibly malicious sources. The ICE [RFC5245] protocol		incorrect and possibly malicious sources. The ICE [RFC5245]
	for example, provides authentication tokens (conveyed in the ice-		protocol, for example, provides authentication tokens (conveyed in
	ufrag and ice-pwd attributes) that allow the identity of a peer to be		the ice-ufrag and ice-pwd attributes) that allow the identity of a
	confirmed before engaging in media exchange with her. Without such		peer to be confirmed before engaging in media exchange with her.
	authentication, a malicious source could, for example, attempt a		Without such authentication, a malicious source could attempt a
	resource exhaustion attack by flooding all possible media-latching		resource exhaustion attack by flooding all possible media-latching
	UDP ports on the SBC in order to prevent calls from succeeding. SBCs		UDP ports on the SBC in order to prevent calls from succeeding. SBCs
	have various mechanisms to prevent this from happening, or alert an		have various mechanisms to prevent this from happening or to alert an
	administrator when it does. Still, a sufficiently sophisticated		administrator when it does. Still, a sufficiently sophisticated
	attacker may be able to bypass them for some time. The most common		attacker may be able to bypass them for some time. The most common
	example is typically referred to as "restricted-latching", whereby		example is typically referred to as "restricted-latching", whereby
	the SBC will not latch to any packets from a source public IP address		the SBC will not latch to any packets from a source public IP address
	other than the one the SIP UA uses for SIP signaling. This way the		other than the one the SIP UA uses for SIP signaling. This way, the
	SBC simply ignores and does not latch onto packets coming from the		SBC simply ignores and does not latch onto packets coming from the
	attacker. In some cases the limitation may be loosened to allow		attacker. In some cases, the limitation may be loosened to allow
	media from a range of IP addresses belonging to the same network in		media from a range of IP addresses belonging to the same network in
	order to allow for use cases such as decomposed UAs and various forms		order to allow for use cases such as decomposed UAs and various forms
	of third party call control. However, since relaxing the		of third-party call control. However, since relaxing the
	restrictions in such a way may provide attackers with a larger attack		restrictions in such a way may provide attackers with a larger attack
	surface, such configurations are generally performed only on a case-		surface, such configurations are generally performed only on a case-
	by-case basis so that the specifics of individual deployments would		by-case basis so that the specifics of individual deployments can be
	be taken into account.		taken into account.
	All of the above problems would still arise if the attacker knows the		All of the above problems would still arise if the attacker knows the
	public source IP of the UA that is actually making the call. This		public source IP of the UA that is actually making the call. This
	would allow them to still flood all of the SBC's public IP addresses		would allow attackers to still flood all of the SBC's public IP
	and ports with packets spoofing that SIP UA's public source IP		addresses and ports with packets spoofing that SIP UA's public source
	address. However, this would only impact media from that IP (or		IP address. However, this would only impact media from that IP (or
	range of IP addresses) rather than all calls that the SBC is		range of IP addresses) rather than all calls that the SBC is
	servicing.		servicing.
	A malicious source could send media packets to an SBC media-latching		A malicious source could send media packets to an SBC media-latching
	UDP port in the hopes of being latched-to for the purpose of		UDP port in the hopes of being latched to for the purpose of
	receiving media for a given SIP session. SBCs have various		receiving media for a given SIP session. SBCs have various
	mechanisms to prevent this as well. Restricted latching for example		mechanisms to prevent this as well. Restricted latching, for
	would also help in this case since the attacker can't make the SBC		example, would also help in this case because the attacker can't make
	send media packets back to themselves since the SBC will not latch		the SBC send media packets back to themselves since the SBC will not
	onto the attacker's media packets, not having seen the corresponding		latch onto the attacker's media packets, not having seen the
	signaling packets first. There could still be an issue if the		corresponding signaling packets first. There could still be an issue
	attacker happens to be either (1) in the IP routing path and thus can		if the attacker happens to be either (1) in the IP routing path where
	spoof the same IP as the real UA and get the media coming back, in		it can thus spoof the same IP as the real UA and get the media coming
	which case the attacker hardly needs to attack at all to begin with,		back, in which case the attacker hardly needs to attack at all to
	or (2) the attacker is behind the same NAT as the legitimate SIP UA,		begin with, or (2) behind the same NAT as the legitimate SIP UA, in
	in which case the attacker's packets will be latched-to by the SBC		which case the attacker's packets will be latched to by the SBC and
	and the SBC will send media back to the attacker. In this latter		the SBC will send media back to the attacker. In the latter case,
	case, which may be of particular concern with Carrier-Grade NATs, the		which may be of particular concern with Carrier-Grade NATs, the
	legitimate SIP UA will likely end the call anyway when a human user		legitimate SIP UA will likely end the call anyway when a human user
	who does not hear anything hangs up. In the case of a non-human call		who does not hear anything hangs up. In the case of a non-human call
	participant, such as an answering machine, this may not happen		participant, such as an answering machine, this may not happen
	(although many such automated UAs would also hang up when they do not		(although many such automated UAs would also hang up when they do not
	receive any media). The attacker could also redirect all media to		receive any media). The attacker could also redirect all media to
	the real SIP UA after receiving it, in which case the attack would		the real SIP UA after receiving it, in which case the attack would
	likely remain undetected and succeed. Again, this would be of		likely remain undetected and succeed. Again, this would be of
	particular concern with larger scale NATs serving many different		particular concern with larger-scale NATs serving many different
	endpoints such as Carrier-Grade NATs. The larger the number of		endpoints, such as Carrier-Grade NATs. The larger the number of
	devices fronted by a NAT is, the more use cases would vary and the		devices fronted by a NAT is, the more use cases would vary, and the
	more the number of possible attack vectors would grow.		more the number of possible attack vectors would grow.
	Naturally, SRTP [RFC3711] would help mitigate such threats and, if		Naturally, Secure RTP (SRTP) [RFC3711] would help mitigate such
	used with the appropriate key negotiation mechanisms, would protect		threats and, if used with the appropriate key negotiation mechanisms,
	the media from monitoring while in transit. It should therefore be		would protect the media from monitoring while in transit. It should
	used independently of HNT. [RFC3261] Section 26 provides an overview		therefore be used independently of HNT. Section 26 of [RFC3261]
	of additional threats and solutions on monitoring and session		provides an overview of additional threats and solutions on
	interception.		monitoring and session interception.
	With SRTP, if the SBC that performs the latching is actually		With SRTP, if the SBC that performs the latching is actually
	participating in the SRTP key exchange, then it would simply refuse		participating in the SRTP key exchange, then it would simply refuse
	to latch onto a source unless it can authenticate it. Failing to		to latch onto a source unless it can authenticate it. Failing to
	implement and use SRTP would represent a serious threat to users		implement and use SRTP would represent a serious threat to users
	connecting from behind Carrier-Grade NATs [RFC6888] and is considered		connecting from behind Carrier-Grade NATs [RFC6888] and is considered
	a harmful practice.		a harmful practice.
	For SIP clients, HNT is usually transparent in the sense that the SIP		For SIP clients, HNT is usually transparent in the sense that the SIP
	UA does not know it occurs. In certain cases it may be detectable,		UA does not know it occurs. In certain cases, it may be detectable,
	such as when ICE is supported by the SIP UA and the SBC modifies the		such as when ICE is supported by the SIP UA and the SBC modifies the
	default connection address and media port numbers in SDP, thereby		default connection address and media port numbers in SDP, thereby
	disabling ICE due to the mismatch condition. Even in that case,		disabling ICE due to the mismatch condition. Even in that case,
	however, the SIP UA only knows a middle box is relaying media, but		however, the SIP UA only knows that a middlebox is relaying media but
	not necessarily that it is performing latching/HNT.		not necessarily that it is performing latching/HNT.
	In order to perform HNT, the SBC has to modify SDP to and from the		In order to perform HNT, the SBC has to modify SDP to and from the
	SIP UA behind a NAT, and thus the SIP UA cannot use S/MIME [RFC5751],		SIP UA behind a NAT; thus, the SIP UA cannot use S/MIME [RFC5751],
	and it cannot sign a sending request or verify a received request		and it cannot sign a sending request, or verify a received request
	using [RFC4474] unless the SBC re-signs the request. However,		using the SIP Identity mechanism [RFC4474] unless the SBC re-signs
	neither S/MIME or [RFC4474] are widely deployed, thus not being able		the request. However, neither S/MIME nor SIP Identity are widely
	to sign/verify requests appear not to be a concern at this time.		deployed; thus, not being able to sign/verify requests appears not to
			be a concern at this time.
	From a privacy perspective, media relaying is sometimes seen as a way		From a privacy perspective, media relaying is sometimes seen as a way
	of protecting one's IP address and not revealing it to the remote		of protecting one's IP address and not revealing it to the remote
	party. That kind of IP address masking is often perceived as		party. That kind of IP address masking is often perceived as
	important. However, this is no longer an exclusive advantage of HNT		important. However, this is no longer an exclusive advantage of HNT
	since it can also be accomplished by client-controlled relaying		since it can also be accomplished by client-controlled relaying
	mechanisms such as TURN [RFC5766], if the client explicitly wishes to		mechanisms such as TURN [RFC5766] if the client explicitly wishes to
	do so.		do so.
	6. IANA Considerations		6. Acknowledgements
	This document has no actions for IANA.
	Note to the RFC-Editor: please remove this section prior to
	publication as an RFC.
	7. Acknowledgements
	The authors would like to thank Flemming Andreasen, Miguel A.		The authors would like to thank Flemming Andreasen, Miguel A.
	Garcia, Alissa Cooper, Vijay K. Gurbani, Ari Keranen and Paul		Garcia, Alissa Cooper, Vijay K. Gurbani, Ari Keranen, and Paul
	Kyzivat for their reviews and suggestions on improving this document.		Kyzivat for their reviews and suggestions on improving this document.
	8. References		7. References
	8.1. Key References		7.1. Normative References
	[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,		[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
	A., Peterson, J., Sparks, R., Handley, M., and E.		A., Peterson, J., Sparks, R., Handley, M., and E.
	Schooler, "SIP: Session Initiation Protocol", RFC 3261,		Schooler, "SIP: Session Initiation Protocol", RFC 3261,
	June 2002.		June 2002.
	[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model		[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
	with Session Description Protocol (SDP)", RFC 3264, June		with Session Description Protocol (SDP)", RFC 3264, June
	2002.		2002.
	skipping to change at page 14, line 30		skipping to change at page 14, line 39
	[RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen,		[RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen,
	A., and M. Bhatia, "Requirements from Session Initiation		A., and M. Bhatia, "Requirements from Session Initiation
	Protocol (SIP) Session Border Control (SBC) Deployments",		Protocol (SIP) Session Border Control (SBC) Deployments",
	RFC 5853, April 2010.		RFC 5853, April 2010.
	[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence		[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
	Protocol (XMPP): Core", RFC 6120, March 2011.		Protocol (XMPP): Core", RFC 6120, March 2011.
	[XEP-0177]		[XEP-0177]
	Beda, J., Saint-Andre, P., Hildebrand, J., and S. Egan,		Beda, J., Saint-Andre, P., Hildebrand, J., and S. Egan,
	"XEP-0177: Jingle Raw UDP Transport Method", XEP XEP-0177,		"XEP-0177: Jingle Raw UDP Transport Method", XSF XEP 0177,
	December 2009.		December 2009.
	8.2. Additional References		7.2. Informative References
	[H.323] International Telecommunication Union, "Packet Based		[H.323] International Telecommunication Union, "Packet-based
	Multimedia Communication Systems", Recommendation H.323,		multimedia communication systems", ITU-T Recommendation
	July 2003.		H.323, December 2009.
	[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.
	[RFC3435] Andreasen, F. and B. Foster, "Media Gateway Control		[RFC3435] Andreasen, F. and B. Foster, "Media Gateway Control
	Protocol (MGCP) Version 1.0", RFC 3435, January 2003.		Protocol (MGCP) Version 1.0", RFC 3435, January 2003.
	[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)
	skipping to change at page 15, line 33		skipping to change at page 15, line 41
	Specification", RFC 5751, January 2010.		Specification", RFC 5751, January 2010.
	[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using		[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
	Relays around NAT (TURN): Relay Extensions to Session		Relays around NAT (TURN): Relay Extensions to Session
	Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.		Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
	[RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A.,		[RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A.,
	and H. Ashida, "Common Requirements for Carrier-Grade NATs		and H. Ashida, "Common Requirements for Carrier-Grade NATs
	(CGNs)", BCP 127, RFC 6888, April 2013.		(CGNs)", BCP 127, RFC 6888, April 2013.
	[tcp-splicing]		[TCP-SPLICING]
	Maltz, D. and P. Bhagwat, "TCP Splice for application		Maltz, D. and P. Bhagwat, "TCP Splice for application
	layer proxy performance", Journal of High Speed Networks		layer proxy performance", Journal of High Speed Networks
	vol. 8, no. 3, 1999, pp. 235-240, March 1999.		Vol. 8, No. 3, 1999, pp. 225-240, March 1999.
	Authors' Addresses		Authors' Addresses
	Emil Ivov		Emil Ivov
	Jitsi		Jitsi
	Strasbourg 67000		Strasbourg 67000
	France		France
	Email: emcho@jitsi.org		EMail: emcho@jitsi.org
	Hadriel Kaplan		Hadriel Kaplan
	Oracle		Oracle
	100 Crosby Drive		100 Crosby Drive
	Bedford, MA 01730		Bedford, MA 01730
	USA		USA
	Email: hadriel.kaplan@oracle.com		EMail: hadrielk@yahoo.com
	Dan Wing		Dan Wing
	Cisco Systems, Inc.		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
End of changes. 84 change blocks.
	201 lines changed or deleted		195 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/