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