#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
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs