One document matched: draft-ietf-rtcweb-stun-consent-freshness-09.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc='yes'?>
<?rfc tocdepth="3"?>
<?rfc compact="yes"?>
<?rfc tocdepth="yes"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline ="yes"?>
<?rfc subcompact="no"?>
<?rfc tocompact="yes"?>
<?rfc colonspace="yes"?>
<rfc category="std" docName="draft-ietf-rtcweb-stun-consent-freshness-09"
ipr="trust200902">
<front>
<title abbrev="STUN Usage for Consent Freshness">STUN Usage for Consent
Freshness</title>
<author fullname="Muthu Arul Mozhi Perumal" initials="M."
surname="Perumal">
<organization>Ericsson</organization>
<address>
<postal>
<street>Ferns Icon</street>
<street>Doddanekundi, Mahadevapura</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560037</code>
<country>India</country>
</postal>
<email>muthu.arul@gmail.com</email>
</address>
</author>
<author fullname="Dan Wing" initials="D" surname="Wing">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>821 Alder Drive</street>
<city>Milpitas</city>
<region>California</region>
<code>95035</code>
<country>USA</country>
</postal>
<email>dwing@cisco.com</email>
</address>
</author>
<author fullname="Ram Mohan Ravindranath" initials="R"
surname="Ravindranath">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>Cessna Business Park</street>
<street>Sarjapur-Marathahalli Outer Ring Road</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560103</code>
<country>India</country>
</postal>
<email>rmohanr@cisco.com</email>
</address>
</author>
<author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>Cessna Business Park, Varthur Hobli</street>
<street>Sarjapur Marathalli Outer Ring Road</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560103</code>
<country>India</country>
</postal>
<email>tireddy@cisco.com</email>
</address>
</author>
<author fullname="Martin Thomson" initials="M." surname="Thomson">
<organization>Mozilla</organization>
<address>
<postal>
<street>Suite 300</street>
<street>650 Castro Street</street>
<city>Mountain View</city>
<region>California</region>
<code>94041</code>
<country>US</country>
</postal>
<email>martin.thomson@gmail.com</email>
</address>
</author>
<date />
<area>RAI</area>
<workgroup>RTCWEB</workgroup>
<abstract>
<t>To prevent sending excessive traffic to an endpoint, periodic consent
needs to be obtained from that remote endpoint.</t>
<t>This document describes a consent mechanism using a new Session
Traversal Utilities for NAT (STUN) usage. This same mechanism can also
determine connection loss ("liveness") with a remote peer.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>To prevent attacks on peers, RTP endpoints have to ensure the remote
peer is willing to receive traffic. This is performed both when the
session is first established to the remote peer using <xref
target="RFC5245">Interactive Connectivity Establishment ICE</xref>
connectivity checks, and periodically for the duration of the session
using the procedures defined in this document.</t>
<t>When a session is first established, ICE implementations obtain an
initial consent to send by performing STUN connectivity checks. This
document describes a new STUN usage with exchange of request and
response messages that verifies the remote peer's ongoing consent to
receive traffic. This consent expires after a period of time and needs
to be continually renewed, which ensures that consent can be
terminated.</t>
<t>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.</t>
<t>This applies to full ICE implementations. An ICE-lite implementation
will not generate consent checks, but will just respond to consent
checks it receives. ICE-lite implementation do not require any changes
to respond to consent checks.</t>
</section>
<section anchor="sec-term" title="Terminology">
<t>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 <xref
target="RFC2119"></xref>.</t>
<t><list style="hanging">
<t hangText="Consent:">The mechanism of obtaining permission to send
to a remote transport address. Initial consent is obtained using ICE
or a TCP handshake.</t>
<t hangText="Consent Freshness:">Maintaining and renewing consent
over time.</t>
<t hangText="Session Liveness:">Detecting loss of connectivity to a
certain transport address.</t>
<t hangText="Transport Address:">The remote peer's IP address and
UDP or TCP port number.</t>
</list></t>
</section>
<section title="Design Considerations">
<t>Although ICE requires periodic keepalive traffic to keep NAT bindings
alive (Section 10 of <xref target="RFC5245"></xref>, <xref
target="RFC6263"></xref>), those keepalives are sent as STUN Indications
which are send-and-forget, and do not evoke a response. A response is
necessary both for consent to continue sending traffic, as well as to
verify session liveness. Thus, we need a request/response mechanism for
consent freshness. ICE can be used for that mechanism because ICE
implementations are already required to continue listening for ICE
messages, as described in section 10 of <xref
target="RFC5245"></xref>.</t>
</section>
<section title="Solution">
<t>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.</t>
<section title="Expiration of Consent">
<t>A <xref target="I-D.ietf-rtcweb-overview">WebRTC
implementation</xref>, which implements full ICE, MUST perform a
combined consent freshness and session liveness test using STUN
request/response as described below:</t>
<t>An endpoint MUST NOT send data other than paced STUN connectivity
checks or responses toward any transport address unless the receiving
endpoint consents to receive data. That is, no application data (e.g.,
RTP or DTLS) can be sent until consent is obtained. After a successful
ICE connectivity check on a particular transport address, consent MUST
be maintained following the procedure described in this document.</t>
<t>Explicit consent to send is obtained and maintained 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. <list style="hanging">
<t hangText="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., <xref
target="RFC6062"></xref>).</t>
</list></t>
<t>Initial consent to send traffic is obtained using ICE. Consent
expires after 30 seconds. That is, if a valid STUN binding response
corresponding to any STUN request 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. STUN consent responses
received after consent expiry do not re-establish consent, and may be
discarded or cause an ICMP error.</t>
<t>To prevent expiry of consent, a STUN binding request can be sent
periodically. To prevent synchronization of consent checks, each
interval MUST be randomized from between 0.8 and 1.2 times the basic
period. Implementations SHOULD set a default interval of 5 seconds,
resulting in a period between checks of 4 to 6 seconds.</t>
<t>Each STUN binding request for consent MUST use a new and <xref
target="RFC4086">cryptographically strong</xref> STUN transaction ID.
Each STUN binding requests for consent is transmitted once only.
Hence, the sender cannot assume that it will receive a response for
each consent request, or that responses will be ordered, since there
could be unreliable or unordered transports on the path. Each STUN
transaction ID is maintained until consent expires or a response is
received for either this transaction or a more recent transaction.</t>
<t>To meet the security needs of consent, an untrusted application
(e.g., JavaScript or signaling servers) MUST NOT be able to obtain or
control the STUN transaction ID, because that enables spoofing of STUN
responses, falsifying consent.</t>
<t>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.</t>
<t>While TCP affords some protection from off-path attackers (<xref
target="RFC5961"></xref>, <xref target="RFC4953"></xref>), 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 can not cause a TCP sender
to send once the consent timer expires (30 seconds).</t>
<t>An endpoint that is not sending any application data does not need
to maintain consent. However, failure to send could cause any NAT or
firewall mappings for the flow to expire. Furthermore, having one peer
unable to send is detrimental to many protocols.</t>
<t>After consent is lost for any reason, 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.</t>
</section>
<section title="Immediate Revocation of Consent">
<t>In some cases it is useful to signal that consent is terminated
rather than relying on a timeout.</t>
<t>Consent for sending application data is 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). Note however that consent
revocation messages can be lost on the network, so an endpoint could
resend these messages, or wait for consent to expire.</t>
<t>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.</t>
<t>Note that an authenticated SRTCP BYE does not terminate consent; it
only indicates the associated SRTP source has quit.</t>
</section>
</section>
<section anchor="liveness" title="Connection Liveness">
<t>Regular consent checks have the side effect of indicating liveness
for the selected 5-tuple. This allows for the timely detection of
network faults. A connection is considered "live" if authenticated
messages are received from a remote endpoint within a given period.</t>
<t>To support this use case, an application MAY be provided a means to
request a notification when there are no authenticated messages received
for a certain period.</t>
<t>An application MAY also be provided a means to alter the basic
consent check period from the default value (the suggested value being
5s) to any value up to 24 seconds. This ensures that connectivity checks
are not generated at an excessive rate and that at least one consent
check is sent every 30 seconds, allowing for the maximal 1.2 times
variation. Note that increasing the consent check period increases the
risk of packet loss causing consent expiration.</t>
<t>Sending consent checks (heartbeats) at a high rate could allow a
malicious application to generate congestion, so applications MUST NOT
send consent checks at an average rate of more than 1 per second.</t>
</section>
<section anchor="DSCP-consent" title="DiffServ Treatment for Consent">
<t>It is RECOMMENDED that STUN consent checks use the same Diffserv
Codepoint markings as the ICE connectivity checks described in Section
7.1.2.4 of <xref target="RFC5245"></xref> for a given 5-tuple. <list
style="hanging">
<t hangText="Note:">It is possible that different Diffserv
Codepoints are used by different media over the same transport
address <xref target="I-D.ietf-tsvwg-rtcweb-qos"></xref>. Such a
case is outside the scope of this document.</t>
</list></t>
</section>
<section title="API Recommendations">
<t>The W3C specification MAY provide the following API points to provide
feedback and control over consent: <list style="numbers">
<t>Generate an event when consent has expired for a given 5-tuple,
meaning that transmission of data has ceased. This could indicate
what application data is affected, such as media or data
channels.</t>
<t>Ability to set the consent check interval from its default
(recommended: 5 seconds) to any value between 1 second and 24
seconds.</t>
</list></t>
</section>
<section title="Security Considerations">
<t>This document describes a security mechanism.</t>
<t>The security considerations discussed in <xref
target="RFC5245"></xref> should also be taken into account.</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>. Thus, in such shared
keying distributions, receipt of an authenticated SRTP packet is not
sufficient to verify consent.</t>
</section>
<section anchor="sec.iana-considerations" title="IANA Considerations">
<t>This document does not require any action from IANA.</t>
</section>
<section title="Acknowledgement">
<t>Thanks to Eric Rescorla, Harald Alvestrand, Bernard Aboba, Magnus
Westerland, Cullen Jennings, Christer Holmberg, Simon Perreault, Paul
Kyzivat, Emil Ivov, and Jonathan Lennox for their valuable inputs and
comments.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.5245"?>
<?rfc include="reference.RFC.4086"?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.ietf-rtcweb-overview"?>
<?rfc include="reference.RFC.3830"?>
<?rfc include="reference.RFC.4568"?>
<?rfc include="reference.RFC.6062"?>
<?rfc include="reference.I-D.ietf-tsvwg-rtcweb-qos"?>
<?rfc include="reference.I-D.ietf-avtcore-srtp-ekt"?>
<?rfc include="reference.RFC.5961"?>
<?rfc include="reference.RFC.4953"?>
<?rfc include="reference.RFC.6263"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:58:13 |