Proposal 105 (handshake revision) needs more thought

[Roger Dingledine]

On Sun, Mar 11, 2007 at 11:51:59PM -0400, Nick Mathewson wrote:
> >    We should keep listing a "Tor" version on that line when listing
> >    old servers that only speak v1 of the link protocol.
> 
> Actually, no:  dir-spec.txt says that
> 
>     "v" -- The version of the Tor protocol that this server is
>            running.  If the value begins with "Tor" SP, the rest of
>            the string is a Tor version number, and the protocol is
>            "The Tor protocol as supported by the given version of
>            Tor."  Otherwise, if the value begins with some other
>            string, Tor has upgraded to a more sophisticated protocol
>            versioning system, and the protocol is "a version of the
>            Tor protocol more recent than any we recognize."
> 
> In other words, if Tor 0.1.2.10-rc sees a "v" line of the form
> "Link 1 Circuit 2", it will assume that it is looking at a router more
> recent than any version it knows about.  This is exactly what we'd
> want it to do, so it's safe to drop the Tor version.

I guess I'm not being clear -- even though I spent quite a while rewriting
that sentence to make sure to be clear. :) I was talking about what to
put on the networkstatus line when listing a server running 0.1.2.10-rc,
and what to put when listing a server running 0.1.0.18. I guess we could
put in a "link 1 circuit 1" addendum if we have no other guesses? Or
just leave out link and circuit versions and have whoever's reading it
know that we mean version 1 if we don't list any?

But in any case we should keep including the "Tor" version, since current
clients use it and care about it.

> >     But for newer
> >    servers, should we drop the Tor version? How does that reconcile with
> >    our one data point, which is the begin_dir example, where we need
> >    to show if we've heard of begin_dir, but it doesn't necessitate a
> >    "back incompatible" version bump?
> > 
> >    Should we just add more arguments to that same line (ending up with
> >    "Tor 0.2.0.6-alpha Link 5 Circuit 6") or do we want multiple "v" lines?
> >    I don't see any strong arguments either way.
> 
> I'll muddy things a bit by suggesting as another option that we could
> add minor numbers to indicate ignoreable features.
> 
> But all in all, I think I like your "Tor 0.2.0.6-alpha Link 5 Circuit
> 6" option best.  We've used platform numbers for another purpose, too:
> bug avoidance.  Sometimes we'll notice, "Hey, Tor version 0.x.y.z has
> a major bug with keeping circuits up, let's not use it for FOOBAR
> cells" and we'll want to know what version of Tor we're looking at
> when we pick our paths.

I'm happy with this. But we should add in a new Motivation section
that I just realized we're missing:

Motivation: supporting other Tor implementations than just Tor

   We'd like to encourage the existence of more Tor server implementations
   than just mainline. And relying on putting Tor versions in the
   descriptors, and then parsing them internally to mean "has this
   functionality, doesn't have that functionality", may not be as
   flexible as we want once we have other implementations with other
   permutations of bugs and features.

Even adding minor versions doesn't seem like it would totally solve the
problem, since it's hard to put a linear order on a bitvector. Hm.

Maybe the other implementations would list link and circuit versions
like the spec says, and they would list their own string for their
implementation (like we use "Tor"), and the implementors of all the
popular versions need to coordinate to say "Hey, if you see version 1.0
of Gate, I screwed up my begindir implementation, so either a) I should
revert my supported versions number, or b) we should put out bugfixes
for all our clients that avoid sending it a begindir." I guess it's
hard to predict how we'll want to handle other server implementations
when we're generalizing from zero examples.

> >    If servers support multiple link versions (e.g. they would include
> >    several in their VERSIONS cell), do we list all of them here, or
> >    just the latest, or ...? My guess is we should list just the latest,
> >    at least until the situation is common where that isn't useful to
> >    most clients.
> 
> I think the whole list should get included.  This isn't as exorbitant
> as it sounds: remember that zlib compresses common strings pretty
> well, and the list of supported protocol versions will be the same for
> all servers running the same version of Tor.

True, assuming there's only one Tor server implementation.

But I suspect that networkstatus bloat is not going to kill us even if
we have to mix and match version numbers. Exit policies are cheap after
all, and this seems like a similar field.

--Roger