[tor-commits] [torspec/master] Add proposals 206, 207, and 208.
nickm at torproject.org
nickm at torproject.org
Thu Oct 11 03:45:39 UTC 2012
commit 688cb0f7dae4a728b818b554a67ed90358ff8c72
Author: Nick Mathewson <nickm at 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.
+
+
More information about the tor-commits
mailing list