Opened 5 years ago

Closed 3 years ago

Last modified 3 years ago

#15935 closed enhancement (implemented)

Implement an advisory-only request to stop for old clients

Reported by: teor Owned by:
Priority: Medium Milestone: Tor: 0.2.9.x-final
Component: Core Tor/Tor Version: Tor: unspecified
Severity: Normal Keywords: SponsorS, needs-proposal, 028-triage, SponsorU-deferred TorCoreTeam201609
Cc: nickm Actual Points:
Parent ID: #15940 Points: medium
Reviewer: Sponsor:

Description (last modified by teor)

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.
  1. Every request in tor should be random-exponential-backoff, which would resolve repeated-connection overloading issues in general. (split to another ticket #15943)
  2. 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

Child Tickets

Change History (13)

comment:1 Changed 5 years ago by teor

This is probably multiple tickets, once we decide to go forward with each option.

comment:2 Changed 5 years ago by teor

Parent ID: #15228#15233

Fix parent

comment:3 Changed 5 years ago by nickm

Keywords: needs-proposal added

Some random thoughts, some of which may be good:

I know Roger has been very leery of anything like a version-based "kill switch" in the past (possibly out of a worry that it would make people worried that we were going to use it for evil). But that doesn't mean that the idea is hopeless.

We used to have something a little like this, by the way. That's how "recommended versions" used to work, I think.

I like the random exponential backoff idea; it should probably be a separate ticket though.

Perhaps this kind of thing should always be advisory. For example, there could be a way to disable it at compile-time, or in the configuration. That way it would be explicit that this is meant as a way to explicitly turn off ancient zombies, not actively used Tors?

Maybe there should be a warning phase before final cutoff for each version?

One issue to consider here is that this is a matter for long-term planning. Even if we put this into 0.2.7 today, we will still need a plan to get all existing clients off the network someday.

Wrt modified or independent clients: that's a separate question. In my experience, botnet jerks don't feel like doing much more work then needed, and don't feel like kludging their Tor binaries very hard.

comment:4 Changed 5 years ago by teor

Description: modified (diff)
Parent ID: #15233#15940
Summary: Implement a kill switch / exponential backoff for old clientsImplement an advisory-only request to stop for old clients

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

comment:5 Changed 5 years ago by teor

Type: defectenhancement

comment:6 Changed 4 years ago by nickm

Milestone: Tor: 0.2.7.x-finalTor: 0.2.8.x-final

comment:7 Changed 4 years ago by nickm

Keywords: 028-triage added

comment:8 Changed 4 years ago by nickm

Keywords: SponsorU removed
Sponsor: SponsorU

Bulk-replace SponsorU keyword with SponsorU field.

comment:9 Changed 4 years ago by nickm

Points: medium

comment:10 Changed 4 years ago by nickm

Milestone: Tor: 0.2.8.x-finalTor: 0.2.???

It is impossible that we will fix all 277 currently open 028 tickets before 028 releases. Time to move some out. This is my first pass through the "new" and "reopened" tickets, looking for things to move to ???.

comment:11 Changed 4 years ago by isabela

Sponsor: SponsorUSponsorU-can

comment:12 Changed 4 years ago by nickm

Keywords: SponsorU-deferred added
Sponsor: SponsorU-can

Remove the SponsorU status from these items, which we already decided to defer from 0.2.9. add the SponsorU-deferred tag instead in case we ever want to remember which ones these were.

comment:13 Changed 3 years ago by nickm

Keywords: TorCoreTeam201609 added
Milestone: Tor: 0.2.???Tor: 0.2.9.x-final
Resolution: implemented
Severity: Normal
Status: newclosed

This falls out as a consequence of proposals 264 and 272, both implemented in 0.2.9

(Edited to fix proposal number)

Last edited 3 years ago by nickm (previous) (diff)
Note: See TracTickets for help on using tickets.