add the dirservers section

svn:r662

doc/tor-design.bib

@@ -10,6 +10,14 @@
   note =	 {\url{http://www.authnet.org/anonnet/}}
 }
 
+% can somebody track down the rest of this? -RD
+@Misc{castro-liskov,
+   author = {Miguel Castro and Barbara Liskov}, 
+   title = {Proactive Recovery in a Byzantine-Fault-Tolerant System},
+   howpublished = {
+     $<$http://www.pmg.lcs.mit.edu/$\tilde{\hspace{5pt}}$castro/application/recovery.pdf$>$},
+}
+
 @inproceedings{econymics,
   title = {On the Economics of Anonymity}, 
   author = {Alessandro Acquisti and Roger Dingledine and Paul Syverson}, 
@@ -63,10 +71,11 @@ full_papers/rao/rao.pdf}},
     note = {\url{http://citeseer.nj.nec.com/pfitzmann90how.html}},
 }
 
-@Misc{mixminion-spec,
-   author =      {Mixminion},
-   title =       {Type {III} ({M}ixminion) Mix Protocol Specifications},
-   note =        {\newline \url{http://mixminion.net/minion-spec.txt}},
+%   author =      {Roger Dingledine and Nick Mathewson},
+@Misc{tor-spec,
+   author =      {Anonymized},
+   title =       {Tor Protocol Specifications},
+   note =        {\url{http://freehaven.net/tor/tor-spec.txt}},
 }
 
 @InProceedings{BM:mixencrypt,
@@ -723,6 +732,16 @@ full_papers/rao/rao.pdf}},
    note =        {\newline \url{http://www.freedom.net/products/whitepapers/white11.html}},
 }
 
+@techreport{freedom2-arch,
+  title = {Freedom Systems 2.0 Architecture}, 
+  author = {Philippe Boucher and Adam Shostack and Ian Goldberg}, 
+  institution = {Zero Knowledge Systems, {Inc.}}, 
+  year = {2000}, 
+  month = {December}, 
+  type = {White Paper}, 
+  day = {18}, 
+}
+
 @techreport{freedom21-security,
   title = {Freedom Systems 2.1 Security Issues and Analysis}, 
   author = {Adam Back and Ian Goldberg and Adam Shostack}, 
@@ -918,7 +937,7 @@ full_papers/rao/rao.pdf}},
   title = {Defending Anonymous Communication Against Passive Logging Attacks}, 
   author = {Matthew Wright and Micah Adler and Brian Neil Levine and Clay Shields}, 
   booktitle = {2003 IEEE Symposium on Security and Privacy}, 
-  pages= {28--41}
+  pages= {28--41},
   year = {2003}, 
   month = {May}, 
   publisher = {IEEE CS}, 

doc/tor-design.tex

@@ -41,7 +41,6 @@
 
 \title{Tor: Design of a Next-Generation Onion Router}
 
-%\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}
@@ -78,6 +77,7 @@ at each node, revealing the downstream node. The original onion routing
 project published several design and analysis papers
 \cite{or-jsac98,or-discex00,or-ih96,or-pet00}. While there was briefly
 a wide area onion routing network,
+% how long is briefly? a day, a month? -RD
 the only long-running and publicly accessible
 implementation was a fragile proof-of-concept that ran on a single
 machine. Many critical design and deployment issues were never implemented,
@@ -99,9 +99,9 @@ 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
-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
+supported application protocol, resulting in a lot of extra code --- most
+of which was never written, so most 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.
 
@@ -162,32 +162,33 @@ onion routers also serve as directory servers; they provide signed
 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:} Node failure for a
-  low-latency system like Tor is not as serious a problem as it is for
-  a traditional mix network. Nonetheless, simple mechanisms that allow
-  connections to be established despite slightly dated information
-  from a directory server or very recent node failure are useful.  Tor
-  permits onion routers to have router twins. These share the same
-  private decryption key that is used when establishing a connection
-  through the onion router. Note that because of how connections are
-  now established with perfect forward secrecy, this does not
-  automatically mean that an onion router can read the traffic on a
-  connection established through its twin even while that connection
-  is active. Also, which nodes are twins can change dynamically
-  depending on current circumstances, and twins may or may not be
-  under the same administrative authority.
-
-\item \textbf{Exit policies:}
-Tor provides a consistent mechanism for each node to specify and
-advertise an exit policy.
-
-\item \textbf{Rendezvous points:}
+on traffic going through the network, any onion router on the path
+can change the contents of cells as they pass by, e.g. to redirect a
+connection on the fly so it connects to a different webserver, or to
+tag encrypted traffic and look for the tagged traffic at the network
+edges \cite{minion-design}.
+
+\item \textbf{Robustness to failed nodes:} A failed node in a traditional
+mix network means lost messages, but in Tor, users can notice failed
+nodes while building circuits and route around them. We further provide a
+simple mechanism that allows connections to be established despite recent
+node failure or slightly dated information from a directory server. Tor
+permits onion routers to have \emph{router twins} --- nodes that share
+the same private decryption key. Note that because connections now have
+perfect forward secrecy, an onion router still cannot read the traffic
+on a connection established through its twin even while that connection
+is active. Also, which nodes are twins can change dynamically depending
+on current circumstances, and twins may or may not be under the same
+administrative authority.
+
+\item \textbf{Exit policies:} Tor provides a consistent mechanism for
+each node to specify and advertise its own exit policy. Exit policies
+are critical in a volunteer-based distributed infrastructure, because
+each operator is comfortable with allowing different types of traffic
+to exit the Tor network from his node.
+
+\item \textbf{Rendezvous points and location-protected servers:} Tor
+provides an integrated mechanism for responder-anonymity
 location-protected servers
 
 \end{tightlist}
@@ -312,7 +313,7 @@ The first of these was the Eternity Service \cite{eternity}. Since
 then, there have been many alternatives and refinements, of which we note
 but a few
 \cite{eternity,gap-pets03,freenet-pets00,freehaven-berk,publius,tangler,taz}.
-From the first, traffic analysis resistant communication has been
+From the beginning, traffic analysis resistant communication has been
 recognized as an important element of censorship resistance because of
 the relation between the ability to censor material and the ability to
 find its distribution source.
@@ -381,7 +382,7 @@ activities); and designs that are difficult or expensive to implement
 or ).
 
 Second, the system must be {\bf usable}.  A hard-to-use system has
-fewer users---and because anonymity systems hide users among users, a
+fewer users --- and because anonymity systems hide users among users, a
 system with fewer users provides less anonymity.  Thus, usability is
 not only a convenience, but is a security requirement for anonymity
 systems.
@@ -404,8 +405,8 @@ speculative solutions to problems we don't KNOW how to solve? -NM]
 
 \subsection{Non-goals}
 In favoring conservative, deployable designs, we have explicitly
-deferred a number of goals---not because they are not desirable in
-anonymity systems---but because solving them is either solved
+deferred a number of goals --- not because they are not desirable in
+anonymity systems --- but because solving them is either solved
 elsewhere, or an area of active research without a generally accepted
 solution.
 
@@ -416,16 +417,18 @@ servers.
 Tor does not claim to provide a definitive solution to end-to-end
 timing or intersection attacks for users who do not run their own
 Onion Routers.
+% Does that mean we do claim to solve intersection attack for
+% the enclave-firewall model? -RD
 
-Tor does not provide ``protocol normalization'' like the Anonymizer,
-Privoxy, or XXX.  In order to provide client indistinguishibility for
+Tor does not provide \emph{protocol normalization} like the Anonymizer or
+Privoxy.  In order to provide client indistinguishibility for
 complex and variable protocols such as HTTP, Tor must be layered with
-a proxy such as Privoxy or XXX.  Similarly, Tor does not currently
+a filtering proxy such as Privoxy.  Similarly, Tor does not currently
 integrate tunneling for non-stream-based protocols; this too must be
 provided by an external service.
 
-Tor is not steganographic. It doesn't try to conceal which users are
-sending or receiving communications via Tor.
+Tor is not steganographic: it doesn't try to conceal which users are
+sending or receiving communications.
 
 
 \SubSection{Adversary Model}
@@ -559,6 +562,7 @@ tagging attacks
 \SubSection{Assumptions}
 
 For purposes of this paper, we assume all directory servers are honest
+% No longer true, see subsec:dirservers below -RD
 and trusted. Perhaps more accurately, we assume that all users and
 nodes can perform their own periodic checks on information they have
 from directory servers and that all will always have access to at
@@ -568,7 +572,7 @@ techniques to cope with a minority dishonest servers.
 
 Somewhere between ten percent and twenty percent of nodes are assumed
 to be compromised. In some circumstances, e.g., if the Tor network is
-running on a hardened network where all operators have had careful
+running on a hardened network where all operators have had
 background checks, the percent of compromised nodes might be much
 lower. It may be worthwhile to consider cases where many of the `bad'
 nodes are not fully compromised but simply (passive) observing
@@ -579,6 +583,8 @@ above. We assume that all adversary components, regardless of their
 capabilities are collaborating and are connected in an offline clique.
 
 We do not assume any hostile users, except in the context of
+% This sounds horrible. What do you mean we don't assume any hostile
+% users? Surely we can tolerate some? -RD
 rendezvous points. Nonetheless, we assume that users vary widely in
 both the duration and number of times they are connected to the Tor
 network. They can also be assumed to vary widely in the volume and
@@ -600,7 +606,78 @@ shape of the traffic they send and receive.
 \label{subsec:exitpolicies}
 
 \SubSection{Directory Servers}
-\label{subsec:dir-servers}
+\label{subsec:dirservers}
+
+First-generation Onion Routing designs \cite{or-jsac98,freedom2-arch} did
+% is or-jsac98 the right cite here? what's our stock OR cite? -RD
+in-band network status updates: each router flooded a signed statement
+to its neighbors, which propagated it onward. But anonymizing networks
+have different security goals than typical link-state routing protocols.
+For example, we worry more about delays (accidental or intentional)
+which cause different parts of the network to have different pictures
+of link-state and topology. We also worry about attacks to deceive a
+client about the router membership list, topology, or current network
+state. Such \emph{partitioning attacks} on client knowledge help an
+adversary with limited resources to efficiently deploy those resources
+when attacking a target.
+
+Instead, Tor uses a small group of redundant directory servers to
+track network topology and node state such as current keys and exit
+policies. The directory servers are normal onion routers, but there are
+only a few of them and they are more trusted. They listen on a separate
+port as an HTTP server, both so participants can fetch current network
+state and router lists (a \emph{directory}), and so other onion routers
+can upload a signed summary of their keys, address, bandwidth, exit
+policy, etc (\emph{server descriptors}.
+
+Of course, a variety of attacks remain. An adversary who controls a
+directory server can track certain clients by providing different
+information --- perhaps by listing only nodes under its control
+as working, or by informing only certain clients about a given
+node. Moreover, an adversary without control of a directory server can
+still exploit differences among client knowledge. If Eve knows that
+node $M$ is listed on server $D_1$ but not on $D_2$, she can use this
+knowledge to link traffic through $M$ to clients who have queried $D_1$.
+
+Thus these directory servers must be synchronized and redundant. The
+software is distributed with the signature public key of each directory
+server, and directories must be signed by a threshold of these keys.
+
+The directory servers in Tor are modeled after those in Mixminion
+\cite{minion-design}, but our situation is easier. Firstly, we make the
+simplifying assumption that all participants agree on who the directory
+servers are. Secondly, Mixminion needs to predict node behavior ---
+that is, build a reputation system for guessing future performance of
+nodes based on past performance, and then figure out a way to build
+a threshold consensus of these predictions. Tor just needs to get a
+threshold consensus of the current state of the network.
+
+The threshold consensus can be reached with standard Byzantine agreement
+techniques \cite{castro-liskov}.
+% Should I just stop the section here? Is the rest crap? -RD
+But this library, while more efficient than previous Byzantine agreement
+systems, is still complex and heavyweight for our purposes: we only need
+to compute a single algorithm, and we do not require strict in-order
+computation steps. The Tor directory servers build a consensus directory
+through a simple four-round broadcast protocol. First, each server signs
+and broadcasts its current opinion to the other directory servers; each
+server then rebroadcasts all the signed opinions it has received. At this
+point all directory servers check to see if anybody's cheating. If so,
+directory service stops, the humans are notified, and that directory
+server is permanently removed from the network. Assuming no cheating,
+each directory server then computes a local algorithm on the set of
+opinions, resulting in a uniform shared directory. Then the servers sign
+this directory and broadcast it; and finally all servers rebroadcast
+the directory and all the signatures.
+
+The rebroadcast steps ensure that a directory server is heard by either
+all of the other servers or none of them (some of the links between
+directory servers may be down). Broadcasts are feasible because there
+are so few directory servers (currently 3, but we expect to use as many
+as 9 as the network scales). The actual local algorithm for computing
+the shared directory is straightforward, and is described in the Tor
+specification \cite{tor-spec}.
+% we should, uh, add this to the spec. oh, and write it. -RD
 
 \Section{Rendezvous points: location privacy}
 \label{sec:rendezvous}
@@ -666,6 +743,10 @@ and the first half of a DH key exchange. When Bob connects to the meeting
 place and gets connected to Alice's pipe, his first cell contains the
 other half of the DH key exchange.
 
+% briefly talk about our notion of giving cookies to people proportional
+% to how important they are, for location-protected servers hardened
+% against DDoS threat? -RD
+
 \subsection{Integration with user applications}
 
 For each service Bob offers, he configures his local onion proxy to know
@@ -841,7 +922,7 @@ link-level cover traffic and also long-range cover traffic. In particular,
 we expect restricted route topologies to reduce the cost of cover traffic
 because there are fewer links to cover.
 \item \emph{Better directory distribution:} Even with the threshold
-directory agreement algorithm described in \ref{sec:dirservers},
+directory agreement algorithm described in \ref{subsec:dirservers},
 the directory servers are still trust bottlenecks. We must find more
 decentralized yet practical ways to distribute up-to-date snapshots of
 network status without introducing new attacks.