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

[teor]

Hi Nick,

> On 3 Aug 2019, at 01:25, Nick Mathewson <nickm at torproject.org> wrote:
> 
>> On Tue, Jun 25, 2019 at 9:24 PM <neel at neelc.org> wrote:
>> 
>> Hi tor-dev@ mailing list,
>> 
>> 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
>> 
>> Thank You,
> 
> Hi, Neel!  Thanks for working on this; I believe it's come a long way
> in the last month!
> 
> Here are a few questions based on the current PR.
> 
> * We need to revise the "relay selection changes" to match the
> vocabulary of guard-spec.txt.  It's easy to say "select at least one
> relay with an ipv6 address", but it's not trivial to do so in
> practice.

On the pull request, I suggested that we make sure that at least one
of the three primary guards has IPv6. (This change might also place
a similar IPv6 requirement on the larger sets of guards chosen by
clients. Is there a nice Venn diagram of all the guard sets?)

Here's one way we could implement an IPv6 guard requirement:

When choosing the last primary guard (or rotating any primary guard),
if there are no IPv6 primary guards, pass a new flag CRN_NEED_IPV6
to router_choose_random_node().

CRN_NEED_IPV6 can be implemented like CRN_PREF_ADDR, but with
a hard-coded preference for IPv6.

/* On clients, only provide nodes that satisfy ClientPreferIPv6OR */
  CRN_PREF_ADDR = 1<<7,

(I cover the non-guard cases below.)

> (Also, do we do this always, or do we do this only when we
> think we can connect to ipv6 addresses?)

Happy eyeballs does not and should not require the client to guess IPv6
reachability. Tor can't reliably get that information, because the results of
OS network APIs may be unreliable, unavailable, or incorrect. (And past
connectivity is not a reliable guide to future connectivity, particularly on
mobile.)

If we want to try to guess, that's an optimisation, which belongs in the
"optional optimisations" section of the proposal.

> * We also need to think about what this algorithm means in terms of
> guard-spec.txt's data structures.  Does it mean that each connection
> to a guard is replaced with two?  Does it mean that some of the
> reachability variables are replaced by two?

I would prefer a new low-level network module that takes an IPv4 and
IPv6 address for each connection request, and reports success if
either address succeeds. And failure if both fail.

(Note that IPv4-only, dual-stack, and IPv6-only are all valid address
combinations. Relays, authorities, and fallbacks are IPv4 or dual stack,
bridge lines are currently IPv4-only or IPv6-only, and v3 single onion
service rendezvous direct connections can be all three.)

This design would have a minimal impact on existing guard data
structures and guard code.

I'd like to put any other guard changes in the "optional optimisations"
section of the proposal. Unless we are sure that they are essential.

> * The proposal considers TCP success vs authentication success as
> indicating that a connection has succeeded. There is a good
> alternative that reduces CPU load, however.  The TLS handshake has
> multiple phases, and the expensive CPU stuff all happens after we
> receive a ServerHello message.  If we treat an incoming ServerHello as
> meaning that the connection will be successful, we can avoid most
> wasted handshakes.

Sounds sensible. Let's use the ServerHellos as the minimal viable product
for merging and release in an alpha. So this feature belongs in the
"minimal viable product" section of the proposal.

Initial feasibility testing can just use TCP connections though.

> [This would definitely not handle the problem where one of a server's
> addresses is correct but the other address is a different server
> entirely, but I hope we can catch that earlier in data flow, possibly
> at the authorities.]

Authority IPv4 or IPv6 reachability checks should catch this issue and
mark the relayMas not Running. (And therefore it won't be in the client's
consensus 2-4 hours after the bad address is in the descriptor or on the
machine.)

IPv4 reachability checks on relays should also catch most IPv4
misconfigurations.

We also have a funding proposal to do IPv6 reachability checks on relays,
which will catch IPv6 misconfigurations before relays upload their
descriptors.

> * The 1.5 second delay, and associated other hardcore times, should be
> a network parameter, transmitted in the consensus.  1.5 seconds can be
> the default, but we will want to keep the ability to tune it later on.

David and I suggested this change on the pull request.

> * For pluggable transports, do we want to manage this process
> ourselves, or delegate the decisions to the PT?  Each option has its
> own benefits and risks.

I suggested on the proposal pull request that we make changing
bridge lines (including pluggable transports) out of scope for this
proposal.

Bridge and PT lines don't currently support multiple IP addresses,
and some transports (meek, snowflake) use a placeholder address,
and the transport doesn't tell tor the real address.

So they can use the new module API for consistency, but they will
only ever pass it an IPv4-only or IPv6-only bridge connect request.

Perhaps we need an "out of scope" section in the proposal.

T
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20190805/95fe4f2d/attachment.html>