Exit Balancing Patch

[Mike Perry]

Thus spake coderman (coderman at gmail.com):

> On 7/18/07, Roger Dingledine <arma at mit.edu> wrote:
> >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.
> >...
> >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 ...uptime-sanity-checking.txt
> 
> we were just discussing this today in #tor.  router "ghettogear"
> consistently averaged 210-260KB/sec for weeks.  then on the 14th/15th
> it went to 20.5MB/sec.  [likely too obvious] it then dropped to
> 6.1MB/sec; still enough to sit at the top of the node bw list (next
> closest, blutmagie, is at 5.6MB/sec).

Notice how just this one node lying was caught. Imagine sufficient
numbers to drown out *all* current guards. Imagine the impact on the
tor network speed if the adversary didn't have the capacity to
properly relay all this traffic. Someone would notice. Right away,
without scanning mechanisms.

And with respect to drowning out guards, all the limit prevents us
from doing is losing these 32 guards who have more than 1.5MBytes/sec.
And they would be weighted equally with all the adversary's other ~500
nodes to drown out the median with 1.5Mbyte nodes under the current
system. This is no protection. The guard speed limit to prevent this
sort of attack needs to be split off, and made much lower.

> so defending against this kind of thing may be useful now, not just in
> the future. :)

The mechanisms are built. All we need is people to scan. If you would
like, I can show you how to run scans via TorFlow and monitor the
results. It is hard for me to juggle scanning continuously right now
by myself, I work a full time job and have 2 Tor projects going :). I
could use some help.

> (also, there are only 32 nodes that are getting clipped right now at
> 1.5, so i don't see raising to 10 giving much improvement.)

It causes the effective loss of N-1.5Mbytes/sec of total Tor
bandwidth..

> >Actually, I just checked the code, and that attack works right now. :(
> >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.
> 
> does this mean that clipping prevents the attack inside
> smartlist_choose_by_bandwidth, but the directory servers are still
> exposed because of the way they compute thresholds, in turn affecting
> guard / stable selection?

Yeah, the limit should be split and lowered. 1.5Mbyte/sec does not
defend against guard selection attacks, as I mentioned above.

-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20070718/476a3c7b/attachment.pgp>