[tor-bugs] #13989 [Tor]: Freak out if we pick too many new guards in too short a time

Tor Bug Tracker & Wiki blackhole at torproject.org
Fri Jan 16 11:03:04 UTC 2015


#13989: Freak out if we pick too many new guards in too short a time
------------------------+--------------------------------
     Reporter:  nickm   |      Owner:
         Type:  defect  |     Status:  new
     Priority:  normal  |  Milestone:  Tor: 0.2.6.x-final
    Component:  Tor     |    Version:
   Resolution:          |   Keywords:  tor-client guards
Actual Points:          |  Parent ID:
       Points:          |
------------------------+--------------------------------

Comment (by asn):

 Some thoughts:

 a) The sniper paper indeed has a table with some "too many new guards"
 thresholds. We should use it.
 However, at the same time, that table was generated by reading past
 consensuses and simulations, not by running Tor.

 Two days ago, I haxed my Tor and changed all the logs in
 `entry_guard_register_connect_status()` to `log_warn()` to see how often
 we use new guards. Over the past two days, and with `NumEntryGuards` being
 1, I have used four guards: The first was my primary guard, then there are
 two extras because of #12450 when booting my laptop without network, and
 another guard that I'm not sure why it was used.

 I also think that this feature should only be enabled if `NumEntryGuards`
 is 1. Since if the client is using more than 1 guard, the guard data
 structures are much more fragile (allowing bugs like #12466).

 b) To make sure that our flaky guard data structures won't bite us here, I
 suggest we make a branch that just logs how many guards have been used
 over a day/week/month, and let testers run it for a while. I imagine that
 different use cases will see different amount of guards. For example, if
 someone switches on/off his network a lot during travelling, he should see
 many more guards used than someone using Tor on their desktop with a
 stable network connection.

 Till then, maybe you want to check your state file and see which guards
 you are currently using? Are you using your top ones, or are they marked
 as `EntryGuardDownSince`?

 c) The thresholds to "freak out" should probably be consensus parameters?
 So that we can tweak them according to the current guard settings. And
 they should also be torrc parameters. We should probably have a torrc
 option on how much to freak out; that is, whether to stop creating
 circuits, or just to issue a warning.

 d) We probably want to do `guards_used_n++` right after we successfully
 connect to a guard, somewhere around
 `entry_guard_register_connect_status()`. We probably don't want to wait
 after the whole circuit is completed, otherwise the other hops can fail
 the circuit and we would blame the guard.

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


More information about the tor-bugs mailing list