tor-webwml.git

1) ## translation metadata

2) # Revision: $Revision$

3) # Translation-Priority: 3-low
4) 
5) #include "head.wmi" TITLE="NLnet Project: Tor for Low Bandwidth Clients"
6) 
7) <div class="main-column">
8) 
9) <!-- PUT CONTENT AFTER THIS TAG -->
10) 
11) <h2>NLnet Project: Tor for Low Bandwidth Clients</h2>
12) <hr />
13) 
14) <p>
15) The Tor anonymity system is currently only usable by internet users who
16) have high-bandwidth connections. Upon the start of the Tor client, a large file
17) with all Tor server descriptions is being downloaded. This file is the so-called Tor
18) Directory and enables the client to choose from the available mix-servers in the Tor network. The
19) download of the full Tor Directory is required by the current Tor protocol. This directory
20) file is too large for users on modem lines or on mobile data networks like GPRS as the initial
21) download that is triggered every time an user logs in takes 10 to 30 minutes over a slow
22) line. As a result, Tor is not usable by modem and mobile users. One of the major goals of
23) the Tor project is to provide secure anonymous internet access to users in dictatorships
24) and repressive states. These locations often have very slow internet connections,
25) either by modem or due to low-bandwidth links to the outside world. By enabling these users to
26) use the Tor network, significant progress can be made towards free communication and
27) information in these countries.
28) </p>
29) 
30) <p>
31) To make Tor usable also for users on low-bandwidth connections, an
32) evolution of the Tor protocol is needed to reduce the initial download size. This new Tor
33) protocol version should change the way a client receives the information for its Tor
34) circuit setup in a way, that the initial download can be performed over a 14.4 kbps modem line
35) in about three minutes. The work to be conducted under the proposal has the ultimate
36) goal of getting the protocol change production ready and propagated to the Tor users
37) within a timeframe of less then 12 months. The resulting software will be published under
38) the 3-Clause BSD license, as all of the Tor code. All deliverables will be fully public.
39) </p>
40) 
41) <p>
42) This project is generously funded by:
43) </p>
44) 
45) <p>
46) <a href="http://www.nlnet.nl/news/2008/20080514-awards.html">
47) <img src="$(IMGROOT)/nlnet-160x60.png" alt="The NLnet foundation" /></a>
48) </p>
49) 
50) <table width="100%" border="0" cellspacing="0" cellpadding="3">

51) <thead>
52) <tr>
53) <th><big>Project</big></th>
54) <th><big>Due Date</big></th>

55) </tr>

56) </thead>

57) 
58) <tr bgcolor="#e5e5e5">
59)   <td>
60)     <b>Deliverable A:</b> Design and evaluation of the protocol change<br />
61)     <small><em>This deliverable covers the detailed design and
62)     simulation-based evaluation of the necessary changes and design
63)     modifications to the current Tor protocol.
64)     The changes in protocol will be relatively substantial, so it requires a careful
65)     evaluation of possible repercussions for the security and anonymity of the Tor network. A
66)     two-month period is planned for this design and evaluation phase, which concludes with an
67)     extensive peer review. Part of Deliverable A will be a goal definition for performance
68)     for the implementation phase. The design goal is to shrink the Tor Directory
69)     size that needs to be downloaded to about 300 Kilobytes, which would enable an user on a 14.4
70)     kbps line to download it in roughly three minutes. There may be deviations from this
71)     design goal if required to maintain anonymity and security, but this is the figure to aim for.

72)     </em></small>

73)   </td>
74)   <td>
75)     July 15, 2008
76)   </td>
77) </tr>
78) 
79) <tr>
80)   <td>
81)     <b>Deliverable B:</b>Implementation of protocol change<br />
82)     <small><em>After design, evaluation and peer review the modifications
83)     need to be implemented and integrated with the current Tor code base. The actual implementation of
84)     the necessary changes will take approximately three months.
85)     </em></small>
86)   </td>
87)   <td>
88)     October 15, 2008
89)   </td>
90) </tr>
91) 
92) <tr bgcolor="#e5e5e5">
93)   <td>
94)     <b>Deliverable C:</b>Testing<br />
95)     <small><em>Since the modification is highly critical to the security
96)     and anonymity of the Tor network, it requires extensive testing and debugging in laboratory and real life
97)     conditions. A period of three months is projected for testing and debugging, where the
98)     responsible developer is committed to the testing effort with 1/3 of its time. Part of the
99)     testing phase will be a public beta period.
100)     </em></small>
101)   </td>
102)   <td>
103)     November 15, 2008
104)   </td>
105) </tr>
106) 
107) <tr>
108)   <td>
109)     <b>Deliverable D:</b>Rollout<br />
110)     <small><em>The actual rollout to the Tor server network will be
111)       conducted in sync with the regular Tor
112)       release schedule. As this schedule is dependent on a number of external
113)       factors, like the completion of other software projects that should go into the same
114)       release, the actual release time and the time until this release has been accepted and
115)       installed by most Tor server operators can vary. From experience a period of three to four
116)       months can be expected. The rollout will be conducted as part of the regular Tor
117)       release process that is a persistent activity done by volunteers and by personal paid through
118)       other grants to the Tor project.
119)     </em></small>
120)   </td>
121)   <td>
122)     February 15, 2009
123)   </td>
124) </tr>
125) </table>
126) 
127) <br />
128) 
129) <a id="Reports"></a>
130) <h2><a class="anchor" href="#Reports">Monthly Status Reports</a></h2>
131) <p>
132) There will be in total eight monthly status reports beginning with the
133) first deliverable on July 15, 2008 and ending with completion of
134) implementation and testing work on February 15, 2009.
135) </p>
136) 

137) <table width="100%" border="0" cellspacing="0" cellpadding="3">
138) <thead>
139) <tr>
140) <th><big>Month,</big></th>
141) <th><big>Status Report</big></th>
142) </tr>
143) </thead>
144) 

145) <tr bgcolor="#e5e5e5">
146)   <td>

147)     <a id="Jun08"></a>
148)     <a class="anchor" href="#Jun08">Jun 08</a>

149)   </td>
150)   <td>
151)     <small><em>We did some initial measuring of Tor clients
152)     bootstrapping. The results are not very surprising: a client

153)     fetches about 10KB of certs, one consensus for 140KB (now 90KB, see

154)     next paragraph), and about 1.5 megs of Server Descriptors (after

155)     half of which it starts building circuits).</em></small>

156)     <br />

157)     <small><em><a href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/138-remove-down-routers-from-consensus.txt">Proposal

158)     138</a> shrinks consensus documents by 30% to
159)     40% and has already been implemented and merged into the spec.
160)     Implementation is part of the 0.2.1.x-alpha tree and the code will

161)     take effect once over two-thirds of the directory authorities

162)     (i.e. 5 out of 6) have upgraded.</em></small>

163)     <br />
164)     <small><em><a href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/140-consensus-diffs.txt">Proposal
165)     140</a> does not directly relate to reducing initial download size,
166)     but instead tries to make subsequent downloads of new consensus
167)     documents use fewer bytes has also been written up and <a
168)     href="http://archives.seul.org/or/dev/Jun-2008/msg00013.html">sent to
169)     or-dev</a>. There are some questions to be answered from other Tor
170)     developers first, but other than that I think it's fine and could

171)     be implemented.</em></small>

172)     <br />
173)     <small><em>The Big Thing is making clients not download all 1.5 megs
174)     of server descriptors. <a href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/141-jit-sd-downloads.txt">Proposal
175)     141</a> has been <a
176)     href="http://archives.seul.org/or/dev/Jun-2008/msg00017.html">sent

177)     to or-dev</a>. There are basically 3 things to it, as

178)     far as I can see at the moment: move load balancing info into the
179)     consensus (should not be hard), implement something so that Tor
180)     clients can fetch SDs on demand from routers along their circuit

181)     while they are building it (described in the draft), and deal with

182)     exit selection. We're still developing ideas for the last part;

183)     some possibilities are mentioned in the draft.</em></small>

184)   </td>
185) </tr>
186) 
187) <tr>
188)   <td>

189)     <a id="Jul08"></a>
190)     <a class="anchor" href="#Jul08">Jul 08</a>

191)   </td>
192)   <td>

193)     <small><em>Work on <a
194)     href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/141-jit-sd-downloads.txt">Proposal
195)     141</a> is continuing:  There are two basic ideas for how to move
196)     load balancing information into the consensus: One is the
197)     authorities generate the weights that clients should use and put
198)     that in the consensus, the other approach is to just put bandwidth
199)     information from the server descriptor there.  The latter option
200)     is probably friendlier when one also considers <a
201)     href="https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/140-consensus-diffs.txt">Proposal

202)     140</a> since it avoids a having number of highly fluctuating

203)     numbers in the consensus.</em></small>
204)     <br />
205)     <small><em>For handling exit policies <a
206)     href="http://archives.seul.org/or/dev/Jul-2008/msg00022.html">a

207)     post on the or-dev mailinglist</a> suggests that a hash identifying a

208)     node's exit policy be added to the consensus document.  The addition
209)     of another 160 high-entropy bits per node to the consensus might
210)     be a cause for concern but we think that since a lot of the exit
211)     policies are the same the consensus document will compress nicely.
212)     Measurements pending.</em></small>

213)   </td>
214) </tr>
215) 
216) <tr bgcolor="#e5e5e5">
217)   <td>
218)     Aug 08
219)   </td>
220)   <td>

221)     <small><em>Directory authority voting documents, and their consensus
222)     forming algorithm have been changed to include bandwidth information
223)     and policy summaries as documented in Proposal 141.  Once five of
224)     the six running authorities have upgraded to trunk at at least
225)     revision 16554 the consensus will start to include that
226)     information.</em></small>

227)   </td>
228) </tr>
229) 
230) <tr>
231)   <td>
232)     Sep 08
233)   </td>
234)   <td>
235)   </td>
236) </tr>
237) 
238) <tr bgcolor="#e5e5e5">
239)   <td>
240)     Oct 08
241)   </td>
242)   <td>
243)   </td>
244) </tr>
245) 
246) <tr>
247)   <td>
248)     Nov 08
249)   </td>
250)   <td>
251)   </td>
252) </tr>
253) 
254) <tr bgcolor="#e5e5e5">
255)   <td>
256)     Dec 08
257)   </td>
258)   <td>
259)   </td>
260) </tr>
261) 
262) <tr>
263)   <td>
264)     Jan 09
265)   </td>
266)   <td>
267)   </td>
268) </tr>
269) </table>
270) 
271) <br />

272) 
273) <!-- Do we want a people section? If so, would it make sense to write what

274) these people will be doing? And what exactly are these people going to