draft-ietf-rtcweb-stun-consent-freshness-05.txt		draft-ietf-rtcweb-stun-consent-freshness-06.txt
	RTCWEB M. Perumal		RTCWEB M. Perumal
	Internet-Draft Ericsson		Internet-Draft Ericsson
	Intended status: Standards Track D. Wing		Intended status: Standards Track D. Wing
	Expires: January 5, 2015 R. Ravindranath		Expires: February 13, 2015 R. Ravindranath
	T. Reddy		T. Reddy
	Cisco Systems		Cisco Systems
	M. Thomson		M. Thomson
	Mozilla		Mozilla
	July 4, 2014		August 12, 2014
	STUN Usage for Consent Freshness		STUN Usage for Consent Freshness
	draft-ietf-rtcweb-stun-consent-freshness-05		draft-ietf-rtcweb-stun-consent-freshness-06
	Abstract		Abstract
	To prevent sending excessive traffic to an endpoint, periodic consent		To prevent sending excessive traffic to an endpoint, periodic consent
	needs to be obtained from that remote endpoint.		needs to be obtained from that remote endpoint.
	This document describes a consent mechanism using a new STUN usage.		This document describes a consent mechanism using a new STUN usage.
	This same mechanism can also determine connection loss ("liveness")		This same mechanism can also determine connection loss ("liveness")
	with a remote peer.		with a remote peer.
	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 January 5, 2015.		This Internet-Draft will expire on February 13, 2015.
	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 3, line 10		skipping to change at page 3, line 10
	interface).		interface).
	This document describes a new STUN usage with exchange of request and		This document describes a new STUN usage with exchange of request and
	response messages to verify the remote peer's consent to receive		response messages to verify the remote peer's consent to receive
	traffic, and the absence of which for a period of time indicates a		traffic, and the absence of which for a period of time indicates a
	loss of liveness.		loss of liveness.
	WebRTC endpoints are required to support full ICE as specified in		WebRTC endpoints are required to support full ICE as specified in
	section 3.4 of [I-D.ietf-rtcweb-transports]. However, when WebRTC		section 3.4 of [I-D.ietf-rtcweb-transports]. However, when WebRTC
	endpoints interwork with other endpoints that support only ICE-lite		endpoints interwork with other endpoints that support only ICE-lite
	(e.g. gateways) those endpoints will not generate consent checks, but		(e.g., gateways) those endpoints will not generate consent checks,
	just respond to consent checks they receive.		but just respond to consent checks they receive.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	Consent: It is the mechanism of obtaining permission to send traffic		Consent: It is the mechanism of obtaining permission to send traffic
	to a certain transport address. This is the initial consent to		to a certain transport address. This is the initial consent to
	send traffic, which is obtained by ICE or a TCP handshake.		send traffic, which is obtained by ICE or a TCP handshake.
	skipping to change at page 4, line 11		skipping to change at page 4, line 11
	There are two ways consent to send traffic is revoked: expiration of		There are two ways consent to send traffic is revoked: expiration of
	consent and immediate revocation of consent, which are discussed in		consent and immediate revocation of consent, which are discussed in
	the following sections.		the following sections.
	4.1. Expiration of Consent		4.1. Expiration of Consent
	A WebRTC browser performs a combined consent freshness and session		A WebRTC browser performs a combined consent freshness and session
	liveness test using STUN request/response as described below:		liveness test using STUN request/response as described below:
	An endpoint MUST NOT send application data (e.g., RTP, RTCP, SCTP,		An endpoint MUST NOT send application data (e.g., RTP, RTCP, SCTP,
	DTLS) on an ICE-initiated connection unless the receiving endpoint		DTLS), over any transport protocol (e.g., UDP, TCP) on an ICE-
	consents to receive the data. After a successful ICE connectivity		initiated connection unless the receiving endpoint consents to
	check on a particular transport address, subsequent consent MUST be		receive the data. After a successful ICE connectivity check on a
	obtained following the procedure described in this document. The		particular transport address, subsequent consent MUST be obtained
	consent expires after a fixed amount of time.		following the procedure described in this document. The consent
			expires after a fixed amount of time. During ICE restart consent
			checks MUST continue to be sent on previously validated pair, and
			MUST be responded to on the previously validated pair, until ICE
			restart completes.
			Note: Although TCP has its own consent mechanism (TCP
			acknowledgements), consent is necessary over a TCP connection
			because it could be translated to a UDP connection (e.g.,
			[RFC6062]).
	Explicit consent to send is obtained by sending an ICE binding		Explicit consent to send is obtained by sending an ICE binding
	request to the remote peer's Transport Address and receiving a		request to the remote peer's Transport Address and receiving a
	matching, authenticated, non-error ICE binding response from the		matching, authenticated, non-error ICE binding response from the
	remote peer's Transport Address. These ICE binding requests and		remote peer's Transport Address. These ICE binding requests and
	responses are authenticated using the same short-term credentials as		responses are authenticated using the same short-term credentials as
	the initial ICE exchange. Implementations MUST cease sending data if		the initial ICE exchange. Implementations MUST cease sending data if
	their consent expires. To prevent expiry of consent, a STUN binding		their consent expires. To prevent expiry of consent, a STUN binding
	request is sent every N milliseconds, where N SHOULD be 5000		request MUST be sent every N milliseconds, where N is chosen randomly
	milliseconds and MUST be randomized at least 20% above and 20% below		with each consent check in the interval [.8N, 1.2N] (to prevent
	that value (to prevent prevent network synchronization). Using the		network synchronization), where N SHOULD be 5000. Using the value
	value 5000 milliseconds and that 20% randomization range, N would be		5000 milliseconds and that 20% randomization range, N would be a
	a value between 4000 and 6000. These STUN binding requests for		value between 4000 and 6000. These STUN binding requests for consent
	consent are not re-transmitted. Each STUN binding request for		are not re-transmitted. Each STUN binding request for consent re-
	consent re-calculates a new random value N and a new		calculates a new random value N and a new cryptographically-random
	cryptographically-random [RFC4086] STUN transaction ID.		[RFC4086] STUN transaction ID.
	The initial Consent to send traffic is obtained by ICE. Consent		The initial Consent to send traffic is obtained by ICE. Consent
	expires after 30 seconds. That is, if a valid STUN binding response		expires after 30 seconds. That is, if a valid STUN binding response
	corresponding to one of the STUN requests sent in the last 30 seconds		corresponding to one of the STUN requests sent in the last 30 seconds
	has not been received from the remote peer's Transport Address, the		has not been received from the remote peer's Transport Address, the
	endpoint MUST cease transmission on that 5-tuple.		endpoint MUST cease transmission on that 5-tuple.
	To meet the security needs of consent, an untrusted application		To meet the security needs of consent, an untrusted application
	(e.g., JavaScript) MUST NOT be able to obtain or control the STUN		(e.g., JavaScript) MUST NOT be able to obtain or control the STUN
	transaction ID, because that enables spoofing STUN responses,		transaction ID, because that enables spoofing STUN responses,
	skipping to change at page 5, line 21		skipping to change at page 5, line 29
	consent has expired.		consent has expired.
	4.2. Immediate Revocation of Consent		4.2. Immediate Revocation of Consent
	The previous section explained how consent expires due to a timeout.		The previous section explained how consent expires due to a timeout.
	In some cases it is useful to signal a connection is terminated,		In some cases it is useful to signal a connection is terminated,
	rather than relying on a timeout. This is done by immediately		rather than relying on a timeout. This is done by immediately
	revoking consent.		revoking consent.
	Consent for sending traffic on the media or data channel is		Consent for sending traffic on the media or data channel is
	immediately revoked by receipt of a an authenticated message that		immediately revoked by receipt of an authenticated message that
	closes the connection (e.g., a TLS fatal alert) or receipt of a valid		closes the connection (e.g., a TLS fatal alert) or receipt of a valid
	and authenticated STUN response with error code Forbidden (403).		and authenticated STUN response with error code Forbidden (403).
			Those consent revocation messages can be lost on the network, so an
			implementation wanting to immediately revoke consent needs to
			remember those credentials until consent expiry (30 seconds).
	Receipt of an unauthenticated message that closes a connection (e.g.,		Receipt of an unauthenticated message that closes a connection (e.g.,
	TCP FIN) does not indicate revocation of consent. Thus, an endpoint		TCP FIN) does not indicate revocation of consent. Thus, an endpoint
	receiving an unauthenticated end-of-session message SHOULD continue		receiving an unauthenticated end-of-session message SHOULD continue
	sending media (over connectionless transport) or attempt to re-		sending media (over connectionless transport) or attempt to re-
	establish the connection (over connection-oriented transport) until		establish the connection (over connection-oriented transport) until
	consent expires or it receives an authenticated message revoking		consent expires or it receives an authenticated message revoking
	consent.		consent.
	Note that an authenticated SRTCP BYE does not terminate consent; it		Note that an authenticated SRTCP BYE does not terminate consent; it
	skipping to change at page 7, line 12		skipping to change at page 7, line 18
	distributions, receipt of an authenticated SRTP packet is not		distributions, receipt of an authenticated SRTP packet is not
	sufficient to verify consent.		sufficient to verify consent.
	9. IANA Considerations		9. IANA Considerations
	This document does not require any action from IANA.		This document does not require any action from IANA.
	10. Acknowledgement		10. Acknowledgement
	Thanks to Eric Rescorla, Harald Alvestrand, Bernard Aboba, Magnus		Thanks to Eric Rescorla, Harald Alvestrand, Bernard Aboba, Magnus
	Westerland, Cullen Jennings, Christer Holmberg and Simon Perreault		Westerland, Cullen Jennings, Christer Holmberg, Simon Perreault, Paul
	for their valuable inputs and comments.		Kyzivat, Emil Ivov, and Jonathan Lennox for their valuable inputs and
			comments.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness		[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
	Requirements for Security", BCP 106, RFC 4086, June 2005.		Requirements for Security", BCP 106, RFC 4086, June 2005.
	skipping to change at page 8, line 20		skipping to change at page 8, line 26
	Description Protocol (SDP) Security Descriptions for Media		Description Protocol (SDP) Security Descriptions for Media
	Streams", RFC 4568, July 2006.		Streams", RFC 4568, July 2006.
	[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC		[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC
	4953, July 2007.		4953, July 2007.
	[RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's		[RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's
	Robustness to Blind In-Window Attacks", RFC 5961, August		Robustness to Blind In-Window Attacks", RFC 5961, August
	2010.		2010.
			[RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays
			around NAT (TURN) Extensions for TCP Allocations", RFC
			6062, November 2010.
	Authors' Addresses		Authors' Addresses
	Muthu Arul Mozhi Perumal		Muthu Arul Mozhi Perumal
	Ericsson		Ericsson
	Mahadevapura		Mahadevapura
	Bangalore, Karnataka 560048		Bangalore, Karnataka 560048
	India		India
	Email: muthu.arul@gmail.com		Email: muthu.arul@gmail.com
End of changes. 11 change blocks.
	22 lines changed or deleted		39 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/