WebRTC Abridged Roundtrip Protocol (WARP)
draft-uberti-tsvwg-warp-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Justin Uberti , Philipp Hancke | ||
| Last updated | 2026-07-22 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-uberti-tsvwg-warp-00
Transport and Services Working Group J. Uberti
Internet-Draft OpenAI
Intended status: Standards Track P. Hancke
Expires: 23 January 2027 Meta Platforms Inc.
22 July 2026
WebRTC Abridged Roundtrip Protocol (WARP)
draft-uberti-tsvwg-warp-00
Abstract
This document outlines a set of improvements to the WebRTC session
setup protocols aimed at significantly reducing connection setup
latency. This improved setup mechanism is known as the WebRTC
Abridged Roundtrip Protocol (WARP). By addressing inefficiencies
within the current multi-protocol handshake process, WARP can reduce
setup latency from 6 RTTs to 2 RTTs when its optimizations are used
together, with a direct impact on perceived performance and
reliability.
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-uberti-tsvwg-warp-
latest.html. Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-uberti-tsvwg-warp/.
Discussion of this document takes place on the tsvwg Working Group
mailing list (mailto:tsvwg@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/tsvwg/. Subscribe at
https://www.ietf.org/mailman/listinfo/tsvwg/.
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/.
Uberti & Hancke Expires 23 January 2027 [Page 1]
Internet-Draft WARP July 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 23 January 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
1.1. Analysis . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5
3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Role of DTLS-SRTP . . . . . . . . . . . . . . . . . . . . 6
3.2. Areas for improvement . . . . . . . . . . . . . . . . . . 6
4. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 6
4.1. SNAP . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. SPED . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. DTLS 1.3 . . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. Total Savings . . . . . . . . . . . . . . . . . . . . . . 7
4.5. Deployment Experience . . . . . . . . . . . . . . . . . . 8
5. Best Practices . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. DTLS Role and a=setup . . . . . . . . . . . . . . . . . . 9
5.2.1. Client-server, server is DTLS client
(a=setup:active) . . . . . . . . . . . . . . . . . . 10
5.2.2. Client-server, server is DTLS server
(a=setup:passive) . . . . . . . . . . . . . . . . . . 10
5.2.3. Peer to Peer, remote peer is DTLS client
(a=setup:active) . . . . . . . . . . . . . . . . . . 11
5.2.4. Peer to Peer, remote peer is DTLS server
(a=setup:passive) . . . . . . . . . . . . . . . . . . 12
5.2.5. Conclusions . . . . . . . . . . . . . . . . . . . . . 12
5.3. RTO sync . . . . . . . . . . . . . . . . . . . . . . . . 13
Uberti & Hancke Expires 23 January 2027 [Page 2]
Internet-Draft WARP July 2026
5.4. Early Application Data . . . . . . . . . . . . . . . . . 13
5.5. DTLS HelloVerifyRequest . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6.1. DTLS 1.3 . . . . . . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
The current WebRTC connection setup, as outlined in [RFC8829], incurs
4 RTTs before media can be sent and 6 RTTs before the data channel
opens. In 2011, this wasn’t much worse than the 4 RTTs needed to set
up a WebSocket over TCP/TLS, but nowadays, compared to QUIC’s
([RFC9000]) optimized 0-RTT setup (1 RTT for a WebSocket), it seems
incredibly slow.
In addition, the typical topology for a WebRTC session has changed
from being a peer-to-peer to client-server interaction, on account of
the rise of the use of WebRTC in conferencing, game streaming, and
other services that have a centrally hosted component. While setup
latency for peer-to-peer calls was largely masked by the time needed
for the human callee to actually answer the call, this latency is
immediately observable in most client-server contexts. As WebRTC
gains traction in additional low-latency domains (e.g., AI services
and robotics), this trend will continue to increase.
Furthermore, reducing the number of RTTs and packets on the wire has
a direct impact on the robustness of the protocol. With fewer steps,
there are fewer things that can be affected by network delays or
losses, which will translate into improved reliability for all WebRTC
topologies.
Accordingly, it is clear that a problem exists, and it is one worth
solving.
1.1. Analysis
First, let's look at the current WebRTC setup protocol.
Similar to the situation noted above regarding WebSockets over TCP/
TLS, much of the current slowness comes from multiple protocols being
stacked atop one another, so that there are multiple handshakes and
these handshakes are all serialized.
For WebRTC, there are five separate protocols involved:
Uberti & Hancke Expires 23 January 2027 [Page 3]
Internet-Draft WARP July 2026
* the signaling protocol (eg HTTP), used for offer-answer exchange
* ICE ([RFC8445]), used to establish a transport from the signaling
exchange
* DTLS 1.2 ([RFC6347]), used to secure the ICE transport
* SCTP ([RFC4960]), used to establish a reliability layer on top of
DTLS
* DCEP ([RFC8832]), used to map WebRTC data channels to SCTP streams
To make matters worse, both DTLS 1.2 and SCTP have a 4-way handshake,
which means that they each incur 2 round trips, which, when combined
with the individual RTTs from signaling and ICE, bring the total
number of RTTs to 6.
On the bright side, DCEP was intentionally designed to not incur an
additional roundtrip, as data can be sent at the same time as the
DCEP open message. However, if the client is the one initiating the
data channel, there will be an extra 0.5 RTT before the server can
send data (when DCEP negotiation is used).
This protocol sandwich is discussed in Section 5 of [RFC8831], but a
full accounting of all the round trips is not provided. Accordingly,
we illustrate this Matryoshka of handshakes below.
Uberti & Hancke Expires 23 January 2027 [Page 4]
Internet-Draft WARP July 2026
Offerer Answerer
| |
|------------- SDP Offer (actpass) --------->|
|<-1---------- SDP Answer (active) ----------|
| |
|<-2---------- ICE/Connectivity Checks ----->|
| |
|<------------ DTLS ClientHello -------------|
|--3---------- DTLS ServerHello ------------>|
|<------------ DTLS Finished ----------------|
| ANSWERER MEDIA READY (3.5RTT) |
|--4---------- DTLS Finished --------------->|
| OFFERER MEDIA READY (4 RTT) |
| |
|------------- SCTP INIT ------------------->|
|<-5---------- SCTP INIT ACK ----------------|
|------------- SCTP COOKIE ECHO ------------>|
|<-6---------- SCTP COOKIE ACK --------------|
| OFFERER DATA READY (6 RTT) |
| |
|------------- DCEP (Open Channel) --------->|
|------------- "hello" --------------------->|
| ANSWERER DATA READY (6.5 RTT) |
| |
|<------------ DCEP ACK ---------------------|
|<------------ "world" ----------------------|
As noted above, DCEP does not require an additional RTT, as the first
data channel payload can be sent concurrently with the DCEP OPEN, per
Section 4 of [RFC8832].
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. Discussion
Uberti & Hancke Expires 23 January 2027 [Page 5]
Internet-Draft WARP July 2026
3.1. Role of DTLS-SRTP
It might be tempting to blame this chatty setup sequence on the
requirement to use DTLS-SRTP ([RFC5764]) rather than SDES
([RFC4568]). During the long discussions that went into mandating
use of DTLS-SRTP for securing the WebRTC media transport, the two
extra round trips needed to establish DTLS were explicitly discussed
but ultimately considered to be an acceptable trade off, as noted in
the IETF 87 RTCWEB minutes.
However, DTLS is used not just for media keying, but also as a secure
transport for WebRTC data channels. Therefore, even if SDES had been
retained for media keying, we would still have the same slow setup
for data channels.
3.2. Areas for improvement
When considering what we can be done to improve this set of stacked
handshakes, we considered the following:
* Are some aspects of protocol negotiation unnecessary when used in
an encapsulated context?
* For the aspects that are necessary, can some of them be shifted
forward into an earlier negotiation?
* Have there been any improvements to underlying protocols that we
can benefit from?
4. Proposed Solution
Looking at the various handshakes through this lens, we can find
multiple potential areas for optimization, which are enumerated
below.
4.1. SNAP
SCTP was designed to be a Layer 4 protocol, similar to TCP, and
therefore includes mechanisms to prevent connection hijacking and
DDoS attacks. However, when run atop DTLS ([RFC8261]), as is always
the case in WebRTC, these concerns do not exist, and therefore these
mechanisms can be bypassed entirely. As a direct result, we can
dispense with the SCTP auth cookie exchange that typically adds its
own roundtrip.
Moreover, once the auth cookie exchange is removed, all that is left
to negotiate are the various initialization parameters (e.g., the
starting sequence number). However, these parameters are declarative
Uberti & Hancke Expires 23 January 2027 [Page 6]
Internet-Draft WARP July 2026
and simply need to be transferred to the remote party. As a result
they can easily be pulled forward and exchanged via SDP during
session negotiation, eliminating the SCTP INIT message exchange and
its associated roundtrip.
This improvement to the SCTP setup process, which saves two
roundtrips, is known as SNAP and is documented in
[I-D.hancke-tsvwg-snap].
4.2. SPED
Turning our attention to DTLS, we can see that in the current ladder
diagram DTLS cannot start until ICE completes, as ICE needs to first
find a viable candidate pair on which to transmit. However, we can
extend the STUN messages used in ICE with a new DATA attribute to
allow DTLS data to be piggybacked over STUN, which enables the first
DTLS roundtrip to occur concurrently with the initial STUN exchange.
This mechanism, known as SPED, saves a DTLS roundtrip and is
documented in [I-D.hancke-webrtc-sped].
4.3. DTLS 1.3
As noted above, DTLS 1.2 requires a 2-RTT setup before data can be
sent. However, DTLS 1.3 ([RFC9147]) supports a 1-RTT setup, as well
as a 0-RTT resumption mechanism. We focus here on the 1-RTT
mechanism as it is simpler and more general, and, thanks to SPED, we
can eliminate its cost by piggybacking it on the underlying ICE
exchange.
The net result is that we can save yet another roundtrip by moving to
DTLS 1.3's 1-RTT setup.
4.4. Total Savings
With these optimizations, we can completely eliminate almost all of
WebRTC's media roundtrips:
* SNAP: 2 RTT
* SPED: 1 RTT
* DTLS 1.3: 1 RTT
In total, we can reduce the cost to establish WebRTC connections with
both media and data to 1 signaling roundtrip and 1 media roundtrip (2
total roundtrips), as shown in the sequence diagram below. (Note the
use of a=setup:passive in the answer, discussed further in the
section on DTLS roles later in this document.)
Uberti & Hancke Expires 23 January 2027 [Page 7]
Internet-Draft WARP July 2026
Offerer Answerer
| |
|--- SDP Offer (actpass, sped, snap) ----->|
|<-1 SDP Answer (passive, sped, snap) -----|
| |
|--- ICE Check + DTLS ClientHello -------->|
|<-2 ICE Response + DTLS ServerHello/Fin --|
|<-- ICE Triggered Check ------------------|
| OFFERER MEDIA/DATA READY (2RTT) |
| |
|--- DTLS Finished + DCEP Open + "hello" ->|
|--- ICE Response ------------------------>|
| ANSWERER MEDIA/DATA READY (2.5RTT) |
| |
|<----------- DCEP ACK --------------------|
|<------------ "world" --------------------|
However, these improvements are all orthogonal, meaning they can be
mixed and matched if needed if conditions require partial adoption.
These mechanisms are all also backwards compatible, allowing clients
to offer a fully optimized approach and negotiate down individual
optimizations if necessary.
4.5. Deployment Experience
In one production deployment, WARP was observed to reduce setup
latency by approximately 4 RTTs at p50 and approximately 12 RTTs at
p95. The median improvement matches the 4-RTT savings expected from
the combined protocol optimizations. The additional improvement at
p95 was attributed to the reduction in handshake packets and,
consequently, the reduced chance of packet loss.
5. Best Practices
As these optimizations touch on various parts of the WebRTC stack,
several interactions have complexities that warrant closer analysis.
5.1. ICE
To minimize setup delay, clients MUST follow the Section 12.1 of
[RFC8445] guidance to begin sending as soon as they have a valid
candidate pair, rather than waiting for pair selection to complete.
[RFC8445] also suggests that both sides use Full ICE implementations
for improved security. Naturally, Full ICE provides significant
benefits when used in a peer-to-peer context, especially in terms of
improving hole punching success as well as consent checking, but this
is of nominal value in a client-server context where the server is
Uberti & Hancke Expires 23 January 2027 [Page 8]
Internet-Draft WARP July 2026
directly reachable and consent can be mostly inferred by the receipt
of a valid STUN check. (One edge case, which requires an on-path
attacker, is the replay of a valid STUN check from a forged source
address, i.e., that of a victim.)
In fact, use of Full ICE can make life more complicated for a server,
in that when it receives a DTLS ClientHello tunneled in a STUN
Binding Request via SPED, it cannot respond with an untunnelled
ServerHello until it completes its own ICE check, whereas a Lite ICE
server would be able to send immediately, as outlined in
Section 12.1.1 of [RFC8445]. In particular, when using post-quantum
crypto suites or other suites with large keys that are split across
multiple DTLS records, it is typically more convenient to send these
records as raw DTLS rather than encapsulating them in STUN using
SPED. This is because only a single DTLS record can be piggybacked
on a STUN Response (which would mean the other records need to be
sent via different STUN transactions).
In addition, in the figure above, the answerer has completed DTLS
after only 1.5 RTTs, but it cannot send data because it has not yet
performed its own ICE checks and identified a Valid candidate pair.
If it were using ICE Lite, this step would be unnecessary and it
would be ready to send at this earlier juncture, which would save an
additional roundtrip.
Therefore, when using WARP on a server, ICE Lite is RECOMMENDED. If
true STUN consent checks are required, a modified version of Full ICE
can be employed, where upon receipt of a STUN request, the associated
candidate pair is immediately added to the Valid List (as is the case
in ICE Lite), but the ICE Agent will still send a check to the remote
endpoint to verify consent, with the candidate pair being removed
from the Valid List if the check fails.
Note that Full ICE is still recommended for all client-to-client
scenarios. In addition to its value in establishing peer-to-peer
connections and identifying the optimal candidate pair, the STUN
checks sent by a client as part of Full ICE provide protection
against DTLS amplification attacks, and are often quite useful in
demultiplexing traffic at the server.
5.2. DTLS Role and a=setup
The role of DTLS client/server in a WebRTC session is controlled by
the a=setup SDP attribute, which is defined in [RFC5763], and the
default guidance in WebRTC (from [RFC9429]) is to use a=setup:active
in the answer. Depending on the scenario, additional considerations
may apply, as shown in a few scenarios below.
Uberti & Hancke Expires 23 January 2027 [Page 9]
Internet-Draft WARP July 2026
5.2.1. Client-server, server is DTLS client (a=setup:active)
In this scenario the answerer is acting as a DTLS client following
the default a=setup:active guidance.
Offerer Answerer
| |
|---- SDP Offer (actpass, sped, snap) ---->|
|<-1- SDP Answer (active, sped, snap) -----|
| |
|--- ICE Check --------------------------->|
|<-2 ICE Response + DTLS ClientHello ------|
|<-- ICE Check (Triggered)-----------------|
| OFFERER MEDIA/DATA READY (2RTT) |
| |
|--- DTLS SHello/Fin + DCEP + "hello" ---->|
|--- ICE Response ------------------------>|
| ANSWERER MEDIA/DATA READY (2.5RTT) |
| |
|<-- DTLS Finished + DCEP ACK -------------|
|<------------ "world" --------------------|
Note that the initial client-server STUN request carries no DTLS
payload as the client (as offerer) is acting as the DTLS server,
which reduces the benefit of SPED slightly. While the overall time
to establish media and data is the same as shown in the
a=setup:passive example above (namely, 2RTT before the offerer can
send, and 2.5 RTTs before the answerer can send), we can do slightly
better when we use a=setup:passive with ICE Lite. ICE Lite is still
desirable in this a=setup:active scenario, as noted above, but does
not change the overall number of RTTs.
5.2.2. Client-server, server is DTLS server (a=setup:passive)
In this scenario the answerer is acting as a DTLS server by
specifying a=setup:passive in the answer, and has also elected to use
ICE Lite. The server has also been made to send the DCEP open
message in this scenario for maximum latency benefit.
Uberti & Hancke Expires 23 January 2027 [Page 10]
Internet-Draft WARP July 2026
Offerer Answerer
| |
|--- SDP Offer (actpass, sped, snap) ----->|
|<-1 SDP Answer (passive, sped, snap, lite)|
| |
|--- ICE Check + DTLS ClientHello -------->|
| ANSWERER MEDIA/DATA READY (1.5RTT) |
| |
|<-2 ICE Response + DTLS SHello/Fin + DCEP |
| OFFERER MEDIA/DATA READY (2RTT) |
| |
|--- DTLS Finished + DCEP ACK + "hello" -->|
|<------------ "world" --------------------|
Because the DTLS ClientHello is piggybacked on the initial client-
server STUN request, the server can complete DTLS processing and
start sending encrypted media and data as soon as that message is
received, at only 1.5 RTTs.
5.2.3. Peer to Peer, remote peer is DTLS client (a=setup:active)
The sequence diagrams above presume that the answerer will not be
able to send STUN checks directly to the offerer, due to the offerer
(as a client) being behind NAT. However, in the event the offerer is
in fact reachable on the first inbound STUN check, this can also lead
to the answerer being able to send in only 1.5 RTTs. (If the offerer
is not reachable, this turns into the client-server, server is DTLS
client scenario above.)
Offerer Answerer
| |
|---- SDP Offer (actpass, sped, snap) ---->|
|<-1- SDP Answer (active, sped, snap) -----|
| |
|<-- ICE Check + DTLS ClientHello ---------|
|--- ICE Res + DTLS SHello/Fin ----------->|
| ANSWERER MEDIA/DATA READY (1.5RTT) |
| |
|--- ICE Check (Triggered) --------------->|
|<-2 ICE Response -------------------------|
| OFFERER MEDIA/DATA READY (2RTT) |
| |
|------------ DCEP OPEN + "hello" ---------|
|<----------- DCEP ACK --------------------|
|<------------ "world" --------------------|
Uberti & Hancke Expires 23 January 2027 [Page 11]
Internet-Draft WARP July 2026
In fact, thanks to SPED, the offerer completes DTLS in a single RTT,
and has to wait for its own triggered check to complete before it can
actually start to send. This suggests that SPED might be useful to
tunnel application data as well as handshake messages, which would
result in the offerer being ready to send after just a single RTT.
However, sending an actual media stream is likely beyond the scope of
SPED, so we leave this possibility for future exploration.
5.2.4. Peer to Peer, remote peer is DTLS server (a=setup:passive)
If the remote peer is a DTLS server, the initial STUN check that it
sends to the offerer will not have a piggybacked DTLS message.
Regardless, if this STUN check succeeds, the answerer will also be
ready to send in only 1.5 RTT. (If not, this scenario turns into the
client-server, server is DTLS server scenario above.)
Offerer Answerer
| |
|---- SDP Offer (actpass, sped, snap) ---->|
|<-1- SDP Answer (passive, sped, snap) ----|
| |
|<-- ICE Check ----------------------------|
|--- ICE Response + DTLS ClientHello ----->|
|--- ICE Check (Triggered) --------------->|
| ANSWERER MEDIA/DATA READY (1.5RTT) |
| |
|<-2 ICE Response + DTLS SHello/Fin + DCEP |
| OFFERER MEDIA/DATA READY (2RTT) |
| |
|--- DTLS Finished + DCEP ACK + "hello" -->|
|<------------ "world" --------------------|
5.2.5. Conclusions
For the most part, the full benefits of WARP can be realized even
when using the existing default behavior for a=setup, with the
offerer needing 2 RTT and the answerer 2.5 RTT to complete the
handshaking. However, in a client-server scenario where ICE Lite is
in use and the server wants to send data first, the server
handshaking latency can be reduced to 1.5 RTT by using
a=setup:passive.
Uberti & Hancke Expires 23 January 2027 [Page 12]
Internet-Draft WARP July 2026
5.3. RTO sync
During the analysis of the current WebRTC handshake, it was noted
that each handshake layer has its own retransmission timeout (RTO).
ICE specifies a minimum of 500ms for its timeout in Section 14.3 of
[RFC8445]; DTLS specifies a suggested value of 400ms in Section 5.8.2
of [RFC9147] (although it notes that a value from ICE MAY be used),
and SCTP specifies a recommended initial value of 1 second and a
minimum of 1 second in Section 16 of [RFC9260].
These separate RTO values are problematic not just because they lead
to considerably different behavior from the various stack layers in
the event of a packet loss, but also because a loss may occur in a
layer that has not yet completed a roundtrip, leading to a fallback
to a (conservative) default value even if there is actual knowledge
of the RTT in another layer.
To address this, when using WARP, implementations SHOULD propagate
the observed RTT values from the ICE layer to the DTLS and SCTP
layers, with no fixed minimum value, as it can be difficult to
predict future needs (TODO: should DTLS' 1.5x offset be
recommended?). If the ICE selected candidate pair changes, the RTT
SHOULD be updated accordingly throughout the layers.
One complexity with this approach is that the ICE RTT is not known
until the first request-response cycle is complete, which means that
if one of the initial messages (e.g., a STUN request with a
piggybacked DTLS ClientHello) is lost, a default RTO value will be
used and therefore the DTLS implementation will be slow to request a
retransmit. To address this, implementations SHOULD allow caching of
ICE RTT values, which can be reused when connecting to the same
server in future sessions.
5.4. Early Application Data
DTLS 1.3 permits a server to send application data after sending its
own Finished, before receiving the client's Finished (Section 2 of
[RFC8446]). The client MUST NOT deliver that data until it has
received and validated the server's certificate, certificate
verification, and Finished, including the signaled certificate
fingerprint. If application data arrives first due to packet loss or
reordering, the client SHOULD buffer it until validation completes.
Uberti & Hancke Expires 23 January 2027 [Page 13]
Internet-Draft WARP July 2026
5.5. DTLS HelloVerifyRequest
When DTLS is run in a WebRTC context, authenticated ICE connectivity
checks already provide the protection for which a DTLS cookie
exchange is normally used. Consequently, the DTLS 1.2
HelloVerifyRequest, or the cookie-bearing DTLS 1.3 HelloRetryRequest,
is not needed (Section 5.1 of [RFC9147]). This is existing WebRTC
behavior, not an optimization introduced by WARP.
6. Security Considerations
See the respective SPED ([I-D.hancke-webrtc-sped]) and SNAP
([I-D.hancke-tsvwg-snap]) docs for the security considerations
associated with those protocols.
6.1. DTLS 1.3
[RFC9147] details how DTLS can be used for amplification attacks and
provides some guidance to defend against this threat, including the
use of a cookie to ensure the client's IP address is legitimate.
This mechanism is usually disabled when DTLS is used in WebRTC, as
STUN credentials usually provide protection against spoofed traffic,
and the self-signed ECC certs used in modern WebRTC are also
typically quite small.
7. IANA Considerations
This document requires no IANA action.
8. References
8.1. Normative References
[I-D.hancke-tsvwg-snap]
Hancke, P., Uberti, J., and V. Boivie, "SCTP Negotiation
Acceleration Protocol", Work in Progress, Internet-Draft,
draft-hancke-tsvwg-snap-00, 30 December 2025,
<https://datatracker.ietf.org/doc/html/draft-hancke-tsvwg-
snap-00>.
[I-D.hancke-webrtc-sped]
Hancke, P., Uberti, J., and J. Oreland, "STUN Protocol for
Embedding DTLS (SPED)", Work in Progress, Internet-Draft,
draft-hancke-webrtc-sped-00, 2 March 2026,
<https://datatracker.ietf.org/doc/html/draft-hancke-
webrtc-sped-00>.
Uberti & Hancke Expires 23 January 2027 [Page 14]
Internet-Draft WARP July 2026
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, DOI 10.17487/RFC4960, September 2007,
<https://www.rfc-editor.org/rfc/rfc4960>.
[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, <https://www.rfc-editor.org/rfc/rfc5763>.
[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,
<https://www.rfc-editor.org/rfc/rfc5764>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/rfc/rfc6347>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[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,
<https://www.rfc-editor.org/rfc/rfc8445>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>.
[RFC8832] Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data Channel
Establishment Protocol", RFC 8832, DOI 10.17487/RFC8832,
January 2021, <https://www.rfc-editor.org/rfc/rfc8832>.
[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,
<https://www.rfc-editor.org/rfc/rfc9147>.
Uberti & Hancke Expires 23 January 2027 [Page 15]
Internet-Draft WARP July 2026
[RFC9260] Stewart, R., Tüxen, M., and K. Nielsen, "Stream Control
Transmission Protocol", RFC 9260, DOI 10.17487/RFC9260,
June 2022, <https://www.rfc-editor.org/rfc/rfc9260>.
[RFC9429] Uberti, J., Jennings, C., and E. Rescorla, Ed.,
"JavaScript Session Establishment Protocol (JSEP)",
RFC 9429, DOI 10.17487/RFC9429, April 2024,
<https://www.rfc-editor.org/rfc/rfc9429>.
8.2. Informative References
[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,
<https://www.rfc-editor.org/rfc/rfc4568>.
[RFC8261] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto,
"Datagram Transport Layer Security (DTLS) Encapsulation of
SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November
2017, <https://www.rfc-editor.org/rfc/rfc8261>.
[RFC8829] Uberti, J., Jennings, C., and E. Rescorla, Ed.,
"JavaScript Session Establishment Protocol (JSEP)",
RFC 8829, DOI 10.17487/RFC8829, January 2021,
<https://www.rfc-editor.org/rfc/rfc8829>.
[RFC8831] Jesup, R., Loreto, S., and M. Tüxen, "WebRTC Data
Channels", RFC 8831, DOI 10.17487/RFC8831, January 2021,
<https://www.rfc-editor.org/rfc/rfc8831>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/rfc/rfc9000>.
Authors' Addresses
Justin Uberti
OpenAI
Email: justin@uberti.name
Philipp Hancke
Meta Platforms Inc.
Email: philipp.hancke@googlemail.com
Uberti & Hancke Expires 23 January 2027 [Page 16]