<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Nice to try to stop this DoS vulnerability at network design
level. <br>
</p>
<p>Can we have an estimation of when will be released this antiDoS
features? 0.4.1.x or 0.4.2.x ?</p>
<p>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.<br>
</p>
<div class="moz-cite-prefix">On 30/5/19 15:49, David Goulet wrote:<br>
</div>
<blockquote type="cite" cite="mid:20190530134926.GA9675@raoul">
<pre class="moz-quote-pre" wrap="">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 <a class="moz-txt-link-freetext" href="https://trac.torproject.org/15516">https://trac.torproject.org/15516</a> 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
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
tor-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tor-dev@lists.torproject.org">tor-dev@lists.torproject.org</a>
<a class="moz-txt-link-freetext" href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev</a>
</pre>
</blockquote>
</body>
</html>