mirrors/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-11-19 09:50:29 +01:00
Code Issues Projects Releases Wiki Activity

another todo item, a half-written tor-design intro

Browse Source 
svn:r543
This commit is contained in:
Roger Dingledine 2003-10-07 15:59:30 +00:00
parent b51d2c05a0
commit e826873ac6
2 changed files with 42 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
doc/TODO
View File

@ -1,4 +1,6 @@
use times(2) rather than gettimeofday to measure how long it takes to process a cell
Legend:
SPEC!! - Not specified
SPEC - Spec not finalized

53
doc/tor-design.tex
View File

@ -42,8 +42,8 @@ Paul Syverson \\ Naval Research Lab \\ syverson@itd.nrl.navy.mil}
\thispagestyle{empty}
\begin{abstract}
We present Tor, a connection-based anonymous communication system based
on onion routing.
We present Tor, a connection-based low-latency anonymous communication
system which addresses many flaws in the original onion routing design.
Tor works in a real-world Internet environment,
requires little synchronization or coordination between nodes, and
protects against known anonymity-breaking attacks as well
@ -59,27 +59,54 @@ as or better than other systems with similar design parameters.
\Section{Overview}
\label{sec:intro}
Onion routing is a TCP-based anonymous communication system
The onion routing project published a number of papers several years
ago \cite{x,y,z}, but because the only implementation was a fragile
proof-of-concept that ran on a single machine, many critical design issues
were not considered or addressed. Here we describe Tor, a protocol for
asynchronous, loosely federated onion routers that provides the following
improvements over the old onion routing design:
Onion routing is a distributed overlay network designed to anonymize
low-latency TCP-based applications such as web browsing, secure
shell, and instant messaging. Users choose a path through the
network and 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 unwrapped by a symmetric key at each
node which reveals the downstream node. The original onion routing
project published several design and analysis papers several years
ago \cite{or-journal,or-discex,or-ih,or-pet}, but because the only
implementation was a fragile proof-of-concept that ran on a single
machine, many critical design and deployment issues were not considered
or addressed. Here we describe Tor, a protocol for asynchronous, loosely
federated onion routers that provides the following improvements over
the old onion routing design:
\begin{itemize}
\item \textbf{Congestion control:} Foo
\item \textbf{No mixing or traffic shaping:}
\item \textbf{Applications talk to the onion proxy via Socks:}
The original onion routing design required a separate proxy for each
supported application protocol, resulting in a lot of extra code (most
of which was never written) and also meaning that a lot of TCP-based
applications were not supported. Tor uses the unified and standard Socks
\cite{socks4,socks5} interface, allowing us to support any TCP-based
program without modification.
\item \textbf{Applications talk to the onion proxy via socks:}
\item \textbf{No mixing or traffic shaping:} The original onion routing
design called for full link padding both between onion routers and between
onion proxies (that is, users) and onion routers \cite{or-journal}. The
later analysis paper \cite{or-pet} suggested \emph{traffic shaping}
schemes that would provide similar protection but use less bandwidth,
but did not go into detail. However, recent research \cite{econymics}
and deployment experience \cite{freedom2-arch} indicate that this level
of resource use is not practical or economical, especially if.
\item \textbf{Directory servers:} Traditional link state
\item \textbf{Congestion control:} Traditional flow control solutions
Our decentralized ack-based congestion control
allows nodes at the edges of the network to detect incidental congestion
or flooding attacks and send less data until the congestion subsides.
\item \textbf{Directory servers:}
\item \textbf{Forward security:}
\item \textbf{Many applications can share one circuit:}
leaky pipes
\item \textbf{End-to-end integrity checking:}
\item \textbf{Robustness to node failure:} router twins