[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #12598 [Tor]: Increase rotation period of guard nodes

#12598: Increase rotation period of guard nodes
-----------------------+-----------------------------------------------
     Reporter:  asn    |      Owner:  asn
         Type:  task   |     Status:  assigned
     Priority:  major  |  Milestone:  Tor: 0.2.6.x-final
    Component:  Tor    |    Version:
   Resolution:         |   Keywords:  tor-guard, 026-triaged-1 unfrozen
Actual Points:         |  Parent ID:  #11480
       Points:         |
-----------------------+-----------------------------------------------

Comment (by asn):

 OK, here is a rough deployment plan:
 1. We merge #9321 to little-t-tor. This allows dirauths to publish
 consensuses with guardfraction info, and it also allows clients to
 understand them and tweak their path selection appropriately.

 2. We deploy guardfraction script to all the authorities we can find. We
 give them some time to populate their consensus database, etc.

 3. We get authorities to run a version of Tor with the #9321 code. They
 enable the feature so that consensuses get produced with GuardFraction
 items. Old clients ignore those items, upgraded clients ignore them too
 because the `UseGuardFraction` is still turned off.

 4. Now we Tor developers can test the guardfraction code on the real
 network. We can manually turn on `UseGuardFraction` in our torrc, and
 check the logs to see if the new probabilities make sense. After this
 phase we should have a reasonable assurance that the code works.

 5. Now it's time to turn the feature on for all upgraded clients. We can
 do this with 3 months of guard lifetime, or we can first up the guard
 lifetime to 9 months. It's useful in both cases.

 We should decide whether we should do this final step when the #9321 code
 is in stable or in alpha. I think that alpha is fine, but this means that
 not all clients will switch to the new path selection logic immediately.
 This is not optimal because
 [https://gitweb.torproject.org/torspec.git/tree/proposals/236-single-
 guard-node.txt#n136 proposal 238 also updates the total bandwidth weights]
 (`G, M, E, D`) according to guardfraction information, which basically
 assumes that all clients upgrade at the same time. In our case, this is
 probably not going to be true, which means that the `Middle` weight and
 the `Exit` weight will get overestimated, since they are going to drain
 some of the `Guard+Middle` weight and the `Guard+Exit` weight. From my
 discussion with Nick Hopper during the past dev meeting, we decided that
 the network should be able to handle this, and the situation will improve
 as more clients update. We maybe should think more about this.

 Finally, I'm not sure if we need an alternative name for `GuardLifetime`
 so that only upgraded clients switch to the new rotation period. I don't
 think this is necessary since it's OK also for old clients to switch to
 the new rotation period, ''as long as there are enough upgraded clients
 out there'' doing the guardfraction path selection so that they fill the
 ''guard traffic gap''.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/12598#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