Hi Neel,

Thanks for this proposal.

On 26 Jun 2019, at 11:15, neel@neelc.org wrote:

I have a new proposal: A Tor Implementation of IPv6 Happy Eyeballs

This is to implement Tor IPv6 Happy Eyeballs and acts as an alternative to Prop299 as requested here: https://trac.torproject.org/projects/tor/ticket/29801

The GitHub pull request is here: https://github.com/torproject/torspec/pull/87

Here's the proposal content, with my comments:

Filename: 306-ipv6-happy-eyeballs.txt

Title: A Tor Implementation of IPv6 Happy Eyeballs

Author: Neel Chauhan

Created: 25-Jun-2019

Status: Open

Ticket: https://trac.torproject.org/projects/tor/ticket/29801

1. Introduction

As IPv4 address space becomes scarce, ISPs and organizations will deploy

IPv6 in their networks. Right now, Tor clients connect to guards using

IPv4 connectivity by default.

When networks first transition to IPv6, both IPv4 and IPv6 will be enabled

on most networks in a so-called "dual-stack" configuration. This is to not

break existing IPv4-only applications while enabling IPv6 connectivity.

However, IPv6 connectivity may be unreliable and clients should be able

to connect to the guard using the most reliable technology, whether IPv4

or IPv6.

In ticket #27490, we introduced the option ClientAutoIPv6ORPort which

lets a client randomly choose between IPv4 or IPv6. However, this

random decision does not take into account unreliable connectivity

or falling back to the competing IP version should one be unreliable

or unavailable.

One way to select between IPv4 and IPv6 on a dual-stack network is a

so-called "Happy Eyeballs" algorithm as per RFC 8305. In one, a client

attempts an IP family, whether IPv4 or IPv6. Should it work, the client

sticks with the working IP family. Otherwise, the client attempts the

opposing version. This means if a dual-stack client has both IPv4 and

IPv6, and IPv6 is unreliable, the client uses IPv4, and vice versa.

In Proposal 299, we have attempted a IP fallback mechanism using failure

counters and preferring IPv4 and IPv6 based on the state of the counters.

However, Prop299 was not standard Happy Eyeballs and an alternative,

standards-compliant proposal was requested in [P299-TRAC] to avoid issues

from complexity caused by randomness.

This proposal describes a Tor implementation of Happy Eyeballs and is

intended as a successor to Proposal 299.

2. Address Selection

To be able to handle Happy Eyeballs in Tor, we will need to modify the

data structures used for connections to guards, namely the extend info

structure.

The extend info structure should contain both an IPv4 and an IPv6 address.

This will allow us to try IPv4 and the IPv6 addresses should both be

available on a relay and the client is dual-stack.

When parsing relay descriptors and filling in the extend info data

structure, we need to fill in both the IPv4 and IPv6 address if they both

are available. If only one family is available for a relay (IPv4 or IPv6),

we should fill in the address for available family and leave the opposing

family null.

When we implement this feature in tor, it would be a good idea to call the

two addresses "preferred" and "alternate" address. With this design,

the low-level connection code doesn't have to know about reachable

addresses, or IPv4/IPv6 preferences. It just has to try them in order.

3. Connecting To A Relay

When a client connects to a guard using an extend info data structure, we

should first check if there is an existing authenticated connection. If

there is, we should use it.

Tor's code already does this check: we won't need to change it.

If there is no existing authenticated connection for an extend info, we

should attempt to connect using the first available, allowed, and preferred

address. At the time of writing, this is IPv4.

That's not quite true: most clients use IPv4 by default, but they can be

configured to prefer IPv6, or only allow certain addresses. And bridge clients

automatically use IPv6 if they are configured with an IPv6 bridge.

We should also schedule a timer for connecting using the other address

should one be available and allowed, and the first attempted version

fails. This should be higher than most client's successful TLS

authentication time. I propose that the timer is 15 seconds. The reason

for this is to accommodate high-latency connections such as dial-up and

satellite.

In the worst case scenario, users see Tor Browser hang for 15 seconds

before it makes a successful connection. That's not acceptable.

Depending on their location, most tor clients authenticate to the first

hop within 0.5-1.5 seconds. So I suggest we use a 1.5 second delay:

In RFC 8305, the default delay is 250 milliseconds, and the maximum

delay is 2 seconds. So 1.5 seconds is reasonable for TLS and tor link

(This delay will mainly affect initial bootstrap, because all of Tor's

other connections are pre-emptive, or re-used.)

A small number of clients may do wasted authentication.

That's ok. Tor already does multiple bootstrap and guard connections.

We have talked about this design in the team over the last few months.

Our key insights are that:

* TCP connections are cheap, but TLS is expensive

* most failed TCP connections fail immediately in the kernel, some

fail quickly with a response from the router, and others are blackholed

* it's unlikely that a client will fail to authenticate to a relay over one

IP version, but succeed over the other IP version, because the directory

authorities authenticate to each relay when they check reachability

* some censorship systems only break authentication over IPv4,

So here are some alternative designs:

1. Tor connects to the preferred address and tries to authenticate.

On failure, or after a 1.5 second delay, it connects to the alternate address

and tries to authenticate.

On the first successful authentication, it closes the other connection.

This design places the least connection load on the network, but might add

a bit of extra TLS load.

2. Tor connects via TCP to the preferred address.

On failure, or after a 250 ms delay, it connects via TCP to the alternate

On the first TCP success, tor attempts to authenticate immediately.

On authentication failure, or after a 1.5 s delay, tor attempts to

authenticate over the second TCP connection.

On the first successful authentication, it closes the other connection.

This design is the most reliable for clients, but it also puts a bit more

connection load on dual-stack guards and authorities.

3. Tor connects via TCP to the preferred address.

On failure, or after a 250ms delay, it connects via TCP to the alternate

address.

On the first TCP success, tor attempts to authenticate, and closes the

This design looks similar to a web browser's implementation of Happy

Eyeballs, because it closely follows the RFC. That might help hide tor

from censors. It adds some extra connection load, but no extra TLS load.

I suggest that we put all 3 alternative designs in the proposal, but start

by implementing and testing alternative 1.

When we implement this code, let's put the happy eyeballs part in a

separate module, as much as possible. That helps us review the code,

and make sure it has good test coverage. It also stops existing files and

functions getting too big.

4. Handling Connection Successes And Failures

Should a connection to a guard succeed and is authenticated via TLS, we

can then use the connection. In this case, we should cancel all other

connection timers and in-progress connections. Cancelling the timers is

so we don't attempt new unnecessary connections when our existing

connection is successful, preventing denial-of-service risks.

However, if we fail all available and allowed connections, we should tell

the rest of Tor that the connection has failed. This is so we can attempt

another guard relay.

5. Acknowledgments

Thank you so much to teor for the discussion of the happy eyeballs proposal.

I wouldn't have been able to do this has it not been for your help.

6. Appendix

[P299-TRAC]: https://trac.torproject.org/projects/tor/ticket/29801