Should ICE filter out bridge interfaces?

[Michal Śledź]

RFC 8445 sec 5.1.1.1. says:

>   Host candidates are obtained by binding to ports on an IP address
   attached to an interface (physical or virtual, including VPN
   interfaces) on the host.

Does it mean that we should filter out bridge interfaces like those created by docker? 

[Michal Śledź]

My question raises from the fact that docker bridge rewrites source ip address. If I open socket on docker bridge interface and try to send anything from it, it will rewrite source ip address. This means that whatever we send to the docker interface, we will get a response from a different ip address and we will reject such response as transport addresses of the request/response are not symmetric.

[Nils Ohlmeier]

Hi Michal,

Based on my personal experience I would say you have a good idea, BUT whenever I tried to implement such filtering of ICE candidates in Firefox, which I thought filtered out candidates which wouldn't work, it didn't take long until someone opened a bug report, because they were running or at least testing WebRTC things in a setup which required these ICE candidates. So what happens if you filter out these bridges candidates and then someone has a test setup which involves docker?

Regarding your product rejecting answers from an non-matching transport address: IMHO you should not do that, because essentially you are preventing the learning of peer reflexive candidates, which often work and are still better then going through a TURN relay.

Best
  Nils Ohlmeier

[Michal Śledź]

Hi Nils!

Good point with running ICE in docker. I think that the problem is specifically with the bridge interface, not with interfaces connected to it. When I run a container and type `ifconfig`, I can see eth0 interface with address 172.17.0.2. When I type `ifconfig` on my host, I can see docker0 bridge with address 172.17.0.1. So when I run ICE on host, I would filter out bridge interface and when I run ICE in the container I wouldn't filter out anything as there is no bridge interface. In other words, I wanted to avoid opening ICE sockets specifically on the bridge interface.

There is also another question, how to detect a bridge interface in a specific programmin language.

I just started playing with docker networks and my own ICE implementation so I might be totally wrong but it's really good to know that someone has already tried the approach.

>Regarding your product rejecting answers from an non-matching transport address: IMHO you should not do that, because essentially you are preventing the learning of peer reflexive candidates, which often work and are still better then going through a TURN relay.

I meant this section https://datatracker.ietf.org/doc/html/rfc8445#section-7.2.5.2.1

prflx candidates are learned from XOR-MAPPED-ADDRESS so I shouldn't drop them out

[Michal Śledź]

This discussion also leads me to the question if that's actually possible to connect ICE running in a docker with ICE running outside docker assuming compliance with section 7.2.5.2.1. Really interesting 

[Michal Śledź]

That of course should be possible as prflx candidates are learned when receiving binding request from an unknown (i.e. not matching any remote candidate) ip address and not XOR-MAPPED-ADDRESS as I wrote before