[tor-dev] Much-revised draft, RFC: removing current obsolete clients from the network

[Tim Wilson-Brown - teor]

> On 8 Jan 2016, at 04:12, Nick Mathewson <nickm at torproject.org> wrote:
> ...
> 
> 2. Some ideas that don't work.
> 
> ...
> 
> 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
>        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.)

I wonder how this affects existing Tor2web clients (as they make
one-hop client intro and rendezvous connections), and the
upcoming rendezvous single onion services, which make one-hop
intro and rendezvous server connections. (I also wonder about
single onion service extends, but I think they're ok.)

>   This would still result in clients not having directories, however,
>   and retrying once an hours.
> 
> 3. 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.]

This might not work for clients that are always on:

Changing authority ports would only affect clients that have yet to
bootstrap, or clients that are off for long enough for their consensus
to expire. Otherwise, they can continue to contact directory mirrors in
their current consensus to obtain their next consensus.

For similar reasons, changing ports only works for tor versions
*without* default Fallback Directory mirrors, which likely means 0.2.7
and earlier.

This might have unintended consequences:

Some clients have FascistFirewall set, which restricts the initial
directory connection (to the authorities) to port 80. If we switched
some authorities away from DirPort 80, we'd need to switch a similar
number to DirPort 80. (Or make sure a sufficient number of default
Fallback Directory mirrors are on DirPort 80 from 0.2.8 onwards.)

(FascistFirewall also restricts OR connections to port 443, but by the
time a client makes an OR connection, it has the full consensus.)

> 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.

If a relay fails to support a client's protocol, does the client continue to
contact relays until it is successful?

If so, does this place extra load on (new) relays as the proportion of new
relays increases? (Or extra load on old relays which still support the old
protocols?)

> 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
>   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.]

Are we aiming to do this for 0.2.8?

I think it would be a good idea, as adding default fallback directories
makes it harder to implement some authority-only strategies for
shutting down old clients.

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160108/71e01493/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160108/71e01493/attachment-0001.sig>