109-no-sharing-ips.txt 3.4 KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677
  1. Filename: 109-no-sharing-ips.txt
  2. Title: No more than one server per IP address.
  3. Version:
  4. Last-Modified:
  5. Author: Kevin Bauer & Damon McCoy
  6. Created: 9-March-2007
  7. Status: Open
  8. Overview:
  9. This document describes a solution to a Sybil attack vulnerability in the
  10. directory servers. Currently, it is possible for a single IP address to
  11. host an arbitrarily high number of Tor routers. We propose that the
  12. directory servers limit the number of Tor routers that may be registered at
  13. a particular IP address to some small (fixed) number, perhaps just one Tor
  14. router per IP address.
  15. While Tor never uses more than one server from a given /16 in the same
  16. circuit, an attacker with multiple servers in the same place is still
  17. dangerous because he can get around the per-server bandwidth cap that is
  18. designed to prevent a single server from attracting too much of the overall
  19. traffic.
  20. Motivation:
  21. Since it is possible for an attacker to register an arbitrarily large
  22. number of Tor routers, it is possible for malicious parties to do this to
  23. as part of a traffic analysis attack.
  24. Security implications:
  25. This countermeasure will increase the number of IP addresses that an
  26. attacker must control in order to carry out traffic analysis.
  27. Specification:
  28. We propose that the directory servers check if an incoming Tor router IP
  29. address is already registered under another router. If this is the case,
  30. then prevent this router from joining the network.
  31. Compatibility:
  32. Upon inspection of a directory server, we found that the following IP
  33. addresses have more than one Tor router:
  34. Scruples 68.5.113.81 ip68-5-113-81.oc.oc.cox.net 443
  35. WiseUp 68.5.113.81 ip68-5-113-81.oc.oc.cox.net 9001
  36. Unnamed 62.1.196.71 pc01-megabyte-net-arkadiou.megabyte.gr 9001
  37. Unnamed 62.1.196.71 pc01-megabyte-net-arkadiou.megabyte.gr 9001
  38. Unnamed 62.1.196.71 pc01-megabyte-net-arkadiou.megabyte.gr 9001
  39. aurel 85.180.62.138 e180062138.adsl.alicedsl.de 9001
  40. sokrates 85.180.62.138 e180062138.adsl.alicedsl.de 9001
  41. moria1 18.244.0.188 moria.mit.edu 9001
  42. peacetime 18.244.0.188 moria.mit.edu 9100
  43. There may exist compatibility issues with this proposed fix. Reasons why
  44. more than one server would share an IP address include:
  45. * Testing. moria1, moria2, peacetime, and other morias all run on one
  46. computer at MIT, because that way we get testing. Moria1 and moria2 are
  47. run by Roger, and peacetime is run by Nick.
  48. * NAT. If there are several servers but they port-forward through the same
  49. IP address, ... we can hope that the operators coordinate with each
  50. other. Also, we should recognize that while they help the network in
  51. terms of increased capacity, they don't help as much as they could in
  52. terms of location diversity. But our approach so far has been to take
  53. what we can get.
  54. * People who have more than 1.5MB/s and want to help out more. For
  55. example, for a while Tonga was offering 10MB/s and its Tor server
  56. would only make use of a bit of it. So Roger suggested that he run
  57. two Tor servers, to use more.
  58. Alternatives:
  59. Roger suggested that instead of capping number of servers per IP to 1, we
  60. should cap total declared bandwidth per IP to some N, and total declared
  61. servers to some M. (He suggested N=5MB/s and M=5.)
  62. Roger also suggested that rather than not listing servers, we mark them as
  63. not Valid.