Re: [MMUSIC] [tram] [rtcweb] TURN permissions for private ips

[Jonathan Lennox <[e-mail]>]

On Aug 5, 2015, at 5:35 PM, Justin Uberti <[e-mail]<mailto:[e-mail]>> wrote:

On Wed, Aug 5, 2015 at 11:32 AM, Simon Perreault <[e-mail]<mailto:[e-mail]>> wrote:
Le 2015-08-05 13:46, Philipp Hancke a écrit :
> If a peer sends candidates with IP addresses from the private space,
> permissions for those are created at the TURN server. Potentially not
> utilising transport encryption even.
>
> I doubt those candidates ever work, so from a privacy point of view it
> seems that clients should not create those permissions in the first
> place. And ICE should probably not try to create pairs.

It's not up to the client to determine what addresses might not might
not work for a given TURN server. There are lots of weird NAT
configurations out there that play games with RFC1918 addresses and can
easily trick clients into doing the wrong thing.

I am somewhat sympathetic to that, but given that there is measurable downside here - extra candidate pairs that take time to check - can you supply a concrete example of where the client choosing not to pair a TURN candidate with a RFC1918 address would cause a problem?

This is really an ICE question, not a TURN question, so adding MMUSIC.

Clearly, if your TURN server is actually on the public internet, pairing RFC1918 address with its candidates won’t do any good.  However, there can be scenarios where you have a TURN server sitting in a DMZ or the like, where it can actually route to RFC 1918 addresses.  I suspect this will be relevant in the various scenarios where the TURN server is topologically equivalent to a web proxy.

As I recall from the discussions around the development of ICE, there are actually a fair number of networks out there which have public IPv4 and RFC1918 addresses directly routable to each other. The examples I remember came about as a result of corporate mergers, where one of the pre-merger companies was using their public address space internally, and the other wasn’t.