#33072: When under load, give 503 aggressively for dirport requests without compression ---------------------------------------+----------------------------------- Reporter: nickm | Owner: dgoulet Type: defect | Status: needs_review Priority: Medium | Milestone: Tor: | 0.4.3.x-final Component: Core Tor/Tor | Version: Severity: Normal | Resolution: Keywords: network-health 043-should | Actual Points: Parent ID: #33018 | Points: Reviewer: nickm, teor, armadev | Sponsor: ---------------------------------------+-----------------------------------
Comment (by arma): Thought 1: ORPort begindir requests from clients ask for compression, right? So this patch is a substantive and useful change, because it will resume answering real Tor clients who are trying to bootstrap from directory authorities, in a way that the #33029 patch broke (because all the dir auths running the #33029 patch are now returning 503 to nearly every consensus fetch attempt from non-relays, including ORPort-based begindir requests). Thought 1b: Other effective ways to make us resume answering clients, but still survive the current flood, include "always answer microdesc-flavored requests" or "always answer ORPort-based requests". I think just favoring microdesc-flavored requests would not be enough to reenable the fetches from torflows though, because torflows set UseMicrodescriptors to 0. And "always answer ORPort-based requests" would not be enough to reenable the fetches for relays that haven't yet ~~gotten into the consensus~~published their relay descriptor, because they would be fetching via the DirPort because they think they're a relay, yet the dir auths do not yet think they are a relay. A third edge case is DocTor and DepicTor (aka consensus- health), because right now with the defenses in place they're failing to fetch dir info from the authorities (#33067). But consensus-health is doing its fetches wrong in all three ways -- it is fetching the vanilla consensus, uncompressed, from the dirport -- so it is going to have to change here no matter what. In sum: looking at whether compression is requested is the best choice of these three. Thought 2: This commit looks fine to me, and it's a good start, but for me it is not enough. Right now all it does is always answer compressed requests, which will implicitly drive bandwidth use toward compressed requests, because this strategy will leave less bandwidth available for uncompressed requests. So it does not accomplish the "aggressively" part. With just this patch, moria1 will still max out its bandwidth use for whatever bandwidthrate I pick. So I will be forced to pick something tiny like 10MBytes/s because I know that whatever I pick, I will use that amount 24/7. And that situation will make the network more brittle, because moria1 won't be able to burst to handle larger directory loads if some other anomaly appears that requires dir auth responses to be able to scale suddenly. So what I want in addition to the above is some way to say 503 to these unwanted requests even if I'm not at the edge of my bandwidth rate this very moment. I would be ok with a config option to just send 503 to uncompressed requests, and be done with it. In that case we are simply declaring that uncompressed requests are no longer supported by dir auths. Or I would also be ok with a config option that specifies what level of bandwidth to give to these requests, i.e., a bucket water level below which we send a 503, even if there are otherwise quite a few tokens in my bucket. That approach is a bit more complicated to build, but it would preserve the illusion that we're still willing to answer uncompressed requests. And it would more seamlessly handle the situation where the current ddos slowly fades away and/or returns later. Thought 2b: We might worry that flat-out denying uncompressed requests will force this current ddoser to change, and we'll end up finding it harder to distinguish their requests and discard them. But I think with #33029 plus dgoulet's patch here, we'll already be denying the great majority of the uncompressed requests. With the "bucket water level" design I just described, we'll reject more but it won't be a substantive difference. Or said another way, if we're worried that the ddoser will change their approach, we should worry about that even if we just do #33029 plus dgoulet's patch, because we will definitely be making their directory fetches very unreliable. So if we're committed to that risk (which I think we have to be, unless we can think of something smarter), we might as well maximize the good side of the tradeoff, and defend ourselves, and our bandwidth use, better. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/33072#comment:4> 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