Re: [tor-dev] Draft proposal -- no number yet: How to safely drop support for old clients.

Hi,

comments inline.

On 09/30/2015 12:01 PM, Nick Mathewson wrote:

Early versions of Tor checked the recommended-versions field in the
directory to see whether they should keep running.  If they didn't
recognize

you did the thing where you

To override this, a Tor instance may include a configuration option,
"IgnoreDisabledVersion VERSION".  It is an error to set this option when
*not* running with a disabled version.

This does not work unless the client already has a consensus that they have parsed so they know they're running a disabled version. I appreciate the sentiment here (don't allow people to blindly set the option), but I'm not sure it's worth it.

3.4. Disabling all versions that don't support this proposal

We should allow 'n' (short for "node") as a synonym for 'r' in
consensus documents.  Later, if we want to disable all Tor versions
before today, we can change the consensus algorithm so that the
consensus (or perhaps only the microdesc consensus) is spelled with
'n' lines instead of 'r' lines.  This will create a consensus which
older clients and relays parse as having no nodes.

Hrm. I'm not a fan of this, it seems like a pretty sad hack. I don't have an alternative ready unfortunately.

3.5. In the event of overzealous retries

We need to be sure that client running versions from 0.2.1 through
0.2.6 respond gracefully to the responses above.  In particular, we
need to make sure that they don't continually retry the connections
that fail in these ways: that would put a lot of extra load on the
network.

Above, I recommend stalling connections rather than just closing
them.  This may prevent the risk of retries, at the risk of using
additional relay resources.

Stalling is much less preferable than closing to me. We should actually do the analysis and do it well to know if we actually have to do it, imo.

Cheers Sebastian