[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev