206-directory-sources.txt 3.3 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990
  1. Filename: 206-directory-sources.txt
  2. Title: Preconfigured directory sources for bootstrapping
  3. Author: Nick Mathewson
  4. Created: 10-Oct-2012
  5. Status: Closed
  6. Implemented-In: 0.2.4.7-alpha
  7. Motivation and History:
  8. We've long wanted a way for clients to do their initial
  9. bootstrapping not from the directory authorities, but from some
  10. other set of nodes expected to probably be up when future clients are
  11. starting.
  12. We tried to solve this a while ago by adding a feature where we could
  13. ship a 'fallback' networkstatus file -- one that would get parsed
  14. when we had no current networkstatus file, and which we would use to
  15. learn about possible directory sources. But we couldn't actually use
  16. it, since it turns out that a randomly chosen list of directory
  17. caches from 4-5 months ago is a terrible place to go when
  18. bootstrapping.
  19. Then for a while we considered an "Extra-Stable" flag so that clients
  20. could use only nodes with a long history of existence from these
  21. fallback networkstatus files. We never built it, though.
  22. Instead, we can do this so much more simply. If we want to ship Tor
  23. with a list of initial locations to go for directory information, why
  24. not just do so?
  25. Proposal:
  26. In the same way that Tor currently ships with a list of directory
  27. authorities, Tor should also ship with a list of directory sources --
  28. places to go for an initial consensus if you don't have a somewhat
  29. recent one.
  30. These need to include an address for the cache's ORPort, and its
  31. identity key. Additionally, they should include a selection weight.
  32. They can be configured with a torrc option, just like directory
  33. authorities are now.
  34. Whenever Tor is starting without a consensus, if it would currently
  35. ask a directory authority for a consensus, it should instead ask one
  36. of these preconfigured directory sources.
  37. I have code for this (see git branch fallback_dirsource_v2) in my
  38. public repository.
  39. When we deploy this, we can (and should) rip out the Fallback
  40. Networkstatus File logic.
  41. How to find nodes to make into directory sources:
  42. We could take any of three approaches for selecting these initial
  43. directory sources.
  44. First, we could try to vet them a little, with a light variant of the
  45. process we use for authorities. We'd want to look for nodes where we knew
  46. the operators, verify that they were okay with keeping the same IP for a
  47. very long time, and so forth.
  48. Second, we could try to pick nodes for listing with each Tor release
  49. based entirely on how long those nodes have been up. Anything that's
  50. been a high-reliability directory for a long time on the same IP
  51. (like, say, a year) could be a good choice.
  52. Third, we could blend the approach and start by looking for
  53. up-for-a-long-time nodes, and then also ask the operators whether
  54. their nodes are likely to stay running for a long time.
  55. I think the third model is best.
  56. Some notes on security:
  57. Directory source nodes have an opportunity to learn about new users
  58. connecting to the network for the first time. Once we have directory
  59. guards, that's going to be a fairly uncommon ability. We should be
  60. careful in any directory guard design to make sure that we don't fall
  61. back to the directory sources any more than we need to. See proposal 207.