Hi Neel, Thanks for this proposal. On 26 Jun 2019, at 11:15, neel@xxxxxxxxx wrote:
Here's the proposal content, with my comments: Supercedes: 299
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.
Tor's code already does this check: we won't need to change it.
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.
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 authentication. (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.
T |
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev