One document matched: draft-thomson-rtcweb-consent-00.xml
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" ipr="trust200902" docName="draft-thomson-rtcweb-consent-00">
<front>
<title abbrev="Receive Consent">
Gaining and Maintaining Consent for Real-Time Applications
</title>
<author initials="M." surname="Thomson" fullname="Martin Thomson">
<organization>Mozilla</organization>
<address>
<postal>
<street>Suite 300</street>
<street>650 Castro Street</street>
<city>Mountain View</city>
<region>CA</region>
<code>94041</code>
<country>US</country>
</postal>
<email>martin.thomson@gmail.com</email>
</address>
</author>
<author fullname="Dan Wing" initials="D." surname="Wing">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>510 McCarthy Blvd.</street>
<city>Milpitas</city>
<region>CA</region>
<code>95035</code>
<country>US</country>
</postal>
<phone>(408) 853 4197</phone>
<email>dwing@cisco.com</email>
</address>
</author>
<author fullname="Cullen Jennings" initials="C." surname="Jennings">
<organization>Cisco</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone>+1 408 421-9990</phone>
<email>fluffy@cisco.com</email>
</address>
</author>
<date year="2013"/>
<area>Application</area>
<workgroup>RTCWEB</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>Consent</keyword>
<keyword>DTLS</keyword>
<abstract>
<t>
This document describes how DTLS provides a WebRTC application a clear indication that a
receiver is willing to receive packets. Mechanisms are described for maintaining that
consent are described.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
In addition to establishing connectivity, <xref target="RFC5245">Interactive Connectivity
Establishment (ICE)</xref> has been used in real-time applications to establish that a peer
is willing to receive packets.
</t>
<t>
This document describes how <xref target="RFC6347">Datagram Transport Layer Security
(DTLS)</xref> is sufficient for establishing consent to receive packets, plus how this
consent can be continuously refreshed.
</t>
<t>
This also uses <xref target="I-D.ietf-tls-applayerprotoneg">Application-Layer Protocol
Negotiation (ALPN)</xref> to restrict that consent to specific uses. Application protocol
tokens are defined for <xref target="RFC3550">the Real-Time Protocol (RTP)</xref> over <xref
target="RFC5764">DTLS-SRTP</xref>, <xref target="I-D.ietf-rtcweb-data-channel">WebRTC data
channels</xref> and a multiplexed combination of these two protocols.
</t>
<section anchor="terminology" title="Conventions and Terminology">
<t>
At times, this document falls back on shorthands for establishing interoperability
requirements on implementations: the capitalized words "MUST", "SHOULD" and "MAY". These
terms are defined in <xref target="RFC2119"/>.
</t>
</section>
</section>
<section anchor="consent" title="Obtaining and Maintaining Receive Consent">
<t>
An endpoint MUST NOT send application data (in WebRTC, RTP or SCTP data) on a DTLS
connection unless the receiving endpoint consents to receive the data.
</t>
<t>
An endpoint that initiates or responds to a DTLS handshake that negotiates a specific
application layer protocol (see <xref target="alpn"/>) explicitly consents to receive
packets containing the described protocol.
</t>
<t>
Consent expires after a fixed amount of time. Explicit consent to receive is indicated by
the receiving endpoint sending authenticated packets from the inverted 5-tuple. An endpoint
uses the receipt of packets as an indication that the remote endpoint still consents to
receive data.
</t>
<t>
Any packet received from the inverted 5-tuple refreshes consent if the packet is
successfully validated by the protocol's authentication check (for instance, a MAC). Any DTLS
message is sufficient to refresh consent, since these contain a MAC. For <xref
target="RFC5764">DTLS-SRTP</xref>, receipt of an authenticated SRTP packet is sufficient.
</t>
<t>
Consent is ended immediately by receipt of a an authenticated message that closes the
connection (for instance, a TLS fatal alert).
</t>
<t>
Receipt of an unauthenticated end-of-session message (e.g., TCP FIN) does not indicate loss
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.
</t>
<section title="Consent in WebRTC">
<t>
WebRTC applications MUST cease transmission on a connection if they have not received any
valid, authenticated packets for 30 seconds.
</t>
<t>
WebRTC applications that intend to maintain consent MUST send an authenticated packet at
least every 10 seconds. If there is no application data to send, the <xref
target="RFC6520">DTLS heartbeat extension</xref> MUST be sent to maintain consent. This
reduces the probability that transient network failures cause consent expiration.
</t>
</section>
<section title="The Role of ICE">
<t>
Given that DTLS is used to establish and maintain consent, ICE is only used to test and
nominate candidate pairs. This allows for the use of DTLS without ICE, though this is
unlikely to work for endpoints with poor connectivity.
</t>
<t>
If ICE is not employed, a DTLS server SHOULD use the denial of service countermeasures
described in Section 4.2.1 of <xref target="RFC6347"/>; specifically the <spanx
style="verb">HelloVerifyRequest</spanx> and the cookie that it carries.
</t>
</section>
<section title="Relationship with Connection Liveness">
<t>
A connection is considered "live" if packets are received from a remote endpoint within an
application-dependent period.
</t>
<t>
A WebRTC application can request a notification when there are no packets received for a
certain period. Similarly, an application can request that heartbeats are sent after an
interval shorter than 10 seconds. These two time intervals might be controlled by the
same configuration item.
</t>
<t>
Sending heartbeats at a high rate could allow a malicious application to generate
congestion. A WebRTC application MUST NOT be able to send heartbeats at a rate higher
than 1 per second.
</t>
</section>
</section>
<section anchor="alpn" title="Application Layer Protocol Identifiers">
<t>
The following ALPN identifiers are defined:
<list style="hanging">
<t hangText="RTP (0x52 0x54 0x50):">
This token indicates that <xref target="RFC5764">DTLS-SRTP</xref> is acceptable or
selected.
</t>
<t hangText="SCTP (0x53 0x43 0x54 0x50):">
This token indicates that <xref target="I-D.ietf-rtcweb-data-channel">WebRTC Data
Channels</xref> is acceptable or accepted. The DTLS record-layer carries encapsulated
<xref target="RFC4960">Stream Control Transmission Protocol (SCTP)</xref> packets as
described in <xref target="I-D.ietf-tsvwg-sctp-dtls-encaps"/>.
</t>
<t hangText="RTP+SCTP (0x52 0x54 0x50 0x2b 0x53 0x43 0x54 0x50):">
This token indicates that both <xref target="RFC5764">DTLS-SRTP</xref> and <xref
target="I-D.ietf-rtcweb-data-channel">WebRTC Data Channels</xref> are acceptable or
selected. The DTLS record-layer carries encapsulated SCTP packets as described in <xref
target="I-D.ietf-tsvwg-sctp-dtls-encaps"/>; this is multiplexed with <xref
target="RFC3711">SRTP</xref> packets as described in <xref target="RFC5764"/>.
</t>
</list>
</t>
<t>
An application that can use a multiplexed combination of SRTP and SCTP MUST select <spanx
style="verb">RTP+SCTP</spanx> if it is available, even if it is not using both protocols
initially. This avoids any need to renegotiate application layer protocols as usage needs
change.
</t>
</section>
<section anchor="security" title="Security Considerations">
<t>
This document defines a security mechanism.
</t>
<t>
Consent does not establish any bounds on the volume of packets that a receiver is willing to
accept. A receiver that receives packets at a rate in excess of what it is willing to
tolerate can close the connection. If the close message is lost, this can result in
unwanted data being received until consent expires (i.e., 30 seconds).
</t>
<t>
SRTP is encrypted and authenticated with symmetric keys; that is, both sender and receiver
know the keys. With two party sessions, receipt of an authenticated packet from the single
remote party is a strong assurance the packet came from that party. However, when a session
involves more than two parties, all of whom know each others keys, any of those parties
could have sent (or spoofed) the packet. Such shared key distributions are possible with
some <xref target="RFC3830">MIKEY</xref> modes, <xref target="RFC4568">Security
Descriptions</xref>, and <xref target="I-D.ietf-avtcore-srtp-ekt">EKT</xref>.
</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>
This document registers three identifiers in the "Application Layer Protocol Negotiation
(ALPN) Protocol IDs" established by <xref target="I-D.ietf-tls-applayerprotoneg"/>.
<list style="hanging">
<t hangText="Protocol:">RTP over DTLS-SRTP</t>
<t hangText="Identification Sequence:">0x52 0x54 0x50 ("RTP")</t>
<t hangText="Specification:">This document.</t>
<t hangText="Protocol:">WebRTC Data Channels</t>
<t hangText="Identification Sequence:">0x53 0x43 0x54 0x50 ("SCTP")</t>
<t hangText="Specification:">This document.</t>
<t hangText="Protocol:">RTP over DTLS-SRTP multiplexed with WebRTC Data Channels</t>
<t hangText="Identification Sequence:">0x52 0x54 0x50 0x2b 0x53 0x43 0x54 0x50 ("RTP+SCTP")</t>
<t hangText="Specification:">This document.</t>
</list>
</t>
</section>
<section anchor="ack" title="Acknowledgements">
<t>
Muthu Arul Mozhi Perumal, Ram Mohan Ravindranath, Tirumaleswar Reddy, and Dan Wing are the
authors of the original draft that dealt with managing consent.
</t>
</section>
<!--
<appendix title="Change Log">
<t>[[The RFC Editor is requested to remove this section at publication.]]</t>
<t>Changes since -0-1:
<list style="symbols">
<t>Document created.</t>
</list>
</t>
</appendix>
-->
</middle>
<back>
<references title="Normative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5245.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5764.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6347.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6520.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-tls-applayerprotoneg.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rtcweb-data-channel.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-tsvwg-sctp-dtls-encaps.xml"?>
</references>
<references title="Informative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3711.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3830.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4568.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4960.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-avtcore-srtp-ekt.xml"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:07:24 |