On 09/04/13 20:46, krishna e bera wrote: > On Tue, 9 Apr 2013 22:59:06 +0600 > Roman Mamedov <rm@xxxxxxxxxx> wrote: > >> On Tue, 9 Apr 2013 12:50:09 -0400 >> krishna e bera <keb@xxxxxxxxxxxxxx> wrote: >> >>> So at the risk of being labelled a BadExit (or at best a non-net-neutral exit) i >>> blocked all of ThePirateBay's ip addresses from my exit node for a >>> while. >> I assume you mean firewall-based blocking? You could have simply rejected >> those IPs via ExitPolicy (see "man tor"). That's a clear-cut way to tell the >> network you don't accept connections to those IPs, and no risk of being >> labeled a BadExit. > The latter. I dont know if it complicates routing decisions in the Tor > network to have lots of ip address exceptions at the exits... > > > _______________________________________________ > tor-relays mailing list > tor-relays@xxxxxxxxxxxxxxxxxxxx > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays It possibly does slightly but we are talking about the sort of "complication" that a modern CPU can resolve in timescales short enough I doubt it would make that much difference especially if hash tables were used if ipset match can handle hash table lookups containing over 20,000 CIDR ranges while processing 75,000 packets per second I suspect tor could easily be made to efficiently use a similar mechanism, if it doesn't already in order to perform the lookups to compute the answer to "What is the subset of exit nodes allowing exit to IP addr X on port Y?" to come close to the same volume of lookups as the above setup with just over 1k exit nodes the client would need to be building 70+ circuits per second assuming a separate lookup table was used for every node, two factors make me think it's unlikely to go anywhere near this load and if it did that it would only be for brief periods of time as opposed to constant as in the former example, those being that I don't see many exit nodes ever having policies 20k entries long and I can't see that many clients needing to connect to 70+ IP address per second at least not on any continual basis perhaps short bursts (Opening a browser and restoring a few dozen tabs at once or something similar). Bittorrent may be an exception to the above but the performance cost would be at the clients end and for one bittorrent is hardly a realtime protocol a little delay making each connection would not make much difference, two it performs poorly if you insist on running it over tor anyway and thirdly the average consumer desktop system is not exactly lacking spare CPU cycles due to the bursty nature of their workloads they statistically tend to spend the majority of their time idling. Maybe someone can correct me if I missed something glaringly obvious but I certainly don't think anyone should be reluctant to add any exit policy entries they deem necessary at least not for this reason.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-relays mailing list tor-relays@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays