diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/tor-design.tex | 116 |
1 files changed, 80 insertions, 36 deletions
diff --git a/doc/tor-design.tex b/doc/tor-design.tex index 5bd25fd244..bed7c8d46f 100644 --- a/doc/tor-design.tex +++ b/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} |