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