Re: [tram] Happy Turnballs

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

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

> 
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tram