mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-25 04:43:31 +01:00
84 lines
3.0 KiB
Plaintext
84 lines
3.0 KiB
Plaintext
Filename: 120-suicide-descriptors.txt
|
|
Title: Suicide descriptors when Tor servers stop
|
|
Version: $Revision$
|
|
Last-Modified: $Date$
|
|
Author: Roger Dingledine
|
|
Created: 15-Aug-2007
|
|
Status: Open
|
|
|
|
Overview:
|
|
|
|
Tor servers should publish a last descriptor whenever they shut down,
|
|
to let others know that they are no longer offering service.
|
|
|
|
The Problem:
|
|
|
|
The main reason for this is in reaction to Internet services that want
|
|
to treat connections from the Tor network differently. Right now,
|
|
if a user experiments with turning on the "relay" functionality, he
|
|
is punished by being locked out of some websites, some IRC networks,
|
|
etc --- and this lockout persists for several days even after he turns
|
|
the server off.
|
|
|
|
Design:
|
|
|
|
During the "slow shutdown" period if exiting, or shortly after the
|
|
user sets his ORPort back to 0 if not exiting, Tor should publish a
|
|
final descriptor with the following characteristics:
|
|
|
|
1) Exit policy is listed as "reject *:*"
|
|
2) It includes a new entry called "opt shutdown 1"
|
|
|
|
The first step is so current blacklists will no longer list this node
|
|
as exiting to whatever the service is.
|
|
|
|
The second step is so directory authorities can avoid wasting time
|
|
doing reachability testing. Authorities should automatically not list
|
|
as Running any router whose latest descriptor says it shut down.
|
|
|
|
[I originally had in mind a third step --- Advertised bandwidth capacity
|
|
is listed as "0" --- so current Tor clients will skip over this node
|
|
when building most circuits. But since clients won't fetch descriptors
|
|
from nodes not listed as Running, this step seems pointless. -RD]
|
|
|
|
Spec:
|
|
|
|
TBD but should be pretty straightforward.
|
|
|
|
Security issues:
|
|
|
|
Now external people can learn exactly when a node stopped offering
|
|
relay service. How bad is this? I can see a few minor attacks based
|
|
on this knowledge, but on the other hand as it is we don't really take
|
|
any steps to keep this information secret.
|
|
|
|
Overhead issues:
|
|
|
|
We are creating more descriptors that want to be remembered. However,
|
|
since the router won't be marked as Running, ordinary clients won't
|
|
fetch the suicide descriptors. Caches will, though. I hope this is ok.
|
|
|
|
Implementation:
|
|
|
|
To make things easy, we should publish the suicide descriptor only
|
|
on controlled shutdown (SIGINT as opposed to SIGTERM). That would
|
|
leave enough time for publishing that we probably wouldn't need any
|
|
extra synchronization code.
|
|
|
|
If that turns out to be too unintuitive for users, I could imagine doing
|
|
it on SIGTERMs too, and just delaying exit until we had successfully
|
|
published to at least one authority, at which point we'd hope that it
|
|
propagated from there.
|
|
|
|
Acknowledgements:
|
|
|
|
tup suggested this idea.
|
|
|
|
Comments:
|
|
|
|
1) Don't name the official feature "suicide descriptors". Suicide is
|
|
irreversible, and the concept pushes many people's buttons. How about
|
|
"shutdown descriptors"?
|
|
2) Maybe add a rule "Don't do this for hibernation if we expect to wake
|
|
up before the next consensus is published"?
|
|
- NM 9 Oct 2007 |