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

From: Simon Perreault <[email-masked]>
Date: Sun, 1 Apr 2018 12:56:18 -0400

2018-03-31 18:50 GMT-04:00 Justin Uberti <[email-masked]>:

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

Simon

---

From: Justin Uberti <[email-masked]>
Date: Sun, 01 Apr 2018 22:09:40 +0000

On Sun, Apr 1, 2018 at 9:56 AM Simon Perreault <[email-masked]> wrote:

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

---

From: Brandon Williams <[email-masked]>
Date: Mon, 2 Apr 2018 12:22:38 -0400

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 <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     2018-03-31 18:50 GMT-04:00 Justin Uberti <[email-masked]
>     <mailto:[email-masked]>>:
> 
>         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?
> 
>     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

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Sat, 7 Apr 2018 07:17:17 +0000

> -----Original Message-----
> From: Brandon Williams [mailto:[email-masked]]
> Sent: Monday, April 2, 2018 9:53 PM
> To: Justin Uberti <[email-masked]>; Simon Perreault <[email-masked]>
> Cc: Konda, Tirumaleswar Reddy <[email-masked]>;
> Nils Ohlmeier <[email-masked]>; Cullen Jennings (fluffy)
> <[email-masked]>; Eric Rescorla <[email-masked]>; [email-masked]
> 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.
> 
> 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

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