draft-ietf-mmusic-rtsp-nat-evaluation-12.txt		draft-ietf-mmusic-rtsp-nat-evaluation-13.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: July 27, 2014		Expires: August 14, 2014
	January 23, 2014		February 10, 2014
	The Evaluation of Different Network Address Translator (NAT) Traversal		The Evaluation 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-12		draft-ietf-mmusic-rtsp-nat-evaluation-13
	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 41		skipping to change at page 1, line 41
	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 July 27, 2014.		This Internet-Draft will expire on August 14, 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 13, line 14		skipping to change at page 13, line 14
	As it may be difficult to determine why the failure occurs, the usage		As it may be difficult to determine why the failure occurs, the usage
	of TLS protected RTSP message exchange at all times would avoid this		of TLS protected RTSP message exchange at all times would avoid this
	issue.		issue.
	4.1.4. Deployment Considerations		4.1.4. Deployment Considerations
	For the Stand-Alone usage of STUN the following applies:		For the Stand-Alone usage of STUN the following applies:
	Advantages:		Advantages:
	o STUN is a solution first used by SIP based applications (See		o STUN is a solution first used by SIP [RFC3261] based applications
	section 1 and 2 of [RFC5389]). As shown above, with little or no		(See section 1 and 2 of [RFC5389]). As shown above, with little
	changes, the RTSP application can re-use STUN as a NAT traversal		or no changes, the RTSP application can re-use STUN as a NAT
	solution, avoiding the pit-fall of solving a problem twice.		traversal solution, avoiding the pit-fall of solving a problem
			twice.
	o Using STUN does not require RTSP server modifications; it only		o Using STUN does not require RTSP server modifications; it only
	affects the client implementation.		affects the client implementation.
	Disadvantages:		Disadvantages:
	o Requires a STUN server deployed in the public address space.		o Requires a STUN server deployed in the public address space.
	o Only works with NATs that perform endpoint independent and address		o Only works with NATs that perform endpoint independent and address
	dependent mappings. Address and Port-Dependent filtering NATs		dependent mappings. Address and Port-Dependent filtering NATs
	skipping to change at page 19, line 31		skipping to change at page 19, line 31
	performance rather than always successful is recommended, as it		performance rather than always successful is recommended, as it
	is most likely to be a server in the public.		is most likely to be a server in the public.
	4. The server responds to the SETUP (200 OK) for each media stream		4. The server responds to the SETUP (200 OK) for each media stream
	with its candidates. A server with a public address usually only		with its candidates. A server with a public address usually only
	provides a single ICE candidate. Also here one candidate is the		provides a single ICE candidate. Also here one candidate is the
	server primary address.		server primary address.
	5. The connectivity checks are performed. For the server the		5. The connectivity checks are performed. For the server the
	connectivity checks from the server to the clients have an		connectivity checks from the server to the clients have an
	additional usage. They verify that there is someone willingly to		additional usage. They verify that there is someone willing to
	receive the media, thus preventing the server from unknowingly		receive the media, thus preventing the server from unknowingly
	performing a DoS attack.		performing a DoS attack.
	6. Connectivity checks from the client promoting a candidate pair		6. Connectivity checks from the client promoting a candidate pair
	were successful. Thus no further SETUP requests are necessary		were successful. Thus no further SETUP requests are necessary
	and processing can proceed with step 7. If another address than		and processing can proceed with step 7. If another address than
	the primary has been verified by the client to work, that address		the primary has been verified by the client to work, that address
	may then be promoted for usage in a SETUP request (Go to 7). If		may then be promoted for usage in a SETUP request (Go to 7). If
	the checks for the available candidates failed and if further		the checks for the available candidates failed and if further
	candidates have been derived during the connectivity checks, then		candidates have been derived during the connectivity checks, then
	skipping to change at page 22, line 4		skipping to change at page 22, line 4
	Specifically, when the RTSP server receives the latching packet		Specifically, when the RTSP server receives the latching packet
	(a.k.a. hole-punching packet, since it is used to punch a hole in the		(a.k.a. hole-punching packet, since it is used to punch a hole in the
	Firewall/NAT and to aid the server for port binding and address		Firewall/NAT and to aid the server for port binding and address
	mapping) from its client, it copies the source IP and Port number and		mapping) from its client, it copies the source IP and Port number and
	uses them as delivery address for media packets. By having the		uses them as delivery address for media packets. By having the
	server send media traffic back the same way as the client's packet		server send media traffic back the same way as the client's packet
	are sent to the server, address mappings will be honored. Therefore		are sent to the server, address mappings will be honored. Therefore
	this technique works for all types of NATs, given that the server is		this technique works for all types of NATs, given that the server is
	not behind a NAT. However, it does require server modifications.		not behind a NAT. However, it does require server modifications.
	Unless there is built-in protection mechanism, latching is very		Unless there is built-in protection mechanism, latching is very
	vulnerable to DDoS attacks (See Security Considerations of		vulnerable to both hijacking and becoming a tool in Distributed
			Denail of Service (DDoS) attacks (See Security Considerations of
	[I-D.ietf-mmusic-latching]), because attackers can simply forge the		[I-D.ietf-mmusic-latching]), because attackers can simply forge the
	source IP & Port of the latching packet. Using the rule for		source IP & Port of the latching packet. Using the rule for
	restricting IP address to the one of the signaling connection will		restricting IP address to the one of the signaling connection will
	need to be applied here also. However, that does not protect against		need to be applied here also. However, that does not protect against
	hijacking from another client behind the same NAT. This can become a		hijacking from another client behind the same NAT. This can become a
	serious issue in deployments with CGNs.		serious issue in deployments with CGNs.
	4.4.2. Necessary RTSP extensions		4.4.2. Necessary RTSP extensions
	To support Latching, the RTSP signaling must be extended to allow the		To support Latching, the RTSP signaling must be extended to allow the
	skipping to change at page 23, line 9		skipping to change at page 23, line 9
	o Limited to work with servers that have an public IP address.		o Limited to work with servers that have an public IP address.
	o The format of the RTP packet for "connection setup" (a.k.a		o The format of the RTP packet for "connection setup" (a.k.a
	Latching packet) is yet to be defined. One possibility is to use		Latching packet) is yet to be defined. One possibility is to use
	RTP No-Op packet format in [I-D.ietf-avt-rtp-no-op].		RTP No-Op packet format in [I-D.ietf-avt-rtp-no-op].
	o SSRC management if RTP is used for latching due to risk for mis-		o SSRC management if RTP is used for latching due to risk for mis-
	association of clients to RTSP sessions at the server if SSRC		association of clients to RTSP sessions at the server if SSRC
	collision occurs.		collision occurs.
	o Has significant security considerations (Section 4.4.4) due to		o Has significant security considerations (See Section 4.4.4), due
	lack of strong authentication mechanism, compare with STUN message		to lack of a strong authentication mechanism and will need to use
	authentication, and will need to use address restrictions.		address restrictions.
	4.4.4. Security Consideration		4.4.4. Security Consideration
	Latching's major security issue is that RTP streams can be hijacked		Latching's major security issue is that RTP streams can be hijacked
	and directed towards any target that the attacker desires unless		and directed towards any target that the attacker desires unless
	address restrictions are used. In the case of NATs with multiple		address restrictions are used. In the case of NATs with multiple
	clients on the inside of them, hijacking can still occur. This		clients on the inside of them, hijacking can still occur. This
	becomes a significant threat in the context of carrier grade NATs		becomes a significant threat in the context of carrier grade NATs
	(CGN).		(CGN).
	skipping to change at page 23, line 49		skipping to change at page 23, line 49
	attacker can send its own Latching packets containing the correct RTP		attacker can send its own Latching packets containing the correct RTP
	SSRC to the correct address and port on the server. The RTSP server		SSRC to the correct address and port on the server. The RTSP server
	will then use the source IP and port from the Latching packet as the		will then use the source IP and port from the Latching packet as the
	destination for the media packets it sends.		destination for the media packets it sends.
	Another variation of this attack is for a man in the middle to modify		Another variation of this attack is for a man in the middle to modify
	the RTP latching packet being sent by a client to the server by		the RTP latching packet being sent by a client to the server by
	simply changing the source IP to the target one desires to attack.		simply changing the source IP to the target one desires to attack.
	One can fend off the snooping based attack by applying encryption to		One can fend off the snooping based attack by applying encryption to
	the RTSP signaling transport. However, if the attacker is an man in		the RTSP signaling transport. However, if the attacker is a man in
	the middle modifying latching packets, the attack is impossible to		the middle modifying latching packets, the attack is impossible to
	defend against other than through address restrictions. As a NAT re-		defend against other than through address restrictions. As a NAT re-
	writes the source IP and (possibly) port this cannot be		writes the source IP and (possibly) port this cannot be
	authenticated, but authentication is required in order to protect		authenticated, but authentication is required in order to protect
	against this type of DoS attack.		against this type of DoS attack.
	Yet another issues is that these attacks also can be used to deny the		Yet another issue is that these attacks also can be used to deny the
	client the service it desires from the RTSP server completely. The		client the service it desires from the RTSP server completely. The
	attacker modifies or originates its own latching packets with another		attacker modifies or originates its own latching packets with another
	port than what the legit latching packets uses, which results in that		port than what the legit latching packets uses, which results in that
	the media server sends the RTP/RTCP traffic to ports the client isn't		the media server sends the RTP/RTCP traffic to ports the client isn't
	listening for RTP/RTCP on.		listening for RTP/RTCP on.
	The amount of random non-guessable material in the latching packet		The amount of random non-guessable material in the latching packet
	determines how well Latching can fend off stream-hijacking performed		determines how well Latching can fend off stream-hijacking performed
	by parties that are off the client to server network path, i.e. lacks		by parties that are off the client to server network path, i.e. lacks
	the capability to see the client's latching packets. This proposal		the capability to see the client's latching packets. This proposal
	skipping to change at page 37, line 41		skipping to change at page 37, line 41
	2013.		2013.
	[I-D.ietf-mmusic-rfc2326bis]		[I-D.ietf-mmusic-rfc2326bis]
	Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M.,		Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M.,
	and M. Stiemerling, "Real Time Streaming Protocol 2.0		and M. Stiemerling, "Real Time Streaming Protocol 2.0
	(RTSP)", draft-ietf-mmusic-rfc2326bis-39 (work in		(RTSP)", draft-ietf-mmusic-rfc2326bis-39 (work in
	progress), January 2014.		progress), January 2014.
	[I-D.ietf-mmusic-rtsp-nat]		[I-D.ietf-mmusic-rtsp-nat]
	Goldberg, J., Westerlund, M., and T. Zeng, "A Network		Goldberg, J., Westerlund, M., and T. Zeng, "A Network
	Address Translator (NAT) Traversal mechanism for media		Address Translator (NAT) Traversal Mechanism for Media
	controlled by Real-Time Streaming Protocol (RTSP)", draft-		Controlled by Real-Time Streaming Protocol (RTSP)", draft-
	ietf-mmusic-rtsp-nat-18 (work in progress), January 2014.		ietf-mmusic-rtsp-nat-20 (work in progress), February 2014.
	[NICE] "Libnice - The GLib ICE implementation,		[NICE] "Libnice - The GLib ICE implementation,
	http://nice.freedesktop.org/wiki/", May 2013.		http://nice.freedesktop.org/wiki/", May 2013.
	[PJNATH] "PJNATH - Open Source ICE, STUN, and TURN Library,		[PJNATH] "PJNATH - Open Source ICE, STUN, and TURN Library,
	http://www.pjsip.org/pjnath/docs/html/", May 2013.		http://www.pjsip.org/pjnath/docs/html/", May 2013.
	[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,		[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
	August 1980.		August 1980.
	skipping to change at page 38, line 25		skipping to change at page 38, line 25
	1999.		1999.
	[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address		[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
	Translator (NAT) Terminology and Considerations", RFC		Translator (NAT) Terminology and Considerations", RFC
	2663, August 1999.		2663, August 1999.
	[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network		[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
	Address Translator (Traditional NAT)", RFC 3022, January		Address Translator (Traditional NAT)", RFC 3022, January
	2001.		2001.
			[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
			A., Peterson, J., Sparks, R., Handley, M., and E.
			Schooler, "SIP: Session Initiation Protocol", RFC 3261,
			June 2002.
	[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.
	[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.
	[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.		[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
End of changes. 11 change blocks.
	18 lines changed or deleted		25 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/