--- 1/draft-ietf-rtcweb-stun-consent-freshness-14.txt 2015-06-22 23:16:18.489338860 -0700 +++ 2/draft-ietf-rtcweb-stun-consent-freshness-15.txt 2015-06-22 23:16:18.537339983 -0700 @@ -1,23 +1,23 @@ RTCWEB M. Perumal Internet-Draft Ericsson Intended status: Standards Track D. Wing -Expires: December 10, 2015 R. Ravindranath +Expires: December 24, 2015 R. Ravindranath T. Reddy Cisco Systems M. Thomson Mozilla - June 8, 2015 + June 22, 2015 STUN Usage for Consent Freshness - draft-ietf-rtcweb-stun-consent-freshness-14 + draft-ietf-rtcweb-stun-consent-freshness-15 Abstract To prevent WebRTC applications, such as browsers, from launching attacks by sending media to unwilling victims, periodic consent to send needs to be obtained from remote endpoints. This document describes a consent mechanism using a new Session Traversal Utilities for NAT (STUN) usage. @@ -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 December 10, 2015. + This Internet-Draft will expire on December 24, 2015. Copyright Notice Copyright (c) 2015 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 @@ -90,23 +90,23 @@ terminated. This document defines what it takes to obtain, maintain, and lose consent to send. Consent to send applies to a single 5-tuple. How applications react to changes in consent is not described in this document. The consent mechanism does not update the ICE procedures defined in [RFC5245]. Consent is obtained only by full ICE implementations. An ICE-lite agent (as defined in Section 2.7 of [RFC5245]) does not generate - connectivity checks or run the ICE state machine. An ICE-lite agent - does not generate consent checks, it will only respond to any checks - that it receives. No changes are required to ICE-lite + connectivity checks or run the ICE state machine. Hence, an ICE-lite + agent does not generate consent checks and will only respond to any + checks that it receives. No changes are required to ICE-lite implementations in order to respond to consent checks, as they are processed as normal ICE connectivity checks. 2. Applicability This document defines what it takes to obtain, maintain, and lose consent to send using ICE. Verification of peer consent before sending traffic is necessary in deployments like WebRTC to ensure that a malicious JavaScript cannot use the browser as a platform for launching attacks. Section 4.4 and Section 5.3 of @@ -176,24 +176,24 @@ need to minimize the time taken to respond to a loss of consent with the desire to reduce the occurrence of spurious failures. ICE does not identify when consent to send traffic ends. This document describes two ways in which consent to send ends: expiration of consent and immediate revocation of consent, which are discussed in the following sections. 5.1. Expiration of Consent - A full ICE implementation obtains consent to send using ICE. After a - successful ICE connectivity check on a particular transport address - (i.e., a candidate pair has been marked as Succeeded), consent MUST - be maintained following the procedure described in this document. + A full ICE implementation obtains consent to send using ICE. After + ICE concludes on a particular candidate pair and whenever the + endpoint sends application data on that pair consent MUST be + maintained following the procedure described in this document. An endpoint MUST NOT send data other than the messages used to establish consent unless the receiving endpoint has consented to receive data. Connectivity checks that are paced as described in Section 16 of [RFC5245] and responses to connectivity checks are permitted. That is, no application data (e.g., RTP or Datagram Transport Layer Security (DTLS)) can be sent until consent is obtained. Explicit consent to send is obtained and maintained by sending an @@ -248,27 +248,29 @@ candidate pair as described earlier. While TCP affords some protection from off-path attackers ([RFC5961], [RFC4953]), there is still a risk an attacker could cause a TCP sender to send forever by spoofing ACKs. To prevent such an attack, consent checks MUST be performed over all transport connections, including TCP. In this way, an off-path attacker spoofing TCP segments cannot cause a TCP sender to send once the consent timer expires (30 seconds). - An endpoint that is not sending any application data does not need to - maintain consent. However, not sending any traffic could cause NAT - or firewall mappings to expire. Furthermore, having one peer unable - to send is detrimental to many protocols. Absent better information - about the network, if an endpoint needs to ensure its NAT or firewall - mappings do not expire, it can be done using keepalive or other - techniques (see Section 10 of [RFC5245] and see [RFC6263]). + An endpoint does not need to maintain consent if it does not send + application data. However, an endpoint MUST regain consent before it + resumes sending application data. In the absence of any packets, any + bindings in middleboxes for the flow might expire. Furthermore, + having one peer unable to send is detrimental to many protocols. + Absent better information about the network, if an endpoint needs to + ensure its NAT or firewall mappings do not expire, it can be done + using keepalive or other techniques (see Section 10 of [RFC5245] and + see [RFC6263]). After consent is lost, the same ICE credentials MUST NOT be used on the affected 5-tuple again. That means that a new session, or an ICE restart, is needed to obtain consent to send on the affected candidate pair. 5.2. Immediate Revocation of Consent In some cases it is useful to signal that consent is terminated rather than relying on a timeout.