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

["Sebastian G. <bastik.tor>" <bastik.tor@xxxxxxxxxxxxxx>]

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