On 1/23/22 5:28 PM, s7r wrote:
Mike Perry wrote:
We need better DoS defenses generally :/
Of course we need better defense, DoS is never actually fixed, no matter what we do. It's just an arms race the way I see it.
Well, I am extremely optimistic about https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/327-pow...
Despite random internet hate on PoW, in the context of onion service DoS (which is our main cause of overall network DoS and actual overload), it looks very likely to be an effective option.
Prop325 describes how we can use PoW to build a system that auto-tunes itself such that only circuits with a sufficient level of PoW succeed. This means that we won't use PoW at all, unless it is needed (ie: only require the level of PoW needed to jump the queue of DoS requests, and advertise this level in the service descriptor).
In this way, an attack can be made considerably more expensive (and most importantly: less profitable) for an attacker, with the only effect that clients wait a bit longer to connect, to solve the PoW, and only while an attack is ongoing. If this system is effective enough, DoS-for-ransom attacks should vanish due to low profitability. And because the system auto-tunes, we should also no longer need PoW at all, after it is deployed, because of this deterrent effect. Win-win-win.
Jamie Harper did an implementation of this proposal: https://github.com/jmhrpr/tor-prop-327
David, asn, and I did a prelim code review of that branch, and while it needs more unit tests, and we need to reduce some of its external dependencies, it was of surprisingly high code quality. Unfortunately, Jamie graduated and moved on to other things.
But if we reduce the consensus weight or assume at network level that relay X should be used less because of a super tiny percent of dropped > circuits we could end up in wasting network resources on one side, and on the other side, maybe granting better probability chances for evil relays that we have not discovered yet to grab circuits. A consensus parameter is of course appropriate here, maybe 20% is a big threshold and should be less, but right now even 0.1% is reported and treated as overload, IMO this is not acceptable.
I generally agree here. For this, I filed: https://gitlab.torproject.org/tpo/core/tor/-/issues/40560
An important detail here is that ntor drops *are also* a form of that same kind of bias away from attacked relays, and toward evil relays.
If a relay is under such heavy DoS such that it is already dropping X% of ntors, it is *already* being forced to not carry X% of circuits. So, at minimum, it is reasonable to give it X% less traffic. However, this reduction must also be subject to the limits of not stripping the guard flag away just for overload/DoS, as I mentioned in my previous post.
At any rate, before we even consider using overload-general for relay weighting, we first need to transition the bwauths to use congestion control, and monitor how that system behaves wrt reducing overload, before we also try to add in overload-general. So it will be a while, and we will have time to thing about and analyze this stuff further.