Subject: [tram] TURN-over-DTLS draft: comments on today's session

From: Jonathan Lennox <[email-masked]>
Date: Thu, 6 Mar 2014 00:45:58 +0000

Hi — due to the conflict with PAYLOAD, I’m watching TRAM now off Meetecho.  So, a few comments on the TURN-over-DTLS discussion:

On ICE pacing — I think the point of ICE pacing is not to reduce the amount of network traffic, but rather to slow the rate at which NAT bindings are created.  Even though TURN-over-DTLS uses a fair number of packets, it’s still only a single NAT binding establishment.  So I think there’s no issue, and ICE pacing doesn’t need to change.

The other certificate question I had — I also raised this previously on this list for TURN-over-TLS.  If a client receives a 300 Try Alternate response to a STUN request, it only receives an IP and port for the ALTERNATE-SERVER to use.  What identity, then, should the client expect the alternate server to assert in its certificate?  We could require that the alternate server always presents the same identity as the original did, but that would seem somewhat limiting to the types of load balancing architectures that could be possible.  Do we need to define a new ALTERNATE-SERVER-NAME attribute?

---

From: Brandon Williams <[email-masked]>
Date: Thu, 06 Mar 2014 09:26:55 +0000

In SaaS-based TURN use cases, at least, ALTERNATE-SERVER-NAME would not 
be required. The name used for DTLS (or TLS) would typically be same for 
the two servers.

I think that without an ALTERNATE-SERVER-NAME attribute, this 
characteristic of the relationship between the ALTERNATE-SERVER and the 
server that issues the error (i.e. they have the same name for 
authentication purposes) may be a requirement. Or is there another way 
that I'm not thinking of to get an alternate name for auth purposes?

--Brandon

On 03/06/2014 12:45 AM, Jonathan Lennox wrote:
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>

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

---

From: Simon Perreault <[email-masked]>
Date: Thu, 06 Mar 2014 09:34:19 +0000

Le 2014-03-06 00:45, Jonathan Lennox a écrit :
> The other certificate question I had — I also raised this previously
> on this list for TURN-over-TLS.  If a client receives a 300 Try
> Alternate response to a STUN request, it only receives an IP and port
> for the ALTERNATE-SERVER to use.  What identity, then, should the
> client expect the alternate server to assert in its certificate?  We
> could require that the alternate server always presents the same
> identity as the original did, but that would seem somewhat limiting
> to the types of load balancing architectures that could be possible.

What limitations specifically do you have in mind?

Thanks,
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: Martin Thomson <[email-masked]>
Date: Thu, 6 Mar 2014 10:07:29 +0000

On 6 March 2014 00:45, Jonathan Lennox <[email-masked]> wrote:
>  If a client receives a 300 Try Alternate response to a STUN request, it only receives an IP and port for the ALTERNATE-SERVER to use.  What identity, then, should the client expect the alternate server to assert in its certificate?

In other protocols, when a redirection of this sort occurs, there is
an expectation that the original name is used to authenticate the
server.

That is, if example.com provides a redirect to some new IP, the server
at the new address needs to offer a certificate that is valid for
example.com.

---

From: Justin Uberti <[email-masked]>
Date: Thu, 6 Mar 2014 13:08:03 +0000

On Thu, Mar 6, 2014 at 12:45 AM, Jonathan Lennox <[email-masked]> wrote:

> Hi — due to the conflict with PAYLOAD, I’m watching TRAM now off Meetecho.
>  So, a few comments on the TURN-over-DTLS discussion:
>
> On ICE pacing — I think the point of ICE pacing is not to reduce the
> amount of network traffic, but rather to slow the rate at which NAT
> bindings are created.  Even though TURN-over-DTLS uses a fair number of
> packets, it’s still only a single NAT binding establishment.  So I think
> there’s no issue, and ICE pacing doesn’t need to change.
>

Agreed regarding pacing, thanks for pointing that out. The overall
bandwidth increase will be negligible.

>
> The other certificate question I had — I also raised this previously on
> this list for TURN-over-TLS.  If a client receives a 300 Try Alternate
> response to a STUN request, it only receives an IP and port for the
> ALTERNATE-SERVER to use.  What identity, then, should the client expect the
> alternate server to assert in its certificate?  We could require that the
> alternate server always presents the same identity as the original did, but
> that would seem somewhat limiting to the types of load balancing
> architectures that could be possible.  Do we need to define a new
> ALTERNATE-SERVER-NAME attribute?

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 6 Mar 2014 13:35:37 +0000

> What limitations specifically do you have in mind?

Consider the use case where turn.small-isp.example is providing TURN relay services, but has contracted with turn.cloud-provider.example to handle surge capacity if it’s overloaded.  cloud-provider.example charges them for bandwidth, so they don’t want to use them all the time.

It could be nice if small-isp didn't have to provision a certificate with cloud-provider, but could just redirect to them securely.

With current TURN authentication mechanisms they’ll still to share user databases and the like, though with the various authentication updates even that might not be necessary.  (Obviously cloud-provider needs to be able to identify users as being customers of small-isp, but ORIGIN should solve that.)