<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Hi Nick,<div><br><div><div dir="ltr">On 3 Aug 2019, at 01:25, Nick Mathewson <<a href="mailto:nickm@torproject.org">nickm@torproject.org</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><span>On Tue, Jun 25, 2019 at 9:24 PM <<a href="mailto:neel@neelc.org">neel@neelc.org</a>> wrote:</span><br><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Hi tor-dev@ mailing list,</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I have a new proposal: A Tor Implementation of IPv6 Happy Eyeballs</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>This is to implement Tor IPv6 Happy Eyeballs and acts as an alternative</span><br></blockquote><blockquote type="cite"><span>to Prop299 as requested here:</span><br></blockquote><blockquote type="cite"><span><a href="https://trac.torproject.org/projects/tor/ticket/29801">https://trac.torproject.org/projects/tor/ticket/29801</a></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>The GitHub pull request is here:</span><br></blockquote><blockquote type="cite"><span><a href="https://github.com/torproject/torspec/pull/87">https://github.com/torproject/torspec/pull/87</a></span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Thank You,</span><br></blockquote><span></span><br><span>Hi, Neel! Thanks for working on this; I believe it's come a long way</span><br><span>in the last month!</span><br><span></span><br><span>Here are a few questions based on the current PR.</span><br><span></span><br><span>* We need to revise the "relay selection changes" to match the</span><br><span>vocabulary of guard-spec.txt. It's easy to say "select at least one</span><br><span>relay with an ipv6 address", but it's not trivial to do so in</span><br><span>practice.</span></div></blockquote><div><br></div><div>On the pull request, I suggested that we make sure that at least one</div><div>of the three primary guards has IPv6. (This change might also place</div><div>a similar IPv6 requirement on the larger sets of guards chosen by</div><div>clients. Is there a nice Venn diagram of all the guard sets?)</div><div><br></div><div>Here's one way we could implement an IPv6 guard requirement:</div><div><br></div><div>When choosing the last primary guard (or rotating any primary guard),</div><div>if there are no IPv6 primary guards, pass a new <span style="background-color: rgba(255, 255, 255, 0);">flag CRN_NEED_IPV6</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">to router_choose_random_node().</span></div><div><span class="n" style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span class="n" style="background-color: rgba(255, 255, 255, 0);">CRN_NEED_IPV6 can be implemented like </span><span style="background-color: rgba(255, 255, 255, 0);"><span class="n">CRN_PREF_ADDR, but with</span></span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><span class="n">a </span></span><span style="background-color: rgba(255, 255, 255, 0);">hard-coded preference for IPv6.</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><span class="n"><br></span></span></div><div><span class="n" style="background-color: rgba(255, 255, 255, 0);"><pre style="padding: 0px; margin-top: 0px; margin-bottom: 0px;"><span class="cm">/* On clients, only provide nodes that satisfy ClientPreferIPv6OR */</span>
<span class="n">CRN_PREF_ADDR</span> <span class="o">=</span> <span class="mi" style="font-weight: bold;">1</span><span class="o"><<</span><span class="mi" style="font-weight: bold;">7</span><span class="p">,</span></pre></span></div><div><br></div><div>(I cover the non-guard cases below.)</div><br><blockquote type="cite"><div dir="ltr"><span>(Also, do we do this always, or do we do this only when we</span><br><span>think we can connect to ipv6 addresses?)</span><br></div></blockquote><div><br></div><div>Happy eyeballs does not and should not require the client to guess IPv6</div><div>reachability. Tor can't reliably get that information, because the results of</div><div>OS network APIs may be unreliable, unavailable, or incorrect. (And past</div><div>connectivity is not a reliable guide to future connectivity, particularly on</div><div>mobile.)</div><div><br></div><div>If we want to try to guess, that's an optimisation, which belongs in the</div><div>"optional optimisations" section of the proposal.</div><br><blockquote type="cite"><div dir="ltr"><span>* We also need to think about what this algorithm means in terms of</span><br><span>guard-spec.txt's data structures. Does it mean that each connection</span><br><span>to a guard is replaced with two? Does it mean that some of the</span><br><span>reachability variables are replaced by two?</span><br></div></blockquote><div><br></div><div>I would prefer a new low-level network module that takes an IPv4 and</div><div>IPv6 address for each connection request, and reports success if</div><div>either address succeeds. And failure if both fail.</div><div><br></div><div>(Note that IPv4-only, dual-stack, and IPv6-only are all valid address</div><div>combinations. Relays, authorities, and fallbacks are IPv4 or dual stack,</div><div>bridge lines are currently IPv4-only or IPv6-only, and v3 single onion</div><div>service rendezvous direct connections can be all three.)</div><div><br></div><div>This design would have a minimal impact on existing guard data</div><div>structures and guard code.</div><div><br></div><div>I'd like to put any other guard changes in the "optional optimisations"</div><div>section of the proposal. Unless we are sure that they are essential.</div><br><blockquote type="cite"><div dir="ltr"><span>* The proposal considers TCP success vs authentication success as</span><br><span>indicating that a connection has succeeded. There is a good</span><br><span>alternative that reduces CPU load, however. The TLS handshake has</span><br><span>multiple phases, and the expensive CPU stuff all happens after we</span><br><span>receive a ServerHello message. If we treat an incoming ServerHello as</span><br><span>meaning that the connection will be successful, we can avoid most</span><br><span>wasted handshakes.</span><br></div></blockquote><div><br></div><div>Sounds sensible. Let's use the ServerHellos as the minimal viable product</div><div>for merging and release in an alpha. So this feature belongs in the</div><div>"minimal viable product" section of the proposal.</div><div><br></div><div>Initial feasibility testing can just use TCP connections though.</div><br><blockquote type="cite"><div dir="ltr"><span>[This would definitely not handle the problem where one of a server's</span><br><span>addresses is correct but the other address is a different server</span><br><span>entirely, but I hope we can catch that earlier in data flow, possibly</span><br><span>at the authorities.]</span><br></div></blockquote><div><br></div><div>Authority IPv4 or IPv6 reachability checks should catch this issue and</div><div>mark the relayMas not Running. (And therefore it won't be in the client's</div><div>consensus 2-4 hours after the bad address is in the descriptor or on the</div><div>machine.)</div><div><br></div><div>IPv4 reachability checks on relays should also catch most IPv4</div><div>misconfigurations.</div><div><br></div><div>We also have a funding proposal to do IPv6 reachability checks on relays,</div><div>which will catch IPv6 misconfigurations before relays upload their</div><div>descriptors.</div><br><blockquote type="cite"><div dir="ltr"><span>* The 1.5 second delay, and associated other hardcore times, should be</span><br><span>a network parameter, transmitted in the consensus. 1.5 seconds can be</span><br><span>the default, but we will want to keep the ability to tune it later on.</span><br></div></blockquote><div><br></div><div>David and I suggested this change on the pull request.</div><br><blockquote type="cite"><div dir="ltr"><span>* For pluggable transports, do we want to manage this process</span><br><span>ourselves, or delegate the decisions to the PT? Each option has its</span><br><span>own benefits and risks.</span><br></div></blockquote><br></div></div><div>I suggested on the proposal pull request that we make changing</div><div>bridge lines (including pluggable transports) out of scope for this</div><div>proposal.</div><div><br></div><div>Bridge and PT lines don't currently support multiple IP addresses,</div><div>and some transports (meek, snowflake) use a placeholder address,</div><div>and the transport doesn't tell tor the real address.</div><div><br></div><div>So they can use the new module API for consistency, but they will</div><div>only ever pass it an IPv4-only or IPv6-only bridge connect request.</div><div><br></div><div>Perhaps we need an "out of scope" section in the proposal.</div><div><br></div><div>T</div></body></html>