diff options
author | Nick Mathewson <nickm@torproject.org> | 2016-08-26 13:48:26 -0400 |
---|---|---|
committer | Nick Mathewson <nickm@torproject.org> | 2016-08-26 13:48:26 -0400 |
commit | 68177157137e97359511cdf86675af2df3a3628c (patch) | |
tree | 7a938fe2a3235d0386407d2b088c0626ed012d9d | |
parent | 6561a518eeb5611731c37f3238fb0bc8888b76dc (diff) | |
download | torspec-68177157137e97359511cdf86675af2df3a3628c.tar.gz torspec-68177157137e97359511cdf86675af2df3a3628c.zip |
Add a proposal for a better way to do 266
-rw-r--r-- | proposals/000-index.txt | 2 | ||||
-rw-r--r-- | proposals/272-valid-and-running-by-default.txt | 59 |
2 files changed, 61 insertions, 0 deletions
diff --git a/proposals/000-index.txt b/proposals/000-index.txt index 41aec3d..d0376cd 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -192,6 +192,7 @@ Proposals by number: 269 Transitionally secure hybrid handshakes [DRAFT] 270 RebelAlliance: A Post-Quantum Secure Hybrid Handshake Based on NewHope [DRAFT] 271 Another algorithm for guard selection [OPEN] +272 Listed routers should be Valid, Running, and treated as such [OPEN] Proposals by status: @@ -251,6 +252,7 @@ Proposals by status: 262 Re-keying live circuits with new cryptographic material 264 Putting version numbers on the Tor subprotocols 271 Another algorithm for guard selection + 272 Listed routers should be Valid, Running, and treated as such ACCEPTED: 140 Provide diffs between consensuses 172 GETINFO controller option for circuit information diff --git a/proposals/272-valid-and-running-by-default.txt b/proposals/272-valid-and-running-by-default.txt new file mode 100644 index 0000000..7e14b6b --- /dev/null +++ b/proposals/272-valid-and-running-by-default.txt @@ -0,0 +1,59 @@ +Filename: 272-valid-and-running-by-default.txt +Title: Listed routers should be Valid, Running, and treated as such +Created: 26 Aug 2016 +Author: Nick Mathewson +Status: Open + +1. Introduction and proposal. + + This proposal describes a change in how clients understand consensus + flags, and how authorities vote on consensuses. + +1.1. Authority-side changes + + Back in proposal 138, we made it so that non-Running routers were not + included in the consensus documents. We should do the same with the + Valid flag. Specifically, after voting, if the authorities find that + a router would not receive the Valid flag, they should not include it + at all. + + This will require the allocation of a new consensus method, since it + is a change in how consensuses are made from votes. + + In the most recent consensus, it will affect exactly 1 router. + +1.2. Client-side changes + + I propose that clients should consider every listed router to be + listed as Running and Valid if any consensus method above or higher + is in use. + +2. Benefits + + Removing the notion of listed but invalid routers will remove an + opportunity for error, and let us remove some client side code. + + More interestingly, the above changes would allow us to eventually + stop including the Running and Valid flags, thereby providing an + authority-side way to feature-gate clients off of the Tor network + without a fast-zombie problem. (See proposal 266 for discussion.) + + +A. An additional possible change + + Perhaps authorities might also treat BadExit like they treat the + absence of Valid and Running: as sufficient reason to not include a + router in the consensus. Right now, there are only 4 listed BadExit + routers in the consensus, amounting to a small fraction of total + bandwidth. + + Making this change would allow us to remove the client-side badexit + logic. + + +B. Does this solve the zombie problem? + + I tested it a little, and it does seem to be a way to make even the + most ancient consensus-understanding Tors stop fetching descriptors + and using the network. More testing needed though. + |