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

[Brandon Williams <[e-mail]>]

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.

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