[or-cvs] r13085: remove some of the done items, in preparation for overhaul (tor/trunk/doc/design-paper)
arma at seul.org
arma at seul.org
Wed Jan 9 15:11:49 UTC 2008
Author: arma
Date: 2008-01-09 10:11:49 -0500 (Wed, 09 Jan 2008)
New Revision: 13085
Modified:
tor/trunk/doc/design-paper/roadmap-future.tex
Log:
remove some of the done items, in preparation for overhaul
Modified: tor/trunk/doc/design-paper/roadmap-future.tex
===================================================================
--- tor/trunk/doc/design-paper/roadmap-future.tex 2008-01-09 14:45:43 UTC (rev 13084)
+++ tor/trunk/doc/design-paper/roadmap-future.tex 2008-01-09 15:11:49 UTC (rev 13085)
@@ -14,8 +14,8 @@
\begin{document}
-\title{Tor Development Roadmap: Wishlist for Nov 2006--Dec 2007}
-\author{Roger Dingledine \and Nick Mathewson \and Shava Nerad}
+\title{Tor Development Roadmap: Wishlist for 2008 and beyond}
+\author{Roger Dingledine \and Nick Mathewson}
\maketitle
\pagestyle{plain}
@@ -26,23 +26,13 @@
\section{Introduction}
-%Hi, Roger! Hi, Shava. This paragraph should get deleted soon. Right now,
-%this document goes into about as much detail as I'd like to go into for a
-%technical audience, since that's the audience I know best. It doesn't have
-%time estimates everywhere. It isn't well prioritized, and it doesn't
-%distinguish well between things that need lots of research and things that
-%don't. The breakdowns don't all make sense. There are lots of things where
-%I don't make it clear how they fit into larger goals, and lots of larger
-%goals that don't break down into little things. It isn't all stuff we can do
-%for sure, and it isn't even all stuff we can do for sure in 2007. The
-%tmp\{\} macro indicates stuff I haven't said enough about. That said, here
-%plangoes...
Tor (the software) and Tor (the overall software/network/support/document
-suite) are now experiencing all the crises of success. Over the next year,
-we're probably going to grow more in terms of users, developers, and funding
-than before. This gives us the opportunity to perform long-neglected
-maintenance tasks.
+suite) are now experiencing all the crises of success. Over the next
+years, we're probably going to grow more in terms of users, developers,
+and funding than before. This document attempts to lay out all the
+well-understood next steps that Tor needs to take. We should periodically
+reorganize it to reflect current and intended priorities.
\section{Code and design infrastructure}
@@ -96,23 +86,7 @@
\subsection{Scalability}
\subsubsection{Improved directory efficiency}
-Right now, clients download a statement of the {\bf network status} made by
-each directory authority. We could reduce network bandwidth significantly by
-having the authorities jointly sign a statement reflecting their vote on the
-current network status. This would save clients up to 160K per hour, and
-make their view of the network more uniform. Of course, we'd need to make
-sure the voting process was secure and resilient to failures in the
-network.\plan{Must do; specify in 2006. 2 weeks to specify, 3-4 weeks to
- implement.}
-We should {\bf shorten router descriptors}, since the current format includes
-a great deal of information that's only of interest to the directory
-authorities, and not of interest to clients. We can do this by having each
-router upload a short-form and a long-form signed descriptor, and having
-clients download only the short form. Even a naive version of this would
-save about 40\% of the bandwidth currently spent by clients downloading
-descriptors.\plan{Must do; specify in 2006. 3-4 weeks.}
-
We should {\bf have routers upload their descriptors even less often}, so
that clients do not need to download replacements every 18 hours whether any
information has changed or not. (As of Tor 0.1.2.3-alpha, clients tolerate
@@ -154,11 +128,12 @@
but need to perform
some more research to make sure they would be safe and effective.\plan{Write
a draft paper; 2 person-months.}
+(XXX we did that)
\subsection{Portability}
Our {\bf Windows implementation}, though much improved, continues to lag
behind Unix and Mac OS X, especially when running as a server. We hope to
-merge promising patches from Mike Chiussi to address this point, and bring
+merge promising patches from Christian King to address this point, and bring
Windows performance on par with other platforms.\plan{Do in 2007; 1.5 months
to integrate not counting Mike's work.}
@@ -166,10 +141,6 @@
operation that require less RAM, and that write to disk less frequently (to
avoid wearing out flash RAM).\plan{Optional; 2 weeks.}
-We should {\bf stop using socketpair on Windows}; instead, we can use
-in-memory structures to communicate between cpuworkers and the main thread,
-and between connections.\plan{Optional; 1 week.}
-
\subsection{Performance: resource usage}
We've been working on {\bf using less RAM}, especially on servers. This has
paid off a lot for directory caches in the 0.1.2, which in some cases are
@@ -181,21 +152,9 @@
around 25 to 50\% of the memory currently allocated for network buffers, and
make Tor a more attractive proposition for restricted-memory environments
like old computers, mobile devices, and the like.\plan{Do in 2007; 2-3 weeks
- plus one week measurement.}
+ plus one week measurement.} (XXX We did this, but we need to do something
+more/else.)
-We should improve our {\bf bandwidth limiting}. The current system has been
-crucial in making users willing to run servers: nobody is willing to run a
-server if it might use an unbounded amount of bandwidth, especially if they
-are charged for their usage. We can make our system better by letting users
-configure bandwidth limits independently for their own traffic and traffic
-relayed for others; and by adding write limits for users running directory
-servers.\plan{Do in 2006; 2-3 weeks.}
-
-On many hosts, sockets are still in short supply, and will be until we can
-migrate our protocol to UDP. We can {\bf use fewer sockets} by making our
-self-to-self connections happen internally to the code rather than involving
-the operating system's socket implementation.\plan{Optional; 1 week.}
-
\subsection{Performance: network usage}
We know too little about how well our current path
selection algorithms actually spread traffic around the network in practice.
@@ -272,39 +231,25 @@
\subsection{Implementation: client-side and bridges-side}
-Our anticensorship design calls for some nodes to act as ``bridges''
-that are outside a national firewall, and others inside the firewall to
-act as pure clients. This part of the design is quite clear-cut; we're
-probably ready to begin implementing it. To {\bf implement bridges}, we
-need to have servers publish themselves as limited-availability relays
-to a special bridge authority if they judge they'd make good servers.
-We will also need to help provide documentation for port forwarding,
-and an easy configuration tool for running as a bridge.
-
-To {\bf implement clients}, we need to provide a flexible interface to
-learn about bridges and to act on knowledge of bridges. We also need
-to teach them how to know to use bridges as their first hop, and how to
-fetch directory information from both classes of directory authority.
-
-Clients also need to {\bf use the encrypted directory variant} added in Tor
-0.1.2.3-alpha. This will let them retrieve directory information over Tor
-once they've got their initial bridges. We may want to get the rest of the
-Tor user base to begin using this encrypted directory variant too, to
-provide cover.
-
Bridges will want to be able to {\bf listen on multiple addresses and ports}
if they can, to give the adversary more ports to block.
\subsection{Research: anonymity implications from becoming a bridge}
+see arma's bridge proposal; e.g. should bridge users use a second layer of
+entry guards?
+
\subsection{Implementation: bridge authority}
-The design here is also reasonably clear-cut: we need to run some
+we run some
directory authorities with a slightly modified protocol that doesn't leak
the entire list of bridges. Thus users can learn up-to-date information
for bridges they already know about, but they can't learn about arbitrary
new bridges.
+we need a design for distributing the bridge authority over more than one
+server
+
\subsection{Normalizing the Tor protocol on the wire}
Additionally, we should {\bf resist content-based filters}. Though an
adversary can't see what users are saying, some aspects of our protocol are
@@ -313,10 +258,6 @@
Look like Firefox; or look like nothing?
Future research: investigate timing similarities with other protocols.
-\subsection{Access control for bridges}
-Design/impl: password-protecting bridges, in light of above.
-And/or more general access control.
-
\subsection{Research: scanning-resistance}
\subsection{Research/Design/Impl: how users discover bridges}
@@ -398,14 +339,6 @@
unless a graduate student is interested.}
\subsection{Implementation security}
-Right now, each Tor node stores its keys unencrypted. We should {\bf encrypt
- more Tor keys} so that Tor authorities can require a startup password. We
-should look into adding intermediary medium-term ``signing keys'' between
-identity keys and onion keys, so that a password could be required to replace
-a signing key, but not to start Tor. This would improve Tor's long-term
-security, especially in its directory authority infrastructure.\plan{Design this
- as a part of the revised ``v2.1'' directory protocol; implement it in
- 2007. 3-4 weeks.}
We should also {\bf mark RAM that holds key material as non-swappable} so
that there is no risk of recovering key material from a hard disk
@@ -458,11 +391,11 @@
To avoid attacks where an adversary claims good performance in order to
attract traffic, we should {\bf have authorities measure node performance}
(including stability and bandwidth) themselves, and not simply believe what
-they're told. Measuring stability can be done by tracking MTBF. Measuring
-bandwidth can be tricky, since it's hard to distinguish between a server with
+they're told. We also measure stability by tracking MTBF. Measuring
+bandwidth will be tricky, since it's hard to distinguish between a server with
low capacity, and a high-capacity server with most of its capacity in
-use.\plan{Do ``Stable'' in 2007; 2-3 weeks. ``Fast'' will be harder; do it
- if we can interest a grad student.}
+use. See also Nikita's NDSS 2008 paper.\plan{Do it if we can interest
+a grad student.}
{\bf Operating a directory authority should be easier.} We rely on authority
operators to keep the network running well, but right now their job involves
More information about the tor-commits
mailing list