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

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

> -----Original Message-----
> From: tram [mailto:[email-masked]] On Behalf Of Simon Perreault
> Sent: Thursday, March 20, 2014 9:00 PM
> To: Prashanth Patil (praspati); [email-masked]
> Subject: Re: [tram] TURN server discovery (please discuss!)
> 
> Le 2014-03-20 10:48, Prashanth Patil (praspati) a écrit :
> > There was a suggestion that domain name could also be extracted from
> > own SIP/XMPP/email identity
> > (http://www.ietf.org/mail-archive/web/tram/current/msg00156.html)-
> > which we plan to add to the draft in the next version.
> 
> But that doesn't work because it would be an application-provided TURN server.
> We need to discover network-provided TURN servers.

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 ?

-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
> 
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram

---

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

> 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

---

From: Brandon Williams <[email-masked]>
Date: Fri, 21 Mar 2014 10:14:56 -0400

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

--Brandon

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

---

From: Brandon Williams <[email-masked]>
Date: Fri, 21 Mar 2014 10:31:00 -0400

On a separate note, also related to (D)TLS ...

It's not completely clear to me how the anycast approach to server 
discovery would work together with secure data flows. What are the 
server-side cert requirements in order to make an anycast solution work? 
I'm not suggesting that it won't work -- just that people (like me) who 
do have much expertize with cert management may need to have it spelled 
out in order to evaluate whether the requirements seem reasonable.

--Brandon

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Sat, 22 Mar 2014 09:03:45 +0000

>out in order to evaluate whether the requirements seem reasonable.

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.
Once you have a definitive address, certificate management (or issues with
it) has to be dealt with the same way it's done for addresses learnt any
other way.

-Prashanth 

>>>> Yes. It brings few other challenges like if TURN server is provided
>>>>by ISP then how will authentication and authorization work ?

---

From: Brandon Williams <[email-masked]>
Date: Mon, 24 Mar 2014 12:29:35 -0400

> it) has to be dealt with the same way it's done for addresses learnt any

I see a typo in my previous message ... "people who _do_ have much 
expertize with cert management" should have been "people who _don't_ 
have much expertize with cert management". I think that was obvious from 
the context, but it still seemed worth pointing out, since when I 
suggested that it may need to be spelled out, I really meant that.

You've described the response to the anycast request, but that assumes 
that a DTLS session has already been negotiated. I'm interested in the 
cert requirements for getting that DTLS session set up in the first 
place. Are they self-signed certificates? How can the client know that 
it has connected to a trusted TURN server? Is there an assumption that 
DTLS in this context will really only be useful for protecting against 
passive eavesdropping and man-in-the-middle attacks after session 
establishment, not potentially malicious TURN servers? Will the TURN 
client be required to accept certs in this context that it would not 
accept in other contexts?

--Brandon

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Tue, 25 Mar 2014 12:12:28 +0000

On 3/24/14 9:59 PM, "Brandon Williams" <[email-masked]> wrote:

>that a DTLS session has already been negotiated.

Im assuming anycast is not secured. DTLS will only be negotiated for
communication with the unicast IP address obtained in the anycast
response. It probably needs to be this way, so that servers that do not
support DTLS can also respond to anycast requests.

>I'm interested in the
>establishment, not potentially malicious TURN servers?

Trust management is indeed tricky. In its absence, opportunistic
encryption is probably what we'll end up.

-Prashanth

>Will the TURN

---

From: Simon Perreault <[email-masked]>
Date: Tue, 25 Mar 2014 10:32:24 -0400

Le 2014-03-25 08:12, Prashanth Patil (praspati) a écrit :
> Im assuming anycast is not secured.

Do you mean a TURN server responding to the *well-known* anycast
address, or any anycast address at all?

I can imagine an application provider using anycast for its own TURN
server cloud, but not using the well-known anycast address. I would
expect this to be secured.

A concrete example: a WebRTC application provider, let's name it
callyourmom.com, sets up 3 TURN servers located in America, Europe, and
Asia. It sets up anycast with IP addresses it owns (not the well-known
addresses). The name turn.callyourmom.com resolves to those anycast
addresses. When a (D)TLS connection is attempted to
turn.callyourmom.com, I would expect the server certificate to be
verified by the client to ensure it is signed by a trusted CA and
matches the turn.callyourmom.com domain name. Then when it receives the
ALTERNATE-SERVER IP address, a new (D)TLS connection would be made, and
once again the server certificate should be verified to match the
turn.callyourmom.com domain name. So even though the ALTERNATE-SERVER
attribute only contains an IP address, the original domain name used for
the first connection is used for validating the server certificate.

Did I get that right?

Simon

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Tue, 25 Mar 2014 15:15:21 +0000

>address, or any anycast address at all?

I meant *well known*, an address assigned by IANA as suggested in the
draft.

>the first connection is used for validating the server certificate.

Yes, and it's easier because the client already knows or has discovered
the domain name, which can be verified. Complicated when the client
discovers an IP address from a well known anycast.

-Prashanth