mirrors/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-11-20 02:09:24 +01:00
Code Issues Projects Releases Wiki Activity

fix typos and a few subsections in roadmap-2007

Browse Source 
svn:r8926
This commit is contained in:
Roger Dingledine 2006-11-10 04:52:39 +00:00
parent a6e15d77fa
commit 968b07985e
3 changed files with 75 additions and 46 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

BIN
doc/design-paper/roadmap-2007.pdf
View File

Binary file not shown.

92
doc/design-paper/roadmap-2007.tex
View File

@ -1,5 +1,7 @@
\documentclass{article}
\usepackage{url}
\newenvironment{tightlist}{\begin{list}{$\bullet$}{
\setlength{\itemsep}{0mm}
\setlength{\parsep}{0mm}
@ -24,17 +26,17 @@
\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...
%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,
@ -62,7 +64,7 @@ With protocol versioning support would come the ability to {\bf future-proof
directory protocol, is pretty firmly tied to the SHA-1 hash function, which
though not yet known to be insecure for our purposes, has begun to show
its age. We should
remove assumptions thoughout our design based on the assumption that public
remove assumptions throughout our design based on the assumption that public
keys, secret keys, or digests will remain any particular size indefinitely.
Our OR {\bf authentication protocol}, though provably
@ -143,12 +145,13 @@ they are to be deployed in 2008.\plan{Design in 2007; unknown difficulty.
\subsubsection{Relay incentives}
To support more users on the network, we need to get more servers. So far,
we've relied on volunteerism to attract server operators, and so far it's
served us well. But in the long run, we need to {\bf design incentices for
served us well. But in the long run, we need to {\bf design incentives for
users to run servers} and relay traffic for others. Most obviously, we
could try to build the network so that servers offered improved service for
other servers, but we would need to do so without weakening anonymity and
making it obvious which connections originate from users running servers. We
have some preliminary designs here~\cite{challenges}, but need to perform
have some preliminary designs here~\cite{tor-challenges}~\cite{incentives-txt},
but need to perform
some more research to make sure they would be safe and effective.\plan{Write
a draft paper; 2 person-months.}
@ -235,12 +238,13 @@ all getting dropped on the floor, the TCP push-back mechanisms don't really
transmit this information back to the incoming streams.\plan{Do in 2007 since
related to bandwidth limiting. 3-4 weeks.}
\subsection{Running Tor as both client and server}
\tmp{many performance tradeoffs and balances that need more attention.
Roger, please write.} \plan{No idea; try profiling and improving things in
2007.}
Many performance tradeoffs and balances that might need more attention.
We first need to track and fix whatever bottlenecks emerge; but we also
need to invent good algorithms for prioritizing the client's traffic
without starving the server's traffic too much.\plan{No idea; try
profiling and improving things in 2007.}
\subsection{Protocol redesign for UDP}
Tor has relayed only TCP traffic since its first versions, and has used
@ -249,7 +253,7 @@ in the long term we will need to allow UDP traffic on the network, and switch
some or all of the network to using a UDP transport. {\bf Supporting UDP
traffic} will make Tor more suitable for protocols that require UDP, such
as many VOIP protocols. {\bf Using a UDP transport} could greatly reduce
resource limitations on servers, and make the network far less interruptable
resource limitations on servers, and make the network far less interruptible
by lossy connections. Either of these protocol changes would require a great
deal of design work, however. We hope to be able to enlist the aid of a few
talented graduate students to assist with the initial design and
@ -365,7 +369,7 @@ unacceptable levels. %Cite something
\plan{Start doing this in 2007; write a paper. 8-16 weeks.}
We've got some preliminary results suggesting that {\bf a topology-aware
routing algorithm}~\cite{routing-zones} could reduce Tor users'
routing algorithm}~\cite{feamster:wpes2004} could reduce Tor users'
vulnerability against local or ISP-level adversaries, by ensuring that they
are never in a position to watch both ends of a connection. We need to
examine the effects of this approach in more detail and consider side-effects
@ -381,12 +385,12 @@ Internet. \plan{Not in 2007 unless a graduate student wants to do it.}
%
% See above; I think I got this.
We should research the efficacy of {\bf website fingperprinting} attacks,
We should research the efficacy of {\bf website fingerprinting} attacks,
wherein an adversary tries to match the distinctive traffic and timing
pattern of the resources constituting a given website to the traffic pattern
of a user's client. These attacks work great in simulations, but in
practice we hear they don't work nearly as well. We should get some actual
numbers to investigte the issue, and figure out what's going on. If we
numbers to investigate the issue, and figure out what's going on. If we
resist these attacks, or can improve our design to resist them, we should.
% add cites
\plan{Possibly part of end-to-end correlation paper. Otherwise, not in 2007
@ -468,9 +472,9 @@ adding named nodes to the network.\plan{Do in 2007; 4-5 weeks.}
\subsection{Protocol security}
In addition to other protocol changes discussed above,
% And should we move somve of them down here? -NM
% And should we move some of them down here? -NM
we should add {\bf hooks for denial-of-service resistance}; we have some
prelimiary designs, but we shouldn't postpone them until we realy need them.
preliminary designs, but we shouldn't postpone them until we really need them.
If somebody tries a DDoS attack against the Tor network, we won't want to
wait for all the servers and clients to upgrade to a new
version.\plan{Research project; do this in 2007 if funded.}
@ -499,7 +503,7 @@ testing framework.\plan{Ongoing basis, time permitting.}
We should also write flexible {\bf automated single-host deployment tests} so
we can more easily verify that the current codebase works with the
network.\plan{Worthwile in 2007; would save lots of time. 2-4 weeks.}
network.\plan{Worthwhile in 2007; would save lots of time. 2-4 weeks.}
We should build automated {\bf stress testing} frameworks so we can see which
realistic loads cause Tor to perform badly, and regularly profile Tor against
@ -559,13 +563,13 @@ current Tor-friendly position.\plan{Do a writeup here in 2007; 1-2 weeks.}
Those who do block Tor users also block overbroadly, sometimes blacklisting
operators of Tor servers that do not permit exit to their services. We could
obviate innocent reasons for doing so by designing a {\bf narrowly-targeted Tor
RBL service} so that those who wanted to overblock Tor clould no longer
RBL service} so that those who wanted to overblock Tor could no longer
plead incompetence.\plan{Possibly in 2007 if we decide it's a good idea; 3
weeks.}
\subsection{All-in-one bundle}
We need a well-tested, well-documented bundle of Tor and supporting
applications configured to use it correctly. We have an intial
applications configured to use it correctly. We have an initial
implementation well under way, but it will need additional work in
identifying requisite Firefox extensions, identifying security threats,
improving user experience, and so on. This will need significantly more work
@ -578,12 +582,17 @@ is quite feasible, but their project is not currently maintained.
\subsection{A Tor client in a VM}
\tmp{a.k.a JanusVM} which is quite related to the firewall-level deployment
section below . Roger, can you write this?
section below. JanusVM is a Linux kernel running in VMWare. It gets an IP
address from the network, and serves as a DHCP server for its host Windows
machine. It intercepts all outgoing traffic and redirects it into Privoxy,
Tor, etc. This Linux-in-Windows approach may help us with scalability in
the short term, and it may also be a good long-term solution rather than
accepting all security risks in Windows.
%\subsection{Interface improvements}
%\tmp{Allow controllers to manipulate server status.}
% (Why is this in the User Experience section?) -RD
% I think it's better left to a generic ``make controller iface bettter'' item.
% I think it's better left to a generic ``make controller iface better'' item.
\subsection{Firewall-level deployment}
Another useful deployment mode for some users is using {\bf Tor in a firewall
@ -596,16 +605,19 @@ and to {\bf construct a recommended set of firewall configurations} to redirect
traffic to Tor.
This is an area where {\bf deployment via a livecd}, or an installation
targetted at specialized home routing hardware, could be useful.
targeted at specialized home routing hardware, could be useful.
\subsection{Assess software and configurations for anonymity risks}
Right now, users and packagers are more or less on their own when selecting
firefox extensions. We should {\bf assemble a recommended list of browser
Firefox extensions. We should {\bf assemble a recommended list of browser
extensions} through experiment, and include this in the application bundles
we distribute.
We should also describe {\bf best practices for using Tor with each class of
application}. \tmp{Roger, say more}
application}. For example, Ethan Zuckerman has written a detailed
tutorial on how to use Tor, Firefox, GMail, and Wordpress to blog with
improved safety. There are many other cases on the Internet where anonymity
would be helpful, and there are a lot of ways to screw up using Tor.
The Foxtor and Torbutton extensions serve similar purposes; we should pick a
favorite, and merge in the useful features of the other.
@ -632,10 +644,16 @@ translators only need to use a single tool to translate the whole Tor suite.
\section{Support}
\tmp{would be nice to set up some actual user support infrastructure, especially
focusing on server operators and on coordinating volunteers.} Roger, can you
write this ? I don't know what ``user support infrastructure'' is.
It would be nice to set up some {\bf user support infrastructure} and
{\bf contributor support infrastructure}, especially focusing on server
operators and on coordinating volunteers.
This includes intuitive and easy ticket systems for bug reports and
feature suggestions (not just mailing lists with a half dozen people
and no clear roles for who answers what), but it also includes a more
personalized and efficient framework for interaction so we keep the
attention and interest of the contributors, and so we make them feel
helpful and wanted.
\section{Documentation}
@ -656,7 +674,7 @@ We should {\bf revise our design paper} to reflect the new decisions and
research we've made since it was published in 2004. This will help other
researchers evaluate and suggest improvements to Tor's current design.
Other projects sometimes implement the client side of our prototocol. We
Other projects sometimes implement the client side of our protocol. We
encourage this, but we should write {\bf a document about how to avoid
excessive resource use}, so we don't need to worry that they will do so
without regard to the effect of their choices on server resources.
@ -665,7 +683,7 @@ without regard to the effect of their choices on server resources.
Our documentation falls into two broad categories: some is `discoursive' and
explains in detail why users should take certain actions, and other
documenation is `comprehensive' and describes all of Tor's features. Right
documentation is `comprehensive' and describes all of Tor's features. Right
now, we have no document that is both deep, readable, and thorough. We
should correct this by identifying missing spots in our design.

29
doc/design-paper/tor-design.bib
View File

@ -199,7 +199,13 @@
@Misc{tor-spec,
author = {Roger Dingledine and Nick Mathewson},
title = {Tor Protocol Specifications},
note = {\url{http://freehaven.net/tor/tor-spec.txt}},
note = {\url{http://tor.eff.org/svn/trunk/doc/tor-spec.txt}},
}
@Misc{incentives-txt,
author = {Roger Dingledine and Nick Mathewson},
title = {Tor Incentives Design Brainstorms},
note = {\url{http://tor.eff.org/svn/trunk/doc/incentives.txt}},
}
@InProceedings{BM:mixencrypt,
@ -1119,8 +1125,7 @@
number = {2},
year = {2003},
month = {Sept},
www_pdf_url = {http://www.acm.org/sigs/sigecom/exchanges/volume_4_(03)/4.2-Shubina.pdf},
www_section = {Anonymous communication},
note = {\url{http://www.acm.org/sigs/sigecom/exchanges/volume_4_(03)/4.2-Shubina.pdf}},
}
@inproceedings{tor-design,
@ -1220,9 +1225,8 @@
year = {2006},
month = {June},
address = {Cambridge, UK},
www_section = {Economics},
bookurl = {http://weis2006.econinfosec.org/},
www_pdf_url = {http://freehaven.net/doc/wupss04/usability.pdf},
note = {\url{http://freehaven.net/doc/wupss04/usability.pdf}},
}
@Misc{six-four,
@ -1240,7 +1244,7 @@
address = {Cambridge, UK},
publisher = {Springer},
bookurl = {http://petworkshop.org/2006/},
www_pdf_url = {http://www.cl.cam.ac.uk/~rnc1/ignoring.pdf},
note = {\url{http://www.cl.cam.ac.uk/~rnc1/ignoring.pdf}},
}
@Misc{zuckerman-threatmodels,
@ -1292,7 +1296,7 @@ Stefan Katzenbeisser and Fernando P\'{e}rez-Gonz\'{a}lez},
school = {Harvard University},
year = {2006},
month = {July},
www_pdf_url = {http://afs.eecs.harvard.edu/~goodell/thesis.pdf},
note = {\url{http://afs.eecs.harvard.edu/~goodell/thesis.pdf}},
}
@inproceedings{tap:pet2006,
@ -1304,7 +1308,7 @@ Stefan Katzenbeisser and Fernando P\'{e}rez-Gonz\'{a}lez},
address = {Cambridge, UK},
publisher = {Springer},
bookurl = {http://petworkshop.org/2006/},
www_pdf_url = {http://petworkshop.org/2006/preproc/preproc_18.pdf},
note = {\url{http://www.cypherpunks.ca/~iang/pubs/torsec.pdf}},
}
@inproceedings{rep-anon,
@ -1313,7 +1317,14 @@ Stefan Katzenbeisser and Fernando P\'{e}rez-Gonz\'{a}lez},
booktitle = {Proceedings of Workshop on Economics of Peer-to-Peer Systems},
year = {2003},
month = {June},
www_pdf_url = {http://freehaven.net/doc/econp2p03/econp2p03.pdf},
note = {\url{http://freehaven.net/doc/econp2p03/econp2p03.pdf}},
}
@misc{tor-challenges,
author = {Roger Dingledine and Nick Mathewson and Paul Syverson},
title = {Challenges in deploying low-latency anonymity},
year = {2005},
note = {Manuscript}
}
%%% Local Variables: