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

[Emil Ivov <[e-mail]>]

On Thu, Aug 6, 2015 at 5:46 PM, Justin Uberti <[e-mail]> wrote:
>
>
> On Thu, Aug 6, 2015 at 5:11 PM, Emil Ivov <[e-mail]> wrote:
>>
>> On Thu, Aug 6, 2015 at 5:01 PM, Justin Uberti <[e-mail]> wrote:
>> >
>> >
>> > On Thu, Aug 6, 2015 at 1:51 PM, Martin Thomson
>> > <[e-mail]>
>> > wrote:
>> >>
>> >> On 6 August 2015 at 13:08, Justin Uberti <[e-mail]> wrote:
>> >> > I think that we should be able to avoid pairing candidates obtained
>> >> > from
>> >> > application TURN servers with RFC 1918 addresses. The app/browser
>> >> > clearly
>> >> > knows which is which.
>> >>
>> >> I'm concerned here that if we let the application choose, we lose the
>> >> defence we were looking to gain.  I think that perhaps 1918 pairing
>> >> could be restricted to TURN servers that are configured/discovered,
>> >> "proxy"-style.
>> >
>> >
>> > Sorry, that is what I was trying to say. The browser knows which turn
>> > servers are "proxies" vs app servers, and can apply the 1918 filtering
>> > on
>> > the pairings from the candidates from the app TURN server.
>>
>> I don't think Jonathan's concerns only apply to proxies though. You
>> can just as well have apps developed for specific networks and there
>> is no reason to prevent those from working.
>>
>> > Agree with your enumeration of concerns as well. Also #5, they consume
>> > bandwidth (at least from client to TURN server), which affects maximum
>> > check
>> > rate in some cases.
>>
>> Why can't we address this by TURN servers simply refusing to create
>> permissions for candidates they know they won't be able to reach?
>
>
> That is one potential solution, which would solve #1/#4/#5.

So, let's say that Alice calls Bob using SuperApp.

Alice sends her 10.0.0.1 address to SuperApp's server, which then
sends it to Bob.

So Bob and SuperApp now know about Alice's 10.0.0.1 but there's no way
around this. Bob, could be in the same network as Alice so it has to
try her private address.

Next, Bob installs 10.0.0.1 on the TURN server provided by SuperApp,
which also now learns about 10.0.0.1. As long as that server is hosted
by the same people as SuperApp (which we can probably consider as the
common case) then we haven't leaked anything.

If the TURN server is hosted by a third party (SuperTURN) then
SuperTURN do get to learn a little bit of extra information, namely
that Alice's public address has a private network in the 10.0.0.0
range behind it and that 10.0.0.1 is being used by someone.

That's all though.

SuperTURN should have no other information regarding Alice and what
little it just learned was not hard to guess any way.

So I am not sure exactly what we are trying to solve here.

Emil


-- 
https://jitsi.org