[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[or-cvs] move some stuff around in sections 1,2,3. Not done yet; st...
Update of /home/or/cvsroot/tor/doc/design-paper
In directory moria.mit.edu:/tmp/cvs-serv20762
Modified Files:
challenges.tex
Log Message:
move some stuff around in sections 1,2,3. Not done yet; still need to work on "Distributed Trust", "related work"
Index: challenges.tex
===================================================================
RCS file: /home/or/cvsroot/tor/doc/design-paper/challenges.tex,v
retrieving revision 1.41
retrieving revision 1.42
diff -u -d -r1.41 -r1.42
--- challenges.tex 7 Feb 2005 03:39:34 -0000 1.41
+++ challenges.tex 7 Feb 2005 05:52:49 -0000 1.42
@@ -1,4 +1,6 @@
\documentclass{llncs}
+% XXXX NM: Fold ``bandwidth and usability'' into ``Tor and filesharing'' --
+% ``bandwidth and file-sharing''.
\usepackage{url}
\usepackage{amsmath}
@@ -16,74 +18,71 @@
\title{Challenges in deploying low-latency anonymity (DRAFT)}
-\author{Roger Dingledine and Nick Mathewson}
-\institute{The Free Haven Project\\
-\email{\{arma,nickm\}@freehaven.net}}
+%\author{Roger Dingledine and Nick Mathewson and }
+%\institute{The Free Haven Project\\
+%\email{\{arma,nickm\}@freehaven.net}}
+\author{Roger Dingledine \\ The Free Haven Project \\ arma@xxxxxxxxxxxxx \and
+Nick Mathewson \\ The Free Haven Project \\ nickm@xxxxxxxxxxxxx \and
+Paul Syverson \\ Naval Research Lab \\ syverson@xxxxxxxxxxxxxxxx}
\maketitle
\pagestyle{empty}
\begin{abstract}
-
- We describe our experiences with deploying Tor, a low-latency
- anonymous general purpose communication system that has been funded
- by the U.S.~Navy, DARPA, and the Electronic Frontier Foundation. The
- basic Tor design supports most applications that run over TCP (those
- that are SOCKS compliant).
-
-%Because of its simplified threat model, Tor does not aim to defend
-%against many of the attacks in the literature.
-
-We describe both policy issues that have come up from operating the
-network and technical challenges to building a more sustainable and
-scalable network.
-
+ There are many unexpected or unexpectedly difficult obstacles to
+ deploying anonymous communications. Drawing on our experiences deploying
+ Tor (the next-generation onion routing network), we describe social
+ challenges and technical issues that must be faced
+ in building, deploying, and sustaining a scalable, distributed, low-latency
+ anonymity network.
\end{abstract}
\section{Introduction}
+% Your network is not practical unless it is sustainable and distributed.
+Anonymous communication is full of surprises. This paper discusses some
+unexpected challenges arising from our experiences deploying Tor, a
+low-latency general-purpose anonymous communication system. We will discuss
+some of the difficulties we have experienced and how we have met them (or how
+we plan to meet them, if we know). We will also discuss some less
+troublesome open problems that we must nevertheless eventually address.
+%We will describe both those future challenges that we intend to explore and
+%those that we have decided not to explore and why.
-Anonymous communication is full of surprises. In this paper we will
-tell you about some of them. We will describe the challenges arising
-from our experiences with deploying, Tor, a low-latency anonymous general
-purpose communication system. We will discuss some of the difficulties
-we have experienced, how we have met them or, when we have some idea,
-how we plan to meet them. We will also discuss some tough open
-problems that have not given us any trouble in our current deployment.
-We will describe both those future challenges that we intend to explore and
-those that we have decided not to explore and why.
+Tor is an overlay network for anonymizing TCP streams over the
+Internet~\cite{tor-design}. It addresses limitations in earlier Onion
+Routing designs~\cite{or-ih96,or-jsac98,or-discex00,or-pet00} by adding
+perfect forward secrecy, congestion control, directory servers, integrity
+checking, configurable exit policies, and location-hidden services using
+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.
-Tor is an overlay network, designed
-to be practical and usable, for protecting TCP streams over the
-Internet~\cite{tor-design}. We have been operating a publicly deployed
-Tor network since October 2003 that has grown to over a hundred volunteer
-nodes and sometimes as much as 80 megabits of average traffic per second.
+We first publicly deployed a Tor network in October 2003; since then it has
+grown to over a hundred volunteer servers and as much as 80 megabits of
+average traffic per second. Tor's research strategy has focused on deploying
+a network to as many users as possible; thus, we have resisted designs that
+would compromise deployability by imposing high resource demands on server
+operators, and designs that would compromise usability by imposing
+unacceptable restrictions on which applications we support. Although this
+strategy has
+its drawbacks (including a weakened threat model, as discussed below), it has
+made it possible for Tor to serve many thousands of users, and attract
+research funding from organizations so diverse as ONR and DARPA
+(for use in securing sensitive communications), and the Electronic Frontier
+Foundation (for maintaining civil liberties of ordinary citizens online).
-Tor has a weaker threat model than many anonymity designs in the
-literature, because our foremost goal is to deploy a
-practical and useful network for interactive (low-latency) communications.
-Subject to this restriction, we try to
-provide as much anonymity as we can. In particular, because we
-support interactive communications without impractically expensive padding,
-we fall prey to a variety
-of intra-network~\cite{back01,attack-tor-oak05,flow-correlation04} and
-end-to-end~\cite{danezis-pet2004,SS03} anonymity-breaking attacks.
+While the Tor design paper~\cite{tor-design} gives an overall view of Tor's
+design and goals, this paper describes some policy, social, and technical
+issues that we face as we continue deployment.
+Rather than trying to provide complete solutions to every problem here, we
+lay out the assumptions and constraints that we have observed while
+deploying Tor in the wild. In doing so, we aim to create a research agenda
+for others to help in addressing these issues. We believe that the issues
+described here will be of general interest to projects attempting to build
+and deploy practical, useable anonymity networks in the wild.
-Users are safe so long as adversaries are unable to
-observe connections as they both enter and leave the Tor network.
-Therefore, Tor's defense lies in having a diverse enough set of servers
-that most real-world
-adversaries are unlikely to be in the right places to attack users.
-Specifically,
-Tor aims to resist observers and insiders by distributing each transaction
-over several nodes in the network. This ``distributed trust'' approach
-means the Tor network can be safely operated and used by a wide variety
-of mutually distrustful users, providing more sustainability and security
-than some previous attempts at anonymizing networks.
-The Tor network has a broad range of users, including ordinary citizens
-concerned about their privacy, corporations
-who don't want to reveal information to their competitors, and law
-enforcement and government intelligence agencies who need
-to do operations on the Internet without being noticed.
+% ----------------
Tor research and development has been funded by the U.S.~Navy and DARPA
for use in securing government
@@ -97,33 +96,15 @@
interests helps maintain both the stability and the security of the
network.
-The ideal Tor network would be practical, useful and and anonymous. When
-trade-offs arise between these properties, Tor's research strategy has been
-to insist on remaining useful enough to attract many users,
-and practical enough to support them. Subject to these
-constraints, we aim to maximize anonymity. This is not the only possible
-direction in anonymity research: designs exist that provide more anonymity
-than Tor at the expense of significantly increased resource requirements, or
-decreased flexibility in application support (typically because of increased
-latency). Such research does not typically abandon aspirations towards
-deployability or utility, but instead tries to maximize deployability and
-utility subject to a certain degree of inherent anonymity (inherent because
-usability and practicality affect usage which affects the actual anonymity
-provided by the network \cite{back01,econymics}). We believe that these
-approaches can be promising and useful, but that by focusing on deploying a
-usable system in the wild, Tor helps us experiment with the actual parameters
-of what makes a system ``practical'' for volunteer operators and ``useful''
-for home users, and helps illuminate undernoticed issues which any deployed
-volunteer anonymity network will need to address.
-While the Tor design paper~\cite{tor-design} gives an overall view its
-design and goals,
-this paper describes the policy and technical issues that Tor faces as
-we continue deployment. Rather than trying to provide complete solutions
-to every problem here, we lay out the assumptions and constraints
-that we have observed through deploying Tor in the wild. In doing so, we
-aim to create a research agenda for others to
-help in addressing these issues.
+%While the Tor design paper~\cite{tor-design} gives an overall view its
+%design and goals,
+%this paper describes the policy and technical issues that Tor faces as
+%we continue deployment. Rather than trying to provide complete solutions
+%to every problem here, we lay out the assumptions and constraints
+%that we have observed through deploying Tor in the wild. In doing so, we
+%aim to create a research agenda for others to
+%help in addressing these issues.
% Section~\ref{sec:what-is-tor} gives an
%overview of the Tor
%design and ours goals. Sections~\ref{sec:crossroads-policy}
@@ -133,15 +114,18 @@
%from a practical useful network to a practical useful anonymous network.
%\section{What Is Tor}
-\section{Distributed trust: safety in numbers}
+\section{Background}
+Here we give a basic overview of the Tor design and its properties, and
+compare Tor to other low-latency anonymity designs.
+
+\subsection{Tor, threat models, and distributed trust}
\label{sec:what-is-tor}
%Here we give a basic overview of the Tor design and its properties. For
%details on the design, assumptions, and security arguments, we refer
%the reader to the Tor design paper~\cite{tor-design}.
-% XXX this section needs to mention that we have exit policies.
-
+\subsubsection{How Tor works}
Tor provides \emph{forward privacy}, so that users can connect to
Internet sites without revealing their logical or physical locations
to those sites or to observers. It also provides \emph{location-hidden
@@ -150,25 +134,26 @@
The design provides these protections even when a portion of its own
infrastructure is controlled by an adversary.
-To create a private network pathway with Tor, the client
+To create a private network pathway with Tor, the client software
incrementally builds a \emph{circuit} of encrypted connections through
servers on the network. The circuit is extended one hop at a time, and
each server along the way knows only which server gave it data and which
server it is giving data to. No individual server ever knows the complete
path that a data packet has taken. The client negotiates a separate set
-of encryption keys for each hop along the circuit to ensure that each
-hop can't trace these connections as they pass through.
+of encryption keys for each hop along the circuit.% to ensure that each
+%hop can't trace these connections as they pass through.
Because each server sees no more than one hop in the
circuit, neither an eavesdropper nor a compromised server can use traffic
analysis to link the connection's source and destination.
-For efficiency, the Tor software uses the same circuit for connections
-that happen within the same short period. Later requests are given a new
+For efficiency, the Tor software uses the same circuit for all the TCP
+connections that happen within the same short period.
+Later requests use a new
circuit, to prevent long-term linkability between different actions by
a single user.
Tor also makes it possible for users to hide their locations while
offering various kinds of services, such as web publishing or an instant
-messaging server. Using Tor ``rendezvous points'', other Tor users can
+messaging server. Using ``rendezvous points'', other Tor users can
connect to these hidden services, each without knowing the other's network
identity.
@@ -176,99 +161,62 @@
application protocols that include personally identifying information need
additional application-level scrubbing proxies, such as
Privoxy~\cite{privoxy} for HTTP. Furthermore, Tor does not permit arbitrary
-IP packets; it only anonymizes TCP and DNS, and only supports connections via
-SOCKS (see Section~\ref{subsec:tcp-vs-ip}).
-
-Tor differs from other deployed systems for traffic analysis resistance
-in its security and flexibility. Mix networks such as
-Mixmaster~\cite{mixmaster-spec} or its successor Mixminion~\cite{minion-design}
-gain the highest degrees of anonymity at the expense of introducing highly
-variable delays, thus making them unsuitable for applications such as web
-browsing. Commercial single-hop
-proxies~\cite{anonymizer} present a single point of failure, where
-a single compromise can expose all users' traffic, and a single-point
-eavesdropper can perform traffic analysis on the entire network.
-Also, their proprietary implementations place any infrastucture that
-depends on these single-hop solutions at the mercy of their providers'
-financial health as well as network security.
-
-No organization can achieve this security on its own. If a single
-corporation or government agency were to build a private network to
-protect its operations, any connections entering or leaving that network
-would be obviously linkable to the controlling organization. The members
-and operations of that agency would be easier, not harder, to distinguish.
-
-Instead, to protect our networks from traffic analysis, we must
-collaboratively blend the traffic from many organizations and private
-citizens, so that an eavesdropper can't tell which users are which,
-and who is looking for what information. By bringing more users onto
-the network, all users become more secure~\cite{econymics}.
+IP packets; it only anonymizes TCP streams and DNS request, and only supports
+connections via SOCKS (see Section~\ref{subsec:tcp-vs-ip}).
-Naturally, organizations will not want to depend on others for their
-security. If most participating providers are reliable, Tor tolerates
-some hostile infiltration of the network. For maximum protection,
-the Tor design includes an enclave approach that lets data be encrypted
-(and authenticated) end-to-end, so high-sensitivity users can be sure it
-hasn't been read or modified. This even works for Internet services that
-don't have built-in encryption and authentication, such as unencrypted
-HTTP or chat, and it requires no modification of those services.
+Most servers operators do not want to allow arbitary TCP connections to leave
+their servers. To address this, Tor provides \emph{exit policies} so that
+each server can block the IP addresses and ports it is unwilling to allow.
+Servers advertise their exit policies to the directory servers, so that
+client can tell which servers will support their connections.
As of January 2005, the Tor network has grown to around a hundred servers
on four continents, with a total capacity exceeding 1Gbit/s. Appendix A
shows a graph of the number of working servers over time, as well as a
-graph of the number of bytes being handled by the network over time. At
+vgraph of the number of bytes being handled by the network over time. At
this point the network is sufficiently diverse for further development
and testing; but of course we always encourage and welcome new servers
to join the network.
-%Tor doesn't try to provide steg (but see Section~\ref{subsec:china}), or
-%the other non-goals listed in tor-design.
-
-Tor is not the only anonymity system that aims to be practical and useful.
-Commercial single-hop proxies~\cite{anonymizer}, as well as unsecured
-open proxies around the Internet, can provide good
-performance and some security against a weaker attacker. The Java
-Anon Proxy~\cite{web-mix} provides similar functionality to Tor but only
-handles web browsing rather than arbitrary TCP\@.
-%Some peer-to-peer file-sharing overlay networks such as
-%Freenet~\cite{freenet} and Mute~\cite{mute}
-Zero-Knowledge Systems' commercial Freedom
-network~\cite{freedom21-security} was even more flexible than Tor in
-that it could transport arbitrary IP packets, and it also supported
-pseudonymous access rather than just anonymous access; but it had
-a different approach to sustainability (collecting money from users
-and paying ISPs to run servers), and has shut down due to financial
-load. Finally, more scalable designs like Tarzan~\cite{tarzan:ccs02} and
-MorphMix~\cite{morphmix:fc04} have been proposed in the literature, but
-have not yet been fielded. We direct the interested reader to Section
-2 of~\cite{tor-design} for a more indepth review of related work.
-
-%six-four. crowds. i2p.
-
-have a serious discussion of morphmix's assumptions, since they would
-seem to be the direct competition. in fact tor is a flexible architecture
-that would encompass morphmix, and they're nearly identical except for
-path selection and node discovery. and the trust system morphmix has
-seems overkill (and/or insecure) based on the threat model we've picked.
-% this para should probably move to the scalability / directory system. -RD
+\subsubsection{Threat models and design philosophy}
+The ideal Tor network would be practical, useful and and anonymous. When
+trade-offs arise between these properties, Tor's research strategy has been
+to insist on remaining useful enough to attract many users,
+and practical enough to support them. Only subject to these
+constraints do we aim to maximize
+anonymity.\footnote{This is not the only possible
+direction in anonymity research: designs exist that provide more anonymity
+than Tor at the expense of significantly increased resource requirements, or
+decreased flexibility in application support (typically because of increased
+latency). Such research does not typically abandon aspirations towards
+deployability or utility, but instead tries to maximize deployability and
+utility subject to a certain degree of inherent anonymity (inherent because
+usability and practicality affect usage which affects the actual anonymity
+provided by the network \cite{back01,econymics}). We believe that these
+approaches can be promising and useful, but that by focusing on deploying a
+usable system in the wild, Tor helps us experiment with the actual parameters
+of what makes a system ``practical'' for volunteer operators and ``useful''
+for home users, and helps illuminate undernoticed issues which any deployed
+volunteer anonymity network will need to address.}
+Because of this strategy, Tor has a weaker threat model than many anonymity
+designs in the literature. In particular, because we
+support interactive communications without impractically expensive padding,
+we fall prey to a variety
+of intra-network~\cite{back01,attack-tor-oak05,flow-correlation04} and
+end-to-end~\cite{danezis-pet2004,SS03} anonymity-breaking attacks.
-\section{Threat model}
-\label{sec:threat-model}
-Tor does not attempt to defend against a global observer. Any adversary who
-can see a user's connection to the Tor network, and who can see the
-corresponding connection as it exits the Tor network, can use timing
-correlation to confirm the user's chosen
-communication partners. Defeating this attack would seem to require
-introducing a prohibitive degree of traffic padding between the user and the
-network, or introducing an unacceptable degree of latency (but see
-Section \ref{subsec:mid-latency}).
-And, it is not clear that padding works at all if we assume a
-minimally active adversary that modifies the timing of packets
-to or from the user by sending network traffic of his own. Thus, Tor
-only attempts to defend against
-external observers who cannot observe both sides of a user's
-connection.
+Tor does not attempt to defend against a global observer. In general, an
+attacker who can observe both ends of a connection through the Tor network
+can correlate the timing and volume of data on that connection as it enters
+and leaves the network, and so link a user to her chosen communication
+parties. Known solutions to this attack would seem to require introducing a
+prohibitive degree of traffic padding between the user and the network, or
+introducing an unacceptable degree of latency (but see Section
+\ref{subsec:mid-latency}). Also, it is not clear that these methods would
+work at all against a minimally active adversary that can introduce timing
+patterns or additional traffic. Thus, Tor only attempts to defend against
+external observers who cannot observe both sides of a user's connection.
Against internal attackers who sign up Tor servers, the situation is more
complicated. In the simplest case, if an adversary has compromised $c$ of
@@ -301,7 +249,7 @@
% not? -nm
% Sure. In fact, better off, since they seem to scale more easily. -rd
-% the below paragraph should probably move later, and merge with
+% XXXX the below paragraph should probably move later, and merge with
% other discussions of attack-tor-oak5.
In practice Tor's threat model is based entirely on the goal of
dispersal and diversity. Murdoch and Danezis describe an attack
@@ -327,20 +275,102 @@
see Section~\ref{subsec:helper-nodes} for discussion of some ways to
address this issue.
-
-see \ref{subsec:routing-zones} for discussion of larger
+See \ref{subsec:routing-zones} for discussion of larger
adversaries and our dispersal goals.
-[this section will get written once the rest of the paper is farther along]
+\subsubsection{Distributed trust}
+Tor's defense lies in having a diverse enough set of servers
+to prevent most real-world
+adversaries from being in the right places to attack users.
+Tor aims to resist observers and insiders by distributing each transaction
+over several nodes in the network. This ``distributed trust'' approach
+means the Tor network can be safely operated and used by a wide variety
+of mutually distrustful users, providing more sustainability and security
+than some previous attempts at anonymizing networks.
+The Tor network has a broad range of users, including ordinary citizens
+concerned about their privacy, corporations
+who don't want to reveal information to their competitors, and law
+enforcement and government intelligence agencies who need
+to do operations on the Internet without being noticed.
+
+No organization can achieve this security on its own. If a single
+corporation or government agency were to build a private network to
+protect its operations, any connections entering or leaving that network
+would be obviously linkable to the controlling organization. The members
+and operations of that agency would be easier, not harder, to distinguish.
+
+Instead, to protect our networks from traffic analysis, we must
+collaboratively blend the traffic from many organizations and private
+citizens, so that an eavesdropper can't tell which users are which,
+and who is looking for what information. By bringing more users onto
+the network, all users become more secure~\cite{econymics}.
+
+Naturally, organizations will not want to depend on others for their
+security. If most participating providers are reliable, Tor tolerates
+some hostile infiltration of the network. For maximum protection,
+the Tor design includes an enclave approach that lets data be encrypted
+(and authenticated) end-to-end, so high-sensitivity users can be sure it
+hasn't been read or modified. This even works for Internet services that
+don't have built-in encryption and authentication, such as unencrypted
+HTTP or chat, and it requires no modification of those services.
+
+%Tor doesn't try to provide steg (but see Section~\ref{subsec:china}), or
+%the other non-goals listed in tor-design.
+
+\subsection{Related work}
+Tor is not the only anonymity system that aims to be practical and useful.
+Commercial single-hop proxies~\cite{anonymizer}, as well as unsecured
+open proxies around the Internet, can provide good
+performance and some security against a weaker attacker. The Java
+Anon Proxy~\cite{web-mix} provides similar functionality to Tor but only
+handles web browsing rather than arbitrary TCP\@.
+%Some peer-to-peer file-sharing overlay networks such as
+%Freenet~\cite{freenet} and Mute~\cite{mute}
+Zero-Knowledge Systems' commercial Freedom
+network~\cite{freedom21-security} was even more flexible than Tor in
+that it could transport arbitrary IP packets, and it also supported
+pseudonymous access rather than just anonymous access; but it had
+a different approach to sustainability (collecting money from users
+and paying ISPs to run servers), and has shut down due to financial
+load. Finally, more scalable designs like Tarzan~\cite{tarzan:ccs02} and
+MorphMix~\cite{morphmix:fc04} have been proposed in the literature, but
+have not yet been fielded. We direct the interested reader to Section
+2 of~\cite{tor-design} for a more in-depth review of related work.
+
+Tor differs from other deployed systems for traffic analysis resistance
+in its security and flexibility. Mix networks such as
+Mixmaster~\cite{mixmaster-spec} or its successor Mixminion~\cite{minion-design}
+gain the highest degrees of anonymity at the expense of introducing highly
+variable delays, thus making them unsuitable for applications such as web
+browsing. Commercial single-hop
+proxies~\cite{anonymizer} present a single point of failure, where
+a single compromise can expose all users' traffic, and a single-point
+eavesdropper can perform traffic analysis on the entire network.
+Also, their proprietary implementations place any infrastucture that
+depends on these single-hop solutions at the mercy of their providers'
+financial health as well as network security.
+
+%XXXX six-four. crowds. i2p.
+
+%XXXX
+have a serious discussion of morphmix's assumptions, since they would
+seem to be the direct competition. in fact tor is a flexible architecture
+that would encompass morphmix, and they're nearly identical except for
+path selection and node discovery. and the trust system morphmix has
+seems overkill (and/or insecure) based on the threat model we've picked.
+% this para should probably move to the scalability / directory system. -RD
+
\section{Crossroads: Policy issues}
\label{sec:crossroads-policy}
-Many of the issues the Tor project needs to address are not just a
-matter of system design or technology development. In particular, the
+Many of the issues the Tor project needs to address extend beyond
+system design and technology development. In particular, the
Tor project's \emph{image} with respect to its users and the rest of
the Internet impacts the security it can provide.
+% No image, no sustainability -NM
+% Fold this into next subsec.
As an example to motivate this section, some U.S.~Department of Energy
penetration testing engineers are tasked with compromising DoE computers
from the outside. They only have a limited number of ISPs from which to
@@ -357,6 +387,7 @@
Tor's interaction with other services on the Internet.
\subsection{Image and security}
+% Communicating security? - NM
A growing field of papers argue that usability for anonymity systems
contributes directly to their security, because how usable the system
@@ -423,6 +454,7 @@
who use the network. We investigate this issue in the next section.
\subsection{Reputability}
+% Maintaining image of social value? Social value? -NM
Another factor impacting the network's security is its reputability:
the perception of its social value based on its current user base. If Alice is
@@ -496,9 +528,11 @@
of ``deniability'' for traffic that originates at that exit node. For
example, it is likely in practice that HTTP requests from a Tor server's IP
will be assumed to be from the Tor network.
-\item Local Tor entry and exit servers allow users on a network to run in an
- `enclave' configuration. [XXXX need to resolve this. They would do this
- for E2E encryption + auth?]
+XXXX clarify.
+\item Maintain the sustainability of the network. XXX sentencize
+%\item Local Tor entry and exit servers allow users on a network to run in an
+% `enclave' configuration. [XXXX need to resolve this. They would do this
+% for E2E encryption + auth?]
\end{tightlist}
First, we try to make the costs of running a Tor server easily minimized.
@@ -542,6 +576,9 @@
remaining users on the network are exactly those willing to use that capacity
there is.
+XXX But is it the right equilibirum? And if it's the wrong one, we lose
+XXX users. And if we lose the wrong users, servers won't want to help.
+
XXX what if the file-sharers are more persistent than the journalists?
\subsection{Tor and file-sharing}
@@ -582,7 +619,7 @@
For the moment, it seems that Tor's bandwidth issues have rendered it
unattractive for bulk file-sharing traffic; this may continue to be so in the
future. Nevertheless, Tor will likely remain attractive for limited use in
-filesharing protocols that have separate control and data channels.
+ filesharing protocols that have separate control and data channels.
[xxxx We should say more -- but what? That we'll see a similar
equilibriating effect as with bandwidth, where sensitive ops switch to
@@ -594,6 +631,11 @@
convincing. if ISPs find the activity antisocial, they don't care *why*
your computer is doing that behavior.
+XXXX deliberately give priority to quiet circuits?
+XXXX or non file-sharing ports??
+XXXX Point is not to beat them off the network, but to keep them from
+XXXX hogging the network.
+
\subsection{Tor and blacklists}
It was long expected that, alongside Tor's legitimate users, it would also
@@ -638,6 +680,9 @@
[****Since this is stupid and we oppose it, shouldn't we name names here -pfs]
[XXX also, they're making \emph{middleman nodes leave} because they're caught
up in the standoff!]
+[XXX Mention: it's not dumb, it's strategic!]
+[XXX Mention: for some servops, any blacklist is a blacklist too many,
+ because it is risky. (Guy lives in apt with one IP.)]
Problems of abuse occur mainly with services such as IRC networks and
Wikipedia, which rely on IP blocking to ban abusive users. While at first
@@ -693,9 +738,13 @@
%by implementing the Morphmix-specific node discovery and path selection
%pieces.
+[XXX Mention correct DNS-RBL implementation. -NM]
+
\section{Crossroads: Design choices}
\label{sec:crossroads-design}
+[XXX sentence here.]
+
\subsection{Transporting the stream vs transporting the packets}
\label{subsec:stream-vs-packet}
\label{subsec:tcp-vs-ip}
@@ -753,6 +802,7 @@
understand which are actual roadblocks and which are easier to resolve
than we think. We certainly wouldn't mind if Tor one day is able to
transport a greater variety of protocols.
+[XXX clarify our actual attitude here. -NM]
\subsection{Mid-latency}
\label{subsec:mid-latency}