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

Hey Pal,

On Fri, Aug 7, 2015 at 2:47 AM, Pal Martinsen (palmarti)
<palmarti@cisco.com> wrote:
>
> On 07 Aug 2015, at 02:11, Emil Ivov <emcho@jitsi.org> wrote:
>
> On Thu, Aug 6, 2015 at 5:01 PM, Justin Uberti <juberti@google.com> wrote:
>
>
>
> On Thu, Aug 6, 2015 at 1:51 PM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>
>
> On 6 August 2015 at 13:08, Justin Uberti <juberti@google.com> 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?
>
> How do you reliably and simply do that without a connectivity check?

There are a few ways a TURN server could be smart about this (e.g.
checking the routing table for local interfaces for example, or
looking into ARP tables) but ultimately they should allow for this to
be configured.

> If the main concern is information leakage, isn’t that up to the client to
> decide what it want to reveal to the TURN server and the remote client?

I don't know that the main concern is leakage (see my previous mail).
I don't see how an application can be worried that the TURN server it
chose is going to find out that there's one of three NATed ranged
behind a certain IP. The TURN server had a 1 in 4 chance of guessing
that even without the app.

That said, I am not opposed to giving JavaScript apps a way to
explicitly signal the stack not to pair certain addresses with TURN.

I just don't want the stack to assume this.

Emil

> Guess what I am saying is that I think it is a good thing to have a “thick”
> client and relatively simple network components.
>
> .-.
> Pål-Erik
>
>
> Emil
>
> --
> https://jitsi.org
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

-- 
https://jitsi.org