[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[or-cvs] add the dirservers section
Update of /home/or/cvsroot/doc
In directory moria.mit.edu:/home2/arma/work/onion/cvs/doc
Modified Files:
tor-design.bib tor-design.tex
Log Message:
add the dirservers section
Index: tor-design.bib
===================================================================
RCS file: /home/or/cvsroot/doc/tor-design.bib,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -d -r1.7 -r1.8
--- tor-design.bib 22 Oct 2003 18:58:44 -0000 1.7
+++ tor-design.bib 23 Oct 2003 11:45:50 -0000 1.8
@@ -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 @@
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 @@
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 @@
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},
Index: tor-design.tex
===================================================================
RCS file: /home/or/cvsroot/doc/tor-design.tex,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -d -r1.17 -r1.18
--- tor-design.tex 22 Oct 2003 22:40:30 -0000 1.17
+++ tor-design.tex 23 Oct 2003 11:45:51 -0000 1.18
@@ -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 @@
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 @@
\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 @@
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}.
+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 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{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 an exit policy.
+\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:}
+\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 @@
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 @@
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 @@
\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 @@
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 @@
\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 @@
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 @@
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 @@
\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 @@
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 @@
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.