commit c5ca54edcc25ff6761fcf45b07f06f4e0861d911
Author: Nick Mathewson <nickm(a)torproject.org>
Date: Wed Nov 14 00:26:13 2012 -0500
Revise introduction lightly.
---
todo | 9 +++++-
tor-design-2012.tex | 74 ++++++++++++++++++---------------------------------
2 files changed, 33 insertions(+), 50 deletions(-)
diff --git a/todo b/todo
index af508bf..489ae86 100644
--- a/todo
+++ b/todo
@@ -22,6 +22,8 @@ ITEMS:
o guard nodes
o Bridges, censorship resistance, and pluggable transports
- Changes and complexities in our path selection algorithms
+ - Bandwidth authorities
+ - Path selection rules
o stream isolation
. Integrate content from the third blog post [steven]
o link protocol tls
@@ -30,9 +32,9 @@ ITEMS:
o torbutton
o tor browser bundle
- . Revise the abstract and introduction [nick]
+ o Revise the abstract and introduction [nick]
o Abstract
- - Introduction
+ o Introduction
. Revise design goals and assumptions [steven]
o Revise tor-design up to "opening and closing streams" [nick]
@@ -40,6 +42,9 @@ ITEMS:
o Revise hidden services section [nick]
o Revise "other design decisions" [nick]
+
+
+
CAN DO AFTER SPONSOR DEADLINE:
- Revise related work [steven]
- Revise "attacks and defenses" [steven]
diff --git a/tor-design-2012.tex b/tor-design-2012.tex
index 035bf0d..bb856e7 100644
--- a/tor-design-2012.tex
+++ b/tor-design-2012.tex
@@ -60,20 +60,11 @@ Nick Mathewson \\ The Free Haven Project \\ nickm(a)freehaven.net \and
Paul Syverson \\ Naval Research Lab \\ syverson(a)itd.nrl.navy.mil}
-%
-% TOPICS TO ADD, NOT NOTED BELOW:
-% - everything from the 'top changes in Tor' posts.
-% - node reliability testing
-% - path selection rules.
-% - Stream isolation
-%
-% What else?
-% - NM
-
\maketitle
\thispagestyle{empty}
\begin{abstract}
+THIS IS A DRAFT. IT IS NOT FINISHED.
We present Tor, a circuit-based low-latency anonymous
communication service. This Onion Routing
system addresses limitations in the earlier design by adding
@@ -103,6 +94,9 @@ anonymous communication.
\section{Overview}
\label{sec:intro}
+THIS IS A DRAFT. IT IS NOT FINISHED. IT IS BASED ON THE 2004 PAPER,
+WITH PARTIAL UPDATES.
+
Onion Routing is a distributed overlay network designed to
anonymize TCP-based applications like web browsing, secure
shell, and instant messaging. Clients choose a path through the
@@ -120,16 +114,11 @@ proof-of-concept that ran on a single machine. Even this simple
deployment processed connections from over sixty thousand
distinct IP addresses from all over the world at a rate of about
fifty thousand per day.
-% TODO: Describe more of Tor's history here. -NM
Here we describe Tor, a protocol for asynchronous,
-loosely federated onion routers that provides the following
+loosely federated onion routers. Tor provides
+provides the following
improvements over the old Onion Routing design:
-% TODO: Perhaps we should drop the entire enumeration of how Tor differs
-% from old Onion Routing; we could instead rattle off a list of ways Tor has
-% changed since 2004, or instead discuss major features of the design as a
-% whole. - NM
-
\textbf{Perfect forward secrecy:} In the original Onion Routing
design, a single hostile node could record traffic and later
compromise successive nodes in the circuit and force them to
@@ -163,17 +152,12 @@ ORs~\cite{or-ih96,or-jsac98}. Tradeoffs between padding
protection and cost were discussed, and \emph{traffic shaping}
algorithms were theorized~\cite{or-pet00} to provide good
security without expensive padding, but no concrete padding
-scheme was suggested. Recent research~\cite{econymics} and
+scheme was suggested. As of our first writing, research~\cite{econymics} and
deployment experience~\cite{freedom21-security} suggest that
this level of resource use is not practical or economical; and
even full link padding is still
-vulnerable~\cite{defensive-dropping}. Thus, until we have a
-proven and convenient design for traffic shaping or low-latency
-mixing that improves anonymity against a realistic adversary, we
-leave these strategies out.
-% We still don't have a solution for the above. Our related work
-% section should summarize what we have learned in the meantime. We
-% *have* had good outcomes from work that tried to -NM
+vulnerable~\cite{defensive-dropping}. This has not changed since
+our first publication, though we remain hopeful.
\textbf{Many TCP streams can share one circuit:} Onion Routing
originally built a separate circuit for each application-level
@@ -193,8 +177,6 @@ exit the circuit from the middle---possibly frustrating traffic
shape and volume attacks based on observing the end of the
circuit. (It also allows for long-range padding if future
research shows this to be worthwhile.)
-% This is still a notable feature of Tor, but we don't use it for
-% anything. -NM
\textbf{Congestion control:} Earlier anonymity designs do not
address traffic bottlenecks. Unfortunately, typical approaches
@@ -203,9 +185,8 @@ inter-node control communication and global views of
traffic. Tor's decentralized congestion control uses end-to-end
acks to maintain anonymity while allowing nodes at the edges of
the network to detect congestion or flooding and send less data
-until the congestion subsides.
-% We've been working on this some; we have found that our current approach
-% doesn't work so well. -NM
+until the congestion subsides. This is an area of active
+experimentation and research.
\textbf{Directory authorities:} The earlier Onion Routing
design planned to flood state information through the
@@ -234,7 +215,7 @@ traffic and look for corresponding corrupted traffic at the
network edges~\cite{minion-design}. Tor hampers these attacks
by verifying data integrity before it leaves the network.
% Our approach here is a little broken; we're working on better. We should
-% acknowledge the problems. -NM
+% acknowledge the problems. Not in this section though. -NM
\textbf{Rendezvous points and hidden services:} Tor provides an
integrated mechanism for responder anonymity via
@@ -246,22 +227,6 @@ path went down or rotated its keys. In Tor, clients negotiate
{\it rendezvous points} to connect with hidden servers; reply
onions are no longer required.
-Unlike Freedom~\cite{freedom2-arch}, Tor does not require OS
-kernel patches or network stack support. This prevents us from
-anonymizing non-TCP protocols, but has greatly helped our
-portability and deployability.
-
-We have implemented all of the above features, including
-rendezvous points. Our source code is available under a free
-license, and Tor is not covered by the patent that affected
-distribution and use of earlier versions of Onion Routing. We
-have deployed a wide-area alpha network to test the design, to
-get more experience with usability and users, and to provide a
-research platform for experimentation. As of this writing, the
-network stands at 32 nodes spread over two continents.
-% The above figure is wrong; the above paragraph doesn't summarize our status
-% well -NM
-
\textbf{Censorship resistance:} A growing number of Tor users
require not only anonymous communications but also censorship
resistance. Tor circumvents attempts to block access to the
@@ -283,7 +248,20 @@ socket -- the ``control port''. Special-purpose controllers have
also been developed by researchers to analyse Tor and prototype
modifications. Additional resistance against protocol
fingerprinting, for the purposes of censorship resistance, may
-be provided by an external ``pluggable transport'' obfuscator.
+be provided by an external ``pluggable transport'' obfuscator.
+
+% More features here. -NM
+
+Unlike Freedom~\cite{freedom2-arch}, Tor does not require OS
+kernel patches or network stack support. This prevents us from
+anonymizing non-TCP protocols, but has greatly helped our
+portability and deployability.
+
+Tor has been operational since 2003. Our source code is available
+under a free license, and Tor is not covered by the patent that
+affected distribution and use of earlier versions of Onion Routing.
+As of this writing, the Tor network stands at about 3000
+nodes.
We review previous work in Section~\ref{sec:related-work},
describe our goals and assumptions in