Re: [tor-dev] Optimistic SOCKS Data

[Tom Ritter <tom@xxxxxxxxx>]

On Thu, 10 Oct 2019 at 10:37, George Kadianakis <desnacked@xxxxxxxxxx> wrote:
> So are you suggesting that we can still do SOCKS error codes? But as
> David said, some of the errors we care about are after the descriptor
> fetch, so how would we do those?

Only 'X'F3' Onion Service Rendezvous Failed' - right?

I think David is proposing we just don't do that one because in his
experience it's pretty rare.

> Also, please help me understand the race condition you refer to. I tried
> to draw this in a diagram form:
>       https://gist.github.com/asn-d6/55fbe7a3d746dc7e00da25d3ce90268a

I edited this:
https://gist.github.com/tomrittervg/e0552ed007dbe50077528936b09a2eff

Whose first diagram (normal situation) is correct?  Something looks
off in yours... You obviously know tor much better; but latency gain
for optimistic socks doesn't come from sending the HTTP GET to tor
sooner, it comes from sending it to the destination sooner - so I
think that the GET must travel to the destination before the
destination replies with CONNECTED, doesn't it?

Anyway, I tried to illustrate Matts race condition as I understand it;
but I am entirely unconcerned with it. There's no way it's going to
take the browser more time to generate a HTTP GET and send it over
SOCKS than it's going to take tor to roundtrip a rendezvous setup.

> IIUC, for onions the advantage of opportunistic SOCKS is that we would
> send DATA to the service right after finishing rendezvous, whereas right
> now we need to do a round-trip with Tor Browser after finishing
> rendezvous. Is that right?
>
> If that's the case, then sending the SOCKS reply after the rendezvous
> circuit is completed would be the same as the current behavior, and
> hence not an optimization, right?

Correct.

> And sending the SOCKS reply after the introduction is completed (as
> David is suggesting) would be an optimization indeed, but we lose
> errors (we lose the rendezvous failed error, which can occur if the
> onion service is under DoS and cannot build new circuits but can still
> receive introductions).

Yup.

> What other problems exist here?

I'll have to think about it more at a time I'm better equipped to.

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