Add proposal 144 from M Fr.

svn:r15586

doc/spec/proposals/000-index.txt

@@ -66,6 +66,7 @@ Proposals by number:
 141  Download server descriptors on demand [DRAFT]
 142  Combine Introduction and Rendezvous Points [OPEN]
 143  Improvements of Distributed Storage for Tor Hidden Service Descriptors [OPEN]
+144  Increase the diversity of circuits by detecting nodes belonging the [DRAFT]
 
 
 Proposals by status:
@@ -78,6 +79,7 @@ Proposals by status:
    133  Incorporate Unreachable ORs into the Tor Network
    134  More robust consensus voting with diverse authority sets
    141  Download server descriptors on demand
+   144  Increase the diversity of circuits by detecting nodes belonging the
  OPEN:
    120  Shutdown descriptors when Tor servers stop
    121  Hidden Service Authentication

doc/spec/proposals/144-enforce-distinct-providers.txt

@@ -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