[tor-relays] max TCP interruption before Tor circuit teardown?

[krishna e bera]

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.)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 547 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20131020/9527dc51/attachment.sig>