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

From: Simon Perreault <[email-masked]>
Date: Mon, 19 Mar 2018 06:50:42 -0400

Tramsters,

$subject is an very interesting idea from EKR presented today by Cullen in
DISPATCH. Could/should we do this in TURN-bis? This could make TURN *much*
more attractive for certain use cases that require fewer round trips...

Simon

---

From: Brandon Williams <[email-masked]>
Date: Mon, 19 Mar 2018 16:50:02 -0400

The idea reminds me of the ufrag permissions draft that Justin and I put 
together a few years ago. It didn't generate much interest at the time, 
but maybe it's time to give it another look?

https://tools.ietf.org/html/draft-williams-tram-ufrag-permission-00

Not quite "forward without permission", but close.

In addition, some of the other parts of the new media stack deck (i.e. 
ICN and controller-based architecture) make me think of the discussions 
some of us have had about trying to allow TURN servers to act as a 
sort-of virtual mutlicast node.

--Brandon

On 03/19/2018 06:50 AM, Simon Perreault wrote:
> Tramsters,
> 
> $subject is an very interesting idea from EKR presented today by Cullen 
> in DISPATCH. Could/should we do this in TURN-bis? This could make TURN 
> *much* more attractive for certain use cases that require fewer round 
> trips...
> 
> Simon
> 
> 
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>

---

From: Nils Ohlmeier <[email-masked]>
Date: Mon, 19 Mar 2018 22:43:04 +0000

It does indeed.

I think in general this is worth looking into.

I also like the idea of simply forwarding all binding requests to the TURN client. Because 1) it does not expose the ufrag to the network when talking to the TURN server. And 2) it’s easier for the TURN server to just check for the STUN request type and hot have to parse for the ufrag attribute as well.

One question which comes to my mind is if the TURN server at some point, e.g. after receiving the permission request, stops forwarding the binding requests blindly?

Best
  Nils Ohlmeier

> On Mar 19, 2018, at 20:50, Brandon Williams <[email-masked]> wrote:
> 
> The idea reminds me of the ufrag permissions draft that Justin and I put together a few years ago. It didn't generate much interest at the time, but maybe it's time to give it another look?
> 
> In addition, some of the other parts of the new media stack deck (i.e. ICN and controller-based architecture) make me think of the discussions some of us have had about trying to allow TURN servers to act as a sort-of virtual mutlicast node.
> 
> --Brandon
> 
>> $subject is an very interesting idea from EKR presented today by Cullen in DISPATCH. Could/should we do this in TURN-bis? This could make TURN *much* more attractive for certain use cases that require fewer round trips...
>> Simon

---

From: Simon Perreault <[email-masked]>
Date: Tue, 20 Mar 2018 06:07:59 -0400

Wow, I had totally forgotten about ufrag perms!

2018-03-19 22:43 GMT+00:00 Nils Ohlmeier <[email-masked]>:
>
> I also like the idea of simply forwarding all binding requests to the TURN
> client. Because 1) it does not expose the ufrag to the network when talking
> to the TURN server. And 2) it’s easier for the TURN server to just check
> for the STUN request type and hot have to parse for the ufrag attribute as
> well.
>

Same opinion here. The point of permissions is to prevent TURN clients from
being able to run generic servers. It seems like always allowing STUN
packets would preserve this feature while solving the session establishment
latency problem. And would be quite a bit simpler to implement than ufrag
perms. Have your cake, eat it, and eat it a second time.

Also, because this is so simple (just one sentence to specify it!), and
impact potential is so great (make Brandon happy!), I wonder if we
shouldn't simply add it to TURN-bis while there's still time.

One question which comes to my mind is if the TURN server at some point,
> e.g. after receiving the permission request, stops forwarding the binding
> requests blindly?

Because the allocation might be paired with multiple remote candidates, I
think we'd need to always forward STUN blindly.

Simon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 20 Mar 2018 10:31:00 +0000

Nice optimization.
We should also discuss the security implications, If any STUN packet is allowed from anyone in the Internet, the TURN client could be subjected to DDoS attack (e.g. spoofed STUN packets from attackers, client wastes cycles validating the message integrity, and could also be subjected to bandwidth-hogging attack).

-Tiru

From: tram [mailto:[email-masked]] On Behalf Of Simon Perreault
Sent: Tuesday, March 20, 2018 10:08 AM
To: Nils Ohlmeier <[email-masked]>
Cc: Cullen Jennings <[email-masked]>; Eric Rescorla <[email-masked]>; [email-masked]; Brandon Williams <[email-masked]>
Subject: Re: [tram] Allow TURN to forward inbound connectivity checks without permission

2018-03-19 22:43 GMT+00:00 Nils Ohlmeier <[email-masked]<mailto:[email-masked]>>:
I also like the idea of simply forwarding all binding requests to the TURN client. Because 1) it does not expose the ufrag to the network when talking to the TURN server. And 2) it’s easier for the TURN server to just check for the STUN request type and hot have to parse for the ufrag attribute as well.

Same opinion here. The point of permissions is to prevent TURN clients from being able to run generic servers. It seems like always allowing STUN packets would preserve this feature while solving the session establishment latency problem. And would be quite a bit simpler to implement than ufrag perms. Have your cake, eat it, and eat it a second time.

Also, because this is so simple (just one sentence to specify it!), and impact potential is so great (make Brandon happy!), I wonder if we shouldn't simply add it to TURN-bis while there's still time.

Because the allocation might be paired with multiple remote candidates, I think we'd need to always forward STUN blindly.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Tue, 20 Mar 2018 08:17:29 -0400

2018-03-20 10:31 GMT+00:00 Konda, Tirumaleswar Reddy <
[email-masked]>:

> the TURN client could be subjected to DDoS attack (e.g. spoofed STUN
> packets from attackers, client wastes cycles validating the message
> integrity, and could also be subjected to bandwidth-hogging attack).
>

That would be new to TURN, but not new to the client: NAT pinholes, created
with STUN or otherwise, expose the client similarly. So while this is
certainly worth mentioning in the security considerations section, I don't
see this as a blocker.

I also can't think of a way that this could be exploited to mount any kind
of practical attack against a specific target...

Simon

---

From: Nils Ohlmeier <[email-masked]>
Date: Tue, 20 Mar 2018 12:30:00 +0000

> On Mar 20, 2018, at 12:17, Simon Perreault <[email-masked]> wrote:
> 
> 2018-03-20 10:31 GMT+00:00 Konda, Tirumaleswar Reddy <[email-masked] <mailto:[email-masked]>>:
> the TURN client could be subjected to DDoS attack (e.g. spoofed STUN packets from attackers, client wastes cycles validating the message integrity, and could also be subjected to bandwidth-hogging attack).
> 
> 
> That would be new to TURN, but not new to the client: NAT pinholes, created with STUN or otherwise, expose the client similarly. So while this is certainly worth mentioning in the security considerations section, I don't see this as a blocker.
> 
> I also can't think of a way that this could be exploited to mount any kind of practical attack against a specific target…

I guess you could divide this into three categories:

- the TURN client is an ICE agent, which needs to be prepared to handle any incoming traffic already any way
- the TURN client is not an ICE agent, but a STUN client, and as Simon pointed out needs to be prepared to receive traffic through the pin holes it created
- the TURN client is purely a TURN client and only ever expected to get traffic back from the TURN relay

I would assume the last scenario is not very common, but I don’t have any numbers to back that up.
I think Simon is right that it’s worth mentioning in the security considerations.

Best
  Nils Ohlmeier

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 20 Mar 2018 14:33:05 +0000

Agreed, it’s not a blocker but needs to be discussed in the Security Considerations section.

-Tiru

From: Nils Ohlmeier [mailto:[email-masked]]
Sent: Tuesday, March 20, 2018 12:30 PM
To: Simon Perreault <[email-masked]>
Cc: Konda, Tirumaleswar Reddy <[email-masked]>; Cullen Jennings <[email-masked]>; Eric Rescorla <[email-masked]>; [email-masked]; Brandon Williams <[email-masked]>
Subject: Re: [tram] Allow TURN to forward inbound connectivity checks without permission

On Mar 20, 2018, at 12:17, Simon Perreault <[email-masked]<mailto:[email-masked]>> wrote:

2018-03-20 10:31 GMT+00:00 Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>:
the TURN client could be subjected to DDoS attack (e.g. spoofed STUN packets from attackers, client wastes cycles validating the message integrity, and could also be subjected to bandwidth-hogging attack).

Best
  Nils Ohlmeier

---

From: Brandon Williams <[email-masked]>
Date: Tue, 20 Mar 2018 11:01:55 -0400

On 03/20/2018 06:07 AM, Simon Perreault wrote:
> Same opinion here. The point of permissions is to prevent TURN clients 
> from being able to run generic servers. It seems like always allowing 
> STUN packets would preserve this feature while solving the session 
> establishment latency problem. And would be quite a bit simpler to 
> implement than ufrag perms. Have your cake, eat it, and eat it a second 
> time.

If you want to prevent someone from running a server on the allocation 
you can't assume that a STUN-looking packet is actually legitimate, so 
some additional validations would be required. Perhaps packet size, 
rate-limiting, and max session counts are enough.

ufrag permissions didn't do enough to be more meaningful there, since it 
would be easy to post the ufrag somewhere public via a mechanism similar 
to dynamic DNS.

--Brandon

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 20 Mar 2018 15:07:56 +0000

> -----Original Message-----
> From: tram [mailto:[email-masked]] On Behalf Of Brandon Williams
> Sent: Tuesday, March 20, 2018 3:02 PM
> To: Simon Perreault <[email-masked]>; Nils Ohlmeier
> <[email-masked]>
> Cc: Cullen Jennings <[email-masked]>; Eric Rescorla <[email-masked]>;
> [email-masked]
> > implement than ufrag perms. Have your cake, eat it, and eat it a
> > second time.
> 
> If you want to prevent someone from running a server on the allocation you
> can't assume that a STUN-looking packet is actually legitimate, so some
> additional validations would be required. Perhaps packet size, rate-limiting, and
> max session counts are enough.

TURN server can also check for the presence of username and MI in the 
STUN packets.

-Tiru

> 
> ufrag permissions didn't do enough to be more meaningful there, since it would
> be easy to post the ufrag somewhere public via a mechanism similar to dynamic
> DNS.
> 
> --Brandon
> 
>

---

From: Justin Uberti <[email-masked]>
Date: Sat, 31 Mar 2018 22:50:41 +0000

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.

On Tue, Mar 20, 2018 at 8:09 AM Konda, Tirumaleswar Reddy <
[email-masked]> wrote:

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