think more about the design section

\begin{abstract}

We present Tor, a connection-based low-latency anonymous communication

system. It is intended as a successor to Onion Routing

% how about removing 'intended as'? Simplifying further?

and addresses many limitations in the original Onion Routing design.

Tor works in a real-world Internet environment,

% it's user-space too

requires little synchronization or coordination between nodes, and

protects against known anonymity-breaking attacks as well

as or better than other systems with similar design parameters.

% and we preseent a big list of open problems at the end

\end{abstract}

%\begin{center}

build a \emph{virtual circuit}, in which each node in the path knows its

predecessor and successor, but no others. Traffic flowing down the circuit

is sent in fixed-size \emph{cells}, which are unwrapped by a symmetric key

at each node and relayed downstream. The original Onion Routing

project published several design and analysis papers

at each node (like the layers of an onion) and relayed downstream. The

original Onion Routing project published several design and analysis

papers

\cite{or-jsac98,or-discex00,or-ih96,or-pet00}. While there was briefly

a wide area Onion Routing network,

% how long is briefly? a day, a month? -RD

\Section{The Tor Design}

\label{sec:design}

high-level intro: overlay network of onion routers with long-term TLS

connections.  (Every OR connects to every other.) Users run local

software (onion proxies) that establish path over network and

construct virtual circuit.  (USers know about all ORs from Directory.)

OPs accept TCP streams and multiplex them across virtual circuit.  OR

on the other side of the cirucuit connects to the destinations of the

TCP streams and continues to relay TCP sessions.

Describe connection protocol.  Link-to-link rate limiting.  Link

padding.

Describe cells.  Control versus Relay.  Cell structure.

Describe how circuits work and how relay cells get passed along,

The Tor network is an overlay network; each node is called an onion router

(OR). Onion routers run on normal computers without needing any special

privileges. Each OR maintains a long-term TLS connection to every other

OR (although we look at ways to relax this clique-topology assumption in

section \ref{subsec:restricted-routes}). A subset of the ORs also act as

directory servers, tracking which routers are currently in the network;

see section \ref{subsec:dirservers} for directory server details. Users

run local software called an onion proxy (OP) that fetches directories,

establishes paths (called \emph{virtual circuits}) over the network,

and handles connections from the user applications. Onion proxies accept

TCP streams and multiplex them across the virtual circuit. The onion

router on the other side of the circuit connects to the destinations of

the TCP streams and relays data.

Section \ref{subsec:cells} discusses the structure of the fixed-size

\emph{cell} that are the unit of communication in Tor. We describe

in Section \ref{subsec:circuits} how circuits work, and in Section

\ref{subsec:circuit-build} how they are built, extended, truncated, and

destroyed. Section \ref{subsec:tcp} discusses the process of opening

TCP streams through Tor, and finally Section \ref{subsec:congestion}

talks about congestion control and fairness issues.

\SubSection{Cells}

4.1 Describe cells.  Control versus Relay.  Cell structure.

4.2 Describe how circuits work and how relay cells get passed along,

decrypted etc.  This will include mentioning leaky-pipe circuit

topology and end-to-end integrity checking.  (Mention tagging.)

Describe how circuits get built, extended, truncated.

4.3 Describe how circuits get built, extended, truncated.

Describe how TCP connections get opened.  (Mention DNS issues)

4.4 Describe how TCP connections get opened.  (Mention DNS issues)

Descibe closing TCP connections and 2-END handshake to mirror TCP

close handshake.

Describe how data is transmitted.

Describe circuit-level and stream-level congestion control issues and

solutions.

4.5 Describe circuit-level and stream-level

congestion control issues and solutions.

Describe circuit-level and stream-level fairness issues; cite Marc's

anonnet stuff.

Describe DoS prevention.

\Section{Other design decisions}

\SubSection{Resource management and DoS prevention}

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.

[XXX mention that designers have to choose what you send across your

Mention that designers have to choose what you send across your

  circuit: wrapped IP packets, wrapped stream data, etc.  [Disspell

  TCP-over-TCP misconception.]]

[XXX Mention that OR-to-OR connections should be highly reliable.  If

  they aren't, everything can stall.]

\Section{Other design decisions}

  TCP-over-TCP misconception.]

Mention that OR-to-OR connections should be highly reliable.  If

  they aren't, everything can stall.

\SubSection{Exit policies and abuse}

\label{subsec:exitpolicies}

Pull attacks and defenses into analysis as a subsection

\Section{Maintaining anonymity sets}

\Section{Maintaining anonymity in Tor}

\label{sec:maintaining-anonymity}

[Put as much of this as a part of open issuses as is possible.]

[Put as much of this as a part of open issues as is possible.]

[what's an anonymity set?]