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