[libnice] Sharing/Reusing UDP ports for ICE candidates?

[Gary Bartlett]

Thank you for your response to my question, Olivier.

I was wondering whether using connect() on an ICE UDP socket (sharing a
single port) would alleviate the need to filter at the application level
(on the inbound side), but have no idea whether/how that work in practice
for ICE.

I suspect I may not have an easy time convincing an enterprise organization
that they shouldn't need to block, monitor, or filter so many ports, though
(when they currently block all inbound/outbound UDP).

I recently ran across and wonder whether anything became of this Internet
Draft by Jennings et al.:
https://tools.ietf.org/html/draft-jennings-behave-rtcweb-firewall-05 which
refers to several reasons why an enterprise might want to block UDP ports,
along with a potential 'solution'.

Thanks again,
Gary

On Fri, Feb 28, 2020 at 11:28 AM Olivier Crête <olivier.crete at collabora.com>
wrote:

> Hi,
>
> There is no such thing in libnice. I don't think it's very valuable to do
> that, opening UDP ports in a firewall costs nothing, and really has no
> added risk, especially if you target a specific computer. If you were to
> re-use the port, you'd have to do the filtering in userspace and waste
> quite a bit of CPU resources.
>
> The one real reason to have multiple connections negotiated from the same
> local socket is to be able to do SIP call forking, but I haven't seen
> anyone implement that with ICE.
>
> Olivier
>
> On Fri, 2020-02-28 at 10:43 -0800, Gary Bartlett wrote:
>
> I'm wondering whether libnice supports the notion of sharing/reusing UDP
> ports for its ICE candidates, so that only a single (or small set of) UDP
> ports can be opened up for it in a firewall?
>
> It sounds like if I reduce the range of available UDP ports by
> calling nice_agent_set_port_range, then this will limit the number of
> active sessions, but if the ports were reusable (e.g. using SO_REUSEADDR or
> SO_REUSEPORT), do you think libnice could handle multiple concurrent
> connectivity checks and WebRTC sessions on this single (or reduced set of)
> local port(s)?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/nice/attachments/20200303/f80331f9/attachment.htm>