Opened 5 years ago

Closed 3 years ago

#14165 closed enhancement (implemented)

Tor needs a protocol versioning scheme

Reported by: TvdW Owned by: nickm
Priority: High Milestone: Tor: 0.2.9.x-final
Component: Core Tor/Tor Version: Tor: 0.2.7
Severity: Normal Keywords: tor-spec, needs-proposal, 027-triaged-1-in, 028-triaged, term-project-ideas, tor-03-unspecified-201612
Cc: Actual Points:
Parent ID: Points: medium
Reviewer: Sponsor:

Description

To support alternate OR implementations, it would be nice if it wasn't required for relays to announce themselves as "Tor <version> on <os>". The current dir-spec.txt mentions :

        The version of the Tor protocol that this relay 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."

This means that any implementation not listing "Tor .*" is required to implement the entire spec plus any feature that may ever be in the spec. Until we invent time travel this will be difficult to achieve.

The alternative is that any alternate Tor implementation needs to announce itself as "Tor".

Suggestions mentioned in #tor-dev :

  • Numerical protocol versions. Basically what we have now but without the "Tor" prefix, and published separately in the consensus. They're nice and compact but require all alternative implementations to implement the exact same set of features. Also doesn't deal with forward compatibility well if features are dropped in newer versions.
  • Capability lists. arma mentioned that this is already there as a hack (V2Dir flag, for example). It also takes a lot of space in the consensus, and they may grow a lot over time.

Child Tickets

TicketTypeStatusOwnerSummary
#13593defectclosedIs "Link 1 2" in the descriptors obsolete?

Change History (18)

comment:1 Changed 5 years ago by massar

They're nice and compact but require all alternative implementations to implement the exact same set of features

One compare this in same way to HTML4, HTML5 etc.

Also doesn't deal with forward compatibility well if features are dropped in newer versions.

Should work totally fine.

eg, lets say we have:

Protocol 5 = before ntor
Protocol 6 = ntor supported
Protocol 7 = ntor, but does not support anything before P6

If the client is at P5 then it can't use P6 nodes or higher. A P7 node won't be able to use a P6 node as it knows that itself does not have

Yes, one will have to be smart about picking features. But basically it will mean that the protocol number is more a 'feature package' number than an actual 'version number'.

Clients implementing higher versions will know what capabilities the older clients do or do not have and thus if they are compatible with them.
Newer clients won't know the newer editions (though we could backport the list of course, eg supports P5, but knows upto P8) for stable branches.

The above thus avoids the problem of having all these flags represented in the consensus ,and a small consensus is a good consensus.

comment:2 Changed 5 years ago by nickm

Keywords: needs-proposal added
Milestone: Tor: 0.2.???

One interesting issue here is that protocol versions come in several potential flavors. For example, to learn what you can do when connecting to a server, you can deal with its "link protocol version"... but if you are going to be extending a circuit through a server, you need to know what it supports for _that_, and if you're using hidden services served at a server, you're going to need a version for that too.

Once we walk far enough down this road, we'll find that these protocols aren't fully dependent: one can provide hidden services version X but relay protocol version Y. Decoupling these would make our protocol design much more challanging.

So perhaps the question is: how much of this can we do without harming anything else/

comment:3 Changed 5 years ago by nickm

Milestone: Tor: 0.2.???Tor: 0.2.7.x-final

These may be worth looking at for 0.2.7.

comment:4 Changed 5 years ago by nickm

Status: newassigned

comment:5 Changed 4 years ago by nickm

Keywords: 027-triaged-1-in added

Marking more tickets as triaged-in for 0.2.7

comment:6 Changed 4 years ago by isabela

Points: medium
Priority: normalmajor
Version: Tor: 0.2.7

comment:7 Changed 4 years ago by nickm

Milestone: Tor: 0.2.7.x-finalTor: 0.2.8.x-final

comment:8 Changed 4 years ago by nickm

Keywords: 028-triaged added

comment:9 Changed 4 years ago by nickm

Severity: Normal

I've written a design as proposal 264.

comment:10 Changed 4 years ago by nickm

Owner: set to nickm

comment:11 Changed 4 years ago by nickm

Milestone: Tor: 0.2.8.x-finalTor: 0.2.9.x-final

It is impossible that we will fix all 234 currently open 028 tickets before 028 releases. Time to move some out. This is my first pass through the accepted and assigned tickets in my name, looking for things to move to 0.2.9.

comment:12 Changed 4 years ago by nickm

Keywords: 6s194 added

comment:13 Changed 4 years ago by nickm

Keywords: term-project-ideas added; 6s194 removed

These tickets were tagged "6s194" as ideas for possible term projects for students in MIT subject 6.S194 spring 2016. I'm retagging with term-project-ideas, so that the students can use the 6s194 tag for tickets they're actually working on.

comment:14 Changed 3 years ago by nickm

SponsorU-can, since #15940 and #15941 are. But before we assume this is really U-can, make sure it fits into the U deliverables.

comment:15 Changed 3 years ago by isabela

Milestone: Tor: 0.2.9.x-finalTor: 0.2.???

tickets market to be removed from milestone 029

comment:16 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:17 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:18 Changed 3 years ago by nickm

Milestone: Tor: unspecifiedTor: 0.2.9.x-final
Resolution: implemented
Status: assignedclosed

I believe this was done with the implementation of proposal 264.

Note: See TracTickets for help on using tickets.