[or-cvs] r15263: minor touchups on proposals (in tor/trunk/doc/spec/proposals: . ideas)
arma at seul.org
arma at seul.org
Sun Jun 15 01:50:31 UTC 2008
Author: arma
Date: 2008-06-14 21:50:31 -0400 (Sat, 14 Jun 2008)
New Revision: 15263
Added:
tor/trunk/doc/spec/proposals/120-shutdown-descriptors.txt
Removed:
tor/trunk/doc/spec/proposals/120-suicide-descriptors.txt
Modified:
tor/trunk/doc/spec/proposals/000-index.txt
tor/trunk/doc/spec/proposals/138-remove-down-routers-from-consensus.txt
tor/trunk/doc/spec/proposals/ideas/xxx-geoip-survey-plan.txt
Log:
minor touchups on proposals
Modified: tor/trunk/doc/spec/proposals/000-index.txt
===================================================================
--- tor/trunk/doc/spec/proposals/000-index.txt 2008-06-15 01:12:14 UTC (rev 15262)
+++ tor/trunk/doc/spec/proposals/000-index.txt 2008-06-15 01:50:31 UTC (rev 15263)
@@ -42,7 +42,7 @@
117 IPv6 exits [NEEDS-REVISION]
118 Advertising multiple ORPorts at once [DRAFT]
119 New PROTOCOLINFO command for controllers [CLOSED]
-120 Suicide descriptors when Tor servers stop [OPEN]
+120 Shutdown descriptors when Tor servers stop [OPEN]
121 Hidden Service Authentication [OPEN]
122 Network status entries need a new Unnamed flag [CLOSED]
123 Naming authorities automatically create bindings [CLOSED]
@@ -73,7 +73,7 @@
133 Incorporate Unreachable ORs into the Tor Network
134 More robust consensus voting with diverse authority sets
OPEN:
- 120 Suicide descriptors when Tor servers stop
+ 120 Shutdown descriptors when Tor servers stop
121 Hidden Service Authentication
135 Simplify Configuration of Private Tor Networks
137 Keep controllers informed as Tor bootstraps
Copied: tor/trunk/doc/spec/proposals/120-shutdown-descriptors.txt (from rev 15249, tor/trunk/doc/spec/proposals/120-suicide-descriptors.txt)
===================================================================
--- tor/trunk/doc/spec/proposals/120-shutdown-descriptors.txt (rev 0)
+++ tor/trunk/doc/spec/proposals/120-shutdown-descriptors.txt 2008-06-15 01:50:31 UTC (rev 15263)
@@ -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
Deleted: tor/trunk/doc/spec/proposals/120-suicide-descriptors.txt
===================================================================
--- tor/trunk/doc/spec/proposals/120-suicide-descriptors.txt 2008-06-15 01:12:14 UTC (rev 15262)
+++ tor/trunk/doc/spec/proposals/120-suicide-descriptors.txt 2008-06-15 01:50:31 UTC (rev 15263)
@@ -1,84 +0,0 @@
-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
\ No newline at end of file
Modified: tor/trunk/doc/spec/proposals/138-remove-down-routers-from-consensus.txt
===================================================================
--- tor/trunk/doc/spec/proposals/138-remove-down-routers-from-consensus.txt 2008-06-15 01:12:14 UTC (rev 15262)
+++ tor/trunk/doc/spec/proposals/138-remove-down-routers-from-consensus.txt 2008-06-15 01:50:31 UTC (rev 15263)
@@ -23,7 +23,7 @@
At a typical bootstrap a client downloads a 140KB consensus, about
10KB of certificates to verify that consensus, and about 1.6MB of
- server descriptors, about half of which it requires before it will
+ server descriptors, about 1/4 of which it requires before it will
start building circuits.
Another proposal deals with how to get that huge 1.6MB fraction to
@@ -33,8 +33,8 @@
to get in order to work.
About one third of the routers listed in a consensus are not running
- and will therefor never be used by clients who use this consensus.
- Not listing those routers will safe about 30% to 40% in size.
+ and will therefore never be used by clients who use this consensus.
+ Not listing those routers will save about 30% to 40% in size.
3. Proposed change
@@ -47,3 +47,4 @@
they support method 4 then this new method will be used: The
consensus document is formed like before but a new last step removes
all routers from the listing that are not marked as Running.
+
Modified: tor/trunk/doc/spec/proposals/ideas/xxx-geoip-survey-plan.txt
===================================================================
--- tor/trunk/doc/spec/proposals/ideas/xxx-geoip-survey-plan.txt 2008-06-15 01:12:14 UTC (rev 15262)
+++ tor/trunk/doc/spec/proposals/ideas/xxx-geoip-survey-plan.txt 2008-06-15 01:50:31 UTC (rev 15263)
@@ -34,7 +34,7 @@
We need to make sure this information isn't exposed in a way that
helps an adversary.
-Methods for curent clients:
+Methods for current clients:
Every client downloads network status documents. There are
currently three methods (one hypothetical) for clients to get them.
@@ -49,7 +49,7 @@
[In both of the above cases, clients choose a running
directory cache at random with odds roughly proportional to
- its bandwidth. If they're just starting, they know a ]
+ its bandwidth. If they're just starting, they know a XXXX FIXME -NM]
- In some future version, clients will choose directory caches
to serve as their "directory guards" to avoid profiling
@@ -82,12 +82,12 @@
Notes:
- [Over H hours, the N for V2 clients is 2*H, and the N for V3
- clients is currently around N/2 or N/3.]
+ clients is currently around H/2 or H/3.]
- (We should only count requests that we actually intend to answer;
503 requests shouldn't count.)
- - These measurements should also be be taken at a directory
+ - These measurements should also be taken at a directory
authority if possible: their picture of the network is skewed
by clients that fetch from them directly. These clients,
however, are all the clients that are just bootstrapping
More information about the tor-commits
mailing list