draft-ietf-mmusic-latching-05.txt		draft-ietf-mmusic-latching-06.txt
	Network Working Group E. Ivov		Network Working Group E. Ivov
	Internet-Draft Jitsi		Internet-Draft Jitsi
	Intended status: Informational H. Kaplan		Intended status: Informational H. Kaplan
	Expires: November 7, 2014 Oracle		Expires: November 30, 2014 Oracle
	D. Wing		D. Wing
	Cisco		Cisco
	May 6, 2014		May 29, 2014
	Latching: Hosted NAT Traversal (HNT) for Media in Real-Time		Latching: Hosted NAT Traversal (HNT) for Media in Real-Time
	Communication		Communication
	draft-ietf-mmusic-latching-05		draft-ietf-mmusic-latching-06
	Abstract		Abstract
	This document describes behavior of signalling intermediaries in		This document describes behavior of signalling intermediaries in
	Real-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 IETF community, as well as 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 components of the HNT components, has a
	number of security issues covered here. Because of those, and unless		number of security issues covered here. Because of those, and unless
	all security considerations explained here are taken into account and		all security considerations explained here are taken into account and
	solved, the IETF advises against use of this mechanism over the		solved, the IETF advises against use of latching mechanism over the
	Internet and recommends other solutions such as the Interactive		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 Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on November 7, 2014.		This Internet-Draft will expire on November 30, 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 30		skipping to change at page 2, line 30
	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, Latching . . . . . . . . . . . . . . . . . . 6
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 11		5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
	8. Informative References . . . . . . . . . . . . . . . . . . . 13		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
			8.1. Key References . . . . . . . . . . . . . . . . . . . . . 13
			8.2. Additional References . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15		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.
	Protocols like SIP [RFC3261], and others that try to use a more		The Session Initiation Protocol (SIP) [RFC3261], and others that try
	direct path for media than with signalling, are difficult to use		to use a more direct path for media than with signalling, are
	across NATs. They use IP addresses and transport port numbers		difficult to use across NATs. These protocols use IP addresses and
	encoded in bodies such as SDP [RFC4566] as well as, in the case of		transport port numbers encoded in bodies such as the Session
	SIP, various header fields. Such addresses and ports are unusable		Description Protocol (SDP) [RFC4566] and, in the case of SIP, various
	unless all peers in a session are located behind the same NAT.		header fields. Such addresses and ports are unusable unless all
			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) and 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 (HNT),
	although some manufacturers sometimes use other names such as "Far-		although a number of manufacturers sometimes use other names such as
	end NAT Traversal" or "NAT assist" instead. The systems which		"Far-end NAT Traversal" or "NAT assist" instead. The systems which
	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		As of this document's creation time, a vast majority of SIP domains
	use HNT to enable SIP devices to communicate across NATs, despite the		use HNT to enable SIP devices to communicate across NATs, despite the
	publication of ICE. There are many reasons for this, but those		publication of ICE. There are many reasons for this, but those
	reasons are not relevant to this document's purpose and will not be		reasons are not relevant to this document's purpose and will not be
	discussed. It is however worth pointing out that the current		discussed. It is however worth pointing out that the current
	deployment levels of HNT and NATs themselves make an exclusive		deployment levels of HNT and NATs themselves make an exclusive
	adoption of ICE highly unlikely in the foreseeable future.		adoption of ICE 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 not novel to experts, publication in an IETF document		used in HNT are well known in the community, publication in an IETF
	is useful as a means of providing common terminology and a reference		document is useful as a means of providing common terminology and a
	for related documents.		reference for related documents.
	In no way does this document try 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 [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's many features in terms of controlling message routing provide
	The SIP signaling-layer component of HNT is typically more		for various ways for addressing NAT traversal. As a result, the HNT
	implementation-specific and deployment-specific than the SDP and		component for SIP is typically more implementation-specific and
	media components. For the purposes of this document it is hence		deployment-specific than the SDP and media components. For the
	assumed that signaling intermediaries handle traffic in a way that		purposes of this document it is hence assumed that signaling
	allows protocols such as SIP to function correctly across the NATs.		intermediaries handle traffic in a way that allows protocols such as
			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 is going to focus primarily on use of HNT
	for SIP. However, the mechanisms described here are relatively		for SIP. However, the mechanisms described here are relatively
	generic and are often used with other protocols, such as XMPP		generic and are often used with other protocols, such as XMPP
	[RFC6120], Media Gateway Control Protocol (MGCP) [RFC3435], H.248/		[RFC6120], Media Gateway Control Protocol (MGCP) [RFC3435], H.248/
	MEGACO [RFC5125], and H.323 [H.323].		MEGACO [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
	skipping to change at page 5, line 21		skipping to change at page 5, line 21
	+-----+ +-----+		+-----+ +-----+
	|NAT-A| |NAT-B|		|NAT-A| |NAT-B|
	+-----+ +-----+		+-----+ +-----+
	/ \		/ \
	/ Private Net Private Net \		/ Private Net Private Net \
	/ \		/ \
	+------+ +------+		+------+ +------+
	| UA-A | | UA-B |		| UA-A | | UA-B |
	+------+ +------+		+------+ +------+
	Figure 1: Logical Deployment Paths		Figure 1: Common Deployment Scenarios
	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.
	Quite often, the IP address of the newly introduced media relay may		While this is not necessary for HNT to work, quite often, the IP
	be the same as that of the signaling intermediary (e.g. the SIP SBC)		address of that media relay may be the same as that of the signaling
	or it may be a completely different one. In almost all cases		intermediary (i.e. the SIP SBC and media relay are co-located on the
	however, the new address would belong to the same IP address family		same host). Also, in almost all cases, the address of the media
	as the one used for signaling, since it is known to work for that UA.		relay would belong to the same IP address family as the one used for
			signaling, as it is known to work for that UA.
	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 call scenario.
	For example if a SIP SDP Offer originally came from a UA behind a		For example if a SIP SDP Offer originally came from a UA behind a
	NAT, the SIP SBC cannot send media to it until an SDP Answer is given		NAT, the SIP SBC cannot send media to it until an SDP Answer is given
	to the UA and latching (Section 4) occurs. Another example is when a		to the UA and latching (Section 4) occurs. Another example is when a
	SIP SBC sends an SDP Offer in a SIP INVITE to a residential		SIP SBC sends an SDP Offer in a SIP INVITE to a residential
	customer's UA and receives back SDP in a 18x response, the SBC may		customer's UA and receives back SDP in a 18x response, the SBC may
	decide not to send media to that customer UA until a SIP 200 response		decide, for policy reasons, not to send media to that customer UA
	for policy reasons, to prevent toll-fraud.		until a SIP 200 response has been received (e.g., to prevent toll-
			fraud).
	4. Media Behavior, Latching		4. Media Behavior, Latching
	An UA behind a NAT streams media from a private address:port set that		An UA that is behind a NAT would stream media from an address and a
	once packets cross the NAT, will be mapped to a public set. The UA		port number (an address:port couple) that are only valid in its local
	however is not typically aware of the public mapping and would often		network. Once packets cross the NAT, that address:port couple will
	advertise the private address:port couple in signaling. This way,		be mapped to a public one. The UA however is not typically aware of
	when the signalling intermediary performing HNT receives private		the public mapping and would often advertise the private address:port
	addressing information from from a NATed UA it will not know what		couple in signaling. This way, while a session is still being setup,
	address/ports to send media to. Therefore media relays used in HNT		the signalling intermediary is not yet aware what addresses and ports
	would often use a mechanism called "latching".		the caller and the callee would end up using for media traffic: it
			has only seen them advertise the private addresses they use behind
			their respective NATs. Therefore media relays used in HNT would
			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:ports are used to		"symmetric-latching" is when the latched address:port couples are
	send media back to the UA. Today most people talk about them both as		used to send media back to the UA. Today most people talk about them
	"latching", and thus this document does as well.		both as "latching", and thus this document does as well.
	The latching mechanism works as follows:		The latching mechanism works as follows:
	1. After receiving an offer from a NATed UA, a signaling		1. After receiving an offer from a NATed UA, a signaling
	intermediary located on the public Internet would allocate a set		intermediary located on the public Internet would allocate a set
	of IP address:ports on a media relay. The set would then be		of IP address:port couples on a media relay. The set would then
	advertised to the remote party so that it would use those media		be advertised to the remote party so that it would use those
	relay address:ports for all media it wished to send toward the		media relay address:port couples for all media it wished to send
	UA.		toward the UA.
	2. Next, after receiving an answer to its offer, the signaling		2. Next, after receiving an answer to its offer, the signaling
	server would allocate a second address:port set on the media		server would allocate a second address:port set on the media
	relay. It would advertise this second set in the answer to the		relay. It would advertise this second set in the answer to the
	UA. The UA will then send to this media relay address:port.		UA. The UA will then send 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, and uses their source address and port as a destination		ports, and uses their source address and port as a destination
	for all media bound in the opposite direction. In other words,		for all media bound in the opposite direction. In other words,
	it "latches" or locks on these source address:port set.		it "latches" or locks on these source address:port set.
	skipping to change at page 7, line 11		skipping to change at page 7, line 13
	traffic would belong to the public interface of the NAT in front		traffic would belong to the public interface of the NAT in front
	of the UA and anything that the relay sends there would find its		of the UA and anything that the relay sends there would find its
	way to it.		way to it.
	5. Similarly the source of the stream originating at the remote		5. Similarly the source of the stream originating at the remote
	party would be latched upon and used for media going in that		party 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 gone		exchanged (e.g., in a subsequent call or after a SIP peer has
	on and off hold). The reasons for such restrictions are mostly		gone on and off hold). The reasons for such restrictions are
	related to security: once a session has started a user agent is		mostly related to security: once a session has started a user
	not expected to suddenly start streaming from a different port		agent is not expected to suddenly start streaming from a
	without sending a new offer first. A change may indicate an		different port without sending a new offer first. A change may
	attempt to hijack the session. In some cases however, a port		indicate an attempt to hijack the session. In some cases
	change may be caused by a re-mapping in a NAT device standing		however, a port change may be caused by a re-mapping in a NAT
	between the SBC and the UA. More advanced SBCs may therefore		device standing between the SBC and the UA. More advanced SBCs
	allow some level of flexibility on the re-latching restrictions		may therefore allow some level of flexibility on the re-latching
	while carefully considering the potential security implications		restrictions while carefully considering the potential security
	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		User Agent Client (UAC) network and 198.51.100/24 facing towards the
	User Agent Server (UAS) network.		User Agent Server (UAS) network.
	192.0.2.1 198.51.100.33		192.0.2.1 198.51.100.33
	Alice NAT 203.0.113.0/24-SBC-198.51.100.0/24 Bob		Alice NAT 203.0.113.0/24-SBC-198.51.100.0/24 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 UAS) |		| | for inbound RTP from Bob) |
	| | | |		| | | |
	3. | | |---INVITE+offer---->|		3. | | |-----INVITE+offer----->|
	| | |c=198.51.100.2:22007|		| | | c=198.51.100.2:22007 |
	| | | |		| | | |
	4. | | |<---180 Ringing-----|		4. | | |<------180 Ringing-----|
	| | | |		| | | |
	| | | |		| | | |
	5. |<------180 Ringing----------------| |		5. |<------180 Ringing----------------| |
	| | | |		| | | |
	6. | | |<---200+answer------|		6. | | |<------200+answer------|
	| | | |		| | | |
	7. | | (SBC allocates 203.0.113.4:36010 |		7. | | (SBC allocates 203.0.113.4:36010 |
	| | for inbound RTP from UAC) |		| | for inbound RTP from Alice) |
	| | | |		| | | |
	8. |<-200+answer,c=203.0.113.4:36010--| c=198.51.100.33 |		8. |<-200+answer,c=203.0.113.4:36010--| c=198.51.100.33 |
	| | | |		| | | |
	9. |------------ACK------------------>| |		9. |------------ACK------------------>| |
	10. | | |-------ACK--------->|		10. | | |----------ACK--------->|
	| | | |		| | | |
	11. |=====RTP,dest=203.0.113.4:36010==>| |		11. |=====RTP,dest=203.0.113.4:36010==>| |
	| | | |		| | | |
	12. | | (SBC latches to |		12. | | (SBC latches to |
	| | source IP address and |		| | source IP address and |
	| | port seen at (10)) |		| | port seen at (11)) |
	| | | |		| | | |
	13. | | |<====== RTP ========|		13. | | |<======= RTP ==========|
	| | | |		| | |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
	XMPP Client1 NAT XMPP Server XMPP Client2		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 |
	| | for inbound RTP from Client2) |		| | for inbound RTP from Juliet) |
	| | | |		| | | |
	4. | | |--session-initiate->|		4. | | |--session-initiate-->|
	| | cand=203.0.113.9:2200|		| | |cand=203.0.113.9:2200|
	| | | |		| | | |
	5. | | |<-------ack---------|		5. | | |<--------ack---------|
	| | | |		| | | |
	| | | |		| | | |
	6. | | |<--session-accept---|		6. | | |<---session-accept---|
	| | | cand=198.51.100.8 |		| | | cand=198.51.100.8 |
	| | | |		| | | |
	7. | | |--------ack-------> |		7. | | |---------ack-------->|
	| | | |		| | | |
	8. | | (Server allocates 203.0.113.9:3300 |		8. | | (Server allocates 203.0.113.9:3300 |
	| | for inbound RTP from Client1) |		| | for inbound RTP from Romeo) |
	| | | |		| | | |
	9. |<-session-accept cand=203.0.113.9:3300-| |		9. |<-session-accept cand=203.0.113.9:3300-| |
	| | | |		| | | |
	10. |-----------------ack------------------>| |		10. |-----------------ack------------------>| |
	| | | |		| | | |
	| | | |		| | | |
	11. |======RTP, dest=203.0.113.9:3300======>| |		11. |======RTP, dest=203.0.113.9:3300======>| |
	| | | |		| | | |
	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 (10)) |		| | src port seen at (11)) |
	| | | |		| | | |
	13. | | |<====== RTP ========|		13. | | |<======= RTP ========|
	| | | |		| | |dest=203.0.113.9:2200|
	14. |<======RTP, to latched address=========| |		14. |<======RTP, to latched address=========| |
	| | | |		| | | |
	Figure 3: Latching by a SIP SBC 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 an exclusively "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
	skipping to change at page 10, line 35		skipping to change at page 10, line 35
	SDP to the UA. However SBCs providing HNT would always be configured		SDP to the UA. However SBCs providing HNT would always be configured
	to avoid this.		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 signalling intermediaries that		a session are connected to different signalling 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
	signalling servers could end up each waiting upon the other to		signalling 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 sets provided in the offer		to start streaming toward the address:port sets provided in the
	/answer even before receiving any inbound traffic. If the entity		offer/answer even before receiving any inbound traffic. If the
	they are streaming to is another HNT performing server it would have		entity they are streaming to is another HNT performing server it
	provided its relay's public address and ports and the early stream		would have provided its relay's public address and ports and the
	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, and 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, and 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, and 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 be working
	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]
	skipping to change at page 11, line 30		skipping to change at page 11, line 30
	"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		media is flowing correctly, evaluate its quality, know if and why it
	failed, etc. Also in some cases routing media through operator		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 that implements HNT may latch to		A common concern is that an SBC (or an XMPP server, all security
	incorrect and possibly malicious sources. A malicious source could,		considerations apply to both) that implements HNT may latch to
	for example, attempt a resource exhaustion attack by flooding all		incorrect and possibly malicious sources. The ICE [RFC5245] protocol
	possible media-latching UDP ports on the SBC in order to prevent		for example, provides authentication tokens (conveyed in the ice-
	calls from succeeding. SBCs have various mechanisms to prevent this		ufrag and ice-pwd attributes) that allow confirming the identity of a
	from happening, or alert an administrator when it does. Still, a		peer before engaging in media exchange with her. Without such
	sufficiently sophisticated attacker may be able to bypass them for		authentication, a malicious source could, for example, attempt a
	some time. The most common example is typically referred to as		resource exhaustion attack by flooding all possible media-latching
	"restricted-latching", whereby the SBC will not latch to any packets		UDP ports on the SBC in order to prevent calls from succeeding. SBCs
	from a source public IP address other than the one the SIP UA uses		have various mechanisms to prevent this from happening, or alert an
	for SIP signaling. This way the SBC simply ignores and does not		administrator when it does. Still, a sufficiently sophisticated
	latch onto packets coming from the attacker. In some cases the		attacker may be able to bypass them for some time. The most common
	limitation may be loosened to allow media from a range of IP		example is typically referred to as "restricted-latching", whereby
	addresses belonging to the same network in order to allow for use		the SBC will not latch to any packets from a source public IP address
	cases such as decomposed UAs and various forms of third party call		other than the one the SIP UA uses for SIP signaling. This way the
	control. However, since relaxing the restrictions in such a way may		SBC simply ignores and does not latch onto packets coming from the
	widen the gap for potential attackers, such configurations are		attacker. In some cases the limitation may be loosened to allow
	generally performed only on a case-by-case basis so that the		media from a range of IP addresses belonging to the same network in
	specifics of individual deployments would be taken into account.		order to allow for use cases such as decomposed UAs and various forms
			of third party call control. However, since relaxing the
			restrictions in such a way may widen the gap for potential attackers,
			such configurations are generally performed only on a case-by-case
			basis so that the specifics of individual deployments would be taken
			into account.
	In all of the above problems would still arise if the attacker knows		All of the above problems would still arise if the attacker knows the
	the public source IP of the UA that is actually making the call.		public source IP of the UA that is actually making the call. This
	This would allow them to still flood all of the SBC's public IP		would allow them to still flood all of the SBC's public IP addresses
	addresses and ports with packets spoofing that SIP UA's public source		and ports with packets spoofing that SIP UA's public source IP
	IP address. However, this would only disturb media from that IP (or		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 example
	would also help in this case since the attacker can't make the SBC		would also help in this case since the attacker can't make the SBC
	send media packets back to themselves since the SBC will not latch		send media packets back to themselves since the SBC will not latch
	onto the attacker's packets. There could still be an issue if the		onto the attacker's media packets, not having seen the corresponding
			signaling packets first. There could still be an issue if the
	attacker happens to be either (1) in the IP routing path and thus can		attacker happens to be either (1) in the IP routing path and thus can
	spoof the same IP as the real UA and get the media coming back, in		spoof the same IP as the real UA and get the media coming back, in
	which case the attacker hardly needs to attack at all to begin with,		which case the attacker hardly needs to attack at all to begin with,
	or (2) the attacker is behind the same NAT as the legitimate SIP UA,		or (2) the attacker is behind the same NAT as the legitimate SIP UA,
	in which case the attacker's packets will be latched-to by the SBC		in which case the attacker's packets will be latched-to by the SBC
	and the SBC will send media back to the attacker. In this latter		and the SBC will send media back to the attacker. In this latter
	case, which may be of particular concern with Carrier-Grade NATs, the		case, which may be of particular concern with Carrier-Grade NATs, the
	legitimate SIP UA will end the call anyway, because a human user		legitimate SIP UA will likely end the call anyway when a human user
	would not hear anything and will hang up. In the case of a non-human		who does not hear anything hangs up. In the case of a non-human call
	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 should		Naturally, SRTP [RFC3711] would help mitigate such threats and should
	be used independently of HNT. For example, in cases where end-to-end		be used independently of HNT. For example, in cases where end-to-end
	encryption is used it would still be possible for an attacker to		encryption is used it would still be possible for an attacker to
	hijack a session despite the use of SRTP and perform a denial of		hijack a session despite the use of SRTP and perform a denial of
	service attack. However, media integrity would not be compromised.		service attack. However, media integrity would not be compromised.
	Additionally, if the SBC that performs the latching is actually		Additionally, 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 this would represent a serious threat to users connecting		implement and use SRTP would represent a serious threat to users
	from behind Carrier-Grade NATs [RFC6888] and is considered a harmful		connecting from behind Carrier-Grade NATs [RFC6888] and is considered
	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 a middle box 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, and 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 it is		using [RFC4474] unless the SBC re-signs the request. However,
	sometimes argued that, neither S/MIME nor [RFC4474] are widely		neither S/MIME or [RFC4474] are widely deployed, thus not being able
	deployed and that this may not be a real concern.		to sign/verify requests appear 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. IANA Considerations
	This document has no actions for IANA.		This document has no actions for IANA.
	Note to the RFC-Editor: please remove this section prior to		Note to the RFC-Editor: please remove this section prior to
	publication as an RFC.		publication as an RFC.
	7. Acknowledgements		7. Acknowledgements
	The authors would like to thank Flemming Andreasen, Miguel A.		The authors would like to thank Flemming Andreasen, Miguel A.
	Garcia, Ari Keraenen and Paul Kyzivat for their reviews and		Garcia, Ari Keranen and Paul Kyzivat for their reviews and
	suggestions on improving this document.		suggestions on improving this document.
	8. Informative References		8. References
	[H.323] International Telecommunication Union, "Packet Based		8.1. Key References
	Multimedia Communication Systems", Recommendation H.323,
	July 2003.
	[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.
			[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
			Norrman, "The Secure Real-time Transport Protocol (SRTP)",
			RFC 3711, March 2004.
			[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
			Description Protocol", RFC 4566, July 2006.
			[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
			(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
			RFC 4787, January 2007.
			[RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen,
			A., and M. Bhatia, "Requirements from Session Initiation
			Protocol (SIP) Session Border Control (SBC) Deployments",
			RFC 5853, April 2010.
			[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
			Protocol (XMPP): Core", RFC 6120, March 2011.
			[XEP-0177]
			Beda, J., Saint-Andre, P., Hildebrand, J., and S. Egan,
			"XEP-0177: Jingle Raw UDP Transport Method", XEP XEP-0177,
			December 2009.
			8.2. Additional References
			[H.323] International Telecommunication Union, "Packet Based
			Multimedia Communication Systems", Recommendation H.323,
			July 2003.
	[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)
	Through Network Address Translators (NATs)", RFC 3489,		Through Network Address Translators (NATs)", RFC 3489,
	March 2003.		March 2003.
	[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
	Norrman, "The Secure Real-time Transport Protocol (SRTP)",
	RFC 3711, March 2004.
	[RFC4474] Peterson, J. and C. Jennings, "Enhancements for		[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
	Authenticated Identity Management in the Session		Authenticated Identity Management in the Session
	Initiation Protocol (SIP)", RFC 4474, August 2006.		Initiation Protocol (SIP)", RFC 4474, August 2006.
	[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
	Description Protocol", RFC 4566, July 2006.
	[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
	(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
	RFC 4787, January 2007.
	[RFC5125] Taylor, T., "Reclassification of RFC 3525 to Historic",		[RFC5125] Taylor, T., "Reclassification of RFC 3525 to Historic",
	RFC 5125, February 2008.		RFC 5125, February 2008.
	[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment		[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
	(ICE): A Protocol for Network Address Translator (NAT)		(ICE): A Protocol for Network Address Translator (NAT)
	Traversal for Offer/Answer Protocols", RFC 5245, April		Traversal for Offer/Answer Protocols", RFC 5245, April
	2010.		2010.
	[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,		[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
	"Session Traversal Utilities for NAT (STUN)", RFC 5389,		"Session Traversal Utilities for NAT (STUN)", RFC 5389,
	October 2008.		October 2008.
	[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet		[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
	Mail Extensions (S/MIME) Version 3.2 Message		Mail Extensions (S/MIME) Version 3.2 Message
	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.
	[RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen,
	A., and M. Bhatia, "Requirements from Session Initiation
	Protocol (SIP) Session Border Control (SBC) Deployments",
	RFC 5853, April 2010.
	[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
	Protocol (XMPP): Core", RFC 6120, March 2011.
	[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.
	[XEP-0177]
	Beda, J., Saint-Andre, P., Hildebrand, J., and S. Egan,
	"XEP-0177: Jingle Raw UDP Transport Method", XEP XEP-0177,
	December 2009.
	[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. 235-240, March 1999.
	Authors' Addresses		Authors' Addresses
	Emil Ivov		Emil Ivov
	Jitsi		Jitsi
	Strasbourg 67000		Strasbourg 67000
End of changes. 38 change blocks.
	200 lines changed or deleted		219 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/