STUN Usage for Consent
Freshness
Ericsson
Ferns Icon
Doddanekundi, Mahadevapura
Bangalore
Karnataka
560037
India
muthu.arul@gmail.com
Cisco Systems
821 Alder Drive
Milpitas
California
95035
USA
dwing@cisco.com
Cisco Systems
Cessna Business Park
Sarjapur-Marathahalli Outer Ring Road
Bangalore
Karnataka
560103
India
rmohanr@cisco.com
Cisco Systems
Cessna Business Park, Varthur Hobli
Sarjapur Marathalli Outer Ring Road
Bangalore
Karnataka
560103
India
tireddy@cisco.com
Mozilla
Suite 300
650 Castro Street
Mountain View
California
94041
US
martin.thomson@gmail.com
RAI
RTCWEB
To prevent sending excessive traffic to an endpoint, periodic consent
needs to be obtained from that remote endpoint.
This document describes a consent mechanism using a new Session
Traversal Utilities for NAT (STUN) usage.
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 Interactive Connectivity Establishment ICE
connectivity checks, and periodically for the duration of the session
using the procedures defined in this document.
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.
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.
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 .
The mechanism of obtaining permission to send to a remote transport
address. Initial consent is obtained using ICE or a TCP handshake.
Maintaining and renewing consent over time.
The remote peer's IP address and UDP or TCP port number.
Although ICE requires periodic keepalive traffic to keep NAT bindings
alive (Section 10 of , ), 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
.
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.
A WebRTC
implementation, which implements full ICE, performs consent freshness
test using STUN request/response as described below:
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.
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.
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., ).
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.
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.
Each STUN binding request for consent MUST use a new cryptographically-random 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:
A STUN response associated with the transaction is received; or
A STUN response associated to a newer transaction is received.
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.
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.
While TCP affords some protection from off-path attackers (, ), 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).
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 and see
). If the endpoint wants to send
application data, it needs to first obtain consent if its consent
has expired.
In some cases it is useful to signal that consent is terminated rather
than relying on a timeout.
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.
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.
Note that an authenticated SRTCP BYE does not terminate consent; it
only indicates the associated SRTP source has quit.
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 for a given 5-tuple.
It is possible that different Diffserv Codepoints are used by
different media over the same transport address . Such a case is outside
the scope of this document.
The DTLS applicability is identical to what is described in Section 4.2
of .
The W3C specification MAY provide the following API to provide
feedback and control over consent:
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.
This document describes a security mechanism.
The security considerations discussed in
should also be taken into account.
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 MIKEY modes, Security
Descriptions, and EKT. Thus, in such shared
keying distributions, receipt of an authenticated SRTP packet is not
sufficient to verify consent.
This document does not require any action from IANA.
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.