commit c68d6fbc397bbe47f1bf9afc0cf15f25e4c95580 Author: Nick Mathewson nickm@torproject.org Date: Thu Oct 11 10:31:49 2012 -0400
edits to proposals 206..208 --- proposals/206-directory-sources.txt | 26 +++++++++++++++----------- proposals/207-directory-guards.txt | 23 +++++++++++------------ proposals/208-ipv6-exits-redux.txt | 12 ++++++------ 3 files changed, 32 insertions(+), 29 deletions(-)
diff --git a/proposals/206-directory-sources.txt b/proposals/206-directory-sources.txt index 585b9ea..8b8ce66 100644 --- a/proposals/206-directory-sources.txt +++ b/proposals/206-directory-sources.txt @@ -9,8 +9,8 @@ Target: 0.2.4.x Motivation and History:
We've long wanted a way for clients to do their initial - bootstrapping, not from the directory authorities, but from some - other set of nodes expected to probably be up as the client is + bootstrapping not from the directory authorities, but from some + other set of nodes expected to probably be up when future clients are starting.
We tried to solve this a while ago by adding a feature where we could @@ -23,7 +23,7 @@ Motivation and History:
Then for a while we considered an "Extra-Stable" flag so that clients could use only nodes with a long history of existence from these - fallback networkstatus files. We never built it, though.x + fallback networkstatus files. We never built it, though.
Instead, we can do this so much more simply. If we want to ship Tor with a list of initial locations to go for directory information, why @@ -33,21 +33,24 @@ Proposal:
In the same way that Tor currently ships with a list of directory authorities, Tor should also ship with a list of directory sources -- - places to go for an initial consensus if you don't have a remotely + places to go for an initial consensus if you don't have a somewhat recent one.
These need to include an address for the cache's ORPort, and its identity key. Additionally, they should include a selection weight.
- Whenever Tor is starting without a consensus, and it would currently + They can be configured with a torrc option, just like directory + authorities are now. + + Whenever Tor is starting without a consensus, if it would currently ask a directory authority for a consensus, it should instead ask one of these preconfigured directory sources.
I have code for this (see git branch fallback_dirsource_v2) in my public repository.
- When we deploy this, we can (and should) rip out the Fallback- - NetworkstatusFile logic. + When we deploy this, we can (and should) rip out the Fallback + Networkstatus File logic.
How to find nodes to make into directory sources: @@ -56,8 +59,8 @@ How to find nodes to make into directory sources: directory sources.
First, we could try to vet them a little, with a light variant of the - authority stuff. We'd want to look for nodes where we knew the - operators, verify that they were okay with keeping the same IP for a + process we use for authorities. We'd want to look for nodes where we knew + the operators, verify that they were okay with keeping the same IP for a very long time, and so forth.
Second, we could try to pick nodes for listing with each Tor release @@ -74,11 +77,12 @@ How to find nodes to make into directory sources:
Some notes on security:
- Directory source nodes have an opportunity to learn about more users + Directory source nodes have an opportunity to learn about new users connecting to the network for the first time. Once we have directory guards, that's going to be a fairly uncommon ability. We should be careful in any directory guard design to make sure that we don't fall - back to the directory sources any more than we need to. + back to the directory sources any more than we need to. See proposal 207. +
diff --git a/proposals/207-directory-guards.txt b/proposals/207-directory-guards.txt index 1310e14..d0563be 100644 --- a/proposals/207-directory-guards.txt +++ b/proposals/207-directory-guards.txt @@ -17,37 +17,36 @@ Motivation:
Proposal:
- In the same way as they currently pick guard nodes as needed, adding - more as those nodes are down, clients should also pick a small-ish - set of directory guard nodes, to persist in Tor's state file. + In the same way as they currently pick guard nodes as needed, adding more + guards as those nodes are down, clients should also pick a small-ish set + of directory guard nodes, to persist in Tor's state file.
Clients should not pick their own guards as directory guards, or pick their directory guards as regular guards.
- When downloading a regular directory object (i.e., not a hidden + When downloading a regular directory object (that is, not a hidden service descriptor), clients should prefer their directory guards first. Then they should try more directories from a recent consensus (if they have one) and pick one of those as a new guard if the existing guards are down and a new one is up. Failing that, they should fall back to a directory authority (or a directory source, if - those get implemented). + those get implemented-- see proposal 206).
- - When fetching multiple descriptors in parallel from their guards, - clients should add new guards and try them if only one of the - client's directory guards is running. + If a client has only one directory guard running, they should add new + guards and try them, and then use their directory guards to fetch multiple + descriptors in parallel.
Discussion:
- The rule that the set of guards and the set directory guards need to + The rule that the set of guards and the set of directory guards need to be disjoint, and the rule that multiple directory guards need to be providing descriptors, are both attempts to make it harder for a - single node to capture route. + single node to capture a route.
Open questions and notes:
What properties does a node need to be a suitable directory guard? - If we require that it have the Guard flag, we'll lose some nodes; + If we require that it have the Guard flag, we'll lose some nodes: only 74% of the directory caches have it (weighted by bandwidth).
We may want to tune the algorithm used to update guards. diff --git a/proposals/208-ipv6-exits-redux.txt b/proposals/208-ipv6-exits-redux.txt index 3b468c0..6185d2a 100644 --- a/proposals/208-ipv6-exits-redux.txt +++ b/proposals/208-ipv6-exits-redux.txt @@ -8,7 +8,7 @@ Target: 0.2.4.x
1. Obligatory Motivation Section
- Insert motivations for IPv6 here. Mention IPv4 address exhaustion. + [Insert motivations for IPv6 here. Mention IPv4 address exhaustion.
Insert official timeline for official IPv6 adoption here.
@@ -17,11 +17,11 @@ Target: 0.2.4.x
Insert profession of firm conviction that eventually there will be something somebody wants to connect to which requires the ability to - connect to an IPv6 address. + connect to an IPv6 address.]
2. Proposal
- Proposal 117 has been there since coderman wrote it 2007, and it's + Proposal 117 has been there since coderman wrote it in 2007, and it's still mostly right. Rather than replicate it in full, I'll describe this proposal as a patch to it.
@@ -31,7 +31,7 @@ Target: 0.2.4.x been moving with IPv4 addresses) to summaries of which IPv6 ports are generally permitted. So let's allow server descriptors to include a list of accepted IPv6 ports, using the same format as the "p" line - in microdecsriptors, using the "ipv6-policy" keyword. + in microdescriptors, using the "ipv6-policy" keyword.
"ipv6-policy" SP ("accept" / "reject") SP PortList NL
@@ -43,7 +43,7 @@ Target: 0.2.4.x "p6" line in microdescriptors.
- This change breaks the existing exit enclave idea for IPv6; but the + This change breaks the existing exit enclave idea for IPv6, but the exiting exit enclave implementation never worked right in the first place. If we can come up with a good way to support it, we can add that back in. @@ -118,7 +118,7 @@ Target: 0.2.4.x
- IPv6 addresses are plentiful, which makes cacheing them dangerous + IPv6 addresses are plentiful, which makes caching them dangerous if you're hoping to avoid tracking over time. (With IPv4 addresses, it's harder to give every user a different IPv4 address for a target hostname with a long TTL, and then accept connections to those IPv4