Re: Proposal: Network status entries need a new Unnamed flag

[Roger Dingledine <arma@xxxxxxx>]

On Thu, Oct 04, 2007 at 11:09:13AM -0400, Roger Dingledine wrote:
> The stopgap solution:
> 
>   tor26 should start accepting and listing the imposters, but it should
>   assign them a new flag: "Unnamed". This would produce three cases from
>   the client perspective:
> 
>   1) A unique Bob is listed as Named, and nobody lists that Bob as
>   Unnamed. Clients can refer to Bob by nickname and be confident.
> 
>   2) Every Bob is listed by some authority as Unnamed. Clients asking
>   for Bob should get a warning in the log and their request should fail
>   ("no such router").
> 
>   3) At least one Bob is not listed by any authorities as Unnamed, but
>   there is no unique Named Bob. In this case we do what we did before
>   (currently "warn but allow it").

I brainstormed with weasel for a while, and we came up with the
following better explanation, which slightly changes the behavior:

PART ONE:

i) a router gets the Named flag in the v3 networkstatus if
  a) it's the only router with that nickname that has the Named flag
     out of all the votes, and
  b) no vote lists it as Unnamed
else,
ii) a router gets the Unnamed flag if
  a) some vote lists a different router with that nickname as Named, or
  b) at least one vote lists it as Unnamed, or
  c) there are other routers with the same nickname that are Unnamed
else,
iii) the router neither gets a Named nor an Unnamed flag.

(This whole proposal is meant only for v3 dir flags; we shouldn't try
to backport it to the v2 dir world.)

PART TWO:

Then client behavior is:

a) If there's a Bob with a Named flag, pick that one.
else b) If the Bobs don't have the Unnamed flag (notice that they should
either all have it, or none), pick one of them and warn.
else c) They all have the Unnamed flag -- no router found.

PART THREE:

Another point to notice is if tor26 names Bob(1), doesn't know about
Bob(2), but moria lists Bob(2). Then Bob(2) doesn't get an Unnamed flag
even if it should (and Bob(1) is not around).

Right now, in v2 dirs, the case where an authority doesn't know about
a server but the other authorities do know is rare. That's because
authorities periodically ask for other networkstatuses and then fetch
descriptors that are missing.

With v3, if that window occurs at the wrong time, it is extended for the
entire period. We could solve this by making the voting more complex,
but that doesn't seem worth it.


I'll update the proposal in svn to reflect these changes.

--Roger