12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485 |
- Filename: 120-shutdown-descriptors.txt
- Title: Shutdown descriptors when Tor servers stop
- Version: $Revision$
- Last-Modified: $Date$
- Author: Roger Dingledine
- Created: 15-Aug-2007
- Status: Dead
- [Proposal dead as of 11 Jul 2008. The point of this proposal was to give
- routers a good way to get out of the networkstatus early, but proposal
- 138 (already implemented) has achieved this.]
- 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 shutdown descriptors. Caches will, though. I hope this is ok.
- Implementation:
- To make things easy, we should publish the shutdown 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:
- 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
|