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

[Cullen Jennings <[e-mail]>]

> On Aug 6, 2015, at 7:14 AM, Jonathan Lennox <[e-mail]> wrote:
> 
> 
>> On Aug 5, 2015, at 5:35 PM, Justin Uberti <[e-mail]> wrote:
>> 
>> On Wed, Aug 5, 2015 at 11:32 AM, Simon Perreault <[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.
> 

Some SPs are putting all their customers behind CGN (carrier grade NAT) and then looking at running cloud data centers where other people can rent servers (AWS style) where those servers have public IPs and at the same time they are directly routable to the all the NATed clients. That allows you to run media servers (STUN, TURN, Conferences MCU / Switches, caches etc) that have a low latency connectivity to the SP's customers endpoints. Note the customers's themselves often deploy an additional layer of residential NAT. 

So scenarios like this might be getting more common ....