1742009 - STUN candidates that match local addresses should not be filtered out when providing mDNS-obfuscated candidates

Status: RESOLVED DUPLICATE of bug 1742337

(Core :: WebRTC: Networking, defect, P2)

Description

[Luc des Trois Maisons]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:94.0) Gecko/20100101 Firefox/94.0

Steps to reproduce:

Resolved ICE candidates using https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/ without acquiring microphone/camera permissions.

I used the following STUN servers:
stun:stun.l.google.com:19302
stun:[2001:4860:4864:4:8000::]:3478

Actual results:

Only obfuscated IPv6 candidates were provided.

Expected results:

Unobfuscated server-reflexive IPv6 candidates are provided.

Comment 1

[Luc des Trois Maisons]

STUN queries for the IPv6 network connection succeed, providing an address local to the client machine (visible in Wireshark) but are subsequently discarded by Firefox.

This appears to be in contravention of https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-mdns-ice-candidates#section-3.1.2.2

I tried to find something explicit in RFC 8828 that overrode the directives in the above draft, but nothing lept out at me.

$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 70:85:c2:6d:3b:23 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.168/24 brd 192.168.0.255 scope global dynamic noprefixroute enp4s0
       valid_lft 33239sec preferred_lft 33239sec
    inet6 2607:f2c0:e98a:41::502/128 scope global dynamic noprefixroute 
       valid_lft 573929sec preferred_lft 141929sec
    inet6 fd2f:8cd6:582f::502/128 scope global noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fd2f:8cd6:582f:0:d77d:fdd6:1d6:fc25/64 scope global noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 2607:f2c0:e98a:41:1093:9f36:fc8f:b9a7/64 scope global dynamic noprefixroute 
       valid_lft 573930sec preferred_lft 141930sec
    inet6 fe80::b15d:5d4c:fee1:eeae/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
3: enp6s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 70:85:c2:6d:3b:21 brd ff:ff:ff:ff:ff:ff
4: wlp5s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 8e:e7:68:c7:03:91 brd ff:ff:ff:ff:ff:ff permaddr 40:a3:cc:14:2e:e5
6: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500
    link/none 
    inet 10.8.0.62 peer 10.8.0.61/32 scope global noprefixroute tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::46f:35c8:3d9d:1bd9/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever

$ ip -6 route
::1 dev lo proto kernel metric 256 pref medium
2607:f2c0:e98a:41::502 dev enp4s0 proto kernel metric 100 pref medium
2607:f2c0:e98a:41::/64 dev enp4s0 proto ra metric 100 pref medium
fd2f:8cd6:582f::502 dev enp4s0 proto kernel metric 100 pref medium
fd2f:8cd6:582f::/64 dev enp4s0 proto ra metric 100 pref medium
fd2f:8cd6:582f::/48 via fe80::c641:1eff:fea9:83c4 dev enp4s0 proto ra metric 100 pref medium
fe80::/64 dev enp4s0 proto kernel metric 100 pref medium
fe80::/64 dev tun0 proto kernel metric 256 pref medium
default via fe80::c641:1eff:fea9:83c4 dev enp4s0 proto ra metric 100 pref medium

Capture snippet from Wireshark:

Session Traversal Utilities for NAT
    [Request In: 5]
    [Time: 0.014764215 seconds]
    Message Type: 0x0101 (Binding Success Response)
    Message Length: 24
    Message Cookie: 2112a442
    Message Transaction ID: fc5c933452a8598d9078ba6c
    [STUN Network Version: RFC-5389/8489 (3)]
    Attributes
        XOR-MAPPED-ADDRESS: 2607:f2c0:e98a:41::502:53773
            Attribute Type: XOR-MAPPED-ADDRESS
            Attribute Length: 20
            Reserved: 00
            Protocol Family: IPv6 (0x02)
            Port (XOR-d): f31f
            [Port: 53773]
            IP (XOR-d): 0715568215d6937552a8598d9078bf6e
            [IP: 2607:f2c0:e98a:41::502]

Comment 2

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

but are subsequently discarded by Firefox.

Thanks Luc for filing! — I'm trying to determine priority. What do you mean by "discarded" and "filtered out"? Are you reporting that:

1. Firefox is unnecessarily obfuscating some candidates it doesn't need to obfuscate, but they're still provided in obfuscated form, and Firefox is still able to connect over them, or
2. Firefox is filtering out some these candidates, and removing them from consideration when trying to pair candidates, and you're unable to connect because of it?

Comment 3

[Luc des Trois Maisons]

...trying to pair candidates

This occurs before pairing when ICE is generating initial candidates to send to the remote peer.

I believe the full slate of host candidates must be obfuscated, as they are now. The subtlety occurs when STUN yields a server-reflexive candidate address for the local peer running Firefox that also matches an address used by a host candidate: when the host candidates are not obfuscated with mDNS, it is appropriate to discard the redundant, matching server-reflexive candidate. However, when host candidates are obfuscated, despite the underlying address being the same, the two candidates (host and server-reflexive) must not be considered equivalent and both must be provided.

As things stand, this prevents a remote peer beyond the functional domain of mDNS from successfully connecting back to Firefox despite the local host having a public IP address. I believe the net result is that this essentially causes publicly routable peers to be functionally reduced to the equivalent of one behind a symmetric NAT.

Comment 4

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Thanks for explaining. This seems like it should be trivial to fix.

Comment 5

[Kyutae Lee [:gorisanson]]

As I commented in 1742337,
this bug is fixed by a patch in upstream:
https://webrtc.googlesource.com/src/+/7eea6672285f765599fd883a5737f5cae8d20917

And the patch begins to be applied on Chromium with version 110.0.5452.0.

Comment 6

[Kyutae Lee [:gorisanson]]

Bug 1742337 was fixed by
https://hg.mozilla.org/integration/autoland/rev/587eb0272431.

And I think this bug 1742009 is supposed to be fixed by it too.