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

  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}, 

\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}