[tor-commits] [tor-design-2012/master] Revise introduction lightly.

[nickm at torproject.org]

commit c5ca54edcc25ff6761fcf45b07f06f4e0861d911
Author: Nick Mathewson <nickm at 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 at freehaven.net \and
 Paul Syverson \\ Naval Research Lab \\ syverson at 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