104-short-descriptors.txt 6.2 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160
  1. Filename: 104-short-descriptors.txt
  2. Title: Long and Short Router Descriptors
  3. Version: $Revision$
  4. Last-Modified: $Date$
  5. Author: Nick Mathewson
  6. Created:
  7. Status: Open
  8. Overview:
  9. This document proposes moving unused-by-clients information from regular
  10. router descriptors into a new "extra info" router descriptor.
  11. Proposal:
  12. Some of the costliest fields in the current directory protocol are ones
  13. that no client actually uses. In particular, the "read-history" and
  14. "write-history" fields are used only by the authorities for monitoring the
  15. status of the network. If we took them out, the size of a compressed list
  16. of all the routers would fall by about 60%. (No other disposable field
  17. would save much more than 2%.)
  18. We propose to remove these fields from descriptors, and and have them
  19. uploaded as a part of a separate signed "extra info" to the authorities.
  20. This document will be signed. A hash of this document will be included in
  21. the regular descriptors.
  22. (We considered another design, where routers would generate and upload a
  23. short-form and a long-form descriptor. Only the short-form descriptor would
  24. ever be used by anybody for routing. The long-form descriptor would be
  25. used only for analytics and other tools. We decided against this because
  26. well-behaved tools would need to download short-form descriptors too (as
  27. these would be the only ones indexed), and hence get redundant info. Badly
  28. behaved tools would download only long-form descriptors, and expose
  29. themselves to partitioning attacks and that like.)
  30. Other disposable fields:
  31. Clients don't need these fields, but removing them doesn't help bandwidth
  32. enough to be worthwhile.
  33. contact (save about 1%)
  34. fingerprint (save about 3%)
  35. We could represent these fields more succinctly, but removing them would
  36. only save 1%. (!)
  37. reject
  38. accept
  39. (Apparently, exit polices are highly compressible.)
  40. [Does size-on-disk matter to anybody? Some clients and servers don't
  41. have much disk, or have really slow disk (e.g. USB). And we don't
  42. store caches compressed right now. -RD]
  43. Specification:
  44. 1. Extra Info Format.
  45. A "extra info" descriptor contains the following fields:
  46. "extra-info" Nickname IP FINGERPRINT
  47. Identifies what router this is an extra info descriptor for.
  48. FINGERPRINT is encoded in hex, with no spaces.
  49. "published"
  50. As currently documented in dir-spec.txt
  51. "read-history"
  52. "write-history"
  53. As currently documented in dir-spec.txt
  54. "router-signature" NL Signature NL
  55. A signature of the PKCS1-padded hash of the entire extra info
  56. document, taken from the beginning of the "extra-info" line, through
  57. the newline after the "router-signature" line. An extra info
  58. document is not valid unless the signature is performed with the
  59. identity key whose digest matches FINGERPRINT.
  60. The "extra-info" field is required and MUST appear first. The
  61. router-signature field is required and MUST appear last. All others are
  62. optional. As for other documents, unrecognized fields must be ignored.
  63. 2. Existing formats
  64. Implementations that use "read-history" and "write-history" SHOULD
  65. accept router descriptors that contain them. (Prior to 0.2.0.x, this
  66. information was encoded in ordinary router descriptors.)
  67. Add these field to router descriptors:
  68. "extra-info-digest" DIGEST
  69. DIGEST is a hex-encoded digest of the router's extra-info document,
  70. as signed in the router's extra-info. (If this field is absent,
  71. no extra-info-digest exists.)
  72. "caches-extra-info"
  73. Present if this router is a directory cache that provides
  74. extra-info documents.
  75. 3. New communications rules
  76. Clients SHOULD generate and upload an extra-info document after each
  77. descriptor they generate and upload; no more, no less. Clients MUST
  78. upload the new descriptor before they upload the new extra-info.
  79. Authorities receiving an extra-info documents SHOULD verify all of the
  80. following:
  81. * They have a router descriptor for some server with a matching
  82. nickname, IP, and identity fingerprint.
  83. * That server's identity key has been used to sign the extra-info
  84. document.
  85. * The extra-info-digest field in the router descriptor matches
  86. the digest of the extra-info document.
  87. Authorities SHOULD try to fetch extra-info documents from one another if
  88. they do not have one matching the digest declared in a router
  89. descriptor.
  90. Caches that are running locally with a tool that needs to use extra-info
  91. documents MAY download and store extra-info documents. They should do
  92. so when they notice that the recommended descriptor has an
  93. extra-info-digest not matching any extra-info document they currently
  94. have. (Caches not running on a host that needs to use extra-info
  95. documents SHOULD NOT download or cache them.)
  96. 4. New URLs
  97. http://<hostname>/tor/extra/d/...
  98. http://<hostname>/tor/extra/fp/...
  99. http://<hostname>/tor/extra/all.z
  100. (As for /tor/server/ URLs: supports fetching extra-info documents
  101. by their digest, by the fingerprint of their servers, or all at
  102. once. Only directory authorities are guaranteed to support these
  103. URLs.)
  104. http://<hostname>/tor/extra/authority.z
  105. (The extra-info document for this router.)
  106. Extra-info documents are uploaded to the same URLs as regular
  107. router descriptors.
  108. Migration:
  109. For extra info approach:
  110. * First:
  111. * Authorities should accept extra info, and support downloading it.
  112. * Routers should upload bandwidth info once authorities accept it.
  113. * Caches should support an option to download and cache it, once
  114. authorities serve it.
  115. * Tools should be updated to use locally cached information.
  116. These tools include:
  117. lefkada's exit.py script.
  118. tor26's noreply script and general directory cache.
  119. https://nighteffect.us/tns/ for its graphs
  120. and check with or-talk for the rest, once it's time.
  121. * Once tools that want bandwidth info support fetching it:
  122. * Have routers stop including bandwidth info in their router
  123. descriptors.