[tor-dev] New Proposal 306: A Tor Implementation of IPv6 Happy Eyeballs

[teor]

Hi Neel,

> On 27 Jun 2019, at 11:10, neel at neelc.org wrote:
> 
> Thank you so much for your feedback. I have pushed your changes (and revert my changes to 000-index.txt) as fixup commits to the GitHub PR.
> 
> Could you please review the new changes?

I'm going to wait a week or two for other people to provide feedback on this thread.

T

>> On 2019-06-25 23:33, teor wrote:
>> Hi Neel,
>> Thanks for this proposal.
>>> On 26 Jun 2019, at 11:15, neel at 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
>> Supercedes: 299
>>> 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:
>> https://metrics.torproject.org/onionperf-buildtimes.html
>> 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
>> authentication.
>> https://tools.ietf.org/html/rfc8305#section-8
>> (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
>>  and time out
>> * 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,
>>  but they are rare
>> 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
>>   address.
>>   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
>>   other connection.
>> 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