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