commit 688cb0f7dae4a728b818b554a67ed90358ff8c72 Author: Nick Mathewson <nickm@torproject.org> Date: Wed Oct 10 22:49:58 2012 -0400 Add proposals 206, 207, and 208. --- proposals/000-index.txt | 6 ++ proposals/206-directory-sources.txt | 85 +++++++++++++++++++++++ proposals/207-directory-guards.txt | 62 +++++++++++++++++ proposals/208-ipv6-exits-redux.txt | 128 +++++++++++++++++++++++++++++++++++ 4 files changed, 281 insertions(+), 0 deletions(-) diff --git a/proposals/000-index.txt b/proposals/000-index.txt index 7671ce5..e2cd9cf 100644 --- a/proposals/000-index.txt +++ b/proposals/000-index.txt @@ -126,6 +126,9 @@ Proposals by number: 203 Avoiding censorship by impersonating an HTTPS server [DRAFT] 204 Subdomain support for Hidden Service addresses [OPEN] 205 Remove global client-side DNS caching [OPEN] +206 Preconfigured directory sources for bootstrapping [OPEN] +207 Directory guards [OPEN] +208 IPv6 Exits Redux [OPEN] Proposals by status: @@ -168,6 +171,9 @@ Proposals by status: 202 Two improved relay encryption protocols for Tor cells 204 Subdomain support for Hidden Service addresses 205 Remove global client-side DNS caching + 206 Preconfigured directory sources for bootstrapping [for 0.2.4.x] + 207 Directory guards [for 0.2.4.x] + 208 IPv6 Exits Redux [for 0.2.4.x] ACCEPTED: 117 IPv6 exits [for 0.2.4.x] 140 Provide diffs between consensuses diff --git a/proposals/206-directory-sources.txt b/proposals/206-directory-sources.txt new file mode 100644 index 0000000..585b9ea --- /dev/null +++ b/proposals/206-directory-sources.txt @@ -0,0 +1,85 @@ +Filename: 206-directory-sources.txt +Title: Preconfigured directory sources for bootstrapping +Author: Nick Mathewson +Created: 10-Oct-2012 +Status: Open +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 + starting. + + We tried to solve this a while ago by adding a feature where we could + ship a 'fallback' networkstatus file -- one that would get parsed + when we had no current networkstatus file, and which we would use to + learn about possible directory sources. But we couldn't actually use + it, since it turns out that a randomly chosen list of directory + caches from 4-5 months ago is a terrible place to go when + bootstrapping. + + 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 + + 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 + not just do so? + +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 + 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 + 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. + + +How to find nodes to make into directory sources: + + We could take any of three approaches for selecting these initial + 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 + very long time, and so forth. + + Second, we could try to pick nodes for listing with each Tor release + based entirely on how long those nodes have been up. Anything that's + been a high-reliability directory for a long time on the same IP + (like, say, a year) could be a good choice. + + Third, we could blend the approach and start by looking for + up-for-a-long-time nodes, and then also ask the operators whether + their nodes are likely to stay running for a long time. + + I think the third model is best. + + +Some notes on security: + + Directory source nodes have an opportunity to learn about more 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. + + + + diff --git a/proposals/207-directory-guards.txt b/proposals/207-directory-guards.txt new file mode 100644 index 0000000..1310e14 --- /dev/null +++ b/proposals/207-directory-guards.txt @@ -0,0 +1,62 @@ +Filename: 207-directory-guards.txt +Title: Directory guards +Author: Nick Mathewson +Created: 10-Oct-2012 +Status: Open +Target: 0.2.4.x + + +Motivation: + + When we added guard nodes to resist profiling attacks, we made it so + that clients won't build general-purpose circuits through just any + node. But clients don't use their guard nodes when downloading + general-purpose directory information from the Tor network. This + allows a directory cache, over time, to learn a large number of IPs + for non-bridge-using users of the Tor network. + +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. + + 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 + 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). + + + 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. + +Discussion: + + The rule that the set of guards and the set 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. + +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; + only 74% of the directory caches have it (weighted by bandwidth). + + We may want to tune the algorithm used to update guards. + + For future-proofing, we may want to have the DirCache flag from 185 + be the one that nodes must have in order to be directory guards. For + now, we could have authorities set it to Guard && DirPort!=0, with a + better algorithm to follow. Authorities should never get the + DirCache flag. + + + diff --git a/proposals/208-ipv6-exits-redux.txt b/proposals/208-ipv6-exits-redux.txt new file mode 100644 index 0000000..3b468c0 --- /dev/null +++ b/proposals/208-ipv6-exits-redux.txt @@ -0,0 +1,128 @@ +Filename: 208-ipv6-exits-redux.txt +Title: IPv6 Exits Redux +Author: Nick Mathewson +Created: 10-Oct-2012 +Status: Open +Target: 0.2.4.x + + +1. Obligatory Motivation Section + + Insert motivations for IPv6 here. Mention IPv4 address exhaustion. + + Insert official timeline for official IPv6 adoption here. + + Insert general desirability of being able to connect to whatever + address there is here. + + 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. + +2. Proposal + + Proposal 117 has been there since coderman wrote it 2007, and it's + still mostly right. Rather than replicate it in full, I'll describe + this proposal as a patch to it. + +2.1. Exit policies + + Rather than specify IPv6 policies in full, we should move (as we have + 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. + + "ipv6-policy" SP ("accept" / "reject") SP PortList NL + + Exits should still, of course, be able to configure more complex + policies, but they should no longer need to tell the whole world + about them. + + After this ipv6-policy line is validated, it should get copied into a + "p6" line in microdescriptors. + + + 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. + +2.2. Which addresses should we connect to? + + One issue that's tripped us up a few times is how to decide whether + we can use IPv6 addresses. You can't use them with SOCKS4 or + SOCKS4a, IIUC. With SOCKS5, there's no way to indicate that you + prefer IPv4 or IPv6. It's possible that some SOCKS5 users won't + understand IPv6 addresses. + + With this in mind, I'm going to suggest that with SOCKS4 or SOCKS4a, + clients should always require IPv4. With SOCKS5, clients should + accept IPv6. + + If it proves necessary, we can also add per-SOCKSPort configuration + flags to override the above default behavior. + + See also partitioning discussion in Security Notes below. + +2.3. Extending BEGIN cells. + + Prop117 (and the section above) says that clients should prefer one + address or another, but doesn't give them a means to tell the exit to + do so. Here's one. + + We define an extension to the BEGIN cell as follows. After the + ADDRESS | ':' | PORT | [00] portion, the cell currently contains all + [00] bytes. We add a 32-bit flags field, stored as an unsigned 32 + bit value, after the [00]. All these flags default to 0, obviously. + We define the following flags: + + bit + 1 -- IPv6 okay. We support learning about IPv6 addresses and + connecting to IPv6 addresses. + 2 -- IPv4 not okay. We don't want to learn about IPv4 addresses + or connect to them. + 3 -- IPv6 preferred. If there are both IPv4 and IPv6 addresses, + we want to connect to the IPv6 one. (By default, we connect + to the IPv4 address.) + 4..32 -- Reserved. + + As with so much else, clients should look at the platform version of + the exit they're using to see if it supports these flags before + sending them. + +2.4. Minor changes to proposal 117 + + GETINFO commands that return an address, and which should return two, + should not in fact begin returning two addresses separated by CRLF. + They should retain their current behavior, and there should be a new + "all my addresses" GETINFO target. + +3. Security notes: + + Letting clients signal that they want or will accept IPv6 addresses + creates two partitioning issues that didn't exist before. One is the + version partitioning issue: anybody who supports IPv6 addresses is + obviously running the new software. Another is option partitioning: + anybody who is using a SOCKS4a application will look different from + somebody who is using a SOCKS5 application. + + We can't do much about version partitioning, I think. If we felt + especially clever, we could have a flag day. Is that necessary? + + For option partitioning, are there many applications whose behavior + is indistinguishable except that they are sometimes configured to use + SOCKS4a and sometimes to use SOCKS5? If so, the answer may well be + to persuade as many users as possible to switch those to SOCKS5, so + that they get IPv6 support and have a large anonymity set. + + + + IPv6 addresses are plentiful, which makes cacheing 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 + addresses from different exits over time. With IPv6, it's easy.) + This makes proposal 205 especially necessary here. + +