1609124 - ICE mode 2 implementation on dual stack configurations is prone to fail

Status: RESOLVED FIXED

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

Description

[Lennart Grahl [:lgrahl]]

The current ICE mode 2 implementation (aka gather default interface addresses) often leads to ICE failures or unnecessary bad connections on dual stack configurations.

When a website has been received via IPv6, only the IPv6 address of the default interface is being used. This breaks host-to-host connections that would have been possible via IPv4. In addition to that, it lets ICE fail completely when STUN/TURN servers are not reachable by IPv6.

The same applies to IPv4: When a website has been received via IPv4, only the IPv4 address of the default interface is being used. This breaks host-to-host connections that would have been possible via IPv6. In addition to that, it lets ICE fail completely when STUN/TURN servers are not reachable by IPv4.

The current implementation violates draft-ietf-rtcweb-ip-handling sec 5.2:

Once an interface has been chosen, the private IPv4
and IPv6 addresses associated with this interface MUST be
discovered and provided to the application. This ensures
that direct connections can still be established in this
mode.

Proposed solution: Resolve the interface that shipped the website and gather all addresses of that interface.

---

Background: For Threema Web, we have removed AAAA records for our STUN/TURN servers as part of an optimisation. Due to this, if our website has been shipped via IPv6, Firefox refuses to contact our TURN servers even though it is perfectly capable to do so. While investigating, we found out the above mentioned behaviour.

Comment 1

[Byron Campen [:bwc]]

Thanks for the report. Right now, we are indeed simply using the IP address the origin was loaded with. I agree that we should be attempting to take that IP address, find its interface, and obtain the rest of the addresses on it.

Comment 2

[Dan Minor [:dminor]]

If I remember correctly, I ran into this while testing some stuff out before Christmas. As far as I can tell, this changed with Bug 1506219, which added code here [1] that only checks for ipv4 or ipv6. For the site I was testing, we were hitting the top branch of the if statement and only getting one of ipv4 or ipv6.

[1] https://searchfox.org/mozilla-central/rev/9e45d74b956be046e5021a746b0c8912f1c27318/media/mtransport/third_party/nICEr/src/ice/ice_ctx.c#737

Comment 3

[Byron Campen [:bwc]]

This has changed since then; https://searchfox.org/mozilla-central/rev/9e45d74b956be046e5021a746b0c8912f1c27318/media/webrtc/signaling/src/peerconnection/PeerConnectionMedia.cpp#550-576

Comment 4

[Byron Campen [:bwc]]

So now, we just ask "What did we use to load this origin?", and don't try to interrogate the networking code at all.

Comment 5

[Silvia Pfeiffer]

FWIW: We regard this as a serious bug and as a company running on WebRTC, it's a reason for us to tell our users to move to another browser for their WebRTC applications. It would be great to get this fixed asap. Thanks.

Comment 6

[Eric Rescorla (:ekr)]

Byron: does that mean that this is fixed?

Comment 7

[Byron Campen [:bwc]]

No. Right now, if we have a network interface with multiple IP addresses on it (eg; a V4 and V6), and we load an origin with the V4 address, we do not gather the V6 address from the same interface. We need some way of asking necko "What interface was this origin loaded with, and what are the IP addresses associated with this interface?"

Comment 8

[Byron Campen [:bwc]]

I guess we could also do this down in nICEr...

Comment 9

[Michael Froman [:mjf]]

My plan is to start looking at this later today.

Comment 10

[Michael Froman [:mjf]]

Attachment: Bug 1609124 - check for associated IP address on interface for ICE dualstack operation. r?bwc!

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c6cfb1f684cc
check for associated IP address on interface for ICE dualstack operation. r=bwc

Comment 12

[Daniel Varga [:dvarga]]

https://hg.mozilla.org/mozilla-central/rev/c6cfb1f684cc

Comment 13

[BugBot [:suhaib / :marco/ :calixte]]

Since the status are different for nightly and release, what's the status for beta?
For more information, please visit auto_nag documentation.