Squeezing non-relays at the entry node

Roger Dingledine arma at mit.edu
Wed Dec 23 10:11:18 UTC 2009

On Sun, Dec 13, 2009 at 08:23:14PM -0500, Roger Dingledine wrote:
> I've been pondering other performance improvements. One of them is to
> rate-limit client connections as they enter the network. Rate limiting
> in the Tor client itself would work better, but it's not a very stable
> equilibrium -- it encourages people to switch to security disasters
> like tortunnel.

I talked to Nick about this idea, and he:
1) Reminded me about proposal 163. Go read that thread. The main
difference is that I proposed a "or has a descriptor in its cache"
check too.
2) Demanded that I break out the "is a client" to its own function. Ok.
3) Thought it was a fine experiment to do.

Here's the newer patch:


> My main concern here is that I wonder if we are being thorough enough at
> detecting "is a relay". It checks the consensus and the descriptor cache
> currently. So if the authorities think you're not Running, they won't put
> you in the consensus, and no relays will hear about you. If you go up and
> down, relays that serve dirport info will have your descriptor cached,
> so they'll recognize you so long as you were around in the past day or so.
> Relays that don't serve dirport info will stop fetching descriptors,
> but they'll continue to fetch the consensus. So they'll still mostly work.

Soon I would like to make all relays above e.g. 50KB/s cache and serve
directory info. Having a separate open DirPort is becoming an obsolete
notion these days anyway now that most Tors use begindir requests over
the ORPort. Once we do that, these relays will be better at identifying
who else is a relay. I'd also like to make all relays regardless of their
dirport status answer begindir requests for their own descriptor. That bug
is currently preventing people (for example, me while testing censorship
stuff in Hong Kong) from using relays with no dirport set as bridges.

But that, as they say, is a proposal for another time.


More information about the tor-dev mailing list