commit c5ca54edcc25ff6761fcf45b07f06f4e0861d911 Author: Nick Mathewson nickm@torproject.org Date: Wed Nov 14 00:26:13 2012 -0500
Revise introduction lightly. --- todo | 9 +++++- tor-design-2012.tex | 74 ++++++++++++++++++--------------------------------- 2 files changed, 33 insertions(+), 50 deletions(-)
diff --git a/todo b/todo index af508bf..489ae86 100644 --- a/todo +++ b/todo @@ -22,6 +22,8 @@ ITEMS: o guard nodes o Bridges, censorship resistance, and pluggable transports - Changes and complexities in our path selection algorithms + - Bandwidth authorities + - Path selection rules o stream isolation . Integrate content from the third blog post [steven] o link protocol tls @@ -30,9 +32,9 @@ ITEMS: o torbutton o tor browser bundle
- . Revise the abstract and introduction [nick] + o Revise the abstract and introduction [nick] o Abstract - - Introduction + o Introduction
. Revise design goals and assumptions [steven] o Revise tor-design up to "opening and closing streams" [nick] @@ -40,6 +42,9 @@ ITEMS: o Revise hidden services section [nick] o Revise "other design decisions" [nick]
+ + + CAN DO AFTER SPONSOR DEADLINE: - Revise related work [steven] - Revise "attacks and defenses" [steven] diff --git a/tor-design-2012.tex b/tor-design-2012.tex index 035bf0d..bb856e7 100644 --- a/tor-design-2012.tex +++ b/tor-design-2012.tex @@ -60,20 +60,11 @@ Nick Mathewson \ The Free Haven Project \ nickm@freehaven.net \and Paul Syverson \ Naval Research Lab \ syverson@itd.nrl.navy.mil}
-% -% TOPICS TO ADD, NOT NOTED BELOW: -% - everything from the 'top changes in Tor' posts. -% - node reliability testing -% - path selection rules. -% - Stream isolation -% -% What else? -% - NM - \maketitle \thispagestyle{empty}
\begin{abstract} +THIS IS A DRAFT. IT IS NOT FINISHED. We present Tor, a circuit-based low-latency anonymous communication service. This Onion Routing system addresses limitations in the earlier design by adding @@ -103,6 +94,9 @@ anonymous communication. \section{Overview} \label{sec:intro}
+THIS IS A DRAFT. IT IS NOT FINISHED. IT IS BASED ON THE 2004 PAPER, +WITH PARTIAL UPDATES. + Onion Routing is a distributed overlay network designed to anonymize TCP-based applications like web browsing, secure shell, and instant messaging. Clients choose a path through the @@ -120,16 +114,11 @@ proof-of-concept that ran on a single machine. Even this simple deployment processed connections from over sixty thousand distinct IP addresses from all over the world at a rate of about fifty thousand per day. -% TODO: Describe more of Tor's history here. -NM Here we describe Tor, a protocol for asynchronous, -loosely federated onion routers that provides the following +loosely federated onion routers. Tor provides +provides the following improvements over the old Onion Routing design:
-% TODO: Perhaps we should drop the entire enumeration of how Tor differs -% from old Onion Routing; we could instead rattle off a list of ways Tor has -% changed since 2004, or instead discuss major features of the design as a -% whole. - NM - \textbf{Perfect forward secrecy:} In the original Onion Routing design, a single hostile node could record traffic and later compromise successive nodes in the circuit and force them to @@ -163,17 +152,12 @@ ORs~\cite{or-ih96,or-jsac98}. Tradeoffs between padding protection and cost were discussed, and \emph{traffic shaping} algorithms were theorized~\cite{or-pet00} to provide good security without expensive padding, but no concrete padding -scheme was suggested. Recent research~\cite{econymics} and +scheme was suggested. As of our first writing, research~\cite{econymics} and deployment experience~\cite{freedom21-security} suggest that this level of resource use is not practical or economical; and even full link padding is still -vulnerable~\cite{defensive-dropping}. Thus, until we have a -proven and convenient design for traffic shaping or low-latency -mixing that improves anonymity against a realistic adversary, we -leave these strategies out. -% We still don't have a solution for the above. Our related work -% section should summarize what we have learned in the meantime. We -% *have* had good outcomes from work that tried to -NM +vulnerable~\cite{defensive-dropping}. This has not changed since +our first publication, though we remain hopeful.
\textbf{Many TCP streams can share one circuit:} Onion Routing originally built a separate circuit for each application-level @@ -193,8 +177,6 @@ exit the circuit from the middle---possibly frustrating traffic shape and volume attacks based on observing the end of the circuit. (It also allows for long-range padding if future research shows this to be worthwhile.) -% This is still a notable feature of Tor, but we don't use it for -% anything. -NM
\textbf{Congestion control:} Earlier anonymity designs do not address traffic bottlenecks. Unfortunately, typical approaches @@ -203,9 +185,8 @@ inter-node control communication and global views of traffic. Tor's decentralized congestion control uses end-to-end acks to maintain anonymity while allowing nodes at the edges of the network to detect congestion or flooding and send less data -until the congestion subsides. -% We've been working on this some; we have found that our current approach -% doesn't work so well. -NM +until the congestion subsides. This is an area of active +experimentation and research.
\textbf{Directory authorities:} The earlier Onion Routing design planned to flood state information through the @@ -234,7 +215,7 @@ traffic and look for corresponding corrupted traffic at the network edges~\cite{minion-design}. Tor hampers these attacks by verifying data integrity before it leaves the network. % Our approach here is a little broken; we're working on better. We should -% acknowledge the problems. -NM +% acknowledge the problems. Not in this section though. -NM
\textbf{Rendezvous points and hidden services:} Tor provides an integrated mechanism for responder anonymity via @@ -246,22 +227,6 @@ path went down or rotated its keys. In Tor, clients negotiate {\it rendezvous points} to connect with hidden servers; reply onions are no longer required.
-Unlike Freedom~\cite{freedom2-arch}, Tor does not require OS -kernel patches or network stack support. This prevents us from -anonymizing non-TCP protocols, but has greatly helped our -portability and deployability. - -We have implemented all of the above features, including -rendezvous points. Our source code is available under a free -license, and Tor is not covered by the patent that affected -distribution and use of earlier versions of Onion Routing. We -have deployed a wide-area alpha network to test the design, to -get more experience with usability and users, and to provide a -research platform for experimentation. As of this writing, the -network stands at 32 nodes spread over two continents. -% The above figure is wrong; the above paragraph doesn't summarize our status -% well -NM - \textbf{Censorship resistance:} A growing number of Tor users require not only anonymous communications but also censorship resistance. Tor circumvents attempts to block access to the @@ -283,7 +248,20 @@ socket -- the ``control port''. Special-purpose controllers have also been developed by researchers to analyse Tor and prototype modifications. Additional resistance against protocol fingerprinting, for the purposes of censorship resistance, may -be provided by an external ``pluggable transport'' obfuscator. +be provided by an external ``pluggable transport'' obfuscator. + +% More features here. -NM + +Unlike Freedom~\cite{freedom2-arch}, Tor does not require OS +kernel patches or network stack support. This prevents us from +anonymizing non-TCP protocols, but has greatly helped our +portability and deployability. + +Tor has been operational since 2003. Our source code is available +under a free license, and Tor is not covered by the patent that +affected distribution and use of earlier versions of Onion Routing. +As of this writing, the Tor network stands at about 3000 +nodes.
We review previous work in Section~\ref{sec:related-work}, describe our goals and assumptions in