Hi All,
I think I see the shape of the DDoS mitigations now, and to test my understanding I'm going to try to recap/quote some of the thread as I understand it; plus, I'll voice some of the questions which linger at the back of my head.
Stuff where I am inferring (possibly wrongly) behaviour from context, is in <angle> brackets.
Observation: I had a hard time following whether a bare reference to "client" in any given explanation, referred to a client-ip-address, or to one of the tor-daemons ("clients behind an ip-address"), or to something (eg: curl) actually using tor. So I may have misapprehended / got some of this wrong...
# The three defences are...
1) Connection-Limiting: if a <given client ip-address> makes too many connections to <a solitary given relay> then <that solitary relay> will start to <destroy further circuits that the ip-address creates, irrespective of which tor-daemon behind that address, created them>
Question: as above, I am really uncertain whether the circuits are destroyed because they are attributed to a given ip-address (potential for collateral damage?) or to a specific overzealous tor-daemon/client *behind* a given ip-address.
Question: I am not sure whether this mitigation is per-relay, or whether the status that <given client ip-address> is being "unfair" gets somehow propagated to the rest of the Tor network?
2) Rate-Limiting: if a <given client ip-address> makes connections too quickly to <a solitary given relay>, when ALSO there are lots of existing connections <to that relay>, then <that solitary relay> will start to ignore that <given client ip-address>
Question: <The same two questions as-previous, apply.>
3) DoS Mitigation: if a <non-relay / random ip-address somewhere on the internet> asks <a relay> to <become> a rendezvous point, it gets ignored, which thereby kills Tor2web.
Notes: initially this worried me because I misread it as "if a non-relay CONNECTS to an RP" - which would ban SingleOnions because no guards - but I am pretty sure of my revised interpretation and I am fairly certain of why this would be a good idea; but if I can make this misinterpretation, then others might do, too.
# Re: my situation...
Teor: yep everything is SingleOnion in EOTK by default, not least because testing onionification of video streams with a bank of RaspberryPi on a single DSL connection is laggy enough without a couple of extra hops.
Questions:
The reason I am worried (above) about "notification of bad behaviour is somehow propagated?" is that I am worried that if I trip a trigger, am I going to effectively be banned from the entire Tor network for "a couple of hours", or am I just going to lose <a solitary relay>?
Reading the text further down, Teor writes: "...the defence will trigger. Then both instances will try another relay..." - so I am pretty sure that this is not a "banhammer" that would kick me off Tor entirely; instead it's more of a "choke".
# Re: EOTK...
Any given EOTK "worker" currently gets 2x tor daemons provisioned to it; this is partly to make better use of the compute bandwidth available on a multiprocessor box, and partly to mitigate exant problems of Tor daemons going "stale" - having 2x daemons makes it less likely to lose the entire worker.
Also: I am looking at #24973 "Tor should be more gentle when launching dozens of circuits at once" - which resonates with my worker pool: I am running 6x2 = 12 worker-daemons (and that figure may double, soon) not to mention all the other tor daemons that I am running (eg: TBB, OnionBalance)
Also: per #24992, I have seen quite a lot of "exceeded launch limit with 10 intro points in the last 180 seconds"-type messages, recently; I am not sure why this has been happening because the tor daemons in question have all been workers running a single HS in each. Perhaps it was having problems establishing ANY introduction points at all, because of the DDoS attack, but the failures still counted?
To summarise: all of this "bad" behaviour on my part, explains why I am/was worried about getting blocked from Tor entirely. :-)
# Re: NYT...
I am still working with NYT to confirm their IP setup on AWS; until now, one of the selling points of enterprise onion networking for me has been the capability to keep everything in one/more "NAT enclaves" which - combined with SingleOnion - mitigates inbound-connection attacks like flooding, whilst permitting "horizontal scaling" which is important with a rewriter-proxy like EOTK.
I'm a little bummed that that may no longer be viable / that in order to do Tor at high bandwidth then your worker fleet will need to have separate and visible IP addresses, because DDoS attribution; however, this is an evolving environment so I suppose that we'll adapt.
In the case of AWS this likely means buying "Elastic IPs" for each worker.
# Speculation...
Aaron wrote: "Because the circuit-creation limit is applied at the guard, wouldn't this affect hidden sevices instead of single onion services?"
Teor wrote: "It will only trigger if hundreds of guard-using clients are behind a single IP address."
This exchange makes me think a couple of things:
a) if my EOTK development farm was using NormalOnions not SingleOnions, then I might actually be in a worse situation because I would be more heavily regulated... in fact:
b) I am wondering if <bad people> might leverage the DDoS mitigations to knock non-SingleOnion onionsites off-air? The attack would be to use a wide diversity of client IPs (eg: botnet) to "just enough" connections to the onion site that the connections back, through the guard, to the rendezvous sites, would trip the DDoS code?
Whether I am right would depend in-part on my proper understanding of defences 1 & 2 at the top of this post, plus also how quickly the onionsite would "give up" on the guard which is now ignoring it.
It would be a bit like a DNS amplification attack; but I'm presuming that I'm somehow wrong; Roger's final paragraph speaks directly to Onions-that-use-guards being apparently safer:
"I expect a popular onion service that doesn't use guards and that runs many Tor instances on the same IP address will trigger the defense often: because it doesn't use guards, each new circuit it builds in response to a rendezvous request will pick an entry point at random, and if some of the conversations with clients last for a while, then outgoing connections will accumulate, eventually reaching the threshold for each relay to decide that that address is being unfair."
...however it is speaking to the protections of relays as a whole, rather than the connectivity of a given onion site through a given guard.
-a