Proposal: Network status entries need a new Unnamed flag

[Nick Mathewson]

On Tue, Oct 09, 2007 at 06:44:19PM -0400, Roger Dingledine wrote:
> 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 makes a lot more sense to me.

> (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.

Also agreed.

> 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.

Okay.

Another thing to consider is that this means we need vote protocol
migration.  I'll spec that.  Do you think it needs a proposal?  The
basic problem is that, since Unnamed and Named are set differently
from other flags, existing authorities won't generate them properly,
and so old authorities and authorities that implement proposal 122
will generate different consensuses, and so no consensus will get all
the signatures.  The solution is for each authority to list in its
vote a list of "voting protocols" that it knows how to generate
consensuses with.  When generating the consensus, the authorities use
the highest-numbered protocol listed by at least 2/3 of the votes.

We could just write the code and upgrade the 2 current v3 authorities
simultaneously.  But IMO it's a good idea to get this solved now,
because if we need to add any new voting rules once the whole v3
directory system is fully deployed, we'll be in rather a bit of hurt.

yrs,
-- 
Nick Mathewson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 652 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20071009/c53011f5/attachment.pgp>