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@xxxxxxxxxxxxxx> a écrit :
>
> 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
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev