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

[Hajar El]

Hi i am a new partner in tor-dev can you help me te understand the stuffs
here
Le 2 août 2019 16:25, "Nick Mathewson" <nickm at torproject.org> a écrit :
>
> 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.  (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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20190802/6deaf5dd/attachment.html>