--- 1/draft-ietf-rtcweb-stun-consent-freshness-05.txt 2014-08-13 19:14:32.067061983 -0700 +++ 2/draft-ietf-rtcweb-stun-consent-freshness-06.txt 2014-08-13 19:14:32.087062468 -0700 @@ -1,23 +1,23 @@ RTCWEB M. Perumal Internet-Draft Ericsson Intended status: Standards Track D. Wing -Expires: January 5, 2015 R. Ravindranath +Expires: February 13, 2015 R. Ravindranath T. Reddy Cisco Systems M. Thomson Mozilla - July 4, 2014 + August 12, 2014 STUN Usage for Consent Freshness - draft-ietf-rtcweb-stun-consent-freshness-05 + draft-ietf-rtcweb-stun-consent-freshness-06 Abstract To prevent sending excessive traffic to an endpoint, periodic consent needs to be obtained from that remote endpoint. This document describes a consent mechanism using a new STUN usage. This same mechanism can also determine connection loss ("liveness") with a remote peer. @@ -29,21 +29,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -92,22 +92,22 @@ interface). This document describes a new STUN usage with exchange of request and response messages to verify the remote peer's consent to receive traffic, and the absence of which for a period of time indicates a loss of liveness. WebRTC endpoints are required to support full ICE as specified in section 3.4 of [I-D.ietf-rtcweb-transports]. However, when WebRTC endpoints interwork with other endpoints that support only ICE-lite - (e.g. gateways) those endpoints will not generate consent checks, but - just respond to consent checks they receive. + (e.g., gateways) those endpoints will not generate consent checks, + but just respond to consent checks they receive. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Consent: It is the mechanism of obtaining permission to send traffic to a certain transport address. This is the initial consent to send traffic, which is obtained by ICE or a TCP handshake. @@ -140,41 +140,50 @@ There are two ways consent to send traffic is revoked: expiration of consent and immediate revocation of consent, which are discussed in the following sections. 4.1. Expiration of Consent A WebRTC browser performs a combined consent freshness and session liveness test using STUN request/response as described below: An endpoint MUST NOT send application data (e.g., RTP, RTCP, SCTP, - DTLS) on an ICE-initiated connection unless the receiving endpoint - consents to receive the data. After a successful ICE connectivity - check on a particular transport address, subsequent consent MUST be - obtained following the procedure described in this document. The - consent expires after a fixed amount of time. + DTLS), over any transport protocol (e.g., UDP, TCP) on an ICE- + initiated connection unless the receiving endpoint consents to + receive the data. After a successful ICE connectivity check on a + particular transport address, subsequent consent MUST be obtained + 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 request to the remote peer's Transport Address and receiving a matching, authenticated, non-error ICE binding response from the remote peer's Transport Address. These ICE binding requests and responses are authenticated using the same short-term credentials as the initial ICE exchange. Implementations MUST cease sending data if their consent expires. To prevent expiry of consent, a STUN binding - request is sent every N milliseconds, where N SHOULD be 5000 - milliseconds and MUST be randomized at least 20% above and 20% below - that value (to prevent prevent network synchronization). Using the - value 5000 milliseconds and that 20% randomization range, N would be - a value between 4000 and 6000. These STUN binding requests for - consent are not re-transmitted. Each STUN binding request for - consent re-calculates a new random value N and a new - cryptographically-random [RFC4086] STUN transaction ID. + request MUST be sent every N milliseconds, where N is chosen randomly + with each consent check in the interval [.8N, 1.2N] (to prevent + network synchronization), where N SHOULD be 5000. Using the value + 5000 milliseconds and that 20% randomization range, N would be a + value between 4000 and 6000. These STUN binding requests for consent + are not re-transmitted. Each STUN binding request for consent re- + calculates a new random value N and a new cryptographically-random + [RFC4086] STUN transaction ID. The initial Consent to send traffic is obtained by ICE. Consent 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 has not been received from the remote peer's Transport Address, the endpoint MUST cease transmission on that 5-tuple. To meet the security needs of consent, an untrusted application (e.g., JavaScript) MUST NOT be able to obtain or control the STUN transaction ID, because that enables spoofing STUN responses, @@ -197,23 +206,26 @@ consent has expired. 4.2. Immediate Revocation of Consent The previous section explained how consent expires due to a timeout. In some cases it is useful to signal a connection is terminated, rather than relying on a timeout. This is done by immediately revoking consent. 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 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., TCP FIN) does not indicate revocation of consent. Thus, an endpoint receiving an unauthenticated end-of-session message SHOULD continue sending media (over connectionless transport) or attempt to re- establish the connection (over connection-oriented transport) until consent expires or it receives an authenticated message revoking consent. Note that an authenticated SRTCP BYE does not terminate consent; it @@ -281,22 +293,23 @@ distributions, receipt of an authenticated SRTP packet is not sufficient to verify consent. 9. IANA Considerations This document does not require any action from IANA. 10. Acknowledgement Thanks to Eric Rescorla, Harald Alvestrand, Bernard Aboba, Magnus - Westerland, Cullen Jennings, Christer Holmberg and Simon Perreault - for their valuable inputs and comments. + Westerland, Cullen Jennings, Christer Holmberg, Simon Perreault, Paul + Kyzivat, Emil Ivov, and Jonathan Lennox for their valuable inputs and + comments. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. @@ -335,20 +348,24 @@ Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006. [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 4953, July 2007. [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's Robustness to Blind In-Window Attacks", RFC 5961, August 2010. + [RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays + around NAT (TURN) Extensions for TCP Allocations", RFC + 6062, November 2010. + Authors' Addresses Muthu Arul Mozhi Perumal Ericsson Mahadevapura Bangalore, Karnataka 560048 India Email: muthu.arul@gmail.com