]> Meta Platforms Inc.

philipp.hancke@googlemail.com

OpenAI

justin@uberti.name

Google

jonaso@google.com

ART Audio/Video Transport Core Maintenance webrtc stun dtls WebRTC setup normally serializes ICE and DTLS, adding at least one extra round trip before secure media can flow. This document defines the STUN Protocol for Embedding DTLS (SPED), which carries DTLS handshake data and acknowledgements inside STUN Binding Requests and Responses. SPED allows ICE and DTLS to proceed in parallel, improves setup behavior under loss, and remains backward compatible with existing ICE processing. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the AVTCORE Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The current WebRTC connection setup, as outlined in , incurs a minimum of 4 RTTs with DTLS 1.2, or 3 RTTs with DTLS 1.3, before media can be sent. The serialization of ICE and DTLS is a large contributor to that as illustrated below for DTLS 1.2: | |<-1---------- SDP Answer (passive)----------| | | |<-2---------- ICE/Connectivity Checks ----->| | | |------------- DTLS ClientHello ------------>| |<-3---------- DTLS ServerHello -------------| |------------- DTLS Finished --------------->| |<-4---------- DTLS Finished ----------------| | | |------------- Application data ------------>| ]]> In addition, deployment experience has shown connection setup reliability issues in scenarios with packet loss, caused by the exponential backoff timer typically used in DTLS implementations. The protocol defined in this specification, SPED, aims to resolve these concerns by embedding the DTLS handshake into STUN, eliminating the delay caused by the serialization of the protocols and improving reliability by sending fewer packets as well as simplifying retransmissions. In fact, when DTLS 1.3 is used, the protocol can reduce the setup latency to as little as a single round-trip, comparable to the latency of the largely deprecated SDES key exchange mechanism . The protocol is backward compatible, supports both DTLS 1.2 and DTLS 1.3 , and can accommodate all DTLS cipher suites, including post-quantum cryptography (PQC) suites that can increase the number of packets sent during DTLS handshaking.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Design

Background

ICE Overview The ICE protocol is complex, but the core steps taken by each ICE agent (client) can be summarized as follows:

1. Enumerate local ICE candidates and send them, out-of-band, to the peer.
2. Combine local ICE candidates with the received remote ICE candidates to form ICE candidate pairs.
3. Evaluate the usability of these ICE candidate pairs by sending STUN Binding Requests. This typically happens in parallel, i.e. an ICE agent may have several binding requests in flight when there are multiple candidate pairs.
4. When a STUN Binding Request is received, reply with a STUN Binding Response.
5. When a STUN Binding Response is received, in response to a request, mark the associated ICE candidate pair as valid.
6. If the ICE agent is in the controlling role, select the "best" ICE candidate pair for subsequent sending of data or media, and indicate the selected candidate pair to the remote ICE agent by sending a new STUN Binding Request with the USE-CANDIDATE flag set.

Some endpoints, typically servers, implement a simpler form of ICE known as ICE Lite . When this form of ICE is used, the ICE Lite endpoint omits steps 3 and 5, and Binding Requests only flow in one direction, from the full to the lite endpoint.

DTLS Overview In WebRTC, DTLS handshaking normally starts once ICE has identified a valid candidate pair, using "client" and "server" roles determined through the a=setup attribute in WebRTC SDP signaling . SPED changes when these DTLS packets can be sent, but not the DTLS handshake contents themselves. We define the term "DTLS packet" to mean the unit of DTLS data typically carried in a single UDP packet. DTLS handshake messages are also organized into "DTLS flights", as detailed in . A DTLS flight consists of a set of handshake messages that are sent together by a DTLS endpoint, and those messages are carried in one or more DTLS packets. Ideally, a flight, even if it contains multiple messages, can fit into a single DTLS packet. However, if a message is large, for example a large certificate, it can be fragmented across multiple DTLS packets. The DTLS flights used during WebRTC session setup are described below. Note that because ICE has already demonstrated remote consent, DTLS' HelloVerifyRequest is not needed to prevent DoS attacks. Once the DTLS handshake has completed, SRTP key extraction occurs and is used to key the sending of media . Media cannot be properly decrypted until all handshake messages have been received.

DTLS 1.2 Handshake The DTLS 1.2 handshake, as specified in , is organized into the following DTLS flights:

1. The DTLS client sends the ClientHello message.
2. The DTLS server responds with the ServerHello, Certificate, ServerKeyExchange, CertificateRequest, and ServerHelloDone messages, packed as noted above.
3. The DTLS client sends the Certificate, ClientKeyExchange, CertificateVerify, ChangeCipherSpec, and Finished messages.
4. The DTLS server sends the ChangeCipherSpec and Finished messages.

Note that DTLS 1.2 does not provide a separate acknowledgement for the server's final flight, so determination of handshake completion must be done implicitly, e.g., via receipt of application data or expiration of retransmission timers.

DTLS 1.3 Handshake The DTLS 1.3 handshake, as specified in , is organized into the following DTLS flights:

1. The DTLS client sends the ClientHello message.
2. The DTLS server sends the ServerHello, EncryptedExtensions, CertificateRequest, Certificate, CertificateVerify, and Finished messages.
3. The DTLS client sends the Certificate, CertificateVerify, and Finished messages.

Note that in DTLS 1.3, the DTLS server sends a DTLS acknowledgement packet upon receiving the Finished message, but the client does not need to wait for this message to begin sending encrypted data.

Goals The desired properties of this solution are:

• It makes WebRTC setup faster by 1 RTT, by allowing ICE and DTLS to proceed in parallel.
• It makes WebRTC session setup less susceptible to packet loss.
• It is strictly an optimization.
• It reduces the number of packets exchanged during session setup, but the size of the STUN Binding Request or Response increases.
• In the event of an incompatibility, each client proceeds with ICE and DTLS as usual.
• It works with all versions of DTLS >= 1.2, and all DTLS cipher suites.
• It is fully backward compatible with existing ICE processing, including interactions with ICE Lite endpoints, as well as endpoints that demultiplex multiple ICE sessions on the same port.

SPED Protocol

Summary The overall mechanism can be summarized as follows:

1. DTLS is started at the same time as ICE.
2. If there is no valid ICE candidate pair, DTLS handshake packets are sent by encapsulating them in a new STUN attribute in the next STUN Binding Request or STUN Binding Response.
3. Once a valid ICE candidate pair exists, the client can continue to send DTLS packets either in embedded form, or as usual over the specified pair.

In addition, to improve the reliability of the DTLS handshake, an explicit acknowledgement mechanism is built into SPED. Encapsulated DTLS handshake packets are acknowledged by sending their CRC-32 in a new STUN attribute in the next STUN Binding Request or STUN Binding Response.

New STUN Attributes This STUN extension defines the following new IETF-assigned attributes in the comprehension-optional range:

• TBD1: DTLS-IN-STUN-DATA
• TBD2: DTLS-IN-STUN-ACK

These attributes have lengths that are not always multiples of 4. By the rules of STUN, any attribute whose length is not a multiple of 4 bytes MUST be immediately followed by 1 to 3 padding bytes to ensure the next attribute, if any, starts on a 4-byte boundary; see .

DTLS-IN-STUN-DATA

• This attribute contains one DTLS handshake packet, or is empty to indicate SPED support when no DTLS packet is being embedded.
• While SPED is active, this attribute MUST be present in every STUN Binding Request or Response sent by a SPED-capable agent.
• The value portion of this attribute is variable length and consists of one DTLS handshake packet from a DTLS flight, as described in or .
• As noted, if the attribute length is not a multiple of 4, padding must be added.
• If the value portion of this attribute is empty, it indicates SPED support and that no DTLS packet is being embedded in that STUN message. An empty value MUST NOT be injected into the DTLS layer.
• If the value portion of this attribute is non-empty but the first byte is not DTLS, i.e. between 20 and 63 inclusive as described in , the attribute SHOULD be silently discarded.

DTLS-IN-STUN-ACK

• This attribute contains acknowledgements of received DTLS-IN-STUN-DATA packets in the order they were received.
• The attribute can be present in either a STUN Binding Request or Response.
• The attribute is variable length and contains a list of uint32 entries, where each entry is the computed CRC-32 of a received DTLS-IN-STUN-DATA attribute value, i.e. a DTLS handshake packet, ignoring padding.
• Implementations SHOULD cap the number of uint32 entries included in this attribute. A cap of 4 entries is RECOMMENDED, which bounds the attribute size while still covering all known handshake cases.
• The attribute can be empty, i.e. the length of the list of uint32 values can be 0.

MTU Considerations When embedding DTLS in STUN, the DTLS MTU MUST take into account the STUN packet overhead, which is noted in the table below:

Attribute	Size	Defined in
STUN header	20
ICE-CONTROLLED / ICE-CONTROLLING	12
PRIORITY	8
USE-CANDIDATE	4	; not on first packet but on subsequent packets
MESSAGE-INTEGRITY	24
MESSAGE-INTEGRITY-SHA256	36	; only applicable when ice2 is used
FINGERPRINT	8
DTLS-IN-STUN-DATA	4	This specification. Overhead for the attribute header
DTLS-IN-STUN-ACK	4-20	This specification. 4 byte attribute header plus 0 to 16 bytes for 0 to 4 CRC-32 values under the RECOMMENDED cap
USERNAME	16+	. Variable, typically 4 byte header plus 9 bytes for two four-byte username fragments and the colon plus 3 bytes padding. The actual size is known before the DTLS exchange starts, either from the SDP exchange or a peer-reflexive candidate
TURN XOR-PEER-ADDRESS	24	. Assuming 16 byte IPv6; only applicable when TURN is used

Accordingly, the typical 1200 byte DTLS MTU, based on the recommendation in , MUST be reduced by the size of the expected overhead. Applications that use custom STUN attributes, i.e. not in the table above, MUST reduce the DTLS MTU further.

Backwards Compatibility SPED is fully backwards compatible with existing ICE agents. If the peer ICE agent does not support SPED, this can be detected via the lack of the mandatory DTLS-IN-STUN-DATA attribute in its first authenticated ICE check or response, and upon recognizing this fact the local ICE agent can easily fall back to standard unencapsulated DTLS. Given this straightforward in-band negotiation, this specification does not currently define an offer/answer negotiation mechanism or any ICE options. Note that even if an ICE option were used, the offerer would still need to be prepared to handle ICE checks, with or without SPED, that arrive before the signaling answer.

Mechanism The specifics of the SPED algorithm are detailed below.

Setup When using SPED, an ICE agent keeps two lists:

1. A list, L1, of pending DTLS handshake packets. These packets are created by the DTLS layer. Elements in the list are removed when ACKed by the peer. The list is cleared when the DTLS layer creates a new flight or the DTLS handshake completes.
2. A list, L2, of pending acknowledgements, as defined above. Entries in L2 are created when embedded DTLS packets are received. Entries MAY be sent more than once to improve robustness against STUN loss.

Sending a STUN Binding Request or Response When sending a STUN Binding Request or Response, the ICE agent MUST follow the steps below:

1. Embed any pending ACKs from L2 in a DTLS-IN-STUN-ACK attribute.
2. If there is a pending DTLS handshake packet in L1 and sufficient space remains in the STUN message, embed one DTLS handshake packet from L1 into a DTLS-IN-STUN-DATA attribute. When multiple packets are pending in L1, round-robin selection is RECOMMENDED.
3. Otherwise, include DTLS-IN-STUN-DATA with an empty value simply to indicate SPED support.

Receiving a STUN Binding Request or Response When receiving a STUN Binding Request or Response, the ICE agent MUST follow the steps below:

1. If this is the first authenticated STUN message received from the peer, and the DTLS-IN-STUN-DATA attribute is not present, conclude that the peer does not support SPED, and conclude SPED processing.
2. If the STUN message contains a DTLS-IN-STUN-ACK attribute, process the CRC-32 values in the attribute and remove each ACKed DTLS handshake packet from L1.
3. If the STUN message contains a non-empty DTLS-IN-STUN-DATA attribute, inject the attribute data into the DTLS layer and add the CRC-32 of the attribute value to L2.

Termination Once a valid ICE candidate pair exists and direct sending is possible, implementations MAY terminate use of SPED and send DTLS directly. Implementations MAY instead continue to send embedded DTLS until DTLS handshaking is complete, for example, to continue to use SPED's explicit acknowledgement mechanism.

Examples

Vanilla DTLS 1.2 | |<-1------ SDP Answer (a=setup:passive) -----| | | |--------- STUN BindingRequest ------------->| |<-2------ STUN BindingResponse -------------| | | |--------- DTLS F1: ClientHello ------------>| |<-3------ DTLS F2: ServerHello, etc---------| |--------- DTLS F3: Finished, etc ---------->| |<-4------ DTLS F4: Finished, etc -----------| |--------- Application data ---------------->| ]]>

DTLS 1.2 with SPED With a=setup:passive in the SDP answer, the offerer is the DTLS client: | |<-1------ SDP Answer (a=setup:passive)------| | | |--------- BindingRequest/DTLS F1 ---------->| |<-2------ BindingResponse/DTLS F2 ----------| | | |--------- DTLS F3: Finished --------------->| |<-3------ DTLS F4: Finished ----------------| |--------- Application data ---------------->| ]]> With a=setup:active in the SDP answer, the answerer is the DTLS client: | |<-1------ SDP Answer (a=setup:active)-------| | | |--------- BindingRequest/{} --------------->| |<-2------ BindingResponse/DTLS F1 ----------| | | |--------- DTLS F2: ServerHello ------------>| |<-3------ DTLS F3: Finished ----------------| |--------- DTLS F4: Finished --------------->| |--------- Application data ---------------->| ]]> The flows are similar when the server uses ICE Lite.

Vanilla DTLS 1.3 | |<-1------ SDP Answer (a=setup:passive) -----| | | |--------- STUN BindingRequest ------------->| |<-2------ STUN BindingResponse -------------| | | |--------- DTLS F1: ClientHello ------------>| |<-3------ DTLS F2: ServerHello, etc --------| |--------- DTLS F3: Finished --------------->| |--------- Application data ---------------->| |<-------- DTLS ACK -------------------------| ]]>

DTLS 1.3 with SPED With a=setup:passive in the SDP answer, the offerer is the DTLS client: | |<-1------ SDP Answer (a=setup:passive)------| | | |--------- BindingRequest/DTLS F1 ---------->| |<-2------ BindingResponse/DTLS F2 ----------| | | |--------- DTLS F3: Finished --------------->| |--------- Application data ---------------->| |<-------- DTLS ACK -------------------------| ]]> With a=setup:active in the SDP answer, the answerer is the DTLS client, and an additional RTT is incurred: | |<-1------ SDP Answer (a=setup:active)-------| | | |--------- BindingRequest/{} --------------->| |<-2------ BindingResponse/DTLS F1 ----------| | | |--------- DTLS F2: ServerHello, etc ------->| |<-3------ DTLS F3: Finished ----------------| |--------- Application data ---------------->| |--------- DTLS ACK ------------------------>| ]]> Again, the flows are similar when the server uses ICE Lite.

DTLS 1.3 with Non-SPED Peer | |<-------- BindingResponse/ ---| ]]> The absence of a DTLS-IN-STUN-DATA attribute allows the client to conclude that the server does not support SPED. | |<-------- DTLS F2: ServerHello ------------ | |--------- DTLS F3: Finished --------------->| |--------- Application data ---------------->| |<-------- DTLS ACK -------------------------| ]]>

DTLS 1.3 with Flight 2 Loss | <- LOST BindingResponse/DTLS F2 -----------| |<-------- BindingRequest/DTLS F2 ------------| |--------- BindingResponse/DTLS F3 ---------->| |--------- Application data ----------------->| |<-------- DTLS ACK --------------------------| ]]>

DTLS 1.3 with Flight 3 Loss | |<-------- DTLS ServerHello ------------------| |--------- DTLS Finished ------------ LOST -> | |--------- BindingRequest/F3=DTLS Finished--->| ]]> Note: The embedding continues until both client and server are known to be writable, but ICE does not send any packets it would not otherwise send. | |<-------- BindingResponse/ACK={F3} ----------| ]]>

DTLS 1.3 PQC with Certificate Fragment Loss The DTLS ClientHello is split into 2 packets. The DTLS ServerHello is split into 2 packets. | <- LOST BindingResponse/ACK={} ---| |<-------- BindingRequest/ACK={F1/1} ---------| ]]> Note: When the server sends ACK{F1/1}, it does not yet have a DTLS packet to send since both of the packets from the ClientHello have arrived. | |<-------- BindingResponse/F2=ServerHello/1 --| |<-------- BindingRequest/F2=ServerHello/2 -->| |--------- BindingRequest/F3=DTLS Finished -->| |--------- DTLS Finished -------------------->| |--------- Application data ----------------->| |<-------- DTLS ACK --------------------------| ]]>

DTLS 1.3 PQC with Multiple Candidate Pairs and Certificate Fragment Loss The DTLS ClientHello is split into 2 packets. The DTLS ServerHello is split into 2 packets. There are two candidate pairs, CP1 and CP2. The ICE agent retransmits BindingRequest once. | CP1 <- LOST BindingResponse/ACK={F1/1} ---------| CP2 |--------- BindingRequest/F1=ClientHello/2 -->| CP2 <- LOST BindingResponse/F2=ServerHello/1 ---| CP1 |--------- BindingRequest/F1=ClientHello/1 --->| CP1 |<-------- BindingResponse/F2=ServerHello/1 ---| CP2 |--------- BindingRequest/ACK={F2/1} --------->| CP2 |<-------- BindingResponse/F2=ServerHello/2 ---| |--------- DTLS Finished ------------------------->| |--------- Application data ---------------------->| |<-------- DTLS ACK -------------------------------| ]]>

Implementation Notes The following configuration for the SPED stack is RECOMMENDED. Note that this guidance may change based on implementation and deployment experience:

1. When SPED is active, disable internal DTLS timeouts, and resume them when receiving the first STUN Binding Response.
2. When using a PQC cipher suite, reduce the DTLS MTU as needed so embedded DTLS packets still fit within the expected path MTU. Experiments with an MTU near 900 bytes have been promising, but the best fragmentation strategy requires more study.

Prior Work

ICE-DTLS The draft from 2012 proposed a similar mechanism to SPED, in which a single RTT could be removed from session setup by replacing STUN Request and Response messages with DTLS ClientHello and ServerHello messages, rather than piggybacking the DTLS messages as SPED does. The ICE-DTLS mechanism ends up being considerably more complex than SPED, on account of the fact that the entirety of ICE functionality needs to be ported over to DTLS, for example consent checks, or retained as a complementary approach, for example peer address discovery. Furthermore, since it changes the details of connectivity negotiation, it is not backward compatible and therefore must be negotiated via SDP ice-options.

Future Work Embedding data into STUN requests is a technique that could also be used for early transmission or improved reliability of other important data. For example, one could imagine transferring key-frames, if small enough, or RTCP or SCTP control messages. However, this has not been thoroughly sketched out in this proposal.

Security Considerations

DTLS Replay and Spoofing This specification uses application-layer caching of DTLS packets which means packets can be sent multiple times using the same sequence number. For the receiver these are considered replays if received multiple times and rejected as described in . The embedded DTLS handshake is authenticated by existing ICE logic, i.e. the ICE USERNAME and MESSAGE-INTEGRITY mechanisms. Any spoofed ICE packets are rejected accordingly.

Pacing and Congestion The protocol defined in this specification increases the size of the STUN packets that are sent by the ICE agent to a peer without knowing if that peer can use the embedded data. Although the initial data sent is just the DTLS ClientHello, this packet can be close to a MTU when a PQC cipher suite is used. If this is unacceptable, an offer-answer mechanism for SPED can be used to address this concern. The STUN requests used for embedding DTLS are already paced as described in , which limits the outgoing bandwidth from this mechanism. However, that pacing assumes an ICE check of "less than 120 bytes", which will not be the case when a DTLS ClientHello is embedded, especially a PQC one. Solutions to this problem require transmitting the DTLS ClientHello less often, perhaps only on certain candidate pairs, and is a subject for further study.

IANA Considerations This document defines two new STUN attributes, DTLS-IN-STUN-DATA and DTLS-IN-STUN-ACK. These attributes need to be registered with IANA in the "STUN Attributes" registry, following the procedures defined in . Provisional names have been used in this draft and the registry.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document describes the mechanisms for allowing a JavaScript application to control the signaling plane of a multimedia session via the interface specified in the W3C RTCPeerConnection API and discusses how this relates to existing signaling protocols. This document defines a Session Description Protocol (SDP) cryptographic attribute for unicast media streams. The attribute describes a cryptographic key and other parameters that serve to configure security for a unicast media stream in either a single message or a roundtrip exchange. The attribute can be used with a variety of SDP media transports, and this document defines how to use it for the Secure Real-time Transport Protocol (SRTP) unicast media streams. The SDP crypto attribute requires the services of a data security protocol to secure the SDP message. [STANDARDS-TRACK] This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK] This document specifies version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection / non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document obsoletes RFC 6347. This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based communication. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN). This document obsoletes RFC 5245. This document specifies how to use the Session Initiation Protocol (SIP) to establish a Secure Real-time Transport Protocol (SRTP) security context using the Datagram Transport Layer Security (DTLS) protocol. It describes a mechanism of transporting a fingerprint attribute in the Session Description Protocol (SDP) that identifies the key that will be presented during the DTLS handshake. The key exchange travels along the media path as opposed to the signaling path. The SIP Identity mechanism can be used to protect the integrity of the fingerprint attribute from modification by intermediate proxies. [STANDARDS-TRACK] This document describes a Datagram Transport Layer Security (DTLS) extension to establish keys for Secure RTP (SRTP) and Secure RTP Control Protocol (SRTCP) flows. DTLS keying happens on the media path, independent of any out-of-band signalling channel present. [STANDARDS-TRACK] Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with Network Address Translator (NAT) traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them. STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC 3489), which presented STUN as a complete solution. This document obsoletes RFC 3489. [STANDARDS-TRACK] RFC 7983 defines a scheme for a Real-time Transport Protocol (RTP) receiver to demultiplex Datagram Transport Layer Security (DTLS), Session Traversal Utilities for NAT (STUN), Secure Real-time Transport Protocol (SRTP) / Secure Real-time Transport Control Protocol (SRTCP), ZRTP, and Traversal Using Relays around NAT (TURN) channel packets arriving on a single port. This document updates RFC 7983 and RFC 5764 to also allow QUIC packets to be multiplexed on a single receiving socket. This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based multimedia sessions established with the offer/answer model. This protocol is called Interactive Connectivity Establishment (ICE). ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN). ICE can be used by any protocol utilizing the offer/answer model, such as the Session Initiation Protocol (SIP). [STANDARDS-TRACK] Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with NAT traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs and does not require any special behavior from them. STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This document obsoletes RFC 5389. If a host is located behind a NAT, it can be impossible for that host to communicate directly with other hosts (peers) in certain situations. In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called "Traversal Using Relays around NAT" (TURN), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. TURN differs from other relay control protocols in that it allows a client to communicate with multiple peers using a single relay address. The TURN protocol was designed to be used as part of the Interactive Connectivity Establishment (ICE) approach to NAT traversal, though it can also be used without ICE. This document obsoletes RFCs 5766 and 6156. The WebRTC framework specifies protocol support for direct, interactive, rich communication using audio, video, and data between two peers' web browsers. This document specifies the non-media data transport aspects of the WebRTC framework. It provides an architectural overview of how the Stream Control Transmission Protocol (SCTP) is used in the WebRTC context as a generic transport service that allows web browsers to exchange generic data from peer to peer. Skype Interactivity Connectivity Establishment (ICE) connectivity checking using the Datagram Transport Layer Security (DTLS) handshake is described. The DTLS handshake provides sufficient information to identify valid candidates and establish consent.

Benchmark Numbers For the scenario without packet loss, benchmarking is straightforward, and the savings from SPED amount to 1 RTT, as expected. However, in packet loss scenarios, the savings can be much larger, especially in the worst (p95) cases. This is likely due in part to using ICE pacing rather than exponential backoff for DTLS retransmissions. In this benchmark, a 200 ms RTT is used. Packet loss is simulated using the virtual network mechanism in Google's libwebrtc. Duration is measured as time from start until both peers have completed the DTLS handshake.

DTLS 1.3 with PQC

DTLS 1.3 with PQC	Loss %	p10 (ms)	p50	average	p95
Vanilla	0	850	850	850	850
SPED	0	650	650	650	650
Vanilla	5%	850	850	947	1253
SPED	5%	650	650	656	700
Vanilla	10%	850	900	1193	2170
SPED	10%	650	650	685	800
Vanilla	25%	850	1350	2020	3080
SPED	25%	650	750	850	1105

DTLS 1.3

DTLS 1.3	Loss %	p10 (ms)	p50	average	p95
Vanilla	0	750	750	750	750
SPED	0	550	550	550	550
Vanilla	5%	750	750	800	1150
SPED	5%	550	550	555	600
Vanilla	10%	750	750	935	1200
SPED	10%	550	550	560	600
Vanilla	25%	750	1150	1400	2560
SPED	25%	550	600	620	750

DTLS 1.2

DTLS 1.2	Loss %	p10 (ms)	p50	average	p95
Vanilla	0	850	850	850	850
SPED	0	650	650	650	650
Vanilla	5%	850	850	916	1300
SPED	5%	650	650	695	1150
Vanilla	10%	850	900	1133	2150
SPED	10%	650	650	690	760
Vanilla	25%	850	1350	3920	8860
SPED	25%	750	750	862	1400

Acknowledgments