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

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

> -----Original Message-----
> From: Brandon Williams [mailto:[email-masked]]
> Sent: Friday, March 21, 2014 7:45 PM
> To: Simon Perreault; Tirumaleswar Reddy (tireddy); Prashanth Patil (praspati);
> [email-masked]
> Subject: Re: [tram] TURN server discovery (please discuss!)
> 
> 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.

> The network geographic location of the attacker
> could be limited, but such attacks could not be prevented entirely.
> 
> Of course, TLS or DTLS could be used for this purpose, but is it reasonable to
> require that overhead just for the purpose of authenticating the TURN control
> traffic?

D{TLS}  would also be required for privacy reasons for example to ensure eavesdropper does not find out the remote peer the user is communicating. 

-Tiru

> 
> --Brandon
> 
> On 03/21/2014 08:58 AM, Simon Perreault wrote:
> > Le 2014-03-21 03:33, Tirumaleswar Reddy (tireddy) a écrit :
> >> Yes. It brings few other challenges like if TURN server is provided by ISP then
> how will authentication and authorization work ?
> >> I mean for users logging into a coffee shop, Hotels etc.
> >>
> >> How will these endpoints know the credentials to use with the TURN servers
> provided by ISP ?
> >
> > 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.
> >
> > Simon
> >
> 
> --
> Brandon Williams; Senior Principal Software Engineer Emerging Products
> Engineering; Akamai Technologies Inc.

---

From: Simon Perreault <[email-masked]>
Date: Fri, 21 Mar 2014 12:11:03 -0400

> Agreed, some type of authentication is necessary.

That's not what I would call authentication. [D]TLS without
authentication protects against message injection AFAIK.

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: Brandon Williams <[email-masked]>
Date: Fri, 21 Mar 2014 12:28:36 -0400

> authentication protects against message injection AFAIK.

Agreed. Authentication was probably the wrong word. STUN mixes user 
authentication together with session-level integrity verification in 
such a way that if you lose one, you also lose the other. If we assume 
user authentication via some other mechanism, then we need to define an 
alternate integrity verification method. I'm not sure that requiring 
(D)TLS is the right way to do it, but I agree it's an option.

--Brandon

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

---

From: Brandon Williams <[email-masked]>
Date: Fri, 21 Mar 2014 12:32:44 -0400

> D{TLS}  would also be required for privacy reasons for example to ensure eavesdropper does not find out the remote peer the user is communicating.

I didn't mean to suggest that you don't get other benefits from using 
secure transport. I simply meant that requiring secure transport in 
order to get server discovery doesn't seem like it should be necessary.

--Brandon