Audio/Video Transport Core Maintenance P. Hancke Internet-Draft Meta Platforms Inc. Intended status: Informational J. Uberti Expires: 6 May 2027 OpenAI J. Oreland Google 2 November 2026 STUN Protocol for Embedding DTLS (SPED) draft-hancke-webrtc-sped-01 Abstract 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 This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://fippo.github.io/warp-snap-sped/draft-hancke-webrtc-sped.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-hancke-webrtc-sped/. Discussion of this document takes place on the AVTCORE Working Group mailing list (mailto:avt@ietf.org), which is archived at https://datatracker.ietf.org/wg/avtcore/. Subscribe at https://www.ietf.org/mailman/listinfo/avt/. Source for this draft and an issue tracker can be found at https://github.com/fippo/warp-snap-sped. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Hancke, et al. Expires 6 May 2027 [Page 1] Internet-Draft SPED November 2026 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 6 May 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 3. Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4 3.1.1. ICE Overview . . . . . . . . . . . . . . . . . . . . 4 3.1.2. DTLS Overview . . . . . . . . . . . . . . . . . . . . 5 3.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. SPED Protocol . . . . . . . . . . . . . . . . . . . . . . 7 3.3.1. Summary . . . . . . . . . . . . . . . . . . . . . . . 7 3.3.2. Capability Negotiation . . . . . . . . . . . . . . . 7 3.3.3. New STUN Attributes . . . . . . . . . . . . . . . . . 8 3.3.4. MTU Considerations . . . . . . . . . . . . . . . . . 9 4. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Setup . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Sending a STUN Binding Request or Response . . . . . . . 11 4.3. Receiving a STUN Binding Request or Response . . . . . . 11 4.4. Direct Transmission on Selected Candidate Pairs . . . . . 12 4.5. Termination . . . . . . . . . . . . . . . . . . . . . . . 12 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Vanilla DTLS 1.2 . . . . . . . . . . . . . . . . . . . . 12 5.2. DTLS 1.2 with SPED . . . . . . . . . . . . . . . . . . . 12 5.3. Vanilla DTLS 1.3 . . . . . . . . . . . . . . . . . . . . 13 5.4. DTLS 1.3 with SPED . . . . . . . . . . . . . . . . . . . 14 5.5. DTLS 1.3 with Flight 2 Loss . . . . . . . . . . . . . . . 14 5.6. DTLS 1.3 with Flight 3 Loss . . . . . . . . . . . . . . . 14 Hancke, et al. Expires 6 May 2027 [Page 2] Internet-Draft SPED November 2026 5.7. DTLS 1.3 PQC with Certificate Fragment Loss . . . . . . . 15 5.8. DTLS 1.3 PQC with Multiple Candidate Pairs and Certificate Fragment Loss . . . . . . . . . . . . . . . . . . . . . . 15 6. Implementation Notes . . . . . . . . . . . . . . . . . . . . 16 6.1. DTLS Timers and MTU . . . . . . . . . . . . . . . . . . . 16 6.2. Candidate-Pair Selection and Bandwidth . . . . . . . . . 16 6.3. DTLS Role Selection . . . . . . . . . . . . . . . . . . . 17 7. Prior Work . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.1. ICE-DTLS . . . . . . . . . . . . . . . . . . . . . . . . 17 8. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9.1. DTLS Replay and Spoofing . . . . . . . . . . . . . . . . 18 9.2. Pacing and Congestion . . . . . . . . . . . . . . . . . . 18 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 10.1. STUN Attributes . . . . . . . . . . . . . . . . . . . . 18 10.2. ICE Option: sped . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 11.1. Normative References . . . . . . . . . . . . . . . . . . 19 11.2. Informative References . . . . . . . . . . . . . . . . . 19 Appendix A. Benchmark Numbers . . . . . . . . . . . . . . . . . 21 A.1. DTLS 1.3 with PQC . . . . . . . . . . . . . . . . . . . . 21 A.2. DTLS 1.3 . . . . . . . . . . . . . . . . . . . . . . . . 22 A.3. DTLS 1.2 . . . . . . . . . . . . . . . . . . . . . . . . 22 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction The current WebRTC connection setup, as outlined in [RFC8829], 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: Client Server | | |------------- SDP Offer (actpass)---------->| |<-1---------- SDP Answer (passive)----------| | | |<-2---------- ICE/Connectivity Checks ----->| | | |------------- DTLS ClientHello ------------>| |<-3---------- DTLS ServerHello -------------| |------------- DTLS Finished --------------->| |<-4---------- DTLS Finished ----------------| | | |------------- Application data ------------>| Hancke, et al. Expires 6 May 2027 [Page 3] Internet-Draft SPED November 2026 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 [RFC4568]. The protocol is backward compatible, supports both DTLS 1.2 [RFC6347] and DTLS 1.3 [RFC9147], and can accommodate all DTLS cipher suites, including post-quantum cryptography (PQC) suites that can increase the number of packets sent during DTLS handshaking. 2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Design 3.1. Background 3.1.1. ICE Overview The ICE protocol [RFC8445] 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. Hancke, et al. Expires 6 May 2027 [Page 4] Internet-Draft SPED November 2026 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 [RFC8445]. 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. 3.1.2. 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 [RFC5763]. 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 Section 5.7 of [RFC9147]. 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 [RFC5764]. Media cannot be properly decrypted until all handshake messages have been received. 3.1.2.1. DTLS 1.2 Handshake The DTLS 1.2 handshake, as specified in Section 4.2 of [RFC6347], is organized into the following DTLS flights: Hancke, et al. Expires 6 May 2027 [Page 5] Internet-Draft SPED November 2026 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. 3.1.2.2. DTLS 1.3 Handshake The DTLS 1.3 handshake, as specified in Section 5 of [RFC9147], 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. 3.2. 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. Hancke, et al. Expires 6 May 2027 [Page 6] Internet-Draft SPED November 2026 * 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. 3.3. SPED Protocol 3.3.1. Summary The overall mechanism can be summarized as follows: 1. Endpoints negotiate SPED support using the sped ICE option. 2. DTLS is started at the same time as ICE. 3. 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. 4. Once an ICE candidate pair is selected, DTLS handshake packets are sent directly over that pair and can also be embedded in STUN messages sent on other candidate pairs. In addition, to improve the reliability of the DTLS handshake, an explicit acknowledgement mechanism is built into SPED. DTLS handshake packets, whether received directly or embedded, are acknowledged by sending their CRC-32 in a new STUN attribute in the next STUN Binding Request or STUN Binding Response. 3.3.2. Capability Negotiation SPED support is negotiated with the sped ICE option in the SDP a=ice- options attribute, as described in Section 5.6 of [RFC8839]. The option applies to the ICE session and indicates support for the STUN attributes and procedures defined in this specification. 3.3.2.1. SDP Offer/Answer Procedures An offerer that wishes to use SPED MUST include the sped ICE option in its offer. If the offer contains sped, an answerer that supports SPED and wishes to use it MUST include sped in its answer. Otherwise, the answerer MUST NOT include the option. Hancke, et al. Expires 6 May 2027 [Page 7] Internet-Draft SPED November 2026 SPED is negotiated when sped appears in both the offer and answer. If the answer does not contain sped, the offerer MUST NOT send the STUN attributes defined in this specification and both endpoints continue with ordinary ICE and DTLS procedures. 3.3.2.2. STUN Checks Received Before the SDP Answer Connectivity checks from the answerer can reach the offerer before the SDP answer. An offerer that advertises sped MUST therefore be prepared to receive and process authenticated STUN messages containing SPED attributes before learning whether the answer includes the option. Offerers that receive SPED attributes in these early STUN messages SHOULD conclude that the answerer supports SPED, but absence of these attributes MUST NOT be used as an indication that the answerer does not support SPED. 3.3.2.3. Backward Compatibility and Fallback An endpoint that does not support SPED omits the sped ICE option from its answer, causing the offerer to use standard unencapsulated DTLS. 3.3.3. 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 [RFC5389]. 3.3.3.1. DTLS-IN-STUN-DATA * This attribute contains one DTLS handshake packet and can be present in either a STUN Binding Request or Response. * The value portion of this attribute is variable length and consists of one DTLS handshake packet from a DTLS flight, as described in Section 5.1 of [RFC9147] or Section 4.2 of [RFC6347]. Hancke, et al. Expires 6 May 2027 [Page 8] Internet-Draft SPED November 2026 * As noted, if the attribute length is not a multiple of 4, padding must be added. * The attribute MUST NOT be included when no DTLS handshake packet is being embedded. If an empty attribute is received, its 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 Section 3 of [RFC9443], the attribute SHOULD be silently discarded. 3.3.3.2. DTLS-IN-STUN-ACK * This attribute contains acknowledgements of received DTLS handshake packets, whether those packets arrived directly or in a DTLS-IN-STUN-DATA attribute, 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 handshake packet. For an embedded packet, the CRC-32 covers the DTLS-IN-STUN-DATA attribute value and ignores 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 SHOULD be omitted when there are no ACKs to send, but MAY be empty. 3.3.4. 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 | [RFC5389] | +--------------------------+------+-------------------------------+ | ICE-CONTROLLED / ICE- | 12 | Section 19.1 of [RFC5245] | | CONTROLLING | | | +--------------------------+------+-------------------------------+ | PRIORITY | 8 | Section 19.1 of [RFC5245] | Hancke, et al. Expires 6 May 2027 [Page 9] Internet-Draft SPED November 2026 +--------------------------+------+-------------------------------+ | USE-CANDIDATE | 4 | Section 19.1 of [RFC5245]; | | | | not on first packet but on | | | | subsequent packets | +--------------------------+------+-------------------------------+ | MESSAGE-INTEGRITY | 24 | Section 15.4 of [RFC5389] | +--------------------------+------+-------------------------------+ | MESSAGE-INTEGRITY-SHA256 | 36 | Section 14.6 of [RFC8489]; | | | | only applicable when ice2 is | | | | used Section 10 of [RFC8445] | +--------------------------+------+-------------------------------+ | FINGERPRINT | 8 | Section 15.5 of [RFC5389] | +--------------------------+------+-------------------------------+ | 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+ | Section 7.1.2.3 of [RFC5245]. | | | | 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 | [RFC8656]. Assuming 16 byte | | | | IPv6; only applicable when | | | | TURN is used | +--------------------------+------+-------------------------------+ Table 1 Accordingly, the typical 1200 byte DTLS MTU, based on the recommendation in [RFC8831], 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. Hancke, et al. Expires 6 May 2027 [Page 10] Internet-Draft SPED November 2026 4. Mechanism The specifics of the SPED algorithm are detailed below. 4.1. 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 DTLS handshake packets are received, either directly or embedded in STUN. Entries MAY be sent more than once to improve robustness against STUN loss. 4.2. Sending a STUN Binding Request or Response When sending a STUN Binding Request or Response, the ICE agent MUST follow the steps below: 1. If L2 contains pending acknowledgements, include them in a DTLS- IN-STUN-ACK attribute. 2. If L1 contains a pending DTLS handshake packet, sufficient space remains in the STUN message, and the candidate pair is eligible for embedding under the implementation's pacing policy, embed one packet from L1 in a DTLS-IN-STUN-DATA attribute. When multiple packets are pending in L1, round-robin selection is RECOMMENDED. 4.3. 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 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. 2. 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. Hancke, et al. Expires 6 May 2027 [Page 11] Internet-Draft SPED November 2026 4.4. Direct Transmission on Selected Candidate Pairs Once an ICE candidate pair is selected, an implementation MUST send DTLS handshake packets directly over that pair without waiting for a scheduled STUN message. The same packets MAY also be embedded in STUN messages on other candidate pairs, subject to normal ICE pacing and the implementation's bandwidth policy. While SPED is active, a directly received DTLS handshake packet is acknowledged by adding its CRC-32 to L2, just as for an embedded packet. The DTLS MTU for a flight that can still be embedded MUST continue to account for STUN overhead. 4.5. Termination Once a selected ICE candidate pair exists, DTLS handshake packets are sent directly as described above. Implementations MAY terminate use of SPED at that point, or continue embedding on other candidate pairs and sending explicit acknowledgements until DTLS handshaking is complete. Note that termination is unilateral; even if an implementation stops sending embedded packets, the remote implementation may continue to do so, and the local implementation MUST continue to process these embedded packets as described above. 5. Examples 5.1. Vanilla DTLS 1.2 Client Server | | |--------- SDP Offer ----------------------->| |<-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 ---------------->| 5.2. DTLS 1.2 with SPED With a=setup:passive in the SDP answer, the offerer is the DTLS client: Hancke, et al. Expires 6 May 2027 [Page 12] Internet-Draft SPED November 2026 Client Server | | |--------- SDP Offer ----------------------->| |<-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: Client Server | | |--------- SDP Offer ----------------------->| |<-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. 5.3. Vanilla DTLS 1.3 Client Server | | |--------- SDP Offer ----------------------->| |<-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 -------------------------| Hancke, et al. Expires 6 May 2027 [Page 13] Internet-Draft SPED November 2026 5.4. DTLS 1.3 with SPED With a=setup:passive in the SDP answer, the offerer is the DTLS client: Client Server | | |--------- SDP Offer ----------------------->| |<-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: Client Server | | |--------- SDP Offer (a=setup:actpass)------>| |<-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. 5.5. DTLS 1.3 with Flight 2 Loss Client Server | | |--------- BindingRequest/DTLS F1 ----------->| <- LOST BindingResponse/DTLS F2 -----------| |<-------- BindingRequest/DTLS F2 ------------| |--------- BindingResponse/DTLS F3 ---------->| |--------- Application data ----------------->| |<-------- DTLS ACK --------------------------| 5.6. DTLS 1.3 with Flight 3 Loss Hancke, et al. Expires 6 May 2027 [Page 14] Internet-Draft SPED November 2026 Client Server | | |<-------- BindingRequest/ACK={} -------------| |--------- BindingResponse/F1=ClientHello --->| |<-------- 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. |<-------- DTLS ACK --------------------------| |--------- Application data ----------------->| |<-------- BindingResponse/ACK={F3} ----------| 5.7. DTLS 1.3 PQC with Certificate Fragment Loss The DTLS ClientHello is split into 2 packets. The DTLS ServerHello is split into 2 packets. Client Server | | |--------- BindingRequest/F1=ClientHello/1 -->| <- 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. |--------- BindingRequest/F1=ClientHello/2 -->| |<-------- BindingResponse/F2=ServerHello/1 --| |<-------- BindingRequest/F2=ServerHello/2 -->| |--------- BindingRequest/F3=DTLS Finished -->| |--------- DTLS Finished -------------------->| |--------- Application data ----------------->| |<-------- DTLS ACK --------------------------| 5.8. 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. Hancke, et al. Expires 6 May 2027 [Page 15] Internet-Draft SPED November 2026 Client Server | | CP1 |--------- BindingRequest/F1=ClientHello/1 --->| 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 -------------------------------| 6. Implementation Notes The following guidance may change based on implementation and deployment experience. 6.1. DTLS Timers and MTU When SPED is active, retransmission will be handled within SPED. Accordingly, implementations SHOULD disable internal DTLS timeouts and resume them once they have terminated SPED. When negotiating a PQC cipher suite, implementations SHOULD 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. 6.2. Candidate-Pair Selection and Bandwidth Embedding DTLS does not create additional connectivity checks or change ICE's normal pacing, but it can substantially increase the size of each check. This is particularly relevant when a PQC handshake spans multiple packets or ICE checks several candidate pairs concurrently. Appendix B.1 of [RFC8445] describes an initial budget of approximately 14,600 bytes of outstanding connectivity-check traffic, and implementations SHOULD ensure that checks stay within that budget even when embedding DTLS packets. Hancke, et al. Expires 6 May 2027 [Page 16] Internet-Draft SPED November 2026 One approach is to only perform SPED embedding on a limited number of the candidate pairs being checked, typically those most likely to succeed (e.g., pairs using a relay candidate), in order to maximize the chance of a successful SPED exchange. Note that this suggested selection algorithm is somewhat different than ICE's built-in PRIORITY ordering. Another approach is to skip SPED embedding for pairs that have outstanding checks. When the available budget is exhausted, implementations SHOULD send their ICE connectivity checks without embedded DTLS until enough time passes to return to an under-budget state. 6.3. DTLS Role Selection For a client/server deployment using SPED, an answer with a=setup:passive lets the offerer act as the DTLS client and include its ClientHello in its first connectivity check. This can allow the server to become ready approximately half an RTT earlier than an a=setup:active answer. Without SPED, choosing a=setup:passive can instead delay server readiness by approximately half an RTT, as otherwise the server could have started the DTLS handshake upon receipt of the first ICE connectivity check. The presence of the sped ICE option can be used to select the optimal value for the setup attribute. 7. Prior Work 7.1. ICE-DTLS The [I-D.thomson-rtcweb-ice-dtls] 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. Hancke, et al. Expires 6 May 2027 [Page 17] Internet-Draft SPED November 2026 8. 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. 9. Security Considerations 9.1. 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 Section 4.5.1 of [RFC9147]. 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. 9.2. Pacing and Congestion Negotiating SPED with an ICE option prevents knowingly embedding DTLS for peers that do not support it, but embedding still increases the size of connectivity checks. A DTLS ClientHello, particularly one using PQC, can bring a STUN message close to the path MTU. The pacing in Appendix B.1 of [RFC8445] assumes connectivity checks of less than 120 bytes and does not, by itself, bound the bandwidth consumed by larger SPED messages. Implementations SHOULD account for actual STUN message sizes across candidate pairs, limit embedding to a subset of prioritized pairs, and continue unmodified ICE checks when the outstanding-data budget is exhausted, as described in Candidate-Pair Selection and Bandwidth above. 10. IANA Considerations 10.1. STUN Attributes 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 [RFC8489]. Provisional names have been used in this draft and the registry. Hancke, et al. Expires 6 May 2027 [Page 18] Internet-Draft SPED November 2026 10.2. ICE Option: sped IANA is requested to register the following value in the "ICE Options" subregistry of the "Interactive Connectivity Establishment (ICE)" registry: * ICE Option: sped * Contact: Authors of this document * Change Controller: IETF * Description: Support for embedding DTLS handshake packets and acknowledgements in STUN messages, as defined in this document. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 11.2. Informative References [I-D.thomson-rtcweb-ice-dtls] Thomson, M., "Using Datagram Transport Layer Security (DTLS) For Interactivity Connectivity Establishment (ICE) Connectivity Checking: ICE-DTLS", Work in Progress, Internet-Draft, draft-thomson-rtcweb-ice-dtls-00, 27 March 2012, . [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, . [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC5245, April 2010, . Hancke, et al. Expires 6 May 2027 [Page 19] Internet-Draft SPED November 2026 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, . [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 2010, . [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP)", RFC 5764, DOI 10.17487/RFC5764, May 2010, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, . [RFC8489] Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing, D., Mahy, R., and P. Matthews, "Session Traversal Utilities for NAT (STUN)", RFC 8489, DOI 10.17487/RFC8489, February 2020, . [RFC8656] Reddy, T., Ed., Johnston, A., Ed., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 8656, DOI 10.17487/RFC8656, February 2020, . [RFC8829] Uberti, J., Jennings, C., and E. Rescorla, Ed., "JavaScript Session Establishment Protocol (JSEP)", RFC 8829, DOI 10.17487/RFC8829, January 2021, . [RFC8831] Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data Channels", RFC 8831, DOI 10.17487/RFC8831, January 2021, . Hancke, et al. Expires 6 May 2027 [Page 20] Internet-Draft SPED November 2026 [RFC8839] Petit-Huguenin, M., Nandakumar, S., Holmberg, C., Keränen, A., and R. Shpount, "Session Description Protocol (SDP) Offer/Answer Procedures for Interactive Connectivity Establishment (ICE)", RFC 8839, DOI 10.17487/RFC8839, January 2021, . [RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, . [RFC9443] Aboba, B., Salgueiro, G., and C. Perkins, "Multiplexing Scheme Updates for QUIC", RFC 9443, DOI 10.17487/RFC9443, July 2023, . Appendix A. 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. A.1. 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 | +-------------------+--------+----------+------+---------+------+ Hancke, et al. Expires 6 May 2027 [Page 21] Internet-Draft SPED November 2026 +-------------------+--------+----------+------+---------+------+ | Vanilla | 25% | 850 | 1350 | 2020 | 3080 | +-------------------+--------+----------+------+---------+------+ | SPED | 25% | 650 | 750 | 850 | 1105 | +-------------------+--------+----------+------+---------+------+ Table 2 A.2. 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 | +----------+--------+----------+------+---------+------+ Table 3 A.3. 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 | Hancke, et al. Expires 6 May 2027 [Page 22] Internet-Draft SPED November 2026 +----------+--------+----------+------+---------+------+ +----------+--------+----------+------+---------+------+ | Vanilla | 10% | 850 | 900 | 1133 | 2150 | +----------+--------+----------+------+---------+------+ | SPED | 10% | 650 | 650 | 690 | 760 | +----------+--------+----------+------+---------+------+ +----------+--------+----------+------+---------+------+ | Vanilla | 25% | 850 | 1350 | 3920 | 8860 | +----------+--------+----------+------+---------+------+ | SPED | 25% | 750 | 750 | 862 | 1400 | +----------+--------+----------+------+---------+------+ Table 4 Acknowledgments Authors' Addresses Philipp Hancke Meta Platforms Inc. Email: philipp.hancke@googlemail.com Justin Uberti OpenAI Email: justin@uberti.name Jonas Oreland Google Email: jonaso@google.com Hancke, et al. Expires 6 May 2027 [Page 23]