On 13-10-20 12:42 PM, Gordon Morehouse wrote:
First, during a SYN flood type overload, some peers which have *existing* circuits built through the relay and are sending SYNs as normal traffic, will stochastically get "caught" in the filter and banned for a short time. If these hosts already have circuits open through the relay which is overloaded, I would prefer to preserve those circuits rather than break them. My defensive strategy versus overload here is to throttle new circuit creation requests, *not* to break existing circuits. ... If a tor relay has a circuit built through a peer, and the peer starts dropping 100% of packets, how long will it take before the relay with the circuit "gives up" on the circuit and tears it down? I want to set my temp ban time *below* this timeout. Thus, unlucky peers that were caught in the filter and have circuits already built through the relay they will experience a brief performance degradation, but they won't lose their active circuits through the overloaded relay, and in the meantime hopefully the overload condition is becoming resolved.
Is there such a timeout? There must be. Can someone tell me what it is?
Would something like an conntrack-tools help? Maybe it provides more direct connection control than trying to game the timings. http://conntrack-tools.netfilter.org/
Also, to what extent would/could the Tor network (or a small group of nodes) count as a "high availability cluster" for entry firewalling purposes? Would clustering help protect against timing attacks on relays or hidden services?
(I lack expertise or resources to answer any of the above, but reading Gordon Morehouse's project got me searching and curious.)