07.01.2016, 18:12 Nick Mathewson:
Mostly spelling corrections and one question at the bottom.
I have not enough insight to comment on the proposed ideas.
[...]
One goal of this proposal is to ensure that future clients to not
*do not*
become zombies at all; and that ancient clients become slow zombies at worst.
- Some ideas that don't work.
2.1. Dropping connections based on link protocols.
Tor versions before before 0.2.3.6-alpha use a renegotiation-based handshake instead of our current handshake. We could detect these handshakes and close the connection at the relay side if the client attempts to renegotiate.
I've tested these changes on versions maint-0.2.0 through maint-0.2.2. They result in zombies with the following behavior:
The client contact each authority it knows about, attempting to
An s is missing to make 'contacts'.
make a one-hop directory connection. It fails, detects a failure, then reconnects more and more slowly ... but one hour later, it resets its connection schedule and starts again.In the steady state this appears to result in about two connections per client per authority per hour. That is probably too many.
(Most authorities would be affected: of the authorities that existed in 0.2.2, gabelmoo has moved and turtles has shut down. The authorities Faravahar and longclaw are new. The authorities moria1, tor26, dizum, dannenberg, urras, maatuska and maatuska would all get hit here.)
maatuska is listed twice.
(We could simply remove the renegotiation-detection code entirely, and reply to all connections with an immediate VERSIONS cell. The behavior would probably be the same, though.)
If we throttled connections rather than closing them, we'd only get one connnection per authority per hour, but authorities would have to
connection
keep open a potentially huge number of sockets.
2.2. Blocking circuit creation under certain circumstances
In tor 0.2.5.1-alpha, we began ignoring the UseNTorHandshake option, and always preferring the ntor handshake where available.
Unfortunately, we can't simply drop all TAP handshakes, since clients and relays can still use them in the hidden service protocol. But we could detect these versions by:
Looking for use of a TAP handshake from an IP not associated with with any known relay, or on a connection where the client
'with' is there twice.
did not authenticate. (This could be from a bridge, but clients don't build circuits that go to an IntroPoint or RendPoint directly after a bridge.)This would still result in clients not having directories, however, and retrying once an hours.
- Ideas that might work
3.1. Move all authorities to new ports
We could have each authority known to older clients start listening for connections at a new port P. We'd forward the old port to the new port. Once sufficiently many clients were using the new ports, we could disable the forwarding.
This would result in the old clients turning into zombies as above, but they would only be scrabbling at nonexistent ports, causing less load on the authorities.
[This proposal would probably be easiest to implement.]
3.2. Start disabling old link protocols on relays
We could have new relays start dropping support for the old link protocols, while maintaining support on the authorities and older relays.
The result here would be a degradation of older client performance over time. They'd still behave zombieishly if the authorities dropped support, however.
3.3. Changing the consensus format.
We could allow 'f' (short for "flag") as a synonym for 's' 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 'f' lines instead of 'f' lines. This will create a consensus which
'f' lines instead of 's' lines.
older clients and relays parse as having all nodes down, which will make them not connect to the network at all.
We could similarly replace "r" with "n", or replace Running with Online, or so on.
In doing this, we could also rename fresh-until and valid-until, so that new clients would have the real expiration date, and old clients would see "this consensus never expires". This would prevent them from downloading new consensuses.
[This proposal would result in the quietest shutdown.]
What would be repeatable in 5 years? I imagine that you would like to get rid of old clients again and again.
Regards, Sebastian G.