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

[Nick Mathewson <nickm@xxxxxxxxxxxxxx>]

On Tue, Jun 25, 2019 at 9:24 PM <neel@xxxxxxxxx> 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.  (Also, do we do this always, or do we do this only when we
think we can connect to ipv6 addresses?)

* 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?

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

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

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

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

cheers,
-- 
Nick
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev