Re: [tram] Happy Turnballs

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

> -----Original Message-----
> From: Jonathan Lennox [mailto:[e-mail]]
> Sent: Monday, April 17, 2017 9:36 PM
> To: Tirumaleswar Reddy (tireddy) <[e-mail]>
> Cc: [e-mail]
> Subject: Re: Happy Turnballs
> 
> 
> > On Apr 17, 2017, at 6:25 AM, Tirumaleswar Reddy (tireddy)
> <[e-mail]> wrote:
> >
> >> -----Original Message-----
> >> From: tram [mailto:[e-mail]] On Behalf Of Jonathan
> >> Lennox
> >> Sent: Wednesday, March 29, 2017 9:34 AM
> >> To: [e-mail]
> >> 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.
> 
> 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.
> 
> As I said, this section needs a DTLS expert.
> 
> Is there usually any server behavioral difference between the two alert types?

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

> 
> >> 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 !
> 
> 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