Exit Balancing Patch

Paul Syverson syverson at itd.nrl.navy.mil
Mon Jul 30 17:18:19 UTC 2007

On Sun, Jul 29, 2007 at 10:33:59PM -0700, Mike Perry wrote:
> As an aside though, an adversary that can afford a 1GB link can do all
> sorts of crazy things with that bandwidth even with the limit in
> place: the first one likely being mounting a sybil attack from a ton of
> disperate IP ranges possibly all from that same link. But yeah, it
> would make that node a nice point of surveilance for an external
> adversary.

It's not that simple. Clearly the biggest bang-for-the-buck adversary
threat from monitoring at this point is caused by somebody setting up
and owning nodes. But if enough of the traffic is concentrated through
few enough nodes, then this might not be true any more. The threat
will not only or even primarily be from bad guys setting up nodes, it
will be from good guys trying to contribute as much as possible to the
network who thereby concentrate enough traffic to make themselves fat
targets for compromise (technical or legal) but much more
significantly bridging by just watching their network pipes (which I
think is the more problematic concern). In a nutshell, the more the
network has single-point proxy properties the more it will have
single-point proxy vulnerabilities. If you can sit on the network
connection of a handful of nodes and watch say half of the traffic in
the network, then you have basically won. This is to some extent the
point made in the "routing zones" paper (Feamster and Dingledine) and
a bit elsewhere, but I think the threat becomes much more realistic
than there in terms of how heavily resourced and influential an
adversary we're talking about.

> Also, I think we should consider doing a similar weighting for
> choosing guards for middle nodes. Guard bandwidth is also somewhat of
> a scarcity, though not as much as exits (40% by my measure).

Agree. Already touched on this with Roger in a side conversation.
Will get back to it in my copious free time.


More information about the tor-dev mailing list