[tor-bugs] #23101 [Core Tor/Tor]: Predict and build specific HS purpose circuits (rather than GENERAL)

[Tor Bug Tracker & Wiki]

#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