Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness
Extracted elements (28)
ICE keepalives are STUN Indications (send-and-forget) and do not evoke a response, so they are insufficient for consent freshness. A request/response mechanism is required, and STUN binding requests serving as consent checks also serve the keepalive purpose, eliminating the need for dedicated keepalive messages on those pairs.
In multi-party sessions using shared SRTP keying (MIKEY, Security Descriptions, EKT), receipt of an authenticated SRTP packet is not sufficient to verify consent, because any party with the shared key could have sent it. Hence, STUN-based consent is required even when SRTP authentication is present.
The 30-second consent expiry was chosen to balance minimizing response time to loss of consent against reducing spurious failures. The randomized check interval (0.8–1.2× base period) prevents synchronization of consent checks across multiple endpoints.
The consent mechanism is an optional extension deployable at one end of a two-party session without impact on the other party, since ICE-lite agents already respond to normal ICE connectivity checks and no changes are required for them.
Although TCP has its own consent mechanism (TCP acknowledgements), consent checks are still necessary over TCP connections because they could be translated to UDP connections (e.g., via TURN TCP allocations per RFC 6062).
ICE-lite agents do not generate consent checks and will only respond to any checks they receive. No changes are required to ICE-lite implementations to respond to consent checks, as they are processed as normal ICE connectivity checks.
The DTLS applicability of this consent mechanism is identical to what is described in Section 4.2 of RFC 7350 (DTLS as Transport for STUN).
After consent is lost, the same ICE credentials MUST NOT be used on the affected 5-tuple again; a new session or ICE restart is needed.
All outstanding STUN consent transactions for a candidate pair MUST be discarded when consent expires.
An endpoint MUST NOT send data other than the messages used to establish consent unless the receiving endpoint has consented to receive data. No application data (e.g., RTP or DTLS) can be sent until consent is obtained.
An endpoint MUST regain consent before it resumes sending application data after a period of not sending.
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.
An endpoint SHOULD await a binding response for each consent request for a time based on the estimated RTT with an allowance for network delay variation.
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.
An untrusted application (e.g., JavaScript or signaling servers) MUST NOT be able to obtain or control the STUN transaction identifier, because that enables spoofing of STUN responses, falsifying consent.
Consent checks MUST be performed over all transport connections, including TCP, to prevent an off-path attacker spoofing TCP segments from causing a TCP sender to send indefinitely.
Each STUN binding request for consent MUST use a new STUN transaction identifier, as described in Section 6 of RFC 5389. Each STUN binding request for consent is transmitted once only.
If a valid STUN binding response has not been received from the remote peer's transport address in 30 seconds, the endpoint MUST cease transmission on that 5-tuple.
Implementations SHOULD set a default consent check interval of 5 seconds, resulting in a randomized period between checks of 4 to 6 seconds.
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 RFC 5245 for a given 5-tuple.
To prevent synchronization of consent checks, each interval MUST be randomized from between 0.8 and 1.2 times the basic period. Implementations MUST NOT set the period between checks to less than 4 seconds.
Consent applies to a single 5-tuple and expires after 30 seconds if no valid STUN binding response is received. An endpoint gains initial consent when the ICE candidate pair enters the Succeeded state.
Consent for sending application data is immediately revoked by receipt of an authenticated message closing the connection (e.g., a TLS fatal alert) or a valid, authenticated STUN response with error code Forbidden (403).
Consent is obtained and maintained by sending a STUN binding request to the remote peer's transport address and receiving a matching, authenticated, non-error STUN binding response. These are authenticated using the same short-term credentials as the initial ICE exchange.
Receipt of an unauthenticated message closing a connection (e.g., TCP FIN) does NOT indicate revocation of consent. An authenticated SRTCP BYE also does not terminate consent; it only indicates the associated SRTP source has quit.
Consent requires a 96-bit STUN transaction ID (per RFC 5389 Section 6) to be uniformly and randomly chosen from 0..2^96-1 and be cryptographically strong, providing security against off-path attackers replaying old STUN consent responses.
The consent mechanism prevents a malicious JavaScript application from using the browser as a platform to launch traffic attacks against unwilling victims by requiring ongoing verified consent from the remote endpoint for every 5-tuple.
Consent state transitions: initial consent is gained when an ICE candidate pair enters the Succeeded state; consent is maintained by successful periodic STUN binding request/response exchanges; consent is lost when no valid response is received within 30 seconds or an authenticated revocation message is received.