WARP Support in str0m

[xnorpx]

This issue tracks the progress of implementing WARP in str0m

WARP by @fippo and @juberti

The current WebRTC connection setup, as outlined in RFC 8829, 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 (RFC 9000) 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 should translate into improved reliability for all WebRTC topologies.

Corresponding issue in Pion

Demo

WARP Status in str0m

• SNAP
• SPED
• DTLS 1.3

SNAP

• Update sctp-proto for out of band signalling: Add support for out of band negotiation for SNAP xnorpx/sctp-proto#1
• str0m direct API changes: [WIP] SNAP support for direct API #811
• str0m SDP changes

SPED

• STUN changes
• ?

DTLS 1.3

• https://issues.chromium.org/issues/42290594
• DTLS 1.3 openssl/openssl#13900
• DTLS 1.3 dimpl#37 DTLS 1.3 implementation dimpl#53
• Post-Quantum Crypto (PQC) support in WebRTC w3c/webrtc-extensions#207

SkipVerifyHello

• Remove VerifyHello in dimpl
• See if it's possible to disable on WinCrypto otherwise document

Reduce MTU fragmentation on OpenSSL

• OpenSSL does not Honor 1200 MTU

[xnorpx]

SNAP POC in #810

[xnorpx]

Ok, here is the state of the handshake after the SNAP changes.

#	Dir	Length	Content
1	C→S	112	STUN Binding Request
2	S→C	64	STUN Binding Response
3	C→S	116	STUN Binding Request (USE-CANDIDATE)
4	C→S	118	DTLS ClientHello
5	S→C	64	STUN Binding Response
6	S→C	60	DTLS HelloVerifyRequest
7	C→S	150	DTLS ClientHello (with cookie)
8	S→C	673	DTLS ServerHello+Certificate+SKE+CR+SHD
9	C→S	622	DTLS Certificate+CKE+CV+CCS+Finished
10	S→C	75	DTLS CCS+Finished

client_direct_snap.pcap.zip

It seems like there is a extra 1 RTT for DTLS HelloVerifyRequest for DDoS protection enabled by default.

This can be turned off in Pion based on this commit it seems to be off in libwebrtc as well?

pion/dtls@0473adf

pion/dtls#513

@algesten thoughts?

Ok, so OpenSSL does not do the HelloVerifyRequest, but Wincrypro and dimpl does.

[juberti]

So that's 4 RTT, 1 STUN + 3 DTLS. Agree that you should be able to remove the HelloVerifyRequest, an authenticated ICE check has already occurred. That and DTLS 1.3 will get you to 2 RTT, SPED will get you to 1.

[juberti]

Seems like in the best case you'll have 2 handshake packets from the client, STUN/DTLS CHello + DTLS Finished, with USE-CANDIDATE as 3 depending on how you count.

[xnorpx]

Right with SPED and the current setup it looks like 3 handshakes is the best we can get. This is my Wireshark with OpenSSL now.

But just getting SNAP will be great improvement for us as we rely on DC for in session signalling.

[algesten]

This can be turned off in Pion based on this commit it seems to be off in libwebrtc as well?

Yeah, no problem making that configurable. I don't know if Wincrypt/SChannels can disable, but openssl and dimpl should be fine to turn this into config.

[algesten]

Agree that you should be able to remove the HelloVerifyRequest, an authenticated ICE check has already occurred.

This insight I think needs to be clearly documented in str0m, and it might also mean we should default HelloVerifyRequest to off (or even not make it a config option until someone asks for it – to avoid clutter).

[xnorpx]

Agree that you should be able to remove the HelloVerifyRequest, an authenticated ICE check has already occurred.

This insight I think needs to be clearly documented in str0m, and it might also mean we should default HelloVerifyRequest to off (or even not make it a config option until someone asks for it – to avoid clutter).

Yes agree since it's default off in libwebrtc we can reduce complexity in dimpl by just remove it.

We can check if it is possible to turn off in WinCrypto, if not we can document it.

[fippo]

Agree that you should be able to remove the HelloVerifyRequest, an authenticated ICE check has already occurred.

This insight I think needs to be clearly documented in str0m, and it might also mean we should default HelloVerifyRequest to off (or even not make it a config option until someone asks for it – to avoid clutter).

The HelloVerifyRequest does serve a purpose, avoiding issues like https://www.enablesecurity.com/blog/webrtc-hello-race-conditions-paper/
But since DTLS runs ontop of ICE in the context of WebRTC (i.e. you can always associate an ice-ufrag pair with the source address) it is not necessary to do in that context.