[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: Running a Tor exit node on an academic network?
- To: or-talk@xxxxxxxxxxxxx
- Subject: Re: Running a Tor exit node on an academic network?
- From: Roger Dingledine <arma@xxxxxxx>
- Date: Tue, 9 May 2006 05:03:28 -0400
- Delivered-to: email@example.com
- Delivered-to: firstname.lastname@example.org
- Delivered-to: email@example.com
- Delivery-date: Tue, 09 May 2006 05:03:30 -0400
- In-reply-to: <firstname.lastname@example.org>
- References: <email@example.com> <firstname.lastname@example.org> <43DAEAA4.email@example.com> <firstname.lastname@example.org>
- Reply-to: or-talk@xxxxxxxxxxxxx
- Sender: owner-or-talk@xxxxxxxxxxxxx
- User-agent: Mutt/1.5.9i
On Sat, Jan 28, 2006 at 10:34:55AM -0800, Joseph Lorenzo Hall wrote:
> * The Library has electronic subscriptions to certain services that
> are based on IP addresses only. Proposal: block exit connections to
> those IP addresses given a list or build a list as needed. The
> eventual list could be thousands of IP addresses long which would have
> a undetermined impact on Tor's performance.
Joe has asked me to speculate a bit more about whether it's smart
to have exit policies with thousands of lines in them.
I think the answer is that it is quite bad indeed. Right now compressed
server descriptors are 1K or less; if we increase that by an order of
magnitude, we're going to load the directory system a lot more, making
it stop scaling a lot quicker. (We could tolerate a small number of
nodes doing this, but tragedy of the commons will kick in.) There are
also some other problems having to do with current client behavior --
we evaluate exit policies in a linear way and we don't cache results,
which means if exit policies get a lot longer, clients are going to
start wasting a lot of time looking through them.
So if you're in the position where you have hundreds or thousands of
particular locations that you don't want to allow connections to, the
two options that come to mind are:
* Block them in large chunks rather than in a fine-grained manner. E.g.,
block 188.8.131.52/8:80. Probably not worth your time to maintain the list
since you'll end up blocking much of the Internet anyway.
* Block *:80, since the services you're needing to block probably believe
that port 80 is the whole Internet already. This will decrease your
usefulness to the Tor network, but that's ok, that's why we have other
nodes. If needed, you can block a few other ports (e.g. 443) if those
are used by your libraries too.
Unfortunately, Joe added another restriction, which is that he wants to
do research on "typical" exit behavior, while at the same time being
restricted by his university about what IP addresses are not known to
blindly trust his school's IP space. I stick with my earlier response
to this case:
Hope that helps,