[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:
                                                 |  mikeperry
     Type:  enhancement                          |         Status:
                                                 |  assigned
 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 asn):

 Replying to [comment:7 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.
 >

 Interesting and indeed makes sense for the cases where vanguard-ish
 designs are enabled (e.g. hidden services in the beginning, and maybe even
 HS clients in the future).

 I think we are reaching the point where the cannibalization logic requires
 a small spec of its own to document this stuff (+ various other
 intricacies).

 Another behavior worth documenting: I wonder how the predictive circuit
 launching should work after this change. Should clients create predictive
 general circuits and also create predictive HS circuits? What about HSes?

 > 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:9>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online