[or-cvs] another todo item, a half-written tor-design intro

[Roger Dingledine]

Update of /home/or/cvsroot/doc
In directory moria.mit.edu:/home2/arma/work/onion/cvs/doc

Modified Files:
	TODO tor-design.tex 
Log Message:
another todo item, a half-written tor-design intro


Index: TODO
===================================================================
RCS file: /home/or/cvsroot/doc/TODO,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -d -r1.26 -r1.27
--- TODO	2 Oct 2003 20:00:38 -0000	1.26
+++ TODO	7 Oct 2003 15:59:29 -0000	1.27
@@ -1,4 +1,6 @@
 
+use times(2) rather than gettimeofday to measure how long it takes to process a cell
+
 Legend:
 SPEC!!  - Not specified
 SPEC    - Spec not finalized

Index: tor-design.tex
===================================================================
RCS file: /home/or/cvsroot/doc/tor-design.tex,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- tor-design.tex	11 Jul 2003 19:28:36 -0000	1.1
+++ tor-design.tex	7 Oct 2003 15:59:30 -0000	1.2
@@ -42,8 +42,8 @@
 \thispagestyle{empty}
 
 \begin{abstract}
-We present Tor, a connection-based anonymous communication system based
-on onion routing.
+We present Tor, a connection-based low-latency anonymous communication
+system which addresses many flaws in the original onion routing design.
 Tor works in a real-world Internet environment,
 requires little synchronization or coordination between nodes, and
 protects against known anonymity-breaking attacks as well
@@ -59,26 +59,53 @@
 \Section{Overview}
 \label{sec:intro}
 
-Onion routing is a TCP-based anonymous communication system
-The onion routing project published a number of papers several years
-ago \cite{x,y,z}, but because the only implementation was a fragile
-proof-of-concept that ran on a single machine, many critical design issues
-were not considered or addressed. Here we describe Tor, a protocol for
-asynchronous, loosely federated onion routers that provides the following
-improvements over the old onion routing design:
+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
+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
+federated onion routers that provides the following improvements over
+the old onion routing design:
 
 \begin{itemize}
-\item \textbf{Congestion control:} Foo
 
-\item \textbf{No mixing or traffic shaping:}
+\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
+of which was never written) and also meaning that a lot of TCP-based
+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{Applications talk to the onion proxy via socks:} 
+\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{Directory servers:}
 
 \item \textbf{Forward security:}
 
 \item \textbf{Many applications can share one circuit:}
+
+leaky pipes
 
 \item \textbf{End-to-end integrity checking:}