WebRTC-Direct: Chrome may be removing ICE credential munging

[evan-brass]

ICE credential munging is currently used by webrtc-direct spec.

Chrome appears to be preparing to disable ICE credential munging in a field trial: https://webrtc-review.googlesource.com/c/src/+/385721
I don't know how these work, but there seems to be a date in that patch: Oct. 11, 2025

They may be considering this now because of a side-channel in the webrtc stats api from late last year: w3c/webrtc-stats#789.

I don't know what y'all want to do. I don't use LibP2P, but I do use ICE credential munging. We could try to make some noise and see if we can convince them to keep it.

Or, if you want to write a V2 webrtc-direct I can give some pointers on how to remove the need for ICE munging in unsignalled browser -> server connections.

[p-shahi]

Thanks for bringing this up @evan-brass - what's the best way to engage with the Chrome folks?
cc @sukunrt @MarcoPolo @aschmahmann

[evan-brass]

Harald Alvestrand is the owner of that patch, and Philipp Hancke has been trying to finish removing SDP munging for a while: webtorrent/webtorrent#288 (comment)

I assume that they are driving removing ICE munging in Chrome, but I don't know the proper "where" to engage with them. Given that SDP munging was forbidden in the spec a long time ago, I'm not sure that there will be a public feedback/tracking issue for this Chrome change. Maybe one of the webrtc spec repos would be a better spot.

Does anyone know how much traffic uses webrtc-direct? I'm wondering what portion of https://webrtchacks.github.io/chromestatus/?buckets=4106 it is.

[MarcoPolo]

I don't know of any metrics that would tell use how much of that traffic is libp2p related.

What is your suggestion to avoid SDP munging of ICE ufrag/pwd?

[evan-brass]

@MarcoPolo
Option 1: Stateless ICE-lightest
You only need to know your peer's pwd if you send a STUN request. Responses only require knowing your own pwd. webrtc-unreliable uses this. The browser needs to be the controlling peer so that it can select the candidate pair and start sending DTLS packets. If the browser generates the SDP offer or if you use a=ice-lite on the server's SDP offer, then the browser will be controlling.

You are supposed to be able to ask the browser to switch roles to controlling using an error 487 in a response, but Firefox currently doesn't do this.

The difficulty with Option 1 is that it doesn't run a full ICE agent. Unless browser's add support for DTLS CID there's no way to know which DTLS context a given packet belongs to because the browser - as the controlling ICE agent - can change it's source ip:port (local candidate).

Option 2: Full ICE agent, pass local credentials in remote ufrag
Browser generates offer, extracts local ufrag and pwd.
Browser applies an answer and sets the remote ufrag to its local password. For the password it could use some constant such as the/ice/password/constant.
Server receives ICE connection test, splits the username into: remote-pwd:remote-ufrag
Server applies remote offer.
Server applies munged answer with local ICE ufrag = remote-pwd, and pwd = the/ice/password/constant.

This is probably the best option for LibP2P I think, and could be versioned with webrtc-direct V1.
You could also have the client randomize the server's pwd, and pass it in the remote ufrag as well, though I personally don't think it's any better then just using a constant.

Option 3: Wrap WebRTC in TURN
Instead of running WebRTC, run a TURN server and run Option 1 inside of it. Instead of using ICE to differentiate peers, you use the TURN username to assign source ip:port tuples to DTLS contexts. The only problem with passing data in the TURN username is that you need to set it when creating the RTCPeerConnection prior to accessing your local offer information (can't send local ufrag/pwd here because they haven't been generated yet). (iceServers can be updated via setConfiguration, but I'm pretty sure these settings won't kick in until a restartICE which would overwrite the localDescription anyway).

WebRTC supports UDP and TCP, but TURN supports UDP, TCP, and TLS which could give more firewall circumvention to webrtc-direct-turn peers with access to TLS maybe?

---

For my own projects swbrd and masquerade I kinda use Option 1 and kinda use Option 3. But they also heavily rely on munging the SDP to various constants/deterministic values which would break if Chrome removes munging the ICE credentials.

[evan-brass]

https://issues.webrtc.org/issues/411871813 "If you want to test whether your app is affected, install Chrome Canary (Chrome 137), and start with the flag "--force-fieldtrials=WebRTC-NoSdpMangleUfrag/Enabled/"

[achingbrain]

Browser applies an answer and sets the remote ufrag to its local password.

It's worth noting that the browser WebRTC API doesn't expose any functionality for setting the local password. The only way it works at the moment is by SDP munging 😩

[evan-brass]

@achingbrain No munging required on the browser side. We only need to read the local password:

const a = new RTCPeerConnection();
a.createDataChannel('');
await a.setLocalDescription();
const {1: local_password} = /a=ice-pwd:(.+)/img.exec(a.localDescription.sdp);
console.log(local_password);

const answer = {type: 'answer', sdp: a.localDescription.sdp.replace(
	/a=ice-ufrag:.+/img, `a=ice-ufrag:${local_password}`
).replace(
	/a=ice-pwd:.+/img, 'a=ice-pwd:the/ice/password/constant'
).replace(
	/a=setup:.+/img, 'a=setup:passive'
)}
await a.setRemoteDescription(answer);

// Add the server's address
await a.addIceCandidate({ sdpMLineIndex: 0, candidate: `candidate:f 1 udp 42 ${'127.0.0.1'} ${3478} typ relay raddr :: rport 0` })

On the server side, we would need to set the credentials, but that's available in Pion (I think here?), WebRTC-rs, Str0m, and probably others.

[achingbrain]

Ah, yes, my apologies - I misread your comment. I thought you meant the browser would have to set it's local password to the/ice/password/constant rather than the remote password in the generated answer.

[p-shahi]

@evan-brass @achingbrain we discussed this in the go-libp2p meeting yesterday - consensus is to test out option 2 soon, then specify and implement after other projects wrap up in the next few months.