Proposal 144: enforce distinct providers

Nick Mathewson nickm at
Tue Jul 15 05:29:42 UTC 2008

On Tue, Jul 01, 2008 at 07:12:58PM -0400, Nick Mathewson wrote:
> Hi!  By request, I'm forwarding this to or-dev and adding it as proposal 144.
> I've reformatted it, and included the reformatted version below.
> Filename: 144-enforce-distinct-providers.txt
> Title: Increase the diversity of circuits by detecting nodes belonging the
> same provider
> Author: Mfr
> Created: 2008-06-15
> Status: Draft
> Overview:
>   Increase network security by reducing the capacity of the relay or
>   ISPs monitoring personally or requisition, a large part of traffic
>   Tor trying to break circuits privacy.  A way to increase the
>   diversity of circuits without killing the network performance.
> Motivation:
>   Since 2004, Roger an Nick publication about diversity [1], very fast

To be clear, the Nick on this paper is Nick Feamster, not me.

I generally agree with Cat's concerns on this one. It's good that we
have this proposal, since this is probably the simplest design
response to the Dingledine & Feamster paper that one could make, and
so analyzing how well it would or would not work is likely to be of

Unfortunately, it is not at all clear that this proposal would make
the network more secure.  In summary, it would change the rules such
that the nodes in a circuit must occupy distinct ASs.  But making
circuits cross multiple ASs will not necessarily improve their
resistance to the IX-monitoring attacks of [5], and may even make such
attacks stronger by spreading the traffic against a larger subset of
the internet at large.  Without analysis, we can't be sure that this
routing algorithm would actually help.

Also, the client->Tor and Tor->destination links aren't considered
here, but they're just about the two most important links for a
traffic analysis discussion.

So for at least a 0.2.1.x timeframe, I'm inclined to leave this
proposal as a Draft.  It is conceivable that AS-based routing might
turn out to be a reasonable and tractable proxy for IX-aware routing
(or something even better), but it's not reasonable to assume that it
will be a win without more thorough analysis.


More information about the tor-dev mailing list