[tor-bugs] #9321 [Tor]: Load balance right when we have higher guard rotation periods

[Tor Bug Tracker & Wiki]

#9321: Load balance right when we have higher guard rotation periods
-------------------------+-------------------------------------------------
     Reporter:  arma     |      Owner:
         Type:  project  |     Status:  new
     Priority:  normal   |  Milestone:  Tor: 0.2.6.x-final
    Component:  Tor      |    Version:
   Resolution:           |   Keywords:  needs-proposal, tor-auth, tor-
Actual Points:           |  client, 026-triaged-1
       Points:           |  Parent ID:  #11480
-------------------------+-------------------------------------------------

Comment (by asn):

 I've done a bit of progress on this. I have a stupid Python script
 that you can point to a directory with consensus documents. It will
 parse them all (using stem), and for each guard it will spit out the
 number of consensuses it was mentioned in, as well as when was the
 earliest and the latest consensus it was in.

 The idea is that this script will have to be finished, and then
 somehow executed in the authorities. The script will spit out an
 output file that can be parsed by little-t-tor in the same fashion as
 the bandwidth authorities do (see measured_bw_line_parse()).

 Few questions that will need to be answered:

 - Will the script be called periodically and the authorities will have
   to parse the output file every once in a while? Or will the script
   be ran once, and then it's the job of the authorities to internally
   update their state with new information?

   I'm currently aiming for the former behavior, to minimize the amount
   of code that needs to be written for little-t-tor. OTOH, this means
   that authorities will need to keep 9 months worth of consensuses in
   their filesystem. As we move closer to completion of this task we
   will see if the former behavior is indeed better.

 - Where will the consensuses be fetched from? To run this script we
   need to have a directory filled with consensuses. How are we going
   to get those documents? rsync cronjob from metrics? Does this scale?
   What else can we do?

 - What should we do about consensus signatures? If we are fetching
   consensuses from metrics, it's reasonable that we don't want to
   trust them blindly. It would be nice if the script (or the auth)
   could validate the consensus signatures, but it's not an easy task:

   How will the script get the public keys of the auths? What if the
   auths set change? What if (as part of an attack) we are given a
   consensus with only one or two auth signatures? Should it be
   accepted even though it's signed by a minority of auths? Should our
   stupid script understand all these consesus security details?

 - What should happen if we are missing a few consensuses? Sometimes
   the auths fail to establish a consensus, so it's reasonable that a
   few consesuses will be missing if we look 9 months back. Should our
   Python script recognize their absense? What if half of the
   consesuses are missing? What if just one is missing? How should our
   script react?

 - We need to think how the guardiness information will be passed to
   clients (since clients need to change their path selection procedure
   according to the guardiness). Proposal 236 simply says:
   {{{
    The authorities include the age of each guard by appending
    '[SP "GV=" INT]' in the guard's "w" line.
   }}}
   But I don't think that's enough. What is an age anyway?

   Should we pass to clients information like "Node was a guard for
   3031/6574 consensuses during the past 9 months"? Should this be
   passed in the consensus as part of the 'w' line or something?

 - How should this be deployed?

   In the beginning it should parse 2-3 months worth of consesuses (the
   current guard lifetime period), and then as more clients upgrade we
   should make it parse 9-10 months (or whatever we decide) worth of
   consesuses?

 I'm planning to tackle these questions soon. Any feedback is helpful!

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9321#comment:13>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online