\documentclass{article} %\usepackage{latex8} \usepackage{times} \usepackage{url} \usepackage{graphics} \usepackage{amsmath} %\pagestyle{empty} \hyphenation{a-non-y-mize a-non-y-miz-er} \renewcommand\url{\begingroup \def\UrlLeft{<}\def\UrlRight{>}\urlstyle{tt}\Url} \newcommand\emailaddr{\begingroup \def\UrlLeft{<}\def\UrlRight{>}\urlstyle{tt}\Url} \newcommand{\workingnote}[1]{} % The version that hides the note. %\newcommand{\workingnote}[1]{(**#1)} % The version that makes the note visible. % If an URL ends up with '%'s in it, that's because the line *in the .bib/.tex % file* is too long, so break it there (it doesn't matter if the next line is % indented with spaces). -DH %\newif\ifpdf %\ifx\pdfoutput\undefined % \pdffalse %\else % \pdfoutput=1 % \pdftrue %\fi \newenvironment{tightlist}{\begin{list}{$\bullet$}{ \setlength{\itemsep}{0mm} \setlength{\parsep}{0mm} % \setlength{\labelsep}{0mm} % \setlength{\labelwidth}{0mm} % \setlength{\topsep}{0mm} }}{\end{list}} \begin{document} %% Use dvipdfm instead. --DH %\ifpdf % \pdfcompresslevel=9 % \pdfpagewidth=\the\paperwidth % \pdfpageheight=\the\paperheight %\fi \title{Resisting Traffic Analysis on Unclassified Networks\thanks{This work supported by DARPA and ONR.}} \author{Roger Dingledine \\ The Free Haven Project \\ arma@freehaven.net \and Nick Mathewson \\ The Free Haven Project \\ nickm@freehaven.net \and Catherine Meadows \\ Naval Research Laboratory \\ meadows@itd.nrl.navy.mil \and Paul Syverson \\ Naval Research Laboratory \\ syverson@itd.nrl.navy.mil} \maketitle \thispagestyle{empty} \begin{abstract} While the need for data and message confidentiality is well known, the need to protect against traffic analysis on networks, including unclassified networks, is less widely recognized. Tor is a circuit-based low-latency anonymous communication service that resists traffic analysis. This second-generation Onion Routing system adds to the first-generation design with perfect forward secrecy, congestion control, directory servers, integrity checking, variable exit policies, and a practical design for rendezvous points. Tor works on the real-world Internet, requires no special privileges or kernel modifications, requires little synchronization or coordination between nodes, and provides a reasonable tradeoff between anonymity, usability, and efficiency. \end{abstract} %\begin{center} %\textbf{Keywords:} anonymity, peer-to-peer, remailer, nymserver, reply block %\end{center} \section{Introduction} It is well known that encryption hides the content of communication but does nothing to hide who is communicating with whom. Indeed, Whit Diffie, an inventor of public-key cryptography, has noted that traffic analysis, not cryptanalysis, is the backbone of signals intelligence \cite{diffiebook}. % Can we be more specific than 'the military'? The military has many reasons to communicate over open networks without revealing its communications partners. Communicating in this way assists intelligence gathering from open Internet sources, rapid formation of dynamic coalitions without an existing shared private infrastructure between members, and private communication with vendors to help conceal procurement patterns. Finally, it is sometimes not the communicants that are sensitive but their location: a server whose physical or logical location is known may be vulnerable to physical attack and denial of service. Onion Routing is an overlay network concept for making anonymous connections resistant to eavesdropping and traffic analysis. It permits low-latency TCP-based communication such as web traffic, secure shell remote login, and instant messaging. The current design and implementation, Tor, improves on the original \cite{or-ih96,or-jsac98,or-discex00,or-pet00} by providing perfect forward secrecy (see Section~\ref{sec:assumptions}), interfacing to unmodified applications via SOCKS, multiplexing application connections on Onion Routing circuits, adding congestion control adding integrity checking, and including a rendezvous points design that protects the responder of a connection in addition to the initiator. Onion Routing may be used anywhere traffic analysis is a concern. Because Onion Routing is an overlay network, it can exist on top of public networks such as the Internet without any modification to the underlying routing structure or protocols. In addition to protecting data confidentiality and integrity, the Onion Routing protocol hides the endpoint of each transmission. An intelligence analyst surfing a web site through Onion Routing is hidden both from that web site and from the Onion Routing network itself. On the other hand, Onion Routing separates anonymity of the communication from that of the data stream. That is, a procurement officer can place orders with a vendor and completely authenticate himself to the vendor while still hiding the communication from any observers---including compromised Onion Routing network components. Onion Routing can also be used to provide location hidden servers with better protection and yet less redundancy than standard approaches to distributed denial of service. In this paper we provide a brief overview of the Tor design. More detailed description is given in \cite{tor-design}. As we describe the system design, we will note how Onion Routing can be used to protect military communications in the above described settings. \subsection{Related Work} We give here a broad description of prior work; for a more complete list of references and comparisons, see \cite{tor-design}. Modern anonymity systems date to Chaum's {\bf Mix-Net} design \cite{chaum-mix}. Chaum proposed hiding the correspondence between sender and recipient by wrapping messages in layers of public-key cryptography, and relaying them through a path composed of ``mixes.'' Each mix in turn decrypts, delays, and re-orders messages, before relaying them toward their destinations. Subsequent relay-based anonymity designs have diverged in two main directions. Some have tried to maximize anonymity at the cost of introducing comparatively large and variable latencies. Because of this decision, these \emph{high-latency} networks resist strong global adversaries, but introduce too much lag for interactive tasks like web browsing, Internet chat, or SSH connections. Tor belongs to the second category: \emph{low-latency} designs that try to anonymize interactive network traffic. These systems handle a variety of bidirectional protocols. They also provide more convenient mail delivery than the high-latency anonymous email networks, because the remote mail server provides explicit and timely delivery confirmation. But because these designs typically involve many packets that must be delivered quickly, it is difficult for them to prevent an attacker who can eavesdrop both ends of the communication from correlating the timing and volume of traffic entering the anonymity network with traffic leaving it. These protocols are also vulnerable to active attacks in which an adversary introduces timing patterns into traffic entering the network and looks for correlated patterns among exiting traffic. Although some work has been done to frustrate these attacks, most designs protect primarily against traffic analysis rather than traffic confirmation (cf.\ Section~\ref{subsec:threat-model}). The simplest low-latency designs are single-hop proxies such as the Anonymizer \cite{anonymizer}, wherein a single trusted server strips the data's origin before relaying it. More complex are distributed-trust, circuit-based anonymizing systems. In these designs, a user establishes one or more medium-term bidirectional end-to-end circuits, and tunnels data in fixed-size cells. Establishing circuits is computationally expensive and typically requires public-key cryptography, whereas relaying cells is comparatively inexpensive and typically requires only symmetric encryption. Because a circuit crosses several servers, and each server only knows the adjacent servers in the circuit, no single server can link a user to her communication partners. There are many other circuit-based designs, that make a variety of design choices; we again refer the reader to \cite{tor-design} for more information. \section{Design goals and assumptions} \label{sec:assumptions} \noindent{\large\bf Goals}\\ Like other low-latency anonymity designs, Tor seeks to frustrate attackers from linking communication partners, or from linking multiple communications to or from a single user. Within this main goal, however, several considerations have directed Tor's evolution. \textbf{Diversity:} If all onion routers were operated by the defense department or ministry of a single nation and all users of the network were DoD users, then traffic patterns of individuals, enclaves, and commands can be protected from hostile observers, whether external or internal. However, any traffic emerging from the Onion Routing network to the Internet would still be recognized as coming from the DoD, since the network would only carry DoD traffic. Therefore, it is necessary that the Onion Routing network carry traffic of a broader class of users. Similarly, having onion routers run by diverse entities, including nonmilitary entities and entities from different countries, will help broaden and enlarge the class of users who will trust that system insiders will not monitor their traffic. This will provide both a greater diversity and greater volume of cover traffic. Unlike confidentiality, a single entity cannot achieve anonymity without collaboration, no matter how strong the technology. %This need %for diversity affects the way other goals must be pursued. \textbf{Deployability:} The design must be deployed and used in the real world. Thus it must not be expensive to run (for example, by requiring more bandwidth than onion router operators are willing to provide); must not place a heavy liability burden on operators (for example, by allowing attackers to implicate onion routers in illegal activities); and must not be difficult or expensive to implement (for example, by requiring kernel patches, or separate proxies for every protocol). We also cannot require non-anonymous parties (such as websites) to run our software. \textbf{Usability:} A hard-to-use system has fewer users---and because anonymity systems hide users among users, a system with fewer users provides less anonymity. Usability is thus not only a convenience: it is a security requirement \cite{econymics,back01}. Tor should therefore not require modifying applications; should not introduce prohibitive delays; and should require users to make as few configuration decisions as possible. Finally, Tor should be easily implemented on all common platforms; we cannot require users to change their operating system in order to be anonymous. (The current Tor implementation runs on Windows and assorted Unix clones including Linux, FreeBSD, and MacOS X.) \textbf{Flexibility:} The protocol must be flexible and well-specified, so Tor can serve as a test-bed for future research. Many of the open problems in low-latency anonymity networks, such as generating dummy traffic or preventing Sybil attacks (where one entity masquerades as many) \cite{sybil}, may be solvable independently from the issues solved by Tor. Hopefully future systems will not need to reinvent Tor's design. (But note that while a flexible design benefits researchers, there is a danger that differing choices of extensions will make users distinguishable. Experiments should be run on a separate network.) \textbf{Simple design:} The protocol's design and security parameters must be well-understood. Additional features impose implementation and complexity costs; adding unproven techniques to the design threatens deployability, readability, and ease of security analysis. Tor aims to deploy a simple and stable system that integrates the best accepted approaches to protecting anonymity.\\ \noindent{\large\bf Non-goals}\label{subsec:non-goals}\\ In favoring simple, deployable designs, we have explicitly deferred several possible goals, either because they are solved elsewhere, or because they are not yet solved. \textbf{Not peer-to-peer:} Tarzan and MorphMix aim to scale to completely decentralized peer-to-peer environments with thousands of short-lived servers, many of which may be controlled by an adversary. This approach is appealing, but still has many open problems, such as greater effects of Sybil attacks and of greater network dynamics \cite{tarzan:ccs02,morphmix:fc04}. \textbf{Not secure against end-to-end attacks:} We do not claim that Tor provides a definitive solution to end-to-end attacks, such as correlating the timing of connections opening or correlating when users are on the system with when certain traffic is observed (also known as intersection attacks). Some approaches may help, for example, accessing the network only through your own onion router; see \cite{tor-design} for more discussion. \textbf{No protocol normalization:} Tor does not provide \emph{protocol normalization} like Privoxy \cite{privoxy} or the Anonymizer \cite{anonymizer}. In other words, Tor anonymizes the channel, but not the data or applications that pass over it. This means that Tor in itself will not hide, for example, a web surfer from being identified by the data or application protocol information observed at a visited web site. If anonymization from the responder is desired for complex and variable protocols like HTTP, Tor must be layered with a filtering proxy such as Privoxy to hide differences between clients, and expunge protocol features that leak identity. Note that by this separation Tor can also provide services that are anonymous to the network yet authenticated to the responder, like SSH. So, for example, road warriors can make authenticated connections to their home systems without revealing this to anyone including the local network access point. Similarly, Tor does not currently integrate tunneling for non-stream-based protocols like UDP; this too must be provided by an external service. \textbf{Not steganographic:} Tor does not try to conceal who is connected to the network from someone in a position to observe that connection. \subsection{Threat Model} \label{subsec:threat-model} A global passive adversary is the most commonly assumed threat when analyzing theoretical anonymity designs. But like all practical low-latency systems, Tor does not protect against such a strong adversary. Instead, we assume an adversary who can observe some fraction of network traffic; who can generate, modify, delete, or delay traffic; who can operate onion routers of its own; and who can compromise some fraction of the onion routers. In low-latency anonymity systems that use layered encryption, the adversary's typical goal is to observe both the initiator and the responder. By observing both ends, passive attackers can confirm a suspicion that Alice is talking to Bob if the timing and volume patterns of the traffic on the connection are distinct enough; active attackers can induce timing signatures on the traffic to force distinct patterns. Rather than focusing on these \emph{traffic confirmation} attacks, we aim to prevent \emph{traffic analysis} attacks, where the adversary uses traffic patterns to learn which points in the network he should attack. Our adversary might try to link an initiator Alice with her communication partners, or try to build a profile of Alice's behavior. He might mount passive attacks by observing the network edges and correlating traffic entering and leaving the network---by relationships in packet timing, volume, or externally visible user-selected options. The adversary can also mount active attacks by compromising routers or keys; by replaying traffic; by selectively denying service to trustworthy routers to move users to compromised routers, or denying service to users to see if traffic elsewhere in the network stops; or by introducing patterns into traffic that can later be detected. The adversary might subvert the directory servers to give users differing views of network state. Additionally, he can try to decrease the network's reliability by attacking nodes or by performing antisocial activities from reliable servers and trying to get them taken down; making the network unreliable flushes users to other less anonymous systems, where they may be easier to attack. %The Tor design provides various protections against these various threats. %Discussion of how well the Tor design defends %against each of these attacks is presented in \cite{tor-design}. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \section{Highlights of the Tor Design} \label{sec:design} The Tor network is an overlay network; each onion router (OR) runs as a normal user-level process without any special privileges. Each onion router maintains a long-term TLS \cite{TLS} connection to every other onion router. Using TLS conceals the data on the connection with perfect forward secrecy (see below), and prevents an attacker from modifying data on the wire or impersonating an OR. Each user runs local software called an onion proxy (OP) to fetch directories, establish circuits across the network, and handle connections from user applications. These onion proxies accept TCP streams and multiplex them across the circuits. The onion router on the other side of the circuit connects to the destinations of the TCP streams and relays data. Traffic passes along these connections in fixed-size cells. Each cell is 512 bytes, and consists of a header and a payload. The header includes a circuit identifier (circID) that specifies which circuit the cell refers to (many circuits can be multiplexed over each TLS connection), and a command to describe what to do with the cell's payload. (Circuit identifiers are connection-specific: each single circuit has a different circID on each OP/OR or OR/OR connection it traverses.) Based on their command, cells are either \emph{control} cells, which are always interpreted by the node that receives them, or \emph{relay} cells, which carry end-to-end stream data. Relay cells have an additional header (the relay header) after the cell header, containing a stream identifier (many streams can be multiplexed over a circuit); an end-to-end checksum for integrity checking; the length of the relay payload; and a relay command. The entire contents of the relay header and the relay cell payload are encrypted or decrypted together as the relay cell moves along the circuit, using the 128-bit AES cipher in counter mode to generate a cipher stream. In Tor, just as each connection can be shared by many circuits, each circuit can be shared by many application-level TCP streams. To avoid delays, users construct circuits preemptively. To limit linkability among their streams, users' OPs build a new circuit periodically if the previous one has been used, and expire old used circuits that no longer have any open streams. OPs consider making a new circuit once a minute: thus even heavy users spend negligible time building circuits, but a limited number of requests can be linked to each other through a given exit node. Also, because circuits are built in the background, OPs can recover from failed circuit creation without delaying streams (which would harm user experience). The full Tor design paper \cite{tor-design} describes the Onion Routing protocol in detail; we highlight a few of its properties here: \begin{itemize} \item {\bf{Perfect forward secrecy:}} Onion Routing was originally vulnerable to a single hostile node recording traffic and later compromising successive nodes in the circuit and forcing them to decrypt it. Rather than using a single multiply encrypted data structure (an \emph{onion}) to lay each circuit, Tor now uses an incremental or \emph{telescoping} path-building design, where the initiator negotiates session keys with each successive hop in the circuit. Once these keys are deleted, subsequently compromised nodes cannot decrypt old traffic. As a side benefit, onion replay detection is no longer necessary, and the process of building circuits is more reliable, since the initiator knows when a hop fails and can then try extending to a new node. \item {\bf{Leaky-pipe circuit topology:}} Through in-band signaling within the circuit, Tor initiators can direct traffic to nodes partway down the circuit. This novel approach allows traffic to exit the circuit from the middle---possibly frustrating traffic shape and volume attacks based on observing the end of the circuit. (It also allows for long-range padding if future research shows this to be worthwhile.) \item {\bf{End-to-end integrity checking:}} The original Onion Routing design did no integrity checking on data. Any node on the circuit could change the contents of data cells as they passed by---for example, to alter a connection request so it would connect to a different webserver, or to `tag' encrypted traffic and look for corresponding corrupted traffic at the network edges \cite{minion-design}. Tor hampers these attacks by checking data integrity before it leaves the network. \item {\bf{Improved robustness to failed nodes:}} A failed node in the old design meant that circuit building failed, but thanks to Tor's step-by-step circuit building, users notice failed nodes while building circuits and route around them. Additionally, liveness information from directories allows users to avoid unreliable nodes in the first place. \item {\bf{Congestion control:}} Even with bandwidth rate limiting, we still need to worry about congestion, either accidental or intentional. If enough users choose the same OR-to-OR connection for their circuits, that connection can become saturated. For example, an attacker could send a large file through the Tor network to a webserver he runs, and then refuse to read any of the bytes at the webserver end of the circuit. Without some congestion control mechanism, these bottlenecks can propagate back through the entire network. We don't need to reimplement full TCP windows (with sequence numbers, the ability to drop cells when we're full and retransmit later, and so on), because TCP already guarantees in-order delivery of each cell. Tor provides both circuit and stream level throttling. \end{itemize} \section{Other design decisions} \subsection{Resource management and denial-of-service} \label{subsec:dos} Providing Tor as a public service creates many opportunities for denial-of-service attacks against the network. While flow control and rate limiting prevent users from consuming more bandwidth than routers are willing to provide, opportunities remain for users to consume more network resources than their fair share, or to render the network unusable for others. We discuss some of these in \cite{tor-design}. \subsection{Exit policies and abuse} \label{subsec:exitpolicies} Exit abuse is a serious barrier to wide-scale Tor deployment. Anonymity presents would-be vandals and abusers with an opportunity to hide the origins of their activities. Attackers can harm the Tor network by implicating exit servers for their abuse. Also, applications that commonly use IP-based authentication (such as institutional mail or webservers) can be fooled by the fact that anonymous connections appear to originate at the exit OR. We stress that Tor does not enable any new class of abuse. Spammers and other attackers already have access to thousands of misconfigured systems worldwide, and the Tor network is far from the easiest way to launch antisocial or illegal attacks. But because the onion routers can easily be mistaken for the originators of the abuse, and the volunteers who run them may not want to deal with the hassle of repeatedly explaining anonymity networks, we must block or limit the abuse that travels through the Tor network. To mitigate abuse issues, in Tor, each onion router's \emph{exit policy} describes to which external addresses and ports the router will connect. This is described further in \cite{tor-design}. Finally, we note that exit abuse must not be dismissed as a peripheral issue: when a system's public image suffers, it can reduce the number and diversity of that system's users, and thereby reduce the anonymity of the system itself. Like usability, public perception is a security parameter. Sadly, preventing abuse of open exit nodes is an unsolved problem, and will probably remain an arms race for the foreseeable future. The abuse problems faced by Princeton's CoDeeN project \cite{darkside} give us a glimpse of likely issues. \subsection{Directory Servers} \label{subsec:dirservers} First-generation Onion Routing designs \cite{freedom2-arch,or-jsac98} used 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, delays (accidental or intentional) that can cause different parts of the network to have different views of link-state and topology are not only inconvenient: they give attackers an opportunity to exploit differences in client knowledge, by observing induced differences in client behavior. 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 to efficiently deploy resources against a target \cite{minion-design}. Tor uses a small group of redundant, well-known onion routers to track changes in network topology and node state, including keys and exit policies. Each such \emph{directory server} acts as an HTTP server, so participants can fetch current network state and router lists, and so other ORs can upload state information. Onion routers periodically publish signed statements of their state to each directory server. The directory servers combine this state information with their own views of network liveness, and generate a signed description (a \emph{directory}) of the entire network state. Client software is pre-loaded with a list of the directory servers and their keys, to bootstrap each client's view of the network. More details are provided in \cite{tor-design}. Using directory servers is simpler and more flexible than flooding. Flooding is expensive, and complicates the analysis when we start experimenting with non-clique network topologies. Signed directories can be cached by other onion routers, so directory servers are not a performance bottleneck when we have many users, and do not aid traffic analysis by forcing clients to periodically announce their existence to any central point. \section{Rendezvous points and hidden services} \label{sec:rendezvous} Rendezvous points are a building block for \emph{location-hidden services} (also known as \emph{responder anonymity}) in the Tor network. Location-hidden services allow Bob to offer a TCP service, such as a webserver, without revealing its IP address. This type of anonymity protects against distributed DoS attacks: attackers are forced to attack the onion routing network as a whole rather than just Bob's IP address. Our design for location-hidden servers has the following goals. \textbf{Access-controlled:} Bob needs a way to filter incoming requests, so an attacker cannot flood Bob simply by making many connections to him. \textbf{Robust:} Bob should be able to maintain a long-term pseudonymous identity even in the presence of router failure. Bob's service must not be tied to a single OR, and Bob must be able to tie his service to new ORs. \textbf{Smear-resistant:} A social attacker who offers an illegal or disreputable location-hidden service should not be able to ``frame'' a rendezvous router by making observers believe the router created that service. \textbf{Application-transparent:} Although we require users to run special software to access location-hidden servers, we must not require them to modify their applications. We provide location-hiding for Bob by allowing him to advertise several onion routers (his \emph{introduction points}) as contact points. He may do this on any robust efficient key-value lookup system with authenticated updates, such as a distributed hash table (DHT) like CFS \cite{cfs:sosp01}\footnote{ Rather than rely on an external infrastructure, the Onion Routing network can run the DHT itself. At first, we can run a simple lookup system on the directory servers.} Alice, the client, chooses an OR as her \emph{rendezvous point}. She connects to one of Bob's introduction points, informs him of her rendezvous point, and then waits for him to connect to the rendezvous point. This extra level of indirection helps Bob's introduction points avoid problems associated with serving unpopular files directly (for example, if Bob serves material that the introduction point's community finds objectionable, or if Bob's service tends to get attacked by network vandals). The extra level of indirection also allows Bob to respond to some requests and ignore others. \subsection{Integration with user applications} Bob configures his onion proxy to know the local IP address and port of his service, a strategy for authorizing clients, and a public key. Bob publishes the public key, an expiration time (``not valid after''), and the current introduction points for his service into the DHT, indexed by the hash of the public key. Bob's webserver is unmodified, and doesn't even know that it's hidden behind the Tor network. Alice's applications also work unchanged---her client interface remains a SOCKS proxy. We encode all of the necessary information into the fully qualified domain name Alice uses when establishing her connection. Location-hidden services use a virtual top level domain called {\tt .onion}: thus hostnames take the form {\tt x.y.onion} where {\tt x} is the authorization cookie, and {\tt y} encodes the hash of the public key. Alice's onion proxy examines addresses; if they're destined for a hidden server, it decodes the key and starts the rendezvous as described above. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \section{Future Directions} \label{sec:conclusion} Tor brings together many innovations into a unified deployable system. The next immediate steps include: \emph{Scalability:} Tor's emphasis on deployability and design simplicity has led us to adopt a clique topology, semi-centralized directories, and a full-network-visibility model for client knowledge. These properties will not scale past a few hundred servers. The Tor design paper \cite{tor-design} describes some promising approaches, but more deployment experience will be helpful in learning the relative importance of these bottlenecks. \emph{Bandwidth classes:} This paper assumes that all ORs have good bandwidth and latency. We should instead adopt the MorphMix model, where nodes advertise their bandwidth level (DSL, T1, T3), and Alice avoids bottlenecks by choosing nodes that match or exceed her bandwidth. In this way DSL users can usefully join the Tor network. \emph{Incentives:} Volunteers who run nodes are rewarded with potentially better anonymity, and those who value the notoriety can be rewarded with publicity \cite{econymics}. More nodes means increased scalability, and more users can mean more anonymity. We need to continue examining the incentive structures for participating in Tor. \emph{Padding Cover traffic:} Currently Tor omits padding for cover traffic---its costs in performance and bandwidth are clear but its security benefits are not well understood. We must pursue more research on link-level cover traffic and long-range cover traffic to determine whether some simple padding method offers provable protection against our chosen adversary. \emph{Caching at exit nodes:} Perhaps each exit node should run a caching web proxy, to improve anonymity for cached pages (Alice's request never leaves the Tor network), to improve speed, and to reduce bandwidth cost. On the other hand, forward security is weakened because caches constitute a record of retrieved files. We must find the right balance between usability and security. \emph{Better directory distribution:} Clients currently download a description of the entire network every 15 minutes. As the state grows larger and clients more numerous, we may need a solution in which clients receive incremental updates to directory state. More generally, we must find more scalable yet practical ways to distribute up-to-date snapshots of network status without introducing new attacks. \emph{Implement location-hidden services:} The design in Section~\ref{sec:rendezvous} has not yet been implemented. While doing so we are likely to encounter additional issues that must be resolved, both in terms of usability and anonymity. \emph{Further specification review:} Although we have a public byte-level specification for the Tor protocols, it needs extensive external review. We hope that as Tor is more widely deployed, more people will examine its specification. \emph{Multisystem interoperability:} We are currently working with the designer of MorphMix to unify the specification and implementation of the common elements of our two systems. So far, this seems to be relatively straightforward. Interoperability will allow testing and direct comparison of the two designs for trust and scalability. \emph{Wider-scale deployment:} The original goal of Tor was to gain experience in deploying an anonymizing overlay network, and learn from having actual users. As of writing there is a distributed network of roughly a dozen nodes. We are now at a point in design and development where we can start deploying a wider network. Once we have many actual users, we will doubtlessly be better able to evaluate some of our design decisions, including our robustness/latency tradeoffs, our performance tradeoffs (including cell size), our abuse-prevention mechanisms, and our overall usability. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %% commented out for anonymous submission %\section*{Acknowledgments} % Peter Palfrader, Geoff Goodell, Adam Shostack, Joseph Sokol-Margolis, % John Bashinski, Zack Brown: % for editing and comments. % Matej Pfajfar, Andrei Serjantov, Marc Rennhard: for design discussions. % Bram Cohen for congestion control discussions. % Adam Back for suggesting telescoping circuits. % Cathy Meadows for formal analysis of the extend protocol. % This work supported by ONR and DARPA. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \bibliographystyle{plain} \bibliography{nato-rta04} \end{document} % Style guide: % U.S. spelling % avoid contractions (it's, can't, etc.) % prefer ``for example'' or ``such as'' to e.g. % prefer ``that is'' to i.e. % 'mix', 'mixes' (as noun) % 'mix-net' % 'mix', 'mixing' (as verb) % 'middleman' [Not with a hyphen; the hyphen has been optional % since Middle English.] % 'nymserver' % 'Cypherpunk', 'Cypherpunks', 'Cypherpunk remailer' % 'Onion Routing design', 'onion router' [note capitalization] % 'SOCKS' % Try not to use \cite as a noun. % 'Authorizating' sounds great, but it isn't a word. % 'First, second, third', not 'Firstly, secondly, thirdly'. % 'circuit', not 'channel' % Typography: no space on either side of an em dash---ever. % Hyphens are for multi-part words; en dashs imply movement or % opposition (The Alice--Bob connection); and em dashes are % for punctuation---like that. % A relay cell; a control cell; a \emph{create} cell; a % \emph{relay truncated} cell. Never ``a \emph{relay truncated}.'' % % 'Substitute ``Damn'' every time you're inclined to write ``very;'' your % editor will delete it and the writing will be just as it should be.' % -- Mark Twain