Proposal: Avoiding infinite length circuits

[Roger Dingledine]

On Tue, Mar 13, 2007 at 11:15:47PM -0400, Roger Dingledine wrote:
>   Right now, an attacker can add load to the Tor network by extending a
>   circuit an arbitrary number of times. Every cell that goes down the
>   circuit then adds N times that amount of load in overall bandwidth
>   use. This vulnerability arises because servers don't know their position
>   on the path, so they can't tell how many nodes there are before them
>   on the path.
> 
>   We propose a new set of relay cells that are distinguishable by
>   intermediate hops as permitting extend cells. This approach will allow
>   us to put an upper bound on circuit length relative to the number of
>   colluding adversary nodes; but there are some downsides too.

In talking to Peter Eckersley, he discovered a variation on this attack
that our defense doesn't cover.

Our defense is to let intermediate relays count how many extend operations
could have happened after them on the circuit, and that way we can limit
circuit lengths to (say) 8 hops.

But what if the attacker builds an 8-hop Tor circuit, and then exits to
a Tor entry guard and pretends that it's a Tor client? At that point it
can talk Tor-inside-Tor and build eight more hops. Then repeat.

Peter suggested one way to defend against it would be a latency test --
if you're too slow at answering an extend cell, then we assume we're
being tricked. That seems very brittle though.

Another approach would be to refuse exits to known Tor server IP:ports.
That's also not a complete solution, since a) there is a slight time
lag between when a new relay goes online and when the other relays know
about it, b) we want to one day make it so each relay doesn't need the
complete list of other relays, and c) there are other open proxies out
there (or heck, Tor bridge relays) that can be used as glue between
attacker circuits.

(The flip side of this approach would be to instead refuse incoming TLS
connections from IP addresses that have a Tor relay running, if the TLS
connection doesn't provide a cert saying it's really the relay connecting
to you. I like this approach less though, because it still has the
problems from above but it also impairs usability for relay operators.)

The long-circuit attack becomes a bigger deal when we consider that it's
not just a DoS attack, but it can be leveraged into an anonymity attack
because it makes clogging attacks low-cost again.

Hm.

--Roger