[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #23101 [Core Tor/Tor]: Predict and build specific HS purpose circuits (rather than GENERAL)
#23101: Predict and build specific HS purpose circuits (rather than GENERAL)
-------------------------------------------------+-------------------------
Reporter: mikeperry | Owner: (none)
Type: enhancement | Status: new
Priority: Medium | Milestone: Tor:
| 0.3.3.x-final
Component: Core Tor/Tor | Version:
Severity: Normal | Resolution:
Keywords: tor-hs, tor-guard, guard-discovery- | Actual Points:
prop247-controller |
Parent ID: #13837 | Points:
Reviewer: | Sponsor:
-------------------------------------------------+-------------------------
Comment (by mikeperry):
Replying to [comment:6 asn]:
> Replying to [comment:5 mikeperry]:
> > Asn - you are right to worry about trying to alter how we deal with
existing purposes, especially in a way that changes the HS state machine.
However, adding a whole new circuit purpose is quite easy. I have done it
several times before (including in my draft patch for parent ticket
#13837). I know how to do it without issue. Aside from a couple asserts
and checks here and there, new purposes get ignored by existing code.
That's what circuit purposes are for.
> >
> > How about this: instead of messing with the existing HS purpose state
machine(s), we create a new purpose (say CIRCUIT_PURPOSE_HS_GENERAL), and
then in circuit_predict_and_launch_new() we launch new circuits of that
type when we predict we need any hidden service circuits. Then we should
be able to make just a few changes to circuit_get_open_circ_or_launch(),
circuit_launch_by_extend_info(), and circuit_find_to_cannibalize() to use
this new circuit type for hidden service circuits (instead of using
CIRCUIT_PURPOSE_C_GENERAL for them).
> >
> > That way circuits with this new purpose will otherwise be ignored
unless we are looking to build a new one. And that mechanism for reusing
them will be very similar as it is today, just drawing from
CIRCUIT_PURPOSE_HS_GENERAL instead of CIRCUIT_PURPOSE_C_GENERAL, and we
also don't have to change our current rephist prediction code.
> >
> > Sound like a plan?
>
> Plausible plan. I'm still a bit concerned but I don't have a better plan
tbh.
>
> What would be the interaction between `CIRCUIT_PURPOSE_C_GENERAL` and
`CIRCUIT_PURPOSE_HS_GENERAL`? e.g. would you be able to cannibalize a
`C_GENERAL` circuit to an `HS_GENERAL` circuit if we find that we have
idle general circuits and we need HS ones (or the opposite)?
The desired behavior is that this should not be allowed. The idea is that
these two types of general circuits will have different path construction
mechanisms for the first three hops (vanguards/pinned middles vs normal),
and should not be mixed.
In terms of how this will be done - I am going to alter
circuit_find_to_cannibalize() so that you must also specify a circuit type
to cannibalize from in addition to the one you want to create, and you
can't switch between these classes of circuits (in the case where there is
nothing to cannibalize in this way, that function can find nothing and
return NULL, and the calling code in circuit_launch_by_extend_info() will
build a fresh circuit instead). Since circuit_find_to_cannibalize()
already behaves as if you specified canibalize_from ==
CIRCUIT_PURPOSE_C_GENERAL, I don't anticipate that the change to draw from
CIRCUIT_PURPOSE_HS_GENERAL will be very complicated.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/23101#comment:7>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs