Hi, tl;dr: ideas to reduce the cw fraction that outdated relays make up of the tor network This email can be somewhat summarized by these three polls: https://twitter.com/nusenu_/status/909356846900801536 https://twitter.com/nusenu_/status/909359701908971520 https://twitter.com/nusenu_/status/909361044988071936 This email was sparked by a recent thread on twitter. As of 2017-09-16 more than 27% CW fraction of the tor network (>2500 relays) run a version of tor that is not recommended by tor's directory authorities [2]. More than 8% CW fraction (>1100 relays) even run tor branches that reached end-of-life and are no longer maintained. So if we agree that 27% CW fraction is to much, we could aim at reducing that fraction within the tor network. Here are a few ideas. 1) Auto-senescence ------------------- Alfie John suggested [1]: > automatic shutdown after its version is too old as used in zcash (the tor snap from Chad Miller does auto-shutdown already today), Moritz replied: > Tor already has this mechanism in the form of recommended/required versions in consensus I looked into that [3] but this is about tor _protocols_ (not versions) and is probably better suitable for avoiding compatibility issues within the tor network as multiple protocols coexist but you can not use that to remove specific tor versions because many versions share the same protocol set [4]. [1] https://twitter.com/alfiedotwtf/status/906310842672603136 [2] https://consensus-health.torproject.org/#recommendedversions [3] https://gitweb.torproject.org/torspec.git/tree/proposals/264-subprotocol-versions.txt#n133 [4] https://gist.github.com/nusenu/1302a04b26dac8e2ef838117f5f3fd2b So back to Alfie's suggestion. If tor should shutdown when 'too old' we have to know what 'too old' is. To come up with a timespan for 'too old' I looked into 61 currently used tor versions that are no longer recommended by dirauths. I measured the time between release date (as mentioned in the changelog) and the last consensus where the given version was listed as a recommended relay tor version [5], but these graphs show the "recommended" lifespan of releases before the new support policy [6] with shorter release cycles for "regular" releases has been introduced. [5] https://twitter.com/nusenu_/status/909355193434853376 [6] https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases So instead of of using this historical data we could simply follow the support policy. regular release: Auto-shutdown 18 months (=9+grace period) after the branch became stable. LTS relase: Auto-shutdown 4 years (=3+grace period) after the branch became stable. Dates would be hardcoded and do not require relays to contact dirauths. So old relays will not but any load on dir auths and fallbackdirs everytime they start. Lets simulate these timespans for tor 0.2.4 and 0.2.5 (and lets assume they are LTS releases) - tor 0.2.4 relays - if they had such a logic - would shutdown on 2017-12-11 (eol date was 2017-08-01) - tor 0.2.5 relays whould shutdown on 2018-10-24 (eol date is 2018-05-01) (not mentioning 0.2.6/7 here) - tor 0.2.9 relays would shutdown on 2020-12-19 (eol date is 2020-01-01) You could add a torrc option to allow operators (and package maintainers) to opt-out of auto-shutdown. There is no doubt that any mechanism to disable old relays _automatically_ and by _default_ would shrink the tor network (compared to not having that), so having a good answer for "What is an acceptable CW fraction for outdated tor versions on the network?" would be important, but since the reasons for removing versions from the recommended list are very different the recommended datapoint might not be enough. 2) consensus weight penalty for outdated relays ----------------------------------------------- Instead of (or additionally to) telling relays to not upload descriptors (complete removal) you could _automatically_ reduce/cap their consensus weight on the dirauth side if they run - unsupported branches (harsher penalty) - run not-recommended tor releases over a long time (less harsh penalty) (The distinction between unsupported branches and not-recommended is currently not available as consensus information.) This approach makes the recommended version list a more critical consensus item and as you know this is not always managed ideally: - new releases not added to the list in a timely manner -> operators upgrading timely get warnings - old releases not removed timely or before deb.torproject.org provided new releases 3) update tor dir auth code to reject old tor releases (not include them in consensus) ------------------------------------------------------------------------- As soon as a tor directory operator updates to a new release the dirauth would no longer vote for specific tor versions (I guess this is the current mostly manual approach). Another important aspect is the practical reality in current package repositories, but I simply assume they will follow LTS releases and are fine with the 4 years (3+grace period) lifespan. regards, nusenu -- https://mastodon.social/@nusenu https://twitter.com/nusenu_
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev