[tor-bugs] #15935 [Tor]: Implement an advisory-only request to stop for old clients (was: Implement a kill switch / exponential backoff for old clients)

Tor Bug Tracker & Wiki blackhole at torproject.org
Wed May 6 19:26:30 UTC 2015


#15935: Implement an advisory-only request to stop for old clients
------------------------+-----------------------------------------------
     Reporter:  teor    |      Owner:
         Type:  defect  |     Status:  new
     Priority:  normal  |  Milestone:  Tor: 0.2.7.x-final
    Component:  Tor     |    Version:  Tor: unspecified
   Resolution:          |   Keywords:  SponsorS, SponsorU needs-proposal
Actual Points:          |  Parent ID:  #15940
       Points:          |
------------------------+-----------------------------------------------
Changes (by teor):

 * parent:  #15233 => #15940


Old description:

> In #15233, we want to kill off 0.2.2 and 0.2.3 clients, but we want to
> make sure they won't increase their request rate to the directory
> authorities if we stop answering them.
>
> We face this issue every time we kill off old client versions.
>
> #15228 will change the scope of this issue, as it may affect the fallback
> directories, as well as the directory authorities.
>
> We don't want to have many of our best directories overloaded with rapid
> requests from obsolete clients.
>
> I suggest, at a minimum:
> 1. A kill switch for old client versions should be part of a valid,
> signed consensus:
> * a permitted-but-not-recommended client versions list, and every version
> not on that list is banned? The problem with this is that new dev
> versions and custom versions would be banned.
> * an obsoleted client version list, every version on that list banned? It
> would be a long list, and custom versions wouldn't be banned.
> 2. Every request in tor should be random-exponential-backoff, which would
> resolve repeated-connection overloading issues in general.
> 3. How do we deal with botnets that don't use the full tor code? They
> need not obey the consensus, or use exponential backoff.

New description:

 In #15233, we want to kill off 0.2.2 and 0.2.3 clients, but we want to
 make sure they won't increase their request rate to the directory
 authorities if we stop answering them.

 We face this issue every time we kill off old client versions.

 #15228 will change the scope of this issue, as it may affect the fallback
 directories, as well as the directory authorities.

 We don't want to have many of our best directories overloaded with rapid
 requests from obsolete clients.

 I suggest, at a minimum:
 1. A advisory request to stop for old clients (which can be disabled on
 compilation or configuration) as part of a valid, signed consensus:
 * a permitted-but-not-recommended client versions list, and every version
 not on that list should stop? The problem with this is that new dev
 versions and custom versions would stop.
 * an obsoleted client version list, every version on that list should
 stop? It would be a long list, and custom versions wouldn't be asked to
 stop.
 2. Every request in tor should be random-exponential-backoff, which would
 resolve repeated-connection overloading issues in general. (split to
 another ticket #15943)
 3. How do we deal with botnets that don't use the full tor code? They need
 not obey the consensus, or use exponential backoff.

 Edit: split #15943, clarify "kill switch" language

--

Comment:

 I'll keep this ticket focused on an advisory request to stop, which can be
 disabled on compilation or configuration.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/15935#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list