[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:
                                                 |  needs_revision
 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):

 Replying to some of the high-level comments of arma:

 Replying to [comment:18 arma]:
 > (F) Are you sure that the proposed branch is related to the topic of
 this ticket? The ticket title and body seem quite different from what the
 branch does. That makes me wonder if maybe we're not actually solving the
 original bug report. :)
 >

 This patch is meant to address the second paragraph of the ticket body,
 and also is meant to directly fix the issue that s7r (and others)
 encountered in #21969. My understanding is that this is the main guard
 issue right now, and not the fact that clients can run out of md retries.
 Do you think this is true, teor?

 > (B) Note that in the ddos mitigation stuff, we refuse circuits from
 overloaders with reason resource-limit (see DOS_CC_DEFENSE_REFUSE_CELL).
 And at least at the time, the goal was to soak up their overload circuits
 at the guard level, i.e. keep them occupied at a point where we're able to
 limit the damage they do. If we implement this ticket, overloader clients
 will immediately skip off to hassle some other guard. Maybe that's ok? Or
 maybe it would be a sad side effect? Maybe we should change the ddos
 mitigation to use some other destroy reason, so we don't trigger
 overloaders to move? I'm not sure what's best, but let's intentionally
 choose something.

 I think this is an important design-level issue here. I was actually not
 aware that the intention of the DoS subsystem is to soak up the overloader
 on a single guard, and if that's the case this patch works completely
 against it and we should NACK it. However, if that's the case, I'm not
 sure what we should do about the users who encounter this reachability
 issue, where they are behind an overloaded guard and they can't use it or
 escape it. Seems like a tradeoff between the overloader completely
 disabling a single guard and its users, or the overloader spreading the
 load across the network and potentially harming multiple relays before
 they kick the overloader to the next one. And of course, all that's
 assuming an accidental overloader who follows the Tor protocol, because if
 they hack their tor client to be intentionally evil they can do whatever
 they want.

 Not sure how to proceed here. Any ideas?

 > (G) Do we have a handle on how often existing guards respond with reason
 resource-limit? Imagine a Tor client that makes a bunch of circuits often,
 say because it's an active onion service. And let's say on average 5% of
 create cells get a resource-limit response. And let's say we wait 30
 minutes before retrying a guard that we marked as down. We're going to
 churn through a *lot* of guards this way, right?

 That's another design-level issue we should think about. We should make
 sure this does not allow an attacker to simply cause an HS to cycle guards
 for ever, by overloading its current guards. Not sure if we can properly
 do this research in the 033 timeframe tho...

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