[tor-dev] Onion Service - Intropoint DoS Defenses

[juanjo]

Nice to try to stop this DoS vulnerability at network design level.

Can we have an estimation of when will be released this antiDoS 
features? 0.4.1.x or 0.4.2.x ?

And just came to my mind reading this, that to stop these attacks we 
could implement some authentication based on Proof of Work or something 
like that. This means that to launch such an attack the attacker (client 
level) should compute the PoW and must have many computing power, while 
normal clients/users don't need almost any change. Actually this is what 
PoW is very useful.

On 30/5/19 15:49, David Goulet wrote:
> Greetings!
>
> As some of you know, a bunch of onion services were or are still under heavy
> DDoS on the network. More specifically, they are bombarded with introduction
> requests (INTRODUCE2 cells) which forces them to rendezvous for each of them
> by creating a ton of circuits.
>
> This basically leads to a resource exhaustion attack on the service side with
> its CPU massively used for path selection, opening new circuits and
> continously handling INTRODUCE2 cells.
>
> Unfortunately, our circuit-level flow control does not apply to the service
> introduction circuit which means that the intro point is allowed, by the Tor
> protocol, to send an arbitrary large amount of cells down the circuit. This
> means for the service that even after the DoS has stopped, it would still
> receive massive amounts of cells because some are either inflight on the
> circuit or queued at the intro point ready to be sent (towards the service).
>
> That being all said, our short-term goal here is to add INTRODUCE2
> rate-limiting (similar to the Guard DoS subsystem deployed early last year)
> *at* the intro point but much simpler. The goal is to soak up the introduction
> load directly at the intro points which would help reduce the load on the
> network overall and thus preserve its health.
>
> Please have a look at https://trac.torproject.org/15516 for some discussions
> and ongoing code work. We are at the point where we have a branch that rate
> limits INTRODUCE2 cells at the intro point but we need to figure out proper
> values for the rate per second and the burst allowed.
>
> One naive approach is to see how much cells an attack can send towards a
> service. George and I have conducted experiment where with 10 *modified* tor
> clients bombarding a service at a much faster rate than 1 per-second (what
> vanilla tor does if asked to connect a lot), we see in 1 minute ~15000
> INTRODUCE2 cells at the service. This varies in the thousands depending on
> different factors but overall that is a good average of our experiment.
>
> This means that 15000/60 = 250 cells per second.
>
> Considering that this is an absurd amount of INTRODUCE2 cells (maybe?), we can
> put a rate per second of let say a fifth meaning 50 and a burst of 200.
>
> Over the normal 3 intro points a service has, it means 150 introduction
> per-second are allowed with a burst of 600 in total. Or in other words, 150
> clients can reach the service every second up to a burst of 600 at once. This
> probably will ring alarms bell for very popular services that probably gets
> 1000+ users a second so please check next section.
>
> I'm not that excited about hardcoded network wide values so this is why the
> next section is more exciting but much more work for us!
>
> One step further: we have not really decided yet if this is something we want
> nor have time to tackle but an idea here would be for a service to inform the
> intro point, using the ESTABLISH_INTRO cell payload, on the parameters it
> wants for its DoS defenses. So let say a very popular .onion with OnionBalance
> and 10 intro points, could tell to its intro points that it wants much higher
> values for the DoS defenses (or even put it off).
>
> However, it doesn't change the initial building block of being able to rate
> limit at the introduction point. As a second step, we can add this new type of
> ESTABLISH_INTRO cell. It is always dicy to introduce a new cell since for
> instance this would leak information to the intro point that the service is
> ">= version". Thus, this needs to be done with carefully.
>
> Time for your thoughts and help! :)
>
> Thanks everyone!
> David
>
>
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20190530/2e6de0ce/attachment-0001.html>