[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: Exit Balancing Patch
- To: or-dev@xxxxxxxxxxxxx
- Subject: Re: Exit Balancing Patch
- From: coderman <coderman@xxxxxxxxx>
- Date: Wed, 18 Jul 2007 02:32:06 -0700
- Delivered-to: archiver@xxxxxxxx
- Delivered-to: or-dev-outgoing@xxxxxxxx
- Delivered-to: or-dev@xxxxxxxx
- Delivery-date: Wed, 18 Jul 2007 05:32:15 -0400
- Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=d3VR2UoEDKYQO6SNKDIkba88jKf4QHZhfRlTNIpHI20RGfRv7PWQR5f2l1zjMf6xAGtU6343KaFHeFaoDYRZiRwSIAgtvpD3hMjMEEMOl3jlVYW31XEIoMEjJ6UP45H6Fs0Tl6i0IbgAi/Ol/3oJDrIK9qQv7uN5IsALQF+3JoY=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=D+vXe95vMu80mXrh+kb95t9MTFYtHMMp+B9pr3LtvUOG6W6v/UaLlavaEeRRZkJ88Kgp66R0Thp3+LnIH91vZw/a3IGiTQnENydVytQZbKjrEgTnlONVe24Pspw51sjT498dbI9bAboUfB237lFPnXbmJRbnKPhz8V2YtHtfThg=
- In-reply-to: <20070718085558.GS11269@xxxxxxxxxxxxxx>
- References: <20070718083602.GA28959@xxxxxxxxxx> <20070718085558.GS11269@xxxxxxxxxxxxxx>
- Reply-to: or-dev@xxxxxxxxxxxxx
- Sender: owner-or-dev@xxxxxxxxxxxxx
On 7/18/07, Roger Dingledine <arma@xxxxxxx> 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).
so defending against this kind of thing may be useful now, not just in
the future. :)
(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.)
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?