minor touchups on proposals

svn:r15263

1 files changed, 81 insertions, 0 deletions

diff --git a/proposals/120-shutdown-descriptors.txt b/proposals/120-shutdown-descriptors.txt
new file mode 100644
index 0000000..f078050
--- /dev/null
+++ b/proposals/120-shutdown-descriptors.txt
@@ -0,0 +1,81 @@
+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: 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 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