[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[or-cvs] No content cut. Just lots of space games. Will keep at it.
Update of /home/or/cvsroot/doc
In directory moria.mit.edu:/tmp/cvs-serv26865
Modified Files:
tor-design.tex
Added Files:
latex8.sty
Log Message:
No content cut. Just lots of space games. Will keep at it.
--- NEW FILE: latex8.sty ---
% ---------------------------------------------------------------
%
% $Id: latex8.sty,v 1.1 2003/11/04 18:00:40 syverson Exp $
%
% by Paolo.Ienne@di.epfl.ch
%
% ---------------------------------------------------------------
%
% no guarantee is given that the format corresponds perfectly to
% IEEE 8.5" x 11" Proceedings, but most features should be ok.
%
% ---------------------------------------------------------------
% with LaTeX2e:
% =============
%
% use as
% \documentclass[times,10pt,twocolumn]{article}
% \usepackage{latex8}
% \usepackage{times}
%
% ---------------------------------------------------------------
% with LaTeX 2.09:
% ================
%
% use as
% \documentstyle[times,art10,twocolumn,latex8]{article}
%
% ---------------------------------------------------------------
% with both versions:
% ===================
%
% specify \pagestyle{empty} to omit page numbers in the final
% version
%
% specify references as
% \bibliographystyle{latex8}
% \bibliography{...your files...}
%
% use Section{} and SubSection{} instead of standard section{}
% and subsection{} to obtain headings in the form
% "1.3. My heading"
%
% ---------------------------------------------------------------
\typeout{IEEE 8.5 x 11-Inch Proceedings Style `latex8.sty'.}
% ten point helvetica bold required for captions
% in some sites the name of the helvetica bold font may differ,
% change the name here:
\font\tenhv = phvb at 10pt
%\font\tenhv = phvb7t at 10pt
% eleven point times bold required for second-order headings
% \font\elvbf = cmbx10 scaled 1100
\font\elvbf = ptmb scaled 1100
% set dimensions of columns, gap between columns, and paragraph indent
\setlength{\textheight}{8.875in}
\setlength{\textwidth}{6.875in}
%\setlength{\columnsep}{0.3125in}
\setlength{\columnsep}{0.26in}
\setlength{\topmargin}{0in}
\setlength{\headheight}{0in}
\setlength{\headsep}{.5in}
\setlength{\parindent}{1pc}
\setlength{\oddsidemargin}{-.304in}
\setlength{\evensidemargin}{-.304in}
% memento from size10.clo
% \normalsize{\@setfontsize\normalsize\@xpt\@xiipt}
% \small{\@setfontsize\small\@ixpt{11}}
% \footnotesize{\@setfontsize\footnotesize\@viiipt{9.5}}
% \scriptsize{\@setfontsize\scriptsize\@viipt\@viiipt}
% \tiny{\@setfontsize\tiny\@vpt\@vipt}
% \large{\@setfontsize\large\@xiipt{14}}
% \Large{\@setfontsize\Large\@xivpt{18}}
% \LARGE{\@setfontsize\LARGE\@xviipt{22}}
% \huge{\@setfontsize\huge\@xxpt{25}}
% \Huge{\@setfontsize\Huge\@xxvpt{30}}
\def\@maketitle
{
\newpage
\null
\vskip .375in
\begin{center}
{\Large \bf \@title \par}
% additional two empty lines at the end of the title
\vspace*{24pt}
{
\large
\lineskip .5em
\begin{tabular}[t]{c}
\@author
\end{tabular}
\par
}
% additional small space at the end of the author name
\vskip .5em
{
\large
\begin{tabular}[t]{c}
\@affiliation
\end{tabular}
\par
\ifx \@empty \@email
\else
\begin{tabular}{r@{~}l}
E-mail: & {\tt \@email}
\end{tabular}
\par
\fi
}
% additional empty line at the end of the title block
\vspace*{12pt}
\end{center}
}
\def\abstract
{%
\centerline{\large\bf Abstract}%
\vspace*{12pt}%
\it%
}
\def\endabstract
{
% additional empty line at the end of the abstract
\vspace*{12pt}
}
\def\affiliation#1{\gdef\@affiliation{#1}} \gdef\@affiliation{}
\def\email#1{\gdef\@email{#1}}
\gdef\@email{}
\newlength{\@ctmp}
\newlength{\@figindent}
\setlength{\@figindent}{1pc}
\long\def\@makecaption#1#2{
\vskip 10pt
\setbox\@tempboxa\hbox{\tenhv\noindent #1.~#2}
\setlength{\@ctmp}{\hsize}
\addtolength{\@ctmp}{-\@figindent}\addtolength{\@ctmp}{-\@figindent}
% IF longer than one indented paragraph line
\ifdim \wd\@tempboxa >\@ctmp
% THEN set as an indented paragraph
\begin{list}{}{\leftmargin\@figindent \rightmargin\leftmargin}
\item[]\tenhv #1.~#2\par
\end{list}
\else
% ELSE center
\hbox to\hsize{\hfil\box\@tempboxa\hfil}
\fi}
% correct heading spacing and type
\def\section{\@startsection {section}{1}{\z@}
{14pt plus 2pt minus 2pt}{14pt plus 2pt minus 2pt} {\large\bf}}
\def\subsection{\@startsection {subsection}{2}{\z@}
{13pt plus 2pt minus 2pt}{13pt plus 2pt minus 2pt} {\elvbf}}
% add the period after section numbers
\newcommand{\Section}[1]{\section{\hskip -1em.~#1}}
\newcommand{\SubSection}[1]{\subsection{\hskip -1em.~#1}}
% end of file latex8.sty
% ---------------------------------------------------------------
Index: tor-design.tex
===================================================================
RCS file: /home/or/cvsroot/doc/tor-design.tex,v
retrieving revision 1.100
retrieving revision 1.101
diff -u -d -r1.100 -r1.101
--- tor-design.tex 4 Nov 2003 14:59:58 -0000 1.100
+++ tor-design.tex 4 Nov 2003 18:00:40 -0000 1.101
@@ -10,6 +10,10 @@
\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
@@ -57,7 +61,7 @@
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 trade-off between anonymity, usability, and efficiency. We
+reasonable tradeoff between anonymity, usability, and efficiency. We
close with a list of open problems in anonymous communication.
\end{abstract}
@@ -73,14 +77,14 @@
Onion Routing is a distributed overlay network designed to anonymize
low-latency TCP-based applications such as web browsing, secure shell,
and instant messaging. Clients choose a path through the network and
-build a \emph{circuit}, in which each node (or ``onion router'')
+build a \emph{circuit}, in which each node (or ``onion router'' or ``OR'')
in the path knows its predecessor and successor, but no other nodes in
the circuit. Traffic flowing down the circuit is sent in fixed-size
\emph{cells}, which are unwrapped by a symmetric key at each node
-(like the layers of an onion) and relayed downstream. The original
+(like the layers of an onion) and relayed downstream. The
Onion Routing project published several design and analysis papers
\cite{or-ih96,or-jsac98,or-discex00,or-pet00}. While a wide area Onion
-Routing network was deployed for some weeks, the only long-running and
+Routing network was deployed briefly, the only long-running and
publicly accessible implementation was a fragile
proof-of-concept that ran on a single machine. Even this simple deployment
processed connections from over sixty thousand distinct IP addresses from
@@ -91,10 +95,8 @@
routers that provides the following improvements over the old Onion
Routing design:
-\begin{tightlist}
-
-\item \textbf{Perfect forward secrecy:} The original Onion Routing
-design was vulnerable to a single hostile node recording traffic and
+\textbf{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,
@@ -106,8 +108,8 @@
reliable, since the initiator knows when a hop fails and can then try
extending to a new node.
-\item \textbf{Separation of ``protocol cleaning'' from anonymity:}
-The original Onion Routing design required a separate ``application
+\textbf{Separation of ``protocol cleaning'' from anonymity:}
+Onion Routing originally required a separate ``application
proxy'' for each supported application protocol---most of which were
never written, so many applications were never supported. Tor uses the
standard and near-ubiquitous SOCKS \cite{socks4} proxy interface, allowing
@@ -116,40 +118,38 @@
application-level proxies such as Privoxy \cite{privoxy}, without trying
to duplicate those features itself.
-\item \textbf{No mixing, padding, or traffic shaping yet:} The original
-Onion
-Routing design called for batching and reordering cells arriving from
-each source. It also included padding between onion routers and, in a
+\textbf{No mixing, padding, or traffic shaping yet:} Onion
+Routing originally called for batching and reordering cells arriving from
+each source, and assumed padding between ORs and, in a
later design, between onion proxies (users) and onion routers
-\cite{or-ih96,or-jsac98}. The trade-off between padding protection
-and cost was discussed, but no general padding scheme was suggested. In
-\cite{or-pet00} it was theorized \emph{traffic shaping} would generally
-be used, but details were not provided. Recent research \cite{econymics}
+\cite{or-ih96,or-jsac98}. Tradeoffs between padding protection
+and cost were discussed, but no general padding scheme was suggested.
+It was theorized, \cite{or-pet00}, but not described how \emph{traffic
+ shaping} would generally be used. Recent research \cite{econymics}
and deployment experience \cite{freedom21-security} suggest that this
-level of resource use is not practical or economical; and even full link
-padding is still vulnerable \cite{defensive-dropping}. Thus, until we
-have a proven and convenient design for traffic shaping or low-latency
-mixing that will improve anonymity against a realistic adversary, we
-leave these strategies out.
+level of resource use is not practical or economical; and even full
+link padding is still vulnerable \cite{defensive-dropping}. Thus,
+until we have a proven and convenient design for traffic shaping or
+low-latency mixing that will improve anonymity against a realistic
+adversary, we leave these strategies out.
-\item \textbf{Many TCP streams can share one circuit:} The
-original Onion Routing design built a separate circuit for each
-application-level request. This hurt performance by requiring
-multiple public key operations for every request, and also presented
+\textbf{Many TCP streams can share one circuit:} Onion Routing originally
+built a separate circuit for each
+application-level request, requiring
+multiple public key operations for every request, and also presenting
a threat to anonymity from building so many different circuits; see
Section~\ref{sec:maintaining-anonymity}. Tor multiplexes multiple TCP
streams along each circuit to improve efficiency and anonymity.
-\item \textbf{Leaky-pipe circuit topology:} Through in-band signaling
+\textbf{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 for long-range padding if
-future research indicates that it can frustrate traffic shape and volume
-attacks at the initiator \cite{defensive-dropping}, and
-also allows traffic to exit the circuit from the middle---again possibly
+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.
+of the circuit. (It also allows for long-range padding if
+future research shows this to be worthwhile.)
-\item \textbf{Congestion control:} Earlier anonymity designs do not
+\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. Tor's decentralized
@@ -157,24 +157,24 @@
while allowing nodes at the edges of the network to detect congestion
or flooding and send less data until the congestion subsides.
-\item \textbf{Directory servers:} The original Onion Routing design
+\textbf{Directory servers:} Earlier Onion Routing design
planned to flood link-state information through the network---an approach
that can be unreliable and open to partitioning attacks or
deception. Tor takes a simplified view toward distributing link-state
-information. Certain more trusted onion routers act as \emph{directory
+information. Certain more trusted nodes act as \emph{directory
servers}: they provide signed directories that describe known
routers and their availability. Users periodically download these
directories via HTTP.
-\item \textbf{Variable exit policies:} Tor provides a consistent mechanism
+\textbf{Variable exit policies:} Tor provides a consistent mechanism
for each node to advertise a policy describing the hosts
and ports to which it will connect. These 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{End-to-end integrity checking:} The original Onion Routing
-design did no integrity checking on data. Any onion router on the
+\textbf{End-to-end integrity checking:} The original Onion Routing
+design did no integrity checking on data. Any OR on the
circuit could change the contents of data cells as they passed by---for
example, to alter a connection request on the fly so it would connect
to a different webserver, or to `tag' encrypted traffic and look for
@@ -182,14 +182,14 @@
Tor hampers these attacks by checking data integrity before it leaves
the network.
-\item \textbf{Improved robustness to failed nodes:} A failed node
+\textbf{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 \textbf{Rendezvous points and location-protected servers:}
+\textbf{Rendezvous points and location-protected servers:}
Tor provides an integrated mechanism for responder anonymity via
location-protected servers. Previous Onion Routing designs included
long-lived ``reply onions'' that could be used to build circuits
@@ -197,12 +197,12 @@
security, and became useless if any node in the path went down
or rotated its keys. In Tor, clients negotiate {\it rendezvous points}
to connect with hidden servers; reply onions are no longer required.
-\end{tightlist}
-Unlike Freedom \cite{freedom2-arch}, Tor only
-attempts to anonymize TCP streams. Because it does not require patches
-(or built-in support) in an operating system's network stack, this
-approach has proven valuable to Tor's portability and deployability.
+
+Unlike Freedom \cite{freedom2-arch}, Tor only tries to anonymize
+TCP streams. It does not require patches (or built-in support) in an
+operating system's network stack, which has been valuable to Tor's
+portability and deployability.
We have implemented most of the above features. Our source code is
available under a free license, and, as far as we know, is unencumbered by
@@ -227,13 +227,13 @@
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 of these mixes in turn
+wrapping messages in layers of public-key cryptography, and relaying them
+through a path composed of ``mixes.'' Each of these in turn
decrypts, delays, and re-orders messages, before relaying them toward
their destinations.
Subsequent relay-based anonymity designs have diverged in two
-principal directions. Some have attempted to maximize anonymity at
+main directions. Some have tried to maximize anonymity at
the cost of introducing comparatively large and variable latencies,
including {\bf Babel} \cite{babel}, {\bf Mixmaster}
\cite{mixmaster-spec}, and
@@ -244,12 +244,12 @@
internet chat, or SSH connections.
Tor belongs to the second category: \emph{low-latency} designs that
-attempt to anonymize interactive network traffic. These systems handle
+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 fire-and-forget anonymous email
-%networks, because the remote mail server provides explicit delivery
-%confirmation.
+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
@@ -260,15 +260,15 @@
looks
for correlated patterns among exiting traffic.
Although some work has been done to frustrate
-these attacks,\footnote{
- The most common approach is to pad and limit communication to a constant
- rate, or to limit
- the variation in traffic shape. Doing so can have prohibitive bandwidth
- costs and/or performance limitations.
-} most designs protect primarily against traffic analysis rather than traffic
-confirmation \cite{or-jsac98}---that is, they assume that the attacker is
-attempting to learn who is talking to whom, not to confirm a prior suspicion
-about who is talking to whom.
+these attacks,%\footnote{
+% The most common approach is to pad and limit communication to a constant
+% rate, or to limit
+% the variation in traffic shape. Doing so can have prohibitive bandwidth
+% costs and/or performance limitations.
+%}
+% Point in the footnote is covered above, yes? -PS
+ 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
{\bf Anonymizer} \cite{anonymizer}, wherein a single trusted server strips the
@@ -299,10 +299,11 @@
implementation's padding policy improves anonymity.
{\bf PipeNet} \cite{back01, pipenet}, another low-latency design proposed at
-about the same time as the original Onion Routing design, provided
+about the same time as Onion Routing, provided
stronger anonymity at the cost of allowing a single user to shut
down the network simply by not sending. Low-latency anonymous
-communication has also been designed for other environments such as
+communication has also been designed for different environments with
+different assumptions, such as
ISDN \cite{isdn-mixes}.
In P2P designs like {\bf Tarzan} \cite{tarzan:ccs02} and {\bf MorphMix}
@@ -379,7 +380,7 @@
\Section{Design goals and assumptions}
\label{sec:assumptions}
-\SubSection{Goals}
+\noindent {\large 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
@@ -426,13 +427,13 @@
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 well-understood
-approaches to protecting anonymity.
+approaches to protecting anonymity.\\
-\SubSection{Non-goals}
+\noindent {\large 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
-their solution is an open research problem.
+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
@@ -606,7 +607,7 @@
\SubSection{Circuits and streams}
\label{subsec:circuits}
-The original Onion Routing design built one circuit for each
+Onion Routing originally built one circuit for each
TCP stream. Because building a circuit can take several tenths of a
second (due to public-key cryptography delays and network latency),
this design imposed high costs on applications like web browsing that
@@ -918,8 +919,7 @@
%see Section~\ref{sec:maintaining-anonymity} for more discussion.
We describe our response below.
-\subsubsection{Circuit-level throttling}
-
+\textbf{Circuit-level throttling:}
To control a circuit's bandwidth usage, each OR keeps track of two
windows. The \emph{packaging window} tracks how many relay data cells the OR is
allowed to package (from outside TCP streams) for transmission back to the OP,
@@ -939,8 +939,7 @@
and a delivery window for every OR in the circuit. If a packaging window
reaches 0, it stops reading from streams destined for that OR.
-\subsubsection{Stream-level throttling}
-
+\textbf{Stream-level throttling}:
The stream-level congestion control mechanism is similar to the
circuit-level mechanism above. ORs and OPs use \emph{relay sendme} cells
to implement end-to-end flow control for individual streams across
@@ -1240,6 +1239,7 @@
We give an overview of the steps of a rendezvous. These steps are
performed on behalf of Alice and Bob by their local onion proxies;
application integration is described more fully below.
+
\begin{tightlist}
\item Bob chooses some introduction points, and advertises them on
the DHT. He can add more later.
@@ -1271,6 +1271,37 @@
communicate as normal.
\end{tightlist}
+\workingnote{
+\noindent$\bullet$ Bob chooses some introduction points, and advertises them on
+ the DHT. He can add more later.\\
+$\bullet$ Bob establishes a Tor circuit to each of his introduction points,
+ and waits. No data is transmitted until a request is received.\\
+$\bullet$ Alice learns about Bob's service out of band (perhaps Bob told her,
+ or she found it on a website). She retrieves the details of Bob's
+ service from the DHT.\\
+$\bullet$ Alice chooses an OR to serve as the rendezvous point (RP) for this
+ transaction. She establishes a circuit to RP, and gives it a
+ rendezvous cookie, which it will use to recognize Bob.\\
+$\bullet$ Alice opens an anonymous stream to one of Bob's introduction
+ points, and gives it a message (encrypted to Bob's public key) which tells him
+ about herself, her chosen RP and the rendezvous cookie, and the
+ first half of an ephemeral
+ key handshake. The introduction point sends the message to Bob.\\
+$\bullet$ If Bob wants to talk to Alice, he builds a new circuit to Alice's
+ RP and provides the rendezvous cookie and the second half of the DH
+ handshake (along with a hash of the session
+ key they now share---by the same argument as in
+ Section~\ref{subsubsec:constructing-a-circuit}, Alice knows she
+ shares the key only with the intended Bob).\\
+$\bullet$ The RP connects Alice's circuit to Bob's. Note that RP can't
+ recognize Alice, Bob, or the data they transmit.\\
+$\bullet$ Alice now sends a \emph{relay begin} cell along the circuit. It
+ arrives at Bob's onion proxy. Bob's onion proxy connects to Bob's
+ webserver.\\
+$\bullet$ An anonymous stream has been established, and Alice and Bob
+ communicate as normal.
+}
+
When establishing an introduction point, Bob provides the onion router
with a public ``introduction'' key. The hash of this public key
identifies a unique service, and (since Bob is required to sign his
@@ -1419,7 +1450,7 @@
of \cite{back01}. Those require a fingerprint of the latencies of
all circuits through the network, combined with those from the
network edges to the targeted user and the responder website. While
-these are in principal feasible and surprises are always possible,
+these are in principle feasible and surprises are always possible,
these constitute a much more complicated attack, and there is no
current evidence of their practicality.}
@@ -1486,8 +1517,7 @@
by bandwidth throttling. Nonetheless, in order to compromise the
anonymity of the endpoints of a circuit by its observations, a
hostile node must be immediately adjacent to that endpoint.
-
-\emph{Run multiple hostile nodes.} If an adversary is able to
+If an adversary is able to
run multiple ORs, and is able to persuade the directory servers
that those ORs are trustworthy and independant, then occasionally
some user will choose one of those ORs for the start and another
@@ -1574,10 +1604,9 @@
\emph{Subvert a majority of directory servers.} If the
adversary controls more than half of the directory servers, he can
decide on a final directory, and thus can include as many
-compromised ORs in the final directory as he wishes. Other than
-trying to ensure that directory server operators are truly
-independent and resistant to attack, Tor does not address this
-possibility.
+compromised ORs in the final directory as he wishes.
+Tor does not address this possibility, except to try to ensure that
+directory server operators are independent and attack resistant.
\emph{Encourage directory server dissent.} The directory
agreement protocol requires that directory server operators agree on
@@ -1589,22 +1618,23 @@
\emph{Trick the directory servers into listing a hostile OR.}
Our threat model explicitly assumes directory server operators will
-be able to filter out most hostile ORs. If this is not true, an
-attacker can flood the directory with compromised servers.
+be able to filter out most hostile ORs.
+% If this is not true, an
+% attacker can flood the directory with compromised servers.
\emph{Convince the directories that a malfunctioning OR is
working.} In the current Tor implementation, directory servers
-assume that if they can start a TLS connection to an an OR, that OR
-must be running correctly. It would be easy for a hostile OR to
-subvert this test by only accepting TLS connections from ORs, and
-ignoring all cells. Thus, directory servers must actively test ORs
-by building circuits and streams as appropriate. The benefits and
-hazards of a similar approach are discussed in \cite{mix-acc}.
+assume that an OR is running correctly if they can start a TLS
+connection to it. A hostile OR could easily subvert this test by
+accepting TLS connections from ORs but ignoring all cells. Directory
+servers must actively test ORs by building circuits and streams as
+appropriate. The tradeoffs of a similar approach are discussed in
+\cite{mix-acc}.
\subsubsection*{Attacks against rendezvous points}
\emph{Make many introduction requests.} An attacker could
-attempt to deny Bob service by flooding his Introduction Point with
+try to deny Bob service by flooding his Introduction Point with
requests. Because the introduction point can block requests that
lack authentication tokens, however, Bob can restrict the volume of
requests he receives, or require a certain amount of computation for
@@ -1615,8 +1645,7 @@
point. But because a service's identity is attached to its public
key, not its introduction point, the service can simply re-advertise
itself at a different introduction point.
-
-\emph{Attack multiple introduction points.} If an attacker is
+If an attacker is
able to disable all of the introduction points for a given service,
he can block access to the service. However, re-advertisement of
introduction points can still be done secretly so that only
@@ -1653,7 +1682,7 @@
user's traffic linkable. Along with opening a fresh circuit, clients can
also limit linkability by exiting from a middle point of the circuit,
or by truncating and re-extending the circuit; but more analysis is
-needed to determine the proper trade-off.
+needed to determine the proper tradeoff.
A similar question surrounds timing of directory operations: how often
should directories be updated? Clients that update infrequently receive
@@ -1812,7 +1841,7 @@
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 trade-offs, our performance trade-offs (including
+robustness/latency tradeoffs, our performance tradeoffs (including
cell size), our abuse-prevention mechanisms, and
our overall usability.