On Tue, Jun 25, 2019 at 9:24 PM neel@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. (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,