Thus spake Roger Dingledine (arma@xxxxxxx): > On Wed, Jul 18, 2007 at 01:36:02AM -0700, Mike Perry wrote: > > 1. Expand MAX_BELIEVABLE_BANDWIDTH from 1.5MBytes/sec to 10Mbytes/sec. > > We already have several Tor nodes with near 5Mbytes/sec. Capping them > > at 1.5MBytes/sec artifically dumps load on slower nodes. > > Hi Mike, > > On the theory that if I plan to answer everything I'll answer nothing, > here is a first response to this little piece. I like this idea. Though beware, it can lead you down the dark and lonely road of replying to yourself 3 times on a mailinglist while there are otherwise nothing but crickets ;) > It's true that this doesn't distribute load ideally, but putting the > cap lower than some of the running routers can prevent an attacker from > publishing a majority of absurdly fast routers and pushing every guard > guard out of having guard status -- similar to the attack described > in > https://tor.eff.org/svn/trunk/doc/spec/proposals/107-uptime-sanity-checking.txt > > Actually, I just checked the code, and that attack works right now. :( Yeah, I see no reason why this attack can't work just by picking a bunch of routers at whatever bandwidth limit is chosen. It seems orthogonal to this patch. > We should consider modifying router_get_advertised_bandwidth() to cap > its answer at MAX_BELIEVABLE_BANDWIDTH, so the smartlist we build in > dirserv_compute_performance_thresholds() won't list the higher bandwidths. > > One solution would be to have a bandwidth level above which you're > *always* guard-worthy, and a separate value for the rate-limiting stuff. Yeah. Both values should have nothing to do with this clipping nonsense though. It is possible to detect bandwidth liars/overloaded nodes via other means (scanning, peer-monitoring). > The reason this number is particularly low still is because back when > I picked it, we had problems where Tor servers on fast pipes couldn't > handle the throughput Tor was sending towards them (due to cpu limits, > etc), so I needed to decrease the attention they were getting. I no > longer have a good handle on the fast Tor servers out there right now, > so I have no idea if this is still smart or no longer smart. We do still > hear on or-talk from people running fast Tor servers on slow CPUs that > are bottlenecked by AES, though. Hm. Why does it matter if routers are CPU or network bound? From the Tor network routing point of view, it shouldn't matter, capacity is capacity. If it is a problem for node operators, they limit their bandwidth in the config, problem solved. If they don't, then they just run at 100% CPU, and Tor should still properly report their observed bandwidth rate (unless they lie, but again, that is a another, orthogonal matter). -- Mike Perry Mad Computer Scientist fscked.org evil labs
Attachment:
pgpd2artJnuzI.pgp
Description: PGP signature