torproject/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-12-06 19:41:15 +01:00
Code Issues Actions Packages Projects Releases Wiki Activity

move some stuff around in sections 1,2,3. Not done yet; still need to work on "Distributed Trust", "related work"

Browse Source 
svn:r3571
This commit is contained in:
Nick Mathewson
2005-02-07 05:52:49 +00:00
parent c76189d4b2
commit bacdecd93a
1 changed files with 271 additions and 221 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/design-paper/challenges.tex
+271 -221
View File
@@ -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@freehaven.net \and
Nick Mathewson \\ The Free Haven Project \\ nickm@freehaven.net \and
Paul Syverson \\ Naval Research Lab \\ syverson@itd.nrl.navy.mil}
\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,11 +96,95 @@ their popular Java Anon Proxy anonymizing client. This wide variety of
interests helps maintain both the stability and the security of the
network.
%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}
%and~\ref{sec:crossroads-design} go on to describe the practical challenges,
%both policy and technical respectively,
%that stand in the way of moving
%from a practical useful network to a practical useful anonymous network.
%\section{What Is Tor}
\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}.
\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
services}, so that critical servers can support authorized users without
giving adversaries an effective vector for physical or online attacks.
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 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.
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 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 ``rendezvous points'', other Tor users can
connect to these hidden services, each without knowing the other's network
identity.
Tor attempts to anonymize the transport layer, not the application layer, so
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 streams and DNS request, and only supports
connections via SOCKS (see Section~\ref{subsec:tcp-vs-ip}).
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
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.
\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. Subject to these
constraints, we aim to maximize anonymity. This is not the only possible
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
@@ -114,161 +197,26 @@ 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.
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.
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}
%and~\ref{sec:crossroads-design} go on to describe the practical challenges,
%both policy and technical respectively,
%that stand in the way of moving
%from a practical useful network to a practical useful anonymous network.
%\section{What Is Tor}
\section{Distributed trust: safety in numbers}
\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.
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
services}, so that critical servers can support authorized users without
giving adversaries an effective vector for physical or online attacks.
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
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.
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
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
connect to these hidden services, each without knowing the other's network
identity.
Tor attempts to anonymize the transport layer, not the application layer, so
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}.
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.
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
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
\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 @@ complicating factors:
% 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 @@ it identifies endpoints when they're also nodes in the Tor network:
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 @@ With this image issue in mind, this section discusses the Tor user base and
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 @@ matter as much as we'd like, it still helps to have some other users
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 @@ Still, anonymity and privacy incentives do remain for server operators:
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 @@ over anonymity tend to leave the system, thus freeing capacity until the
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 @@ ports.
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 @@ in practice, plausible deniability is hypothetical and doesn't seem very
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 @@ from these networks even though Tor does not allow SMTP at all.)
[****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 @@ workable alternative.
%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 @@ would be good to investigate each of these items in further depth and to
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}