Re: [tram] Allow TURN to forward inbound connectivity checks without permission

["Konda, Tirumaleswar Reddy" <[e-mail]>]

> -----Original Message-----
> From: Brandon Williams [mailto:[e-mail]]
> Sent: Monday, April 2, 2018 9:53 PM
> To: Justin Uberti <[e-mail]>; Simon Perreault <[e-mail]>
> Cc: Konda, Tirumaleswar Reddy <[e-mail]>;
> Nils Ohlmeier <[e-mail]>; Cullen Jennings (fluffy)
> <[e-mail]>; Eric Rescorla <[e-mail]>; [e-mail]
> Subject: Re: [tram] Allow TURN to forward inbound connectivity checks without
> permission
> 
> Agreed.
> 
> Different networks will require different access controls. Some will be fine with
> letting anything through. Some will be fine with letting anything through as long
> as it looks like STUN. And some will want to have the tighter controls they get
> from existing methods.
> 
> Providing flexibility with a discussion of the trade-offs seems like the right
> approach to me too.
> 
> The ufrag method was intended more to protect the client by giving some
> control over what's allowed through while opening it up a bit more.
> Neither that nor checking for STUN framing protects the relay or network from
> a dedicated user who really wants to create a new service, but both protect
> against the simplest misuses.

Agreed, we will update the draft to explain the discussed points.

-Tiru

> 
> --Brandon
> 
> On 04/01/2018 06:09 PM, Justin Uberti wrote:
> >
> >
> > On Sun, Apr 1, 2018 at 9:56 AM Simon Perreault <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >     2018-03-31 18:50 GMT-04:00 Justin Uberti <[e-mail]
> >     <mailto:[e-mail]>>:
> >
> >         As Brandon says, the ufrag/pwd info could be posted along with
> >         the address of the server, so while this raises the bar, it
> >         doesn't solve the problem.
> >
> >         I agree with Brandon that the only reasonable way to completely
> >         contain this is some sort of server policy, e.g., some time
> >         window or session count after which the permission bypass
> >         expires, meaning that someone running a server would have to be
> >         continually requesting new allocations and posting their
> >         address/credentials.
> >
> >
> >     Do we need to completely contain this? Is there actually a problem
> >     with the proposal?
> >
> >     Allowing STUN in allows someone to run a server if and only if the
> >     protocol masquerades as STUN. It doesn't allow a user to run an
> >     arbitrary server. For this to be exploitable, the user would also
> >     need to control the clients in some way.
> >
> >     I can't think of a way this could be exploited practically. Maybe I
> >     lack imagination?
> >
> >
> > I don't think this is fatal to the proposal. I just think that we need
> > to be up front that this is a potential loophole, and have some
> > explicit discussion in the document of how one might solve this
> > problem should it become necessary (e.g., with server policy).