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.
+% Perhaps mention that not all of these are things that we invented. -NM
+
\item \textbf{Separation of protocol cleaning from anonymity:}
The original Onion Routing design required a separate ``application
proxy'' for each
vulnerable to active attacks \cite{defensive-dropping}.
%[An upcoming FC04 paper. I'll add a cite when it's out. -RD]
+%Say that: although some less resource-heavy traffic shaping approaches may
+%help resist certain attacks, we aren't getting on the bandwagon yet? -NM.
+
\item \textbf{Leaky-pipe circuit topology:} Through in-band
signalling within the
circuit, Tor initiators can direct traffic to nodes partway down the
the cost of introducing comparatively large and variable latencies,
for example, Babel\cite{babel}, Mixmaster\cite{mixmaster-spec}, and
Mixminion\cite{minion-design}. Because of this
-decision, such \emph{high-latency} networks are well-suited for anonymous
+trade-off, such \emph{high-latency} networks are well-suited for anonymous
email, but introduce too much lag for interactive tasks such as web browsing,
internet chat, or SSH connections.
+% Parts of this graf belongs later in expository order. Some of the
+% sentences seem superficially unrelated.
Tor belongs to the second category: \emph{low-latency} designs that
attempt to anonymize interactive network traffic. Because such
traffic tends to involve a relatively large numbers of packets, it is
\cite{web-mix}).
Another low latency design that was proposed independently and at
-about the same time as Onion Routing was PipeNet \cite{pipenet}.
-This provided anonymity protections that were stronger than Onion Routing's,
+about the same time as the original Onion Routing was PipeNet \cite{pipenet}.
+It provided anonymity protections that were stronger than Onion Routing's,
but at the cost of allowing a single user to shut down the network simply
by not sending. It was also never implemented or formally published.
comparatively inexpensive. Because a tunnel crosses several servers, no
single server can learn the user's communication partners.
-Systems such as earlier versions of Freedom and Onion Routing
-build the anonymous channel all at once (using an onion). Later
-designs of Freedom and Onion Routing as described herein build
-the channel in stages as does AnonNet
+%[Ouch: We haven't said what an onion is yet, but we use the word here! -NM]
+Systems such as earlier versions of Freedom and the original Onion Routing
+build the anonymous channel all at once (using an onion).
+Later designs of Freedom and Tor as described herein build
+the channel in stages, as does AnonNet
\cite{anonnet}. Amongst other things, this makes perfect forward
secrecy feasible.
Distributed-trust anonymizing systems differ in how they prevent attackers
from controlling too many servers and thus compromising too many user paths.
Some protocols rely on a centrally maintained set of well-known anonymizing
-servers. Current Tor design falls into this category.
+servers. The current Tor design falls into this category.
Others (such as Tarzan and MorphMix) allow unknown users to run
servers, while using a limited resource (DHT space for Tarzan; IP space for
MorphMix) to prevent an attacker from owning too much of the network.
\subsection{Goals}
-% Are these really our goals? ;) -NM
+% Reformat this section like ``Adversary Model'' is formatted. -NM
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 point. Within this
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.
+systems. In order to be usable, Tor should with most of a
+user's unmodified aplication; shouldn't introduce prohibitive delays; and
+[XXX what else?].
Third, the protocol must be {\bf extensible}, so that it can serve as
a test-bed for future research in low-latency anonymity systems.
distinguishable. Thus, implementations should not permit different
protocol extensions to coexist in a single deployed network.)
+% We should mention that there's a specification someplace: the spec makes us
+% easier to extend too. -NM
+
The protocol's design and security parameters must be {\bf
conservative}. Additional features impose implementation and
complexity costs. [XXX Say that we don't want to try to come up with
speculative solutions to problems we don't KNOW how to solve? -NM]
-[XXX mention something about robustness? But we really aren't that
- robust. We just assume that tunneled protocols tolerate connection
- loss. -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
+anonymity systems --- but because they are either solved
elsewhere, or an area of active research without a generally accepted
solution.
Unlike Tarzan or Morphmix, Tor does not attempt to scale to completely
decentralized peer-to-peer environments with thousands of short-lived
-servers.
+servers, many of which may be controlled by an adversary.
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.
+% Mention would-be approaches. -NM
% Does that mean we do claim to solve intersection attack for
% the enclave-firewall model? -RD
% for later. -PS
-\item[Compromised Tor-node:] can arbitrarily manipulate the
+\item{Hostile Tor node:] can arbitrarily manipulate the
connections under its control, as well as creating new connections
(that pass through itself).
\end{description}
\SubSection{Known attacks against low-latency anonymity systems}
\label{subsec:known-attacks}
+% Should be merged into ``Threat model'' and reiterated in Attacks. -NM
We discuss each of these attacks in more detail below, along with the
aspects of the Tor design that provide defense. We provide a summary
selectively DOS servers,
introduce timing into messages,
directory attacks,
-tagging attacks
+tagging attacks,
+smear attacks,
+entrapment attacks
\SubSection{Assumptions}
+% Should be merged into ``Threat model''.
For purposes of this paper, we assume all directory servers are honest
% No longer true, see subsec:dirservers below -RD
of the spectrum are \emph{open exit} nodes that will connect anywhere;
on the other end are \emph{middleman} nodes that only relay traffic to
other Tor nodes, and \emph{private exit} nodes that only connect locally
-or to addresses internal to that node's organization. This private exit
+or to addresses internal to that node's organization.
+This private exit
node configuration is more secure for clients --- the adversary cannot
see plaintext traffic leaving the network (e.g. to a webserver), so he
is less sure of Alice's destination. More generally, nodes can require
a variety of forms of traffic authentication \cite{onion-discex00}.
+Most onnion routers will function as \emph{limited exits} that permit
+connections to the world at large, but restrict access to certain abuse-prone
+addresses and services.
Tor offers more reliability than the high-latency fire-and-forget
anonymous email networks, because the sender opens a TCP stream
Preventing abuse of open exit nodes is an unsolved problem. Princeton's
CoDeeN project \cite{darkside} gives us a glimpse of what we're in for.
+% This is more speculative than a description of our design.
but their solutions, which mainly involve rate limiting and blacklisting
nodes which do bad things, don't translate directly to Tor. Rate limiting
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
+that can 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
are not a performance bottleneck when we have many users, and also they
won't aid traffic analysis by forcing clients to periodically announce
their existence to any central point.
+% Mention Hydra as an example of non-clique topologies. -NM, from RD
\Section{Rendezvous points: location privacy}
\label{sec:rendezvous}
\item foo
\end{itemize}
+\item \textbf{Attacks against rendezvous points}
+\begin{itemize}
+\item foo
+\end{itemize}
+
\end{enumerate}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
from having actual users. We are now at the point where we can start
deploying a wider network. We will see what happens!
% ok, so that's hokey. fix it. -RD
+\item \emph{Further specification review:} Foo.
\end{itemize}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
projects / thirdparty / tor.git / commitdiff
