Proposal 144: enforce distinct providers

Wed Jul 2 09:10:05 UTC 2008

I don't believe that this will have the intended effect.  If anything, I'd 
expect to see this increase latency, and push more traffic towards exchange 
points, where (depending on the structure of the exchange), an attacker could
easily monitor many providers at once, 'cheaply'.

Further, without correlation of leaf nodes that are partially or completely 
subsumbed in a given AS, changing AS numbers isn't really indicative of any
useful characteristic.  For that matter, without correlating all of the AS
numbers owned by a given entity (an interesting challenge, to be polite), 
there's no guarantee at all that a changing AS reflects anything at all.

Beyond that, if you're still talking about classful address space in this day
and age, I'd suggest that some consideration of modern networking might well
be in order...

cheers!

On Tue, 1 Jul 2008, Nick Mathewson wrote:
> 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
>  relays Tor running are focused among an half dozen of providers,
>  controlling traffic of some dozens of routers [2].
>
>  In the same way the generalization of VMs clonables paid by hour,
>  allowing starting in few minutes and for a small cost, a set of very
>  high-speed relay whose in a few hours can attract a big traffic that
>  can be analyzed, increasing the vulnerability of the network.
>
>  Whether ISPs or domU providers, these usually have several groups of
>  IP Class B.  Also the restriction in place EnforceDistinctSubnets
>  automatically excluding IP subnet class B is only partially
>  effective. By contrast a restriction at the class A will be too
>  restrictive.
>
> Therefore it seems necessary to consider another approach.
>
> Proposal:
>
>  Add a provider control based on AS number added by the router on is
>  descriptor, controlled by Directories Authorities, and used like the
>  declarative family field for circuit creating.
>
> Design:
>
> Step 1 :
>
> Add to the router descriptor a provider information get request [4]
>  by the router itself.
>
>         "provider" name NL
>
>            'names' is the AS number of the router formated like this:
>            'ASxxxxxx' where AS is fixed and xxxxxx is the AS number,
>            left aligned ( ex: AS98304 , AS4096,AS1 ) or if AS number
>            is missing the network A class number is used like that:
>            'ANxxx' where AN is fixed and xxx is the first 3 digits of
>            the IP (ex: for the IP 1.1.1.2 AN1) or an 'L' value is set
>            if it's a local network IP.
>
>            If two ORs list one another in their "provider" entries,
>            then OPs should treat them as a single OR for the purpose
>            of path selection.
>
>            For example, if node A's descriptor contains "provider B",
>            and node B's descriptor contains "provider A", then node A
>            and node B should never be used on the same circuit.
>
>    Add the regarding config option in torrc
>
>            EnforceDistinctProviders set to 1 by default.
>            Permit building circuits with relays in the same provider
>            if set to 0.
>            Regarding to proposal 135 if TestingTorNetwork is set
>            need to be EnforceDistinctProviders is unset.
>
>    Control by Authorities Directories of the AS numbers
>
>         The Directories Authority control the AS numbers of the new node
>         descriptor uploaded.
>
>            If an old version is operated by the node this test is
>            bypassed.
>
>            If AS number get by request is different from the
>            description, router is flagged as non-Valid by the testing
>            Authority for the voting process.
>
> Step 2     When a ' significant number of nodes' of valid routers are
> generating descriptor with provider information.
>
>        Add missing provider information get by DNS request
> functionality for the circuit user:
>
>                During circuit building, computing, OP apply first
>                family check and EnforceDistinctSubnets directives for
>                performance, then if provider info is needed and
>                missing in router descriptor try to get AS provider
>                info by DNS request [4].  This information could be
>                DNS cached.  AN ( class A number) is never generated
>                during this process to prevent DNS block problems.  If
>                DNS request fails ignore and continue building
>                circuit.
>
> Step 3 When the 'whole majority' of valid Tor clients are providing
> DNS request.
>
>        Older versions are deprecated and mark as no-Valid.
>
>  EnforceDistinctProviders replace EnforceDistinctSubnets functionnality.
>
>        EnforceDistinctSubnets is removed.
>
>        Functionalities deployed in step 2 are removed.
>
> Security implications:
>
>      This providermeasure will increase the number of providers
>      addresses that an attacker must use in order to carry out
>      traffic analysis.
>
> Compatibility:
>
>        The presented protocol does not raise compatibility issues
>        with current Tor versions. The compatibility is preserved by
>        implementing this functionality in 3 steps, giving time to
>        network users to upgrade clients and routers.
>
> Performance and scalability notes:
>
>        Provider change for all routers could reduce a little
>        performance if the circuit to long.
>
>        During step 2 Get missing provider information could increase
>        building path time and should have a time out.
>
> Possible Attacks/Open Issues/Some thinking required:
>
>        These proposal seems be compatible with proposal 135 Simplify
>        Configuration of Private Tor Networks.
>
>        This proposal does not resolve multiples AS owners and top
>        providers traffic monitoring attacks [5].
>
>        Unresolved AS number are treated as a Class A network. Perhaps
>        should be marked as invalid.  But there's only fives items on
>        last check see [2].
>
>        Need to define what's a 'significant number of nodes' and
>        'whole majority' ;-)
>
> References:
> [1] Location Diversity in Anonymity Networks by Nick Feamster and Roger
> Dingledine.
> In the Proceedings of the Workshop on Privacy in the Electronic Society
> (WPES 2004), Washington, DC, USA, October 2004
> http://freehaven.net/anonbib/#feamster:wpes2004
> [2] http://as4jtw5gc6efb267.onion/IPListbyAS.txt
> [3] see Goodell Tor Exit Page
> http://cassandra.eecs.harvard.edu/cgi-bin/exit.py
> [4] see the great IP to ASN DNS Tool
> http://www.team-cymru.org/Services/ip-to-asn.html
> [5] Sampled Traffic Analysis by Internet-Exchange-Level Adversaries by
> Steven J. Murdoch and Piotr Zielinski.
> In the Proceedings of the Seventh Workshop on Privacy Enhancing Technologies
>
> (PET 2007), Ottawa, Canada, June 2007.
> http://freehaven.net/anonbib/#murdoch-pet2007
> [5] http://bugs.noreply.org/flyspray/index.php?do=details&id=690
>

==========================================================================
"A cat spends her life conflicted between a deep, passionate and profound
desire for fish and an equally deep, passionate and profound desire to
avoid getting wet.  This is the defining metaphor of my life right now."