One document matched: draft-ietf-rtcweb-stun-consent-freshness-08.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-08"
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. 
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
To prevent attacks on peers, 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 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="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 for consent to continue sending traffic. 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, performs consent freshness 
test using STUN request/response as described below:
</t>
<t>
An endpoint MUST NOT send paced STUN connectivity checks 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 obtained following
the procedure described in this document.
</t>
<t>
Explicit consent to send is obtained by sending an STUN binding request
to the remote peer's transport address and receiving a matching,
authenticated, non-error STUN binding response from the remote peer's
transport address. These STUN 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 is granted as a result of a successful ICE connectivity 
check on a particular transport address, and expires 30 seconds after an 
ICE candidate par has been selected. Once an ICE candidate pair has been 
selected, consent for the ICE candidate pairs lasts for 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 <xref
target="RFC4086">cryptographically-random</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, and a response might be for a previous request
(rather than for the most recently sent request).  Consent expiration causes 
immediate termination of all outstanding STUN consent transactions. Each 
STUN transaction is maintained until one of the following criteria is 
fulfilled:<list style="symbols">
<t>A STUN response associated with the transaction is received; or</t>
<t>A STUN response associated to a newer transaction is received.</t>
</list>
</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>
To prevent attacks on the peer during ICE restart, an endpoint that
 continues to send traffic on the previously validated candidate 
 pair during ICE restart MUST continue to perform consent freshness 
 on that candidate pair as described earlier.
</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, the endpoint needs to ensure its NAT or
firewall mappings persist which can be done using keepalive or other
techniques (see Section 10 of <xref target="RFC5245"></xref> and see
<xref target="RFC6263"></xref>). If the endpoint wants to send
application data, it needs to first obtain consent if its consent
has expired.
</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="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="DTLS applicability">
<t>The DTLS applicability is identical to what is described in Section 4.2
 of <xref target="RFC7350"></xref>. </t>
</section>

<section title="API Recommendations">
<t>
The W3C specification MAY provide the following API 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>
</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, Jonathan Lennox, Inaki Baz Castillo, Rajmohan Banavi 
and Christian Groves for their valuable inputs and comments. Thanks to 
Christer Holmberg for doing a through review.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.5245"?>
<?rfc include="reference.RFC.4086"?>
<?rfc include="reference.RFC.6263"?>
</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.7350"?>

</references>
</back>
</rfc>