[tor-bugs] #25347 [Core Tor/Tor]: Tor stops building circuits, and doesn't start when it has enough directory information

[Tor Bug Tracker & Wiki]

#25347: Tor stops building circuits, and doesn't start when it has enough directory
information
-------------------------------------------------+-------------------------
 Reporter:  teor                                 |          Owner:  asn
     Type:  defect                               |         Status:
                                                 |  assigned
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.3.3.x-final
Component:  Core Tor/Tor                         |        Version:  Tor:
                                                 |  0.3.0.6
 Severity:  Normal                               |     Resolution:
 Keywords:  031-backport, 032-backport,          |  Actual Points:
  033-must, tor-guard, tor-client, tbb-          |
  usability-website, tbb-needs,                  |
  033-triage-20180320, 033-included-20180320     |
Parent ID:  #21969                               |         Points:  1
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by asn):

 Some more info after discussing with Nick:

 Replying to [comment:10 asn]:
 > Like you said, I think the most obvious misbehavior here is that you
 keep on hassling your guard even tho it's telling you to relax by sending
 your `RESOURCELIMIT` `DESTROY` cells. Perhaps one approach here would be
 to choose a different guard after a guard has sent us `RESOURCELIMIT`
 cells, in an attempt to unclog the guard and to get better service.
 '''Let's think about this some more:'''
 >
 > What's the best behavior here? Should we mark the guard as down after
 receiving a single `RESOURCELIMIT` cell, or should we hassle the guard a
 bit before giving up?
 >

 Some reasons to go with the former approach here is:
 a) The way primary guards work, even if we ditch the guard for a single
 `RESOURCELIMIT` cell, we are gonna retry it again after a few minutes.
 Also, after a few minutes there are higher chances that the guard is gonna
 be unclogged since we stopped hassling it.
 b) It will be easier to implement.

 > Most importantly, can we make sure that the `DESTROY` cell came from the
 guard and not from some other node in the path? If we can make sure that
 the `DESTROY` cell came from the guard, this seem to me like a pretty safe
 countermeasure since we should trust the guard to tell us whether it's
 overworked or not.
 >

 Nick says that if we get a `DESTROY` cell before we receive a `CREATED`
 cell (or maybe before we send an `EXTEND` cell) we can be sure it comes
 from the guard since there is no one else on the path. I wonder if this is
 easy to figure out in code.

 Nick also suggested we get feedback from Mike first since he will have
 good ideas on whether this can be bad for anonymity.

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