Subject: Re: [tram] Happy Turnballs

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 17 Apr 2017 10:25:27 +0000

> -----Original Message-----
> From: tram [mailto:[email-masked]] On Behalf Of Jonathan Lennox
> Sent: Wednesday, March 29, 2017 9:34 AM
> To: [email-masked]
> Subject: [tram] Happy Turnballs
> 
> So I was asked to write up my comments on Happy Eyeballs for TURN.  Here’re
> my thoughts.
> 
> As always with Happy Eyeballs, when connecting to a TURN server specified by
> a DNS name, do a DNS query for both IPv6 and IPv4, and then (with
> appropriate timing based on expected success), attempt to connect to both
> the returned IPv6 and IPv4 addresses, in parallel.

As per https://tools.ietf.org/html/rfc6555, by default IPv6 should have slight preference (or head-start) over IPv4 unless the client address preference policy is modified giving preference to IPv4 over IPv6.

> 
> The complexities occur when both IPv4 and IPv6 connections succeed; the
> dispreferred connection (which should usually be the IPv4 connection, but this
> is client policy) must be closed in a way that doesn’t leave lingering state on
> the server.

Agreed.

> 
> The process to follow depends on the transport protocol being used for TURN.
> 
> 1. For TCP or TLS, do standard Happy Eyeballs: initiate a TCP connect to both
> addresses, and use the first connection to succeed.  If both succeed, close the
> dispreferred connection normally (with TCP FIN, i.e. socket close) before
> sending any data on the connection.
> 
> 2. For DTLS, send (separate) clientHello messages to both addresses.
> Terminating the dispreferred DTLS association depends on the response.  If the
> server is using stateless cookies (as it normally should for a TURN server on the
> open Internet), it will send back a HelloVerifyRequest.  The preferred
> association can continue normally, and the dispreferred association can be
> silently discarded.
> 
> If the server is not using stateless cookies, it will instead send back a
> ServerHello message (and associated messages in that flight).  In this case, the
> client should gracefully tear down the dispreffered association to avoid
> lingering server state: it should send a user_canceled alert, followed by a
> close_notify alert.

user_cancelled alert is typically triggered when initiated by a user, close_notify alert is sufficient to inform the recipient that the sender will not send 
any more messages on this connection.

> 
> [This section should be verified by a DTLS expert.]
> 
> 3. For UDP, send TURN Allocate requests to both addresses, without
> authentication information.  If the TURN server is requiring authentication (as
> it normally will), it will send back 401 Unauthenticated responses.  This does
> not create server state, so the dispreferred allocation attempt can be silently
> discarded.

TURN server would have to remember the Nonce value !

> 
> If the TURN server is not requiring authentication (as, for example, a server
> which controls access via network topology, as described in Section 9 of draft-
> ietf-tram-turn-server-discovery), it is possible for both Allocate requests to
> succeed.  (Note that since the scenario this is describing is using plaintext UDP,
> this is a case that draft-ietf-tram-turn-server-discovery requires only be
> enabled by explicit administrator configuration.)  In this case, the dispreffered
> allocation should be explicitly torn down, by sending a Refresh with a LIFETIME
> value of 0.

Looks good.

-Tiru

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

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 17 Apr 2017 16:05:43 +0000

> On Apr 17, 2017, at 6:25 AM, Tirumaleswar Reddy (tireddy) <[email-masked]> wrote:
> 

Right — I was eliding that part, but my intention was that all the timing and policy would follow the recommendations in 6555.

> any more messages on this connection.

As I said, this section needs a DTLS expert.

Is there usually any server behavioral difference between the two alert types?

> TURN server would have to remember the Nonce value !

It shouldn’t — normally, Nonce values can be encoded in a way that’s stateless for the server (e.g., timestamp plus an HMAC), and this is usually considered good practice so as to avoid state-exhaustion attacks on the server.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 18 Apr 2017 02:08:57 +0000

> From: Jonathan Lennox [mailto:[email-masked]]
> Sent: Monday, April 17, 2017 9:36 PM
> To: Tirumaleswar Reddy (tireddy) <[email-masked]>
> Cc: [email-masked]
> Subject: Re: Happy Turnballs
> 
> 
> >> So I was asked to write up my comments on Happy Eyeballs for TURN.
> >> Here’re my thoughts.
> >>
> >> As always with Happy Eyeballs, when connecting to a TURN server
> >> specified by a DNS name, do a DNS query for both IPv6 and IPv4, and
> >> then (with appropriate timing based on expected success), attempt to
> >> connect to both the returned IPv6 and IPv4 addresses, in parallel.
> >
> > As per https://tools.ietf.org/html/rfc6555, by default IPv6 should have slight
> preference (or head-start) over IPv4 unless the client address preference
> policy is modified giving preference to IPv4 over IPv6.
> 
> Right — I was eliding that part, but my intention was that all the timing and
> policy would follow the recommendations in 6555.

Okay.

> 
> >> If the server is not using stateless cookies, it will instead send
> >> back a ServerHello message (and associated messages in that flight).
> >> In this case, the client should gracefully tear down the dispreffered
> >> association to avoid lingering server state: it should send a
> >> user_canceled alert, followed by a close_notify alert.
> >
> > user_cancelled alert is typically triggered when initiated by a user,
> > close_notify alert is sufficient to inform the recipient that the sender will not
> send any more messages on this connection.
> 

Yes, user_cancelled is a warning; close_notify needs to be exchanged (see https://tools.ietf.org/html/rfc6012#section-5.5) 

> >> authentication information.  If the TURN server is requiring
> >> authentication (as it normally will), it will send back 401
> >> Unauthenticated responses.  This does not create server state, so the
> >> dispreferred allocation attempt can be silently discarded.
> >
> It shouldn’t — normally, Nonce values can be encoded in a way that’s stateless
> for the server (e.g., timestamp plus an HMAC), and this is usually considered
> good practice so as to avoid state-exhaustion attacks on the server.

Got it, Thanks.

-Tiru