Hello,
I am digging this out to make some kind of announcement
I am actually working over those problems, and I am developing a new approach
to solve these (still early research state, but with really encouraging
results). Basically, I've developing a software architecture which will let you
deploy major features, hotfixes or rollbacks in a snap of fingers (to clients
and relays), without needing any relay to restart and without perturbing their
ongoing connections. The good news is that, so far, the measured performance
impact of this techno is somewhat light.
I guess it might sound a bit mystical. So if you're interested to find out
more, I will be presenting my ongoing research at HotPETs in Stockolm
(https://petsymposium.org/2019/program.php#hotpets_program), the talk is
"Flexible Anonymous Network".
Oh, and there is even more promise in this technology than just addressing the
'forward compatibility in the design and backward compatibility in the
implementation' headache :) But enough of teasing, see you in Stockolm!
Best regards,
Florentin
On 5/23/19 8:49 PM, David Goulet wrote:
On 22 May (18:57:06), Mike Perry wrote:
Nick Mathewson:
Filename: 303-protover-removal-policy.txt
Title: When and how to remove support for protocol versions
Author: Nick Mathewson
Created: 21 May 2019
Status: Draft
1. Background
With proposal 264, added support for "subprotocol versions" -- a
means to declare which features are required for participation in the
Tor network. We also created a mechanism (refined later in proposal
297) for telling Tor clients and relays that they cannot participate
effectively in the Tor network, and they need to shut down.
In this document, we describe a policy according to which these
decisions should be made in practice.
2. Recommending features (for clients and relays)
A subprotocol version SHOULD become recommended soon after all
release series that did not provide it become unsupported (within a
month or so).
For example, the current oldest LTS release series is 0.2.9; when it
becomes unsupported in 2020, the oldest supported release series will
be 0.3.5. Suppose that 0.2.9 supports a subprotocol Cupcake=1, and
that all stable 0.3.5.x versions support Cupcake=1-3. Around one
month after the end of 0.2.9 support, Cupcake=3 should become a
_recommended_ protocol for clients and relays.
Additionally, a feature can become _recommended_ because of security
reasons. If we believe that it is a terrible idea to run an old
protocol, we can make it _recommended_ for relays or clients or both.
We should not do this lightly, since it will be annoying.
To be clear, "_recommended_" and "_required_" terms here are from
Proposal #264, Section 4, right? Aka the consensus lines?
These only affect WARN-vs-exit behavior by clients and relays that lack
support, right? Clients and relays will still *negotiate* and use
protocol versions that they both have, even if they are not listed as
either recommended or required?
Afaiu, you can only negotiate what you know which is the protover list you
support (the one advertised by relays).
For instance, if "Cupcake=1-3" is what you support as a client but the
recommended is "Cupcake=2-3", you can still do "1" but you will be warned.
If _required_, let say "Cupcake=3" but the client is "Cupcake=1-2", then the
client does _not_ join the network. If _required_ is "Cupcake=1-3" for both
the relay and client, then yes they can use version "1" instead of "3" if I'm
not mistaken else "Cupcake=3" should be used.
Are there cases where they don't/won't negotiate to use a new protover
field, such as for anonymity fragmentation reasons? How do we handle
those?
As an example for the prop289 (authenticated SENDMEs), we handle that with a
consensus parameters that flip knobs at once to avoid partitioning problem as
much as possible. _And_ then the protover is changed changed into the
_recommended_ or _required_ field depending on where we are.
(I am trying to gauge the impact of this proposal on our ability to roll
out new features that clients can use right away vs ensure that old
clients and relays can still work. It seems to focus on the latter,
and I want to get a handle on at what expense).
3. Requiring features (for relays)
We regularly update the directory authorities to require relays to
run certain versions of Tor or later. We generally do this after a
short outreach campaign to get as many relays as possible to upgrade.
We MAY make a feature required for relays one month after every
version without it is obsolete and unsupported, though it is better
to wait three months if possible.
We SHOULD make a feature required for relays within 12 months after
every version without it is obsolete and unsupported.
As a cultural signaling thing, I think it is better to say to relay
operators, "keep your relay's operating system and its Tor
