1445771 - Loopback and link-local addresses

Status: NEW

(Core :: WebRTC: Signaling, enhancement, P3)

Description

[Lennart Grahl [:lgrahl]]

Loopback and link-local addresses are being filtered by Firefox. I couldn't find a related IETF document mentioning this, so I'm wondering why this is being done.

* IPv4 and IPv6 loopback addresses can be useful when connecting to the same device.
* IPv6 link-local addresses can be useful when a device doesn't have IPv6 global addresses.

If you're concerned about MAC leaking for link-local addresses, I have an idea:

1. Verify that the interface has used a random link-local address (RFC4941) or filter it. This would make sure no useful information is leaking.
2. If 1. resulted in the address being filtered, hold back the link-local address. If the other peer also provides a link-local address and that one is reachable (send a STUN binding request, check for a response), hand it out. So, if only one of the peers provides a link-local address, they will be able to talk to each other.

Now, you say that is rather complicated for a corner case. But this would also resolve an issue with mode 2 for data channel only applications (see bug 1438823) that isn't a corner case. I will add a comment there how I think it could work.

If you're concerned that those two peers may discover they are very near to each other... well, I have no solution to offer but in that case not even server reflexive candidates will protect you well enough since a simple tracepath will reveal that.

Comment 1

[Eric Rescorla (:ekr)]

If we're not providing link-local, then this is a bug. However, we're supposed to filter loopback:


https://tools.ietf.org/html/draft-ietf-ice-rfc5245bis-20#section-5.1.1.1:

"Addresses from a loopback interface MUST NOT be included in the candidate addresses."

Comment 2

[Nils Ohlmeier [:drno]]

By default we do filter out link-local addresses: https://searchfox.org/mozilla-central/rev/3abf6fa7e2a6d9a7bfb88796141b0f012e68c2db/media/mtransport/third_party/nICEr/src/stun/addrs.c#400

I don't remember the reason, but the only indicator I was able to find was the wording "... then host candidates corresponding to IPv6 link-local addresses [RFC4291] MUST NOT be gathered." from https://tools.ietf.org/html/draft-ietf-ice-rfc5245bis-20#section-5.1.1.1
But this only applies under special circumstances.

Comment 3

[Lennart Grahl [:lgrahl]]

I understand that sentence in the following way:
* If we have at least one IPv6 address that prevents location tracking, discard all the others who don't. If not, take all of them.
* The same thing as above for link-local addresses.

Comment 4

[Lennart Grahl [:lgrahl]]

Your thoughts?

Comment 5

[Nils Ohlmeier [:drno]]

I think the biggest issue so far is to identify random link-local address (RFC4941). And also be able to do that across all OS's. If we have a solution to that I'll happy to stop filtering link local.

Maybe the other option here is to stop filtering link local is when we use mDNS candidates instead.

Comment 6

[Felipe Erias]

For additional context, this issue prevents WebRTC from being used between mobile peers linked through Neighbor Awareness Networking (also known as WiFi Aware, available in the Pixel2 and Pixel3 phones).

Among other features, WiFi Aware enables fast 1-to-1 connections between mobile devices. These connections use scoped IPv6 adresses, e.g. fe80::5e:63ff:fefb:be0%aware_data0

When trying to use WebRTC between these devices, ICE negotiation does not take the Aware link into account and fails.

(In case it is relevant, in my tests the devices were disconnected from any other network.)

If you need more information and/or testing, I have the necessary hardware with me and would be more than happy to help.

More details are available at https://groups.google.com/forum/#!topic/discuss-webrtc/FlKQafa1Kfo from where I was pointed to this bug.