draft-ietf-mmusic-rtsp-nat-evaluation-15.txt		draft-ietf-mmusic-rtsp-nat-evaluation-16.txt
	Network Working Group M. Westerlund		Network Working Group M. Westerlund
	Internet-Draft Ericsson		Internet-Draft Ericsson
	Intended status: Informational T. Zeng		Intended status: Informational T. Zeng
	Expires: October 22, 2015 April 20, 2015		Expires: November 20, 2015 May 19, 2015
	The Comparison of Different Network Address Translator (NAT) Traversal		The Comparison of Different Network Address Translator (NAT) Traversal
	Techniques for Media Controlled by Real-time Streaming Protocol (RTSP)		Techniques for Media Controlled by Real-time Streaming Protocol (RTSP)
	draft-ietf-mmusic-rtsp-nat-evaluation-15		draft-ietf-mmusic-rtsp-nat-evaluation-16
	Abstract		Abstract
	This document describes several Network Address Translator (NAT)		This document describes several Network Address Translator (NAT)
	traversal techniques that were considered to be used for establishing		traversal techniques that were considered to be used for establishing
	the RTP media flows controlled by the Real-time Streaming Protocol		the RTP media flows controlled by the Real-time Streaming Protocol
	(RTSP). Each technique includes a description of how it would be		(RTSP). Each technique includes a description of how it would be
	used, the security implications of using it and any other deployment		used, the security implications of using it and any other deployment
	considerations it has. There are also discussions on how NAT		considerations it has. There are also discussions on how NAT
	traversal techniques relate to firewalls and how each technique can		traversal techniques relate to firewalls and how each technique can
	skipping to change at page 1, line 40		skipping to change at page 1, line 40
	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 October 22, 2015.		This Internet-Draft will expire on November 20, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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 41		skipping to change at page 2, line 41
	4.2.4. ALG considerations . . . . . . . . . . . . . . . . . 17		4.2.4. ALG considerations . . . . . . . . . . . . . . . . . 17
	4.2.5. Deployment Considerations . . . . . . . . . . . . . . 17		4.2.5. Deployment Considerations . . . . . . . . . . . . . . 17
	4.2.6. Security Considerations . . . . . . . . . . . . . . . 18		4.2.6. Security Considerations . . . . . . . . . . . . . . . 18
	4.3. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 18		4.3. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	4.3.1. Introduction . . . . . . . . . . . . . . . . . . . . 18		4.3.1. Introduction . . . . . . . . . . . . . . . . . . . . 18
	4.3.2. Using ICE in RTSP . . . . . . . . . . . . . . . . . . 19		4.3.2. Using ICE in RTSP . . . . . . . . . . . . . . . . . . 19
	4.3.3. Implementation burden of ICE . . . . . . . . . . . . 21		4.3.3. Implementation burden of ICE . . . . . . . . . . . . 21
	4.3.4. ALG Considerations . . . . . . . . . . . . . . . . . 21		4.3.4. ALG Considerations . . . . . . . . . . . . . . . . . 21
	4.3.5. Deployment Considerations . . . . . . . . . . . . . . 22		4.3.5. Deployment Considerations . . . . . . . . . . . . . . 22
	4.3.6. Security Consideration . . . . . . . . . . . . . . . 22		4.3.6. Security Consideration . . . . . . . . . . . . . . . 22
	4.4. Latching . . . . . . . . . . . . . . . . . . . . . . . . 22		4.4. Latching . . . . . . . . . . . . . . . . . . . . . . . . 23
	4.4.1. Introduction . . . . . . . . . . . . . . . . . . . . 22		4.4.1. Introduction . . . . . . . . . . . . . . . . . . . . 23
	4.4.2. Necessary RTSP extensions . . . . . . . . . . . . . . 23		4.4.2. Necessary RTSP extensions . . . . . . . . . . . . . . 23
	4.4.3. ALG Considerations . . . . . . . . . . . . . . . . . 24		4.4.3. ALG Considerations . . . . . . . . . . . . . . . . . 24
	4.4.4. Deployment Considerations . . . . . . . . . . . . . . 24		4.4.4. Deployment Considerations . . . . . . . . . . . . . . 24
	4.4.5. Security Consideration . . . . . . . . . . . . . . . 25		4.4.5. Security Consideration . . . . . . . . . . . . . . . 25
	4.5. A Variation to Latching . . . . . . . . . . . . . . . . . 26		4.5. A Variation to Latching . . . . . . . . . . . . . . . . . 26
	4.5.1. Introduction . . . . . . . . . . . . . . . . . . . . 26		4.5.1. Introduction . . . . . . . . . . . . . . . . . . . . 27
	4.5.2. Necessary RTSP extensions . . . . . . . . . . . . . . 27		4.5.2. Necessary RTSP extensions . . . . . . . . . . . . . . 27
	4.5.3. ALG Considerations . . . . . . . . . . . . . . . . . 27		4.5.3. ALG Considerations . . . . . . . . . . . . . . . . . 28
	4.5.4. Deployment Considerations . . . . . . . . . . . . . . 27		4.5.4. Deployment Considerations . . . . . . . . . . . . . . 28
	4.5.5. Security Considerations . . . . . . . . . . . . . . . 28		4.5.5. Security Considerations . . . . . . . . . . . . . . . 28
	4.6. Three Way Latching . . . . . . . . . . . . . . . . . . . 28		4.6. Three Way Latching . . . . . . . . . . . . . . . . . . . 28
	4.6.1. Introduction . . . . . . . . . . . . . . . . . . . . 28		4.6.1. Introduction . . . . . . . . . . . . . . . . . . . . 28
	4.6.2. Necessary RTSP extensions . . . . . . . . . . . . . . 28		4.6.2. Necessary RTSP extensions . . . . . . . . . . . . . . 29
	4.6.3. ALG Considerations . . . . . . . . . . . . . . . . . 29		4.6.3. ALG Considerations . . . . . . . . . . . . . . . . . 29
	4.6.4. Deployment Considerations . . . . . . . . . . . . . . 29		4.6.4. Deployment Considerations . . . . . . . . . . . . . . 29
	4.6.5. Security Considerations . . . . . . . . . . . . . . . 29		4.6.5. Security Considerations . . . . . . . . . . . . . . . 29
	4.7. Application Level Gateways . . . . . . . . . . . . . . . 30		4.7. Application Level Gateways . . . . . . . . . . . . . . . 30
	4.7.1. Introduction . . . . . . . . . . . . . . . . . . . . 30		4.7.1. Introduction . . . . . . . . . . . . . . . . . . . . 30
	4.7.2. Outline On how ALGs for RTSP work . . . . . . . . . . 30		4.7.2. Outline On how ALGs for RTSP work . . . . . . . . . . 31
	4.7.3. Deployment Considerations . . . . . . . . . . . . . . 31		4.7.3. Deployment Considerations . . . . . . . . . . . . . . 32
	4.7.4. Security Considerations . . . . . . . . . . . . . . . 32		4.7.4. Security Considerations . . . . . . . . . . . . . . . 32
	4.8. TCP Tunneling . . . . . . . . . . . . . . . . . . . . . . 32		4.8. TCP Tunneling . . . . . . . . . . . . . . . . . . . . . . 33
	4.8.1. Introduction . . . . . . . . . . . . . . . . . . . . 33		4.8.1. Introduction . . . . . . . . . . . . . . . . . . . . 33
	4.8.2. Usage of TCP tunneling in RTSP . . . . . . . . . . . 33		4.8.2. Usage of TCP tunneling in RTSP . . . . . . . . . . . 33
	4.8.3. ALG Considerations . . . . . . . . . . . . . . . . . 33		4.8.3. ALG Considerations . . . . . . . . . . . . . . . . . 33
	4.8.4. Deployment Considerations . . . . . . . . . . . . . . 33		4.8.4. Deployment Considerations . . . . . . . . . . . . . . 34
	4.8.5. Security Considerations . . . . . . . . . . . . . . . 34		4.8.5. Security Considerations . . . . . . . . . . . . . . . 34
	4.9. TURN (Traversal Using Relay NAT) . . . . . . . . . . . . 34		4.9. TURN (Traversal Using Relay NAT) . . . . . . . . . . . . 34
	4.9.1. Introduction . . . . . . . . . . . . . . . . . . . . 34		4.9.1. Introduction . . . . . . . . . . . . . . . . . . . . 34
	4.9.2. Usage of TURN with RTSP . . . . . . . . . . . . . . . 35		4.9.2. Usage of TURN with RTSP . . . . . . . . . . . . . . . 35
	4.9.3. ALG Considerations . . . . . . . . . . . . . . . . . 36		4.9.3. ALG Considerations . . . . . . . . . . . . . . . . . 36
	4.9.4. Deployment Considerations . . . . . . . . . . . . . . 36		4.9.4. Deployment Considerations . . . . . . . . . . . . . . 36
	4.9.5. Security Considerations . . . . . . . . . . . . . . . 37		4.9.5. Security Considerations . . . . . . . . . . . . . . . 37
	5. Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . 37		5. Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . 37
	6. Comparison of NAT traversal techniques . . . . . . . . . . . 38		6. Comparison of NAT traversal techniques . . . . . . . . . . . 38
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 40		8. Security Considerations . . . . . . . . . . . . . . . . . . . 40
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41
	10. Informative References . . . . . . . . . . . . . . . . . . . 41		10. Informative References . . . . . . . . . . . . . . . . . . . 42
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
	1. Introduction		1. Introduction
	Today there is a proliferating deployment of different types of		Today there is a proliferating deployment of different types of
	Network Address Translator (NAT) boxes that in many cases only		Network Address Translator (NAT) boxes that in many cases only
	loosely follow standards		loosely follow standards
	[RFC3022][RFC2663][RFC3424][RFC4787][RFC5382]. NATs cause		[RFC3022][RFC2663][RFC3424][RFC4787][RFC5382]. NATs cause
	discontinuity in address realms [RFC3424], therefore an application		discontinuity in address realms [RFC3424], therefore an application
	protocol, such as Real-time Streaming Protocol (RTSP)		protocol, such as Real-time Streaming Protocol (RTSP)
	skipping to change at page 22, line 43		skipping to change at page 22, line 43
	4.3.6. Security Consideration		4.3.6. Security Consideration
	One should review the security consideration section of ICE and STUN		One should review the security consideration section of ICE and STUN
	to understand that ICE contains some potential issues. However these		to understand that ICE contains some potential issues. However these
	can be avoided by correctly using ICE in RTSP. An important factor		can be avoided by correctly using ICE in RTSP. An important factor
	is to secure the signalling, i.e. use TLS between RTSP client and		is to secure the signalling, i.e. use TLS between RTSP client and
	server. In fact ICE does help avoid the DDoS attack issue with RTSP		server. In fact ICE does help avoid the DDoS attack issue with RTSP
	substantially as it reduces the possibility for a DDoS using RTSP		substantially as it reduces the possibility for a DDoS using RTSP
	servers to attackers that are on-path between the RTSP server and the		servers to attackers that are on-path between the RTSP server and the
	target and capable of intercepting the STUN connectivity check		target and capable of intercepting the STUN connectivity check
	packets and correctly send a response to the server.		packets and correctly send a response to the server. The ICE
			connectivity checks with their random transaction IDs from the server
			to the client serves as return-routability check and prevents off-
			path attacker to succeed with address spoofing. Similar to Mobile
			IPV6's return routability procedure (Section 5.2.5 of [RFC6275]).
	4.4. Latching		4.4. Latching
	4.4.1. Introduction		4.4.1. Introduction
	Latching is a NAT traversal solution that is based on requiring RTSP		Latching is a NAT traversal solution that is based on requiring RTSP
	clients to send UDP packets to the server's media output ports.		clients to send UDP packets to the server's media output ports.
	Conventionally, RTSP servers send RTP packets in one direction: from		Conventionally, RTSP servers send RTP packets in one direction: from
	server to client. Latching is similar to connection-oriented		server to client. Latching is similar to connection-oriented
	traffic, where one side (e.g., the RTSP client) first "connects" by		traffic, where one side (e.g., the RTSP client) first "connects" by
	skipping to change at page 29, line 36		skipping to change at page 29, line 48
	o May be simpler to implement due to the avoidance of the ICE		o May be simpler to implement due to the avoidance of the ICE
	prioritization and check-board mechanisms.		prioritization and check-board mechanisms.
	However, a 3-way Latching protocol is very similar to using STUN in		However, a 3-way Latching protocol is very similar to using STUN in
	both directions as Latching and verification protocol. Using STUN		both directions as Latching and verification protocol. Using STUN
	would remove the need for implementing a new protocol.		would remove the need for implementing a new protocol.
	4.6.5. Security Considerations		4.6.5. Security Considerations
	The three way latching is significantly securer than its simpler		Three way latching is significantly more secure than its simpler
	versions discussed above. The client to server nonce which is		versions discussed above. The client to server nonce which is
	included in signalling and also can be bigger than the 32-bits of		included in signalling and also can be bigger than the 32-bits of
	random data that the SSRC field supports makes it very difficult for		random data that the SSRC field supports makes it very difficult for
	an off-path attacker to perform an denial of service attack by		an off-path attacker to perform an denial of service attack by
	diverting the media.		diverting the media.
	The client to server nonce and its echoing back does not protect		The client to server nonce and its echoing back does not protect
	against on-patch attacker, including malicious clients. However, the		against on-patch attacker, including malicious clients. However, the
	server to client nonce and its echoing back prevents malicious		server to client nonce and its echoing back prevents malicious
	clients to divert the media stream by spoofing the source address and		clients to divert the media stream by spoofing the source address and
	port, as it can't echo back the nonce in these cases.		port, as it can't echo back the nonce in these cases. Similar to the
			Mobile IPv6 return routability procedure (Section 5.2.5 of [RFC6275])
	Three way latching is really only vulnerable to an on-path attacker		Three way latching is really only vulnerable to an on-path attacker
	that is quite capable. First the attacker can either learn the		that is quite capable. First the attacker can either learn the
	client to server nonce, by intercepting the signalling, or modifying		client to server nonce, by intercepting the signalling, or modifying
	the source information (target destination) of a client's latching		the source information (target destination) of a client's latching
	packet. Secondly, it is also on-path between the server and target		packet. Secondly, it is also on-path between the server and target
	destination and can generate a response using the server's nonce. An		destination and can generate a response using the server's nonce. An
	adversary that has these capabilities are commonly capable of causing		adversary that has these capabilities are commonly capable of causing
	significantly worse damage than this using other methods.		significantly worse damage than this using other methods.
	skipping to change at page 41, line 23		skipping to change at page 41, line 29
	signaling connection.		signaling connection.
	The usage of TURN has severe risk of denial of service attacks		The usage of TURN has severe risk of denial of service attacks
	against a client. The TURN server can also be used as a redirect		against a client. The TURN server can also be used as a redirect
	point in a DDoS attack unless the server has strict enough rules for		point in a DDoS attack unless the server has strict enough rules for
	who may create bindings.		who may create bindings.
	The latching and variant of latching have so big security issues that		The latching and variant of latching have so big security issues that
	they should not be used at all. The three way latching as well as		they should not be used at all. The three way latching as well as
	ICE mitigates these security issues and performs the important		ICE mitigates these security issues and performs the important
	return-routability check that prevents spoofed source addresses, and		return-routability checks that prevents spoofed source addresses, and
	should be recommended for that reason. RTP ALG's is a security risk		should be recommended for that reason. RTP ALG's is a security risk
	as they can create an incitement against using secure RTSP		as they can create an incitement against using secure RTSP
	signalling. That can be avoided as ALGs requires trust in the		signalling. That can be avoided as ALGs requires trust in the
	middlebox, and that trust becomes explicit if one uses the hop-by-hop		middlebox, and that trust becomes explicit if one uses the hop-by-hop
	security solution as specified in Section 19.3 of RTSP 2.0.		security solution as specified in Section 19.3 of RTSP 2.0.
	[I-D.ietf-mmusic-rfc2326bis]. The remaining methods can be		[I-D.ietf-mmusic-rfc2326bis]. The remaining methods can be
	considered safe enough, assuming that the appropriate security		considered safe enough, assuming that the appropriate security
	mechanisms are used and not ignored.		mechanisms are used and not ignored.
	9. Acknowledgements		9. Acknowledgements
	The author would also like to thank all persons on the MMUSIC working		The author would also like to thank all persons on the MMUSIC working
	group's mailing list that has commented on this document. Persons		group's mailing list that has commented on this document. Persons
	having contributed in such way in no special order to this protocol		having contributed in such way in no special order to this protocol
	are: Jonathan Rosenberg, Philippe Gentric, Tom Marshall, David Yon,		are: Jonathan Rosenberg, Philippe Gentric, Tom Marshall, David Yon,
	Amir Wolf, Anders Klemets, Flemming Andreasen, Ari Keranen, Bill		Amir Wolf, Anders Klemets, Flemming Andreasen, Ari Keranen, Bill
	Atwood, Alissa Cooper, Colin Perkins, Sarah Banks and David Black.		Atwood, Alissa Cooper, Colin Perkins, Sarah Banks, David Black and
	Thomas Zeng would also like to give special thanks to Greg Sherwood		Alvaro Retana. Thomas Zeng would also like to give special thanks to
	of PacketVideo for his input into this memo.		Greg Sherwood of PacketVideo for his input into this memo.
	Section 1.1 contains text originally written for RFC 4787 by Francois		Section 1.1 contains text originally written for RFC 4787 by Francois
	Audet and Cullen Jennings.		Audet and Cullen Jennings.
	10. Informative References		10. Informative References
	[I-D.ietf-avt-rtp-no-op]		[I-D.ietf-avt-rtp-no-op]
	Andreasen, F., "A No-Op Payload Format for RTP", draft-		Andreasen, F., "A No-Op Payload Format for RTP", draft-
	ietf-avt-rtp-no-op-04 (work in progress), May 2007.		ietf-avt-rtp-no-op-04 (work in progress), May 2007.
	skipping to change at page 44, line 9		skipping to change at page 44, line 13
	Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.		Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
	[RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays		[RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays
	around NAT (TURN) Extensions for TCP Allocations", RFC		around NAT (TURN) Extensions for TCP Allocations", RFC
	6062, November 2010.		6062, November 2010.
	[RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for		[RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for
	Keeping Alive the NAT Mappings Associated with RTP / RTP		Keeping Alive the NAT Mappings Associated with RTP / RTP
	Control Protocol (RTCP) Flows", RFC 6263, June 2011.		Control Protocol (RTCP) Flows", RFC 6263, June 2011.
			[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
			in IPv6", RFC 6275, July 2011.
	[RFC7362] Ivov, E., Kaplan, H., and D. Wing, "Latching: Hosted NAT		[RFC7362] Ivov, E., Kaplan, H., and D. Wing, "Latching: Hosted NAT
	Traversal (HNT) for Media in Real-Time Communication", RFC		Traversal (HNT) for Media in Real-Time Communication", RFC
	7362, September 2014.		7362, September 2014.
	[STUN-IMPL]		[STUN-IMPL]
	"Open Source STUN Server and Client,		"Open Source STUN Server and Client,
	http://sourceforge.net/projects/stun/", May 2013.		http://sourceforge.net/projects/stun/", May 2013.
	Authors' Addresses		Authors' Addresses
End of changes. 17 change blocks.
	21 lines changed or deleted		29 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/