Subject: Re: [tram] TURN server discovery (please discuss!)

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 21 Mar 2014 16:51:02 +0000

> -----Original Message-----
> From: Simon Perreault [mailto:[email-masked]]
> Sent: Friday, March 21, 2014 9:41 PM
> To: Tirumaleswar Reddy (tireddy); Brandon Williams; Prashanth Patil (praspati);
> [email-masked]
> Subject: Re: [tram] TURN server discovery (please discuss!)
> 
> Le 2014-03-21 12:07, Tirumaleswar Reddy (tireddy) a écrit :
> >> I think that some type of authentication is necessary, even if all it
> >> provides is the ability to verify that the two ends of the tunnel
> >> remain consistent throughout the life of the allocation. Without at
> >> least that, then the service is open to DOS attacks via message injection.
> >
> > Agreed, some type of authentication is necessary.
> 
> That's not what I would call authentication. [D]TLS without authentication
> protects against message injection AFAIK.

DTLS without authentication won't protect the TURN server from clients sending huge number of Allocate requests and taking up all the resources in the TURN server. 
I think both D{TLS} and authentication is required.

-Tiru

> 
> Simon
> --
> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
> STUN/TURN server               --> http://numb.viagenie.ca

---

From: "Karl Stahl" <[email-masked]>
Date: Fri, 21 Mar 2014 21:03:26 +0100

1) I want to emphasize Simon's view in the authentication discussion:
" If the TURN server is provided by the network, couldn't we assume that
authentication is network-based? That is, if you succeed in talking to the
server, then that means you're good. TURN servers would effectively have "no
authentication" in the protocol."

The need for this milestone mechanism/RFC is for an enterprise or a an ISP
to announce a TURN server for their users of their network. The DHCP method
directly reflects this by responding:
"Here are your IP address, your default gateway, your DNS servers and now
the suggested TURN server to use". (The TURN deployed is a networks resource
only available on the local connection - it only has the allocated public
port available to the WAN-side. That is TURN server/router/firewall
combination more or less integrated.) 

So the auto discovered turn-server should only be available and offered to
those allowed to use it - rather than being authenticated (like an
application provided TURN server is). The browser should use the auto
discovered TURN server without authentication.

2) The opposite - Can the browser trust the TURN server offered (also raised
here)? - is not a problem with the DHCP method (If we get network resources
like our IP address, default gateway via DHCP, we should of course also
trust and the same DHCP server with giving us the TURN server address to
place our real-time traffic at.)

However, that may not be the case with the AnyCast method. Simon previously
raised:
"> Suppose we define well-known anycast TURN server addresses. How would 
> this not be subject to the same service quality issues that plagued 
> 6to4? That is, anyone could set up a badly-maintained, 
> under-provisioned TURN server and announce it over BGP to the world, 
> as it was done for
> 6to4 relays. Or just bad BGP outbound filter configuration. And how 
> can we prevent triangle routing? There is nothing guaranteeing that 
> the anycast server you see is being provided to you by your ISP, 
> rather than a server sitting on the other side of the planet

I got an "network-way idea" to address this from a developer of ours that I
have not considered/presented yet and I will also read up on draft
draft-patil-tram-turn-serv-disc-00, and see it I have some educated thoughts
to contribute. It would be good if we can avoid having to introduce
certificates or similar here and just stick to the network level.

A few other points (maybe a better read of
draft-patil-tram-turn-serv-disc-00 obsoletes some of these points and I will
know better on Monday, but anyway):

3) Two methods (DHCP and Anycast) are suggested in the draft. I assume the
thought is that browsers must implement both and the ISP can use any.
Correct? 
- But if one is good enough, shall we then drop the other to make life
easier? 

4) In addition to some doubts raised here against the DHCP discovery, there
were plenty in the discussion at the September-October discussion at the
[rtcweb]-list (summary in
http://www.ietf.org/mail-archive/web/tram/current/msg00132.html), mainly: 

a: concerns whether OSs actually forwards such extended DHCP information for
the browser to use
- If I remember correctly, only Bernard Aboba from MS confirmed that is was
available in Windows.

b: I withdrew my own(!) suggestion to use DHCP to find a network provider
offered TURN server because DHCP is NOT used in many networks, which instead
use (for handing out IP address etc): RA - Router Advertisement - in IPv6,
the IPCP protocol for PPPoE and something else for the mobile OTT channel.

I tend to focus on the Anycast method only (but will read up on
draft-patil-tram-turn-serv-disc-00 until Monday and may be more educated
then...)

/Karl   

-----Ursprungligt meddelande-----
Från: tram [mailto:[email-masked]] För Tirumaleswar Reddy (tireddy)
Skickat: den 21 mars 2014 17:51
Till: Simon Perreault; Brandon Williams; Prashanth Patil (praspati);
[email-masked]
Ämne: Re: [tram] TURN server discovery (please discuss!)

> To: Tirumaleswar Reddy (tireddy); Brandon Williams; Prashanth Patil 
> (praspati); [email-masked]
> >> I think that some type of authentication is necessary, even if all 
> >> it provides is the ability to verify that the two ends of the 
> >> tunnel remain consistent throughout the life of the allocation. 
> >> Without at least that, then the service is open to DOS attacks via
message injection.
> That's not what I would call authentication. [D]TLS without 
> authentication protects against message injection AFAIK.

DTLS without authentication won't protect the TURN server from clients
sending huge number of Allocate requests and taking up all the resources in
the TURN server. 
I think both D{TLS} and authentication is required.

-Tiru

> Simon

_______________________________________________
tram mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tram

---

From: Brandon Williams <[email-masked]>
Date: Fri, 21 Mar 2014 16:24:19 -0400

Since it's a service being provided by the network provider, the 
provider could easily apply a policy-based solution to the problem you 
describe (e.g. rate-limiting allocation requests). Are there other 
specific operations where you think lack of authentication could be a 
problem to which it's not possible to apply a policy-enforcement solution?

--Brandon

-- 
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.

---

From: Oleg Moskalenko <[email-masked]>
Date: Fri, 21 Mar 2014 13:49:33 -0700

Current situation is that the existing WebRTC clients do not support TURN
servers without authentication (no-authentication option).

Having a sort of authentication to simplify the DOS attacks defense would
be nice. For example, a long-term credentials mechanism with password
equals to the username. Then any client will be able to authenticate itself
but a DOS attack would be difficult - because a full auth cycle will be
happening. A replay attacks will also be addressed, if the TURN server
handles the nonces properly.

On Fri, Mar 21, 2014 at 1:24 PM, Brandon Williams <
[email-masked]> wrote:

> Since it's a service being provided by the network provider, the provider
> could easily apply a policy-based solution to the problem you describe
> (e.g. rate-limiting allocation requests). Are there other specific
> operations where you think lack of authentication could be a problem to
> which it's not possible to apply a policy-enforcement solution?
>
> --Brandon
>
>
>>> (praspati);
>>> authentication

---

From: Simon Perreault <[email-masked]>
Date: Fri, 21 Mar 2014 16:59:41 -0400

Le 2014-03-21 16:49, Oleg Moskalenko a écrit :
> Current situation is that the existing WebRTC clients do not support
> TURN servers without authentication (no-authentication option).

If this is indeed the case, wouldn't it be trivial to modify the
client's code so that auth-less TURN servers are supported?

> Having a sort of authentication to simplify the DOS attacks defense
> would be nice. For example, a long-term credentials mechanism with
> password equals to the username. Then any client will be able to
> authenticate itself but a DOS attack would be difficult - because a full
> auth cycle will be happening. 

Where does the username come from?

How would a "full auth cycle" prevent a DoS?

> A replay attacks will also be addressed,
> if the TURN server handles the nonces properly.

I don't see what threat this addresses.

Simon

---

From: Oleg Moskalenko <[email-masked]>
Date: Fri, 21 Mar 2014 14:11:22 -0700

> client's code so that auth-less TURN servers are supported?

that's a question for WebRTC platform developers (not application
developers, that's part of the core). Hopefully that must be easy. But the
existing WebRTC clients will have to be replaced.

> Where does the username come from?

In the proposed scheme, the TURN client is free to use any username. In the
TURN auth challenge reply, clients sends the username in the response. So
the TURN server learns the username. Then the TURN server can take that
username and assume that the password is equal to the username. Then the
server is checking the validity of the reply - going thru the full
integrity check. If the nonce is unique, then the dialog will be unique and
cannot be copied.

> How would a "full auth cycle" prevent a DoS?

The auth dialog will serve the same purpose as the cookie request-response
in DTLS negotiations. Each dialog is unique, so a DOS attack is much more
difficult - because a stupid simple traffic generator would not work.

> I don't see what threat this addresses.

A simple replay of the client traffic will be rejected by the server.

Oleg

---

From: Simon Perreault <[email-masked]>
Date: Fri, 21 Mar 2014 17:18:29 -0400

Le 2014-03-21 17:11, Oleg Moskalenko a écrit :
> In the proposed scheme, the TURN client is free to use any username. In
> the TURN auth challenge reply, clients sends the username in the
> response. So the TURN server learns the username. Then the TURN server
> can take that username and assume that the password is equal to the
> username. Then the server is checking the validity of the reply - going
> thru the full integrity check. If the nonce is unique, then the dialog
> will be unique and cannot be copied.
> 
> 
> The auth dialog will serve the same purpose as the cookie
> request-response in DTLS negotiations. Each dialog is unique, so a DOS
> attack is much more difficult - because a stupid simple traffic
> generator would not work.

So it's all about making the client implementation more complex so that
only determined attackers can launch an attack?

If that's right then I don't see what this would buy us. Smells like
security by obscurity. The server would still need to enforce a usage
policy as described by Brandon.

Simon

---

From: Oleg Moskalenko <[email-masked]>
Date: Fri, 21 Mar 2014 14:54:08 -0700

> only determined attackers can launch an attack?

No, that's not right. I propose NO CHANGES to the client. That behavior
does not introduce anything new. That is using the existing auth mechanism.
I just proposed a convention that for the network-secured TURN servers, we
use passwords equal to the usernames. That's it. Then the clients will be
100% backward-compatible, we will have cookie-like dialog session
protection and the real authentication burden will be on the network
infrastructure: if  client can connect to the server, then the client is
allowed to use the server. We will have the best of two approaches.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 24 Mar 2014 09:04:03 -0400

Le 2014-03-21 17:54, Oleg Moskalenko a écrit :
> does not introduce anything new. That is using the existing auth
> mechanism. I just proposed a convention that for the network-secured
> TURN servers, we use passwords equal to the usernames. That's it. Then
> the clients will be 100% backward-compatible, we will have cookie-like
> dialog session protection and the real authentication burden will be on
> the network infrastructure: if  client can connect to the server, then
> the client is allowed to use the server. We will have the best of two
> approaches.

I'm sorry, I still don't get it fully.

I understand the value of cookies in network protocols in general. But
what I don't understand is:

- What threat would this proposal be protecting against in STUN
specifically? Can you give an example of an attack that this proposal
would prevent?

- Why is it important that we do not change clients?

- Why do you not consider the new client behaviour "generate a username,
use it as the password as well" a change to client implementation?

Simon

---

From: Oleg Moskalenko <[email-masked]>
Date: Mon, 24 Mar 2014 10:39:12 -0700

> specifically? Can you give an example of an attack that this proposal

I was talking about TURN ALLOCATE - not STUN BINDING - requests. If you
take a look at the ALLOCATE dialog, you will see that a simple
traffic-generator client just in a few seconds can exhaust the whole TURN
server capacity - if no authentication is used. Many thousands allocations
can be created in a few seconds if the client sends the same request from
different local ports - and the client even does not have to listen to the
replies. Or even a simple software error can cause the same effect. You
come with a laptop to a coffee shop and after a few seconds you shutdown
the coffee shop's network TURN server. Nice. With a sort of authentication
(even a bogus one) that task will be much more difficult for a malicious
client - it will buy some time for the network equipment to determine wrong
situation, at least.

If TLS or DTLS is used as the protocol, that "bogus authentication" would
be not necessary, the TLS/DTLS handshake would serve the same purpose.

Another reason for a "bogus authentication" is to provide some voluntary
information to the server for logging.

> - Why is it important that we do not change clients?

backward compatibility is a good thing

> use it as the password as well" a change to client implementation?

that's a minor application-level change. Still a change, I admit.

Oleg

---

From: Brandon Williams <[email-masked]>
Date: Mon, 24 Mar 2014 15:53:09 -0400

Hi Oleg,

I'm not seeing how the mechanism you propose would help in the attack 
scenario you describe. Why would a traffic generator client looking to 
exhaust the TURN server capacity not just send bogus usernames in the 
attack packets?

--Brandon

On 03/24/2014 01:39 PM, Oleg Moskalenko wrote:
>
>
>
> On Mon, Mar 24, 2014 at 6:04 AM, Simon Perreault
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> traffic-generator client just in a few seconds can exhaust the whole
> TURN server capacity - if no authentication is used. Many thousands
> allocations can be created in a few seconds if the client sends the same
> request from different local ports - and the client even does not have
> to listen to the replies. Or even a simple software error can cause the
> same effect. You come with a laptop to a coffee shop and after a few
> seconds you shutdown the coffee shop's network TURN server. Nice. With a
> sort of authentication (even a bogus one) that task will be much more
> difficult for a malicious client - it will buy some time for the network
> equipment to determine wrong situation, at least.
>
> If TLS or DTLS is used as the protocol, that "bogus authentication"
> would be not necessary, the TLS/DTLS handshake would serve the same purpose.
>

---

From: Oleg Moskalenko <[email-masked]>
Date: Mon, 24 Mar 2014 13:13:58 -0700

This is somewhat similar to, say, the cookie mechanism in DTLS. In the
"bogs authentication" scheme, the client must be statefull - it must
examine every response packet and it must invoke real digest calculation
algorithms to construct the authenticated ALLOCATE request (after the
challenge response). So it is like 100 or 1000 times more calculation-heavy
than sending thousands similar initial ALLOCATION requests with a "traffic
generator" tool. This is a cheap simple first-line defense against a naive
DoS attack.

A TURN server may invoke another defense mechanism - an allocation rate
control limitation. But still the effect of a DoS attack would be similar -
the "real" clients will not be able to connect to the TURN server if a
malicious  "traffic generator" client
is active.

---

From: "Karl Stahl" <[email-masked]>
Date: Mon, 31 Mar 2014 23:01:09 +0200

I read the turn server discovery draft more thoroughly now and think it does
the job well, with the following remarks:

A) The problem 2) below (With the anycast method, can we know that it really
is our trusted enterprise or ISP providing the TURN server, i.e. is it
close?). You have the solution (actually same as the "network-way idea" I
mentioned below) in 8.2 already (although spelled out for other reasons):
"Sensitive clients that do not wish to leak information about their presence
can set an IP TTL on their TURN requests that limits how far they can travel
into the public Internet."

I suggest that this TTL limitation with the anycast method is specified
(e.g. Don't look further than 3 steps - local firewall + max 2 ISP routers)
and brought into section 3. Discovery Procedure, step 3 of the draft.

B) Shall we have more than one method (see 3 and 4 below)? If the Anycast
method can be used by everyone, why then also have DHCP?

I have heard more fears that DHCP options are not available in common OSs.
If so, the DHCP method should be skipped. If a service provider deploys DHCP
discovered TURN servers, but some webrtc browser don't find/can use them, it
would just be bad.

C) I saw Patil's advertised change to the Anycast method
http://www.ietf.org/mail-archive/web/tram/current/msg00433.html and agree it
is better:
"The response to an anycast request will be a 300 (try alternate) response.
The response will contain the unicast address in the ALTERNATE_SERVER
attribute. This has been discussed (in another context), and will be
included in the next revision."

/Karl

-----Ursprungligt meddelande-----
Från: Karl Stahl [mailto:[email-masked]]
Skickat: den 21 mars 2014 21:03
Till: 'Tirumaleswar Reddy (tireddy)'; 'Simon Perreault'; 'Brandon Williams';
'Prashanth Patil (praspati)'; [email-masked]'
Ämne: SV: [tram] TURN server discovery (please discuss!)

/Karl   

-----Ursprungligt meddelande-----
Från: tram [mailto:[email-masked]] För Tirumaleswar Reddy (tireddy)
Skickat: den 21 mars 2014 17:51
Till: Simon Perreault; Brandon Williams; Prashanth Patil (praspati);
[email-masked]

message injection.

-Tiru