144-enforce-distinct-providers.txt 6.3 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165
  1. Filename: 144-enforce-distinct-providers.txt
  2. Title: Increase the diversity of circuits by detecting nodes belonging the
  3. same provider
  4. Author: Mfr
  5. Created: 2008-06-15
  6. Status: Draft
  7. Overview:
  8. Increase network security by reducing the capacity of the relay or
  9. ISPs monitoring personally or requisition, a large part of traffic
  10. Tor trying to break circuits privacy. A way to increase the
  11. diversity of circuits without killing the network performance.
  12. Motivation:
  13. Since 2004, Roger an Nick publication about diversity [1], very fast
  14. relays Tor running are focused among an half dozen of providers,
  15. controlling traffic of some dozens of routers [2].
  16. In the same way the generalization of VMs clonables paid by hour,
  17. allowing starting in few minutes and for a small cost, a set of very
  18. high-speed relay whose in a few hours can attract a big traffic that
  19. can be analyzed, increasing the vulnerability of the network.
  20. Whether ISPs or domU providers, these usually have several groups of
  21. IP Class B. Also the restriction in place EnforceDistinctSubnets
  22. automatically excluding IP subnet class B is only partially
  23. effective. By contrast a restriction at the class A will be too
  24. restrictive.
  25. Therefore it seems necessary to consider another approach.
  26. Proposal:
  27. Add a provider control based on AS number added by the router on is
  28. descriptor, controlled by Directories Authorities, and used like the
  29. declarative family field for circuit creating.
  30. Design:
  31. Step 1 :
  32. Add to the router descriptor a provider information get request [4]
  33. by the router itself.
  34. "provider" name NL
  35. 'names' is the AS number of the router formated like this:
  36. 'ASxxxxxx' where AS is fixed and xxxxxx is the AS number,
  37. left aligned ( ex: AS98304 , AS4096,AS1 ) or if AS number
  38. is missing the network A class number is used like that:
  39. 'ANxxx' where AN is fixed and xxx is the first 3 digits of
  40. the IP (ex: for the IP 1.1.1.2 AN1) or an 'L' value is set
  41. if it's a local network IP.
  42. If two ORs list one another in their "provider" entries,
  43. then OPs should treat them as a single OR for the purpose
  44. of path selection.
  45. For example, if node A's descriptor contains "provider B",
  46. and node B's descriptor contains "provider A", then node A
  47. and node B should never be used on the same circuit.
  48. Add the regarding config option in torrc
  49. EnforceDistinctProviders set to 1 by default.
  50. Permit building circuits with relays in the same provider
  51. if set to 0.
  52. Regarding to proposal 135 if TestingTorNetwork is set
  53. need to be EnforceDistinctProviders is unset.
  54. Control by Authorities Directories of the AS numbers
  55. The Directories Authority control the AS numbers of the new node
  56. descriptor uploaded.
  57. If an old version is operated by the node this test is
  58. bypassed.
  59. If AS number get by request is different from the
  60. description, router is flagged as non-Valid by the testing
  61. Authority for the voting process.
  62. Step 2 When a ' significant number of nodes' of valid routers are
  63. generating descriptor with provider information.
  64. Add missing provider information get by DNS request
  65. functionality for the circuit user:
  66. During circuit building, computing, OP apply first
  67. family check and EnforceDistinctSubnets directives for
  68. performance, then if provider info is needed and
  69. missing in router descriptor try to get AS provider
  70. info by DNS request [4]. This information could be
  71. DNS cached. AN ( class A number) is never generated
  72. during this process to prevent DNS block problems. If
  73. DNS request fails ignore and continue building
  74. circuit.
  75. Step 3 When the 'whole majority' of valid Tor clients are providing
  76. DNS request.
  77. Older versions are deprecated and mark as no-Valid.
  78. EnforceDistinctProviders replace EnforceDistinctSubnets functionnality.
  79. EnforceDistinctSubnets is removed.
  80. Functionalities deployed in step 2 are removed.
  81. Security implications:
  82. This providermeasure will increase the number of providers
  83. addresses that an attacker must use in order to carry out
  84. traffic analysis.
  85. Compatibility:
  86. The presented protocol does not raise compatibility issues
  87. with current Tor versions. The compatibility is preserved by
  88. implementing this functionality in 3 steps, giving time to
  89. network users to upgrade clients and routers.
  90. Performance and scalability notes:
  91. Provider change for all routers could reduce a little
  92. performance if the circuit to long.
  93. During step 2 Get missing provider information could increase
  94. building path time and should have a time out.
  95. Possible Attacks/Open Issues/Some thinking required:
  96. These proposal seems be compatible with proposal 135 Simplify
  97. Configuration of Private Tor Networks.
  98. This proposal does not resolve multiples AS owners and top
  99. providers traffic monitoring attacks [5].
  100. Unresolved AS number are treated as a Class A network. Perhaps
  101. should be marked as invalid. But there's only fives items on
  102. last check see [2].
  103. Need to define what's a 'significant number of nodes' and
  104. 'whole majority' ;-)
  105. References:
  106. [1] Location Diversity in Anonymity Networks by Nick Feamster and Roger
  107. Dingledine.
  108. In the Proceedings of the Workshop on Privacy in the Electronic Society
  109. (WPES 2004), Washington, DC, USA, October 2004
  110. http://freehaven.net/anonbib/#feamster:wpes2004
  111. [2] http://as4jtw5gc6efb267.onion/IPListbyAS.txt
  112. [3] see Goodell Tor Exit Page
  113. http://cassandra.eecs.harvard.edu/cgi-bin/exit.py
  114. [4] see the great IP to ASN DNS Tool
  115. http://www.team-cymru.org/Services/ip-to-asn.html
  116. [5] Sampled Traffic Analysis by Internet-Exchange-Level Adversaries by
  117. Steven J. Murdoch and Piotr Zielinski.
  118. In the Proceedings of the Seventh Workshop on Privacy Enhancing Technologies
  119. (PET 2007), Ottawa, Canada, June 2007.
  120. http://freehaven.net/anonbib/#murdoch-pet2007
  121. [5] http://bugs.noreply.org/flyspray/index.php?do=details&id=690