|  | @@ -0,0 +1,165 @@
 | 
	
		
			
				|  |  | +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
 |