Fill out section 5.1, some of which should move into 2, 3, or 4.

svn:r699
This commit is contained in:
Nick Mathewson 2003-11-01 03:06:23 +00:00
parent b8400b281a
commit a3a111b326
2 changed files with 96 additions and 10 deletions

View File

@ -937,6 +937,13 @@ full_papers/rao/rao.pdf}},
note = {\url{http://www.firstmonday.dk/issues/issue3_4/goldberg/}}
}
@Misc{tcp-over-tcp-is-bad,
key = {tcp-over-tcp-is-bad},
title = {Why TCP Over TCP Is A Bad Idea},
author = {Olaf Titz},
note = {\url{http://sites.inka.de/sites/bigred/devel/tcp-tcp.html}}
}
@inproceedings{wright02,
title = {An Analysis of the Degradation of Anonymous Protocols},
author = {Matthew Wright and Micah Adler and Brian Neil Levine and Clay Shields},

View File

@ -1072,16 +1072,95 @@ see Section~\ref{sec:maintaining-anonymity} for more discussion.
\SubSection{Resource management and DoS prevention}
\label{subsec:dos}
Describe DoS prevention. cookies before tls begins, rate limiting of
create cells, link-to-link rate limiting, etc.
Mention twins, what the do, what they can't.
How we should do sequencing and acking like TCP so that we can better
tolerate lost data cells.
Mention that designers have to choose what you send across your
circuit: wrapped IP packets, wrapped stream data, etc. [Disspell
TCP-over-TCP misconception.]
Mention that OR-to-OR connections should be highly reliable. If
they aren't, everything can stall.
Providing Tor as a public service provides many opportunities for an
attacker to mount denial-of-service attacks against the network. While
flow control and rate limiting (discussed in
section~\ref{subsec:congestion}) prevents users from consuming more
bandwidth than nodes are willing to provide, opportunities remain for
consume more network resources than their fair share, or to render the
network unusable for other users.
First of all, there are a number of CPU-consuming denial-of-service
attacks wherein an attacker can force an OR to perform expensive
cryptographic operations. For example, an attacker who sends a
\emph{create} cell full of junk bytes can force an OR to perform an RSA
decrypt its half of the Diffie-Helman handshake. Similarly, an attacker
fake the start of a TLS handshake, forcing the OR to carry out its
(comparatively expensive) half of the handshake at no real computational
cost to the attacker.
To address these attacks, several approaches exist. First, ORs may
demand proof-of-computation tokens \cite{hashcash} before beginning new
TLS handshakes or accepting \emph{create} cells. So long as these
tokens are easy to verify and computationally expensive to produce, this
approach limits the DoS attack multiplier. Additionally, ORs may limit
the rate at which they accept create cells and TLS connections, so that
the computational work of doing so does not drown out the (comparatively
inexpensive) work of symmetric cryptography needed to keep users'
packets flowing. This rate limiting could, however, allows an attacker
to slow down other users as they build new circuits.
% What about link-to-link rate limiting?
% This paragraph needs more references.
More worrisome are distributed denial of service attacks wherein an
attacker uses a large number of compromised hosts throughout the network
to consume the Tor network's resources. Although these attacks are not
new to the networking literature, some proposed approaches are a poor
fit to anonymous networks. For example, solutions based on backtracking
harmful traffic present a significant risk that an anonymity-breaking
adversary could exploit the backtracking mechanism to compromise users'
anonymity. [XXX So, what should we say here? -NM]
% Now would be a good point to talk about twins. What the do, what
% they can't.
Attackers also have an opportunity to attack the Tor network by mounting
attacks on the hosts and network links running it. If an attacker can
successfully disrupt a single circuit or link along a virtual circuit,
all currently open streams passing along that part of the circuit
become unrecoverable, and are closed. The current Tor design treats
such attacks as intermittent network failures, and depends on users and
applications to respond or recover as appropriate. A possible future
design could use an end-to-end based TCP-like acknowledgment protocol,
so that no streams are lost unless the entry or exit point themselves
are disrupted. This solution would require more buffering at exits,
however, and its network properties still need to be investigated. [XXX
That sounds really evasive. We should say more.]
%[XXX Mention that OR-to-OR connections should be highly reliable
% (whatever that means). If they aren't, everything can stall.]
%=====================
% This stuff should go elsewhere. Probably section 2.
Channel-based anonymity designs must choose which protocol layer to
anonymize. They may choose to intercept IP packets directly, and relay
them whole (stripping the source address) as the contents of their
anonymous channels [XXX cite an example]. Alternatively, they may
accept TCP streams and relay the data in those streams along the
channel, ignoring the breakdown of that data into TCP frames. (Tor takes
this approach, as does [XXX].) Finally, they may accept
application-level protocols (such as HTTP) and relay the application
requests themselves along their anonymous channels.
This protocol-layer decision represents a compromise between flexibility
and anonymity. For example, a system that understands HTTP can strip
identifying information from those requests; can take advantage of
caching to limit the number of requests that leave the network; and can
batch or encode those requests in order to minimize the number of
connections. On the other hand, an IP-level anonymizer can handle
nearly any protocol, even ones unforeseen by their designers. TCP-level
anonymity networks like Tor present a middle approach: they are fairly
application neutral (so long as the application supports, or can be
tunneled across, TCP), but by treating application connections as data
streams rather than raw TCP packets, they avoid the well-known
inefficiencies of tunneling TCP over TCP \cite{tcp-over-tcp-is-bad}.
% Is there a better tcp-over-tcp-is-bad reference?
%Also mention that weirdo IP trickery requires kernel patches to most
%operating systems? -NM
\SubSection{Exit policies and abuse}
\label{subsec:exitpolicies}