flesh out more of the entries in the intro

svn:r573

doc/tor-design.tex

@@ -32,11 +32,12 @@
 %  \pdfpageheight=\the\paperheight
 %\fi
 
-\title{Tor: Design of a Next-generation Onion Router}
+\title{Tor: Design of a Next-Generation Onion Router}
 
-\author{Roger Dingledine \\ The Free Haven Project \\ arma@freehaven.net \and
-Nick Mathewson \\ The Free Haven Project \\ nickm@freehaven.net \and
-Paul Syverson \\ Naval Research Lab \\ syverson@itd.nrl.navy.mil}
+\author{Anonymous}
+%\author{Roger Dingledine \\ The Free Haven Project \\ arma@freehaven.net \and
+%Nick Mathewson \\ The Free Haven Project \\ nickm@freehaven.net \and
+%Paul Syverson \\ Naval Research Lab \\ syverson@itd.nrl.navy.mil}
 
 \maketitle
 \thispagestyle{empty}
@@ -60,14 +61,14 @@ as or better than other systems with similar design parameters.
 \label{sec:intro}
 
 Onion routing is a distributed overlay network designed to anonymize
-low-latency TCP-based applications such as web browsing, secure
-shell, and instant messaging. Users choose a path through the
-network and build a \emph{virtual circuit}, in which each node in
-the path knows its predecessor and successor, but no others. Traffic
-flowing down the circuit is unwrapped by a symmetric key at each
-node which reveals the downstream node. The original onion routing
-project published several design and analysis papers several years
-ago \cite{or-journal,or-discex,or-ih,or-pet}, but because the only
+low-latency TCP-based applications such as web browsing, secure shell,
+and instant messaging. Users choose a path through the network and
+build a \emph{virtual circuit}, in which each node in the path knows its
+predecessor and successor, but no others. Traffic flowing down the circuit
+is sent in fixed-size \emph{cells}, which are unwrapped by a symmetric key
+at each node, revealing the downstream node. The original onion routing
+project published several design and analysis papers in recent years
+\cite{or-journal,or-discex,or-ih,or-pet}, but because the only
 implementation was a fragile proof-of-concept that ran on a single
 machine, many critical design and deployment issues were not considered
 or addressed. Here we describe Tor, a protocol for asynchronous, loosely
@@ -76,6 +77,15 @@ the old onion routing design:
 
 \begin{itemize}
 
+\item \textbf{Perfect forward secrecy:} The original onion routing
+design is vulnerable to a single hostile node recording traffic and later
+forcing successive nodes in the circuit to decrypt it. Rather than using
+onions to lay the circuits, Tor uses an incremental or \emph{telescoping}
+path-building design, where the initiator negotiates session keys with
+each successive hop in the circuit. Onion replay detection is no longer
+necessary, and the network as a whole is more reliable to boot, since
+the initiator knows which hop failed and can try extending to a new node.
+
 \item \textbf{Applications talk to the onion proxy via Socks:}
 The original onion routing design required a separate proxy for each
 supported application protocol, resulting in a lot of extra code (most
@@ -84,30 +94,54 @@ applications were not supported. Tor uses the unified and standard Socks
 \cite{socks4,socks5} interface, allowing us to support any TCP-based
 program without modification.
 
+\item \textbf{Many applications can share one circuit:} The original
+onion routing design built one circuit for each request. Aside from the
+performance issues of doing public key operations for every request, it
+also turns out that regular communications patterns mean building lots
+of circuits can endanger anonymity \cite{wright03}. Tor multiplexes many
+connections down each circuit, but still rotates the circuit periodically
+to avoid too much linkability.
+
 \item \textbf{No mixing or traffic shaping:} The original onion routing
 design called for full link padding both between onion routers and between
 onion proxies (that is, users) and onion routers \cite{or-journal}. The
 later analysis paper \cite{or-pet} suggested \emph{traffic shaping}
-schemes that would provide similar protection but use less bandwidth,
-but did not go into detail. However, recent research \cite{econymics}
-and deployment experience \cite{freedom2-arch} indicate that this level
-of resource use is not practical or economical, especially if.
-
-\item \textbf{Directory servers:} Traditional link state
-
-\item \textbf{Congestion control:} Traditional flow control solutions
- Our decentralized ack-based congestion control
-allows nodes at the edges of the network to detect incidental congestion
-or flooding attacks and send less data until the congestion subsides.
-
-
-\item \textbf{Forward security:}
-
-\item \textbf{Many applications can share one circuit:}
-
-leaky pipes
-
-\item \textbf{End-to-end integrity checking:}
+to provide similar protection but use less bandwidth, but did not go
+into detail. However, recent research \cite{econymics} and deployment
+experience \cite{freedom2-arch} indicate that this level of resource
+use is not practical or economical; and even full link padding is still
+vulnerable to active attacks \cite{defensive-dropping}.
+
+\item \textbf{Leaky pipes:} Through in-band signalling within the circuit,
+Tor initiators can direct traffic to nodes partway down the circuit. This
+allows for long-range padding to frustrate timing attacks at the initiator
+\cite{defensive-dropping}, but because circuits are used by more than
+one application, it also allows traffic to exit the circuit from the
+middle -- thus frustrating timing attacks based on observing exit points.
+%Or something like that. hm.
+
+\item \textbf{Congestion control:} Earlier anonymity designs do not
+address traffic bottlenecks. Unfortunately, typical approaches to load
+balancing and flow control in overlay networks involve inter-node control
+communication and global views of traffic. Our decentralized ack-based
+congestion control maintains reasonable anonymity while allowing nodes
+at the edges of the network to detect congestion or flooding attacks
+and send less data until the congestion subsides.
+
+\item \textbf{Directory servers:} Rather than attempting to flood
+link-state information through the network, which can be unreliable and
+open to partitioning attacks or outright deception, Tor takes a simplified
+view towards distributing link-state information. Certain more trusted
+onion routers also serve as directory servers; they provide signed
+\emph{directories} describing all routers they know about, and which
+are currently up. Users periodically download these directories via HTTP.
+
+\item \textbf{End-to-end integrity checking:} Without integrity checking
+on traffic going through the network, an onion router can change the
+contents of cells as they pass by, e.g. by redirecting a connection on
+the fly so it connects to a different webserver, or by tagging encrypted
+traffic and looking for traffic at the network edges that has been
+tagged \cite{minion-design}.
 
 \item \textbf{Robustness to node failure:} router twins
 
@@ -120,11 +154,12 @@ location-protected servers
 
 \end{itemize}
 
-We review mixes and mix-nets in Section \ref{sec:background},
-describe our goals and assumptions in Section \ref{sec:assumptions},
+We review previous work in Section \ref{sec:background}, describe
+our goals and assumptions in Section \ref{sec:assumptions},
 and then address the above list of improvements in Sections
-\ref{sec:design}-\ref{sec:nymservers}. We then summarize how our design
-stands up to known attacks, and conclude with a list of open problems.
+\ref{sec:design}-\ref{sec:maintaining-anonymity}. We then summarize
+how our design stands up to known attacks, and conclude with a list of
+open problems.
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
@@ -193,6 +228,15 @@ them.
 \Section{Future Directions and Open Problems}
 \label{sec:conclusion}
 
+Tor brings together many innovations from many different projects into
+a unified deployable system. But there are still several attacks that
+work quite well, as well as a number of sustainability and run-time
+issues remaining to be ironed out. In particular:
+
+\begin{itemize}
+\item foo
+\end{itemize}
+
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
 \Section{Acknowledgments}