On 2011-10-24 14:10 , Eugen Leitl wrote: > On Mon, Oct 24, 2011 at 01:46:13PM +0200, Jeroen Massar wrote: >> On 2011-10-24 13:34 , [email protected] wrote: >> [..] >>> The problem is that they're using denial of service attacks to overload the >>> servers, and parts of the Tor network as a result. Tor doesn't seem to >>> handle this very well. >> >> The internet does not handle (D)DoS attacks either. > > Don't know what the internet is, but if you speak BGP on the Internet > you can always nullroute the target, or the origin network.
(I mentioned in my mail that one cannot do that for Tor, implying one can with the normal internet, because of the absence of a source address, should have written that out better I guess) Even those nice nullroute communities do not make those packets arrive at your upstream links and fill them up. Only way to do that is then to simply stop announcing the route in question to the links that those packets are coming in over. (this is the strategy taken by most IRC servers btw, which then keep on announcing the prefix on the local IX where most of their clients likely exist) Do also note that is a generally a limit to the amount of source filtering one can do. Every ACL added can bog things up and one really does not want to keep state. But it all depends on the attack, in the end more have more capacity is the only really thing one can do about this. [..] >> DoS attacks by overloading a network are always possible and the only >> real solution to that is to add way more capacity than the adversary has. > > That's the brute force way to do it. Smarter ways would be use > connectionless protocols... Unfortunately Tor implies (TCP + TLS/SSL) connections and thus lots of state. Thus wiping out a node would just mean creating enough connections which should be easily done on most nodes in the directory given a properly sized botnet. > ... or use proof of work (like hashcash) > in order that using the network at high priority needs credits > which have to be earned by being a member in good standing (as > seen from other nodes). If you would introduce something like hashcash, does the source node or the intermediate node have to do this hashcash calculation? I do hope that verifying the hashcash is then factors lighter than generating it. Do note though that some If the source has to do it you are going to transfer a bit of text from the source to the intermediary node and thus the intermediary node might learn that way what the real source is. I don't think this is very viable, even though it has merit, I would say, change the subject line and go for a proposal and we'll see how far it can solve something. Greets, Jeroen _______________________________________________ tor-talk mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
