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