Re: (FWD) Re: BitTorrent - can it be blocked?

[Roger Dingledine <arma@xxxxxxx>]

On Wed, Dec 08, 2004 at 01:07:43PM -0000, Paul Gardner wrote:
> Ultimately you might want to develop some kind of connection limit/speed
> throttling (per client) at point of introduction?

Since this has the potential for turning into a bike shed problem
(http://www.linuxmafia.com/~rick/lexicon.html#bikeshed), let me put out a
few facts to start us out.

Tor already has a few congestion control and rate
limiting features built-in -- see sections 4.5 and 4.6 of
http://tor.freehaven.net/cvs/tor/doc/design-paper/tor-design.html . But
they're mainly designed for fairness and for letting the server operator
protect himself, rather than overall abuse control.

You can configure Tor to rate-limit overall incoming bytes/second. But
setting this too low provides crummy service to all users, not just the
ones abusing the network.

We could limit the number of TLS connections from a given client (that
is, IP), but a) some IPs NAT for a whole lot of clients -- AOL is the
canonical example of this; and b) it wouldn't help much because a single
TLS connection is enough to multiplex many circuits and many streams. We
could limit the number of circuits a given TLS connection can have open
at once; but I don't think this is being a problem currently.

Because "extend" relay cells look just like "data" relay cells when
they're encrypted, there's no way for entry nodes to limit the number
of streams that are opened over a given circuit. (We could fix this if
we needed to, but it's not clear to me that it would help.)

We could rate limit the bytes going over each connection or each
circuit. But this wouldn't foil smart programs like Bittorrent that open
many connections over time. Even if each entry node limited each client
to say 10kB/s, clients could use N entry nodes in parallel (for example
by cranking up min_peers) to get fine overall speeds.

We could try to build a coordinated black-list by communicating among
entry nodes about users that have many connections open or are using
many bytes. But it seems like an incredibly hard research problem to do
that without letting an adversary start to enumerate IPs of clients.

We could let the allowed bandwidth for a circuit decay over time or
after many bytes, to provide improved service to people who don't talk so
much. But again, Bittorrent is smarter than that -- it will prefer working
circuits to non-working circuits and simply migrate to the new ones.

We could provide better quality of service to cells on circuits that don't
talk much, by putting such cells to the front of the line. But this is
hard to do with our current system because once you've crypted a cell
and put it on the out buffer, you can't easily uncrypt it and change
the order of things. Also, if you're pushing a lot of bytes already,
and the link is pretty much full, then even moving cells to the front
of the buffer won't solve the fact that we have to wait for the previous
flushes to finish first.

We can't block the default bittorrent port in exit policies, because
there's no such port. (Blocking 6969 isn't what we want, because
connections to the trackers are not the ones causing pain.)

We can't integrate an IDS on exit nodes and snipe outgoing connections
with certain signatures, because a) we don't want the added complexity
of an IDS and maintaining signatures and so on inside Tor, a') such
things have historically been bloated and don't work so well, and b)
we don't actually want to be building that tool, we want to be building
a content-neutral anonymous transport system.

Ok, so that's a big list of what we can't do to help. What _can_ we do?

Stayed tuned for a follow-up post. :)

--Roger