proposals/120-shutdown-descriptors.txt

   1 Filename: 120-shutdown-descriptors.txt
   2 Title: Shutdown descriptors when Tor servers stop
   3 Version: $Revision$
   4 Last-Modified: $Date$
   5 Author: Roger Dingledine
   6 Created: 15-Aug-2007
   7 Status: Dead
   8
   9 [Proposal dead as of 11 Jul 2008. The point of this proposal was to give
  10 routers a good way to get out of the networkstatus early, but proposal
  11 138 (already implemented) has achieved this.]
  12
  13 Overview:
  14
  15   Tor servers should publish a last descriptor whenever they shut down,
  16   to let others know that they are no longer offering service.
  17
  18 The Problem:
  19
  20   The main reason for this is in reaction to Internet services that want
  21   to treat connections from the Tor network differently. Right now,
  22   if a user experiments with turning on the "relay" functionality, he
  23   is punished by being locked out of some websites, some IRC networks,
  24   etc --- and this lockout persists for several days even after he turns
  25   the server off.
  26
  27 Design:
  28
  29   During the "slow shutdown" period if exiting, or shortly after the
  30   user sets his ORPort back to 0 if not exiting, Tor should publish a
  31   final descriptor with the following characteristics:
  32
  33   1) Exit policy is listed as "reject *:*"
  34   2) It includes a new entry called "opt shutdown 1"
  35
  36   The first step is so current blacklists will no longer list this node
  37   as exiting to whatever the service is.
  38
  39   The second step is so directory authorities can avoid wasting time
  40   doing reachability testing. Authorities should automatically not list
  41   as Running any router whose latest descriptor says it shut down.
  42
  43   [I originally had in mind a third step --- Advertised bandwidth capacity
  44   is listed as "0" --- so current Tor clients will skip over this node
  45   when building most circuits. But since clients won't fetch descriptors
  46   from nodes not listed as Running, this step seems pointless. -RD]
  47
  48 Spec:
  49
  50   TBD but should be pretty straightforward.
  51
  52 Security issues:
  53
  54   Now external people can learn exactly when a node stopped offering
  55   relay service. How bad is this? I can see a few minor attacks based
  56   on this knowledge, but on the other hand as it is we don't really take
  57   any steps to keep this information secret.
  58
  59 Overhead issues:
  60
  61   We are creating more descriptors that want to be remembered. However,
  62   since the router won't be marked as Running, ordinary clients won't
  63   fetch the shutdown descriptors. Caches will, though. I hope this is ok.
  64
  65 Implementation:
  66
  67   To make things easy, we should publish the shutdown descriptor only
  68   on controlled shutdown (SIGINT as opposed to SIGTERM). That would
  69   leave enough time for publishing that we probably wouldn't need any
  70   extra synchronization code.
  71
  72   If that turns out to be too unintuitive for users, I could imagine doing
  73   it on SIGTERMs too, and just delaying exit until we had successfully
  74   published to at least one authority, at which point we'd hope that it
  75   propagated from there.
  76
  77 Acknowledgements:
  78
  79   tup suggested this idea.
  80
  81 Comments:
  82
  83   2) Maybe add a rule "Don't do this for hibernation if we expect to wake
  84      up before the next consensus is published"?
  85                                                       - NM 9 Oct 2007