122-unnamed-flag.txt 5.9 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138
  1. Filename: 122-unnamed-flag.txt
  2. Title: Network status entries need a new Unnamed flag
  3. Version: $Revision$
  4. Last-Modified: $Date$
  5. Author: Roger Dingledine
  6. Created: 04-Oct-2007
  7. Status: Closed
  8. Implemented-In: 0.2.0.x
  9. 1. Overview:
  10. Tor's directory authorities can give certain servers a "Named" flag
  11. in the network-status entry, when they want to bind that nickname to
  12. that identity key. This allows clients to specify a nickname rather
  13. than an identity fingerprint and still be certain they're getting the
  14. "right" server. As dir-spec.txt describes it,
  15. Name X is bound to identity Y if at least one binding directory lists
  16. it, and no directory binds X to some other Y'.
  17. In practice, clients can refer to servers by nickname whether they are
  18. Named or not; if they refer to nicknames that aren't Named, a complaint
  19. shows up in the log asking them to use the identity key in the future
  20. --- but it still works.
  21. The problem? Imagine a Tor server with nickname Bob. Bob and his
  22. identity fingerprint are registered in tor26's approved-routers
  23. file, but none of the other authorities registered him. Imagine
  24. there are several other unregistered servers also with nickname Bob
  25. ("the imposters").
  26. While Bob is online, all is well: a) tor26 gives a Named flag to
  27. the real one, and refuses to list the other ones; and b) the other
  28. authorities list the imposters but don't give them a Named flag. Clients
  29. who have all the network-statuses can compute which one is the real Bob.
  30. But when the real Bob disappears and his descriptor expires? tor26
  31. continues to refuse to list any of the imposters, and the other
  32. authorities continue to list the imposters. Clients don't have any
  33. idea that there exists a Named Bob, so they can ask for server Bob and
  34. get one of the imposters. (A warning will also appear in their log,
  35. but so what.)
  36. 2. The stopgap solution:
  37. tor26 should start accepting and listing the imposters, but it should
  38. assign them a new flag: "Unnamed".
  39. This would produce three cases in terms of assigning flags in the consensus
  40. networkstatus:
  41. i) a router gets the Named flag in the v3 networkstatus if
  42. a) it's the only router with that nickname that has the Named flag
  43. out of all the votes, and
  44. b) no vote lists it as Unnamed
  45. else,
  46. ii) a router gets the Unnamed flag if
  47. a) some vote lists a different router with that nickname as Named, or
  48. b) at least one vote lists it as Unnamed, or
  49. c) there are other routers with the same nickname that are Unnamed
  50. else,
  51. iii) the router neither gets a Named nor an Unnamed flag.
  52. (This whole proposal is meant only for v3 dir flags; we shouldn't try
  53. to backport it to the v2 dir world.)
  54. Then client behavior is:
  55. a) If there's a Bob with a Named flag, pick that one.
  56. else b) If the Bobs don't have the Unnamed flag (notice that they should
  57. either all have it, or none), pick one of them and warn.
  58. else c) They all have the Unnamed flag -- no router found.
  59. 3. Problems not solved by this stopgap:
  60. 3.1. Naming authorities can go offline.
  61. If tor26 is the only authority that provides a binding for Bob, when
  62. tor26 goes offline we're back in our previous situation -- the imposters
  63. can be referenced with a mere ignorable warning in the client's log.
  64. If some other authority Names a different Bob, and tor26 goes offline,
  65. then that other Bob becomes the unique Named Bob.
  66. So be it. We should try to solve these one day, but there's no clear way
  67. to do it that doesn't destroy usability in other ways, and if we want
  68. to get the Unnamed flag into v3 network statuses we should add it soon.
  69. 3.2. V3 dir spec magnifies brief discrepancies.
  70. Another point to notice is if tor26 names Bob(1), doesn't know about
  71. Bob(2), but moria lists Bob(2). Then Bob(2) doesn't get an Unnamed flag
  72. even if it should (and Bob(1) is not around).
  73. Right now, in v2 dirs, the case where an authority doesn't know about
  74. a server but the other authorities do know is rare. That's because
  75. authorities periodically ask for other networkstatuses and then fetch
  76. descriptors that are missing.
  77. With v3, if that window occurs at the wrong time, it is extended for the
  78. entire period. We could solve this by making the voting more complex,
  79. but that doesn't seem worth it.
  80. [3.3. Tor26 is only one tor26.
  81. We need more naming authorities, possibly with some kind of auto-naming
  82. feature. This is out-of-scope for this proposal -NM]
  83. 4. Changes to the v2 directory
  84. Previously, v2 authorities that had a binding for a server named Bob did
  85. not list any other server named Bob. This will change too:
  86. Version 2 authorities will start listing all routers they know about,
  87. whether they conflict with a name-binding or not: Servers for which
  88. this authority has a binding will continue to be marked Named,
  89. additionally all other servers of that nickname will be listed without the
  90. Named flag (i.e. there will be no Unnamed flag in v2 status documents).
  91. Clients already should handle having a named Bob alongside unnamed
  92. Bobs correctly, and having the unnamed Bobs in the status file even
  93. without the named server is no worse than the current status quo where
  94. clients learn about those servers from other authorities.
  95. The benefit of this is that an authority's opinion on a server like
  96. Guard, Stable, Fast etc. can now be learned by clients even if that
  97. specific authority has reserved that server's name for somebody else.
  98. 5. Other benefits:
  99. This new flag will allow people to operate servers that happen to have
  100. the same nickname as somebody who registered their server two years ago
  101. and left soon after. Right now there are dozens of nicknames that are
  102. registered on all three binding directory authorities, yet haven't been
  103. running for years. While it's bad that these nicknames are effectively
  104. blacklisted from the network, the really bad part is that this logic
  105. is really unintuitive to prospective new server operators.