[tram] Happy Turnballs

[Jonathan Lennox <[e-mail]>]

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.

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.

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.

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

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.


Comments welcome.