WebRTC does not work in the modern browsers when a peer is not behind a NAT because of the obfuscating host address

Question

While troubleshooting my web app, I found draft-mdns-ice-candidates, which is about obfuscating addresses in host candidates by using mDNS.

And I found that when the two peer (agent L, agent R) is in a topology as in the Figure 7 below, the WebRTC peer connection fails because the host address of agent R is obfuscated and the srflx address of agent R is discarded since agent R is not behind a NAT. The relevant expressions in rfc8445 about discarding the srflx address of agent R are below.

5.1.3. Eliminating Redundant Candidates

Next, the ICE agents (initiating and responding) eliminate redundant candidates. Two candidates can have the same transport address yet different bases, and these would not be considered redundant. Frequently, a server-reflexive candidate and a host candidate will be redundant when the agent is not behind a NAT. A candidate is redundant if and only if its transport address and base equal those of another candidate. The agent SHOULD eliminate the redundant candidate with the lower priority. - section 5.1.3 of rfc8445

---

(Figure 7 is from section 15.1 of rfc8445)

And in section 5 of draft-mdns-ice-candidates, I found no explanation about the case of Figure 7. When I tested the recent version of Chrome, Firefox, and Safari, the WebRTC peer connection failed in all of the browsers in the case of Figure 7, because of the reason I wrote above — the host address of agent R was obfuscated and the srflx address of agent R was discarded.

When turning off obfuscating local addresses by changing the browser setting (the obfuscating is done by default), the WebRTC peer connection is successfully established. (I tested this successful connection on Chrome, and FireFox. In Chrome, by disabling Anonymize local IPs exposed by WebRTC in "about:flags" page. In Firefox, by setting false media.peerconnection.ice.obfuscate_host_addresses in "about:config" page.)

Is this a problem of the IETF’s WebRTC spec? (Maybe a collision between draft-mdns-ice-candidates and rfc8445?) Or a problem of the implementations of the modern browsers? Is there a way to establish WebRTC peer connection in the case of Figure 7 without turning off the obfuscating host address? I want to know.

Answer 1

Good news!

This bug in implementation was fixed by a patch in upstream WebRTC repo (it's my contribution!): https://webrtc.googlesource.com/src/+/7eea6672285f765599fd883a5737f5cae8d20917

The upstream WebRTC code with the patch applied begins to be included on Chromium with version 110.0.5452.0. Thus all Chromium browsers (including Chrome) at or above the version 110.0.5452.0 are supposed to be applied the patch.

Since the patch was committed on upstream WebRTC repo, we can also expect that other browsers (like Firefox or Safari) apply the patch sooner or later.

---

UPDATE:

The upstream patch was cherry-picked in Webkit.

It turned out that, for Firefox, a separate patch for itself was needed. (This patch also is my contribution.) Firefox uses a different library, other than from upstream WebRTC, for its ICE stack. So applying the patch in upstream did not work for Firefox. (Regarding this, it seems interesting Firefox had the same bug too.)

Answer 2

From draft-ietf-mmusic-mdns-ice-candidates-02, Section 3.1.2.2:

Regardless of the result, a server-reflexive candidate will be generated; the transport address of this candidate is an IP address and therefore distinct from the hostname transport address of the associated mDNS candidate, and as such MUST NOT be considered redundant per the guidance in [RFC8445], Section 5.1.3. To avoid accidental IP address disclosure, this server-reflexive candidate MUST have its raddr field set to "0.0.0.0"/"::" and its rport field set to "9", as discussed in [ICESDP], Section 9.1.

Omitting a SRFLX candidate because its server-reflexive IP address matches an IP address used to produce a local obfuscated candidate appears to be explicitly nonconforming.