-
Notifications
You must be signed in to change notification settings - Fork 84
/
206-directory-sources.txt
89 lines (61 loc) · 3.29 KB
/
206-directory-sources.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
Filename: 206-directory-sources.txt
Title: Preconfigured directory sources for bootstrapping
Author: Nick Mathewson
Created: 10-Oct-2012
Status: Closed
Implemented-In: 0.2.4.7-alpha
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 when future clients are
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.
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 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.
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
Networkstatus File 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
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
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 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. See proposal 207.