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

For now I think we will follow the suggestion of letting the server enforce
this policy, and return 403 in the case where the target IP would be
considered unreachable by the server.

Chrome will also need to be updated to actually do the right thing on this
403...

On Tue, Aug 11, 2015 at 6:32 AM, Emil Ivov <emcho@jitsi.org> wrote:

> 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
>