[freehaven-dev] Tarzan overview

[Roger Dingledine <arma@mit.edu>]

Comments appreciated!
---------------------

Free (in the sense of freely usable and extensible) services for
anonymous communications and transactions on the Internet are still
relatively primitive. Many people continue to use Mixmaster for
anonymous communication despite latency, reliability, and software
complexity problems. Academics who are trying to solve these problems are
reluctant to begin deploying a system until all of the hard problems are
solved. Companies such as ZKS and Anonymizer are tackling these problems
from a commercial perspective, but their solutions must emphasize user
convenience and experience in order to make money. They are forced to
solve both the infrastructure problem and also the user interface problem,
and they end up paying money to maintain a robust reliable infrastructure
from which to offer their service.

The widespread increase in availability of bandwidth and processing power
allows for another alternative: an infrastructure built out of volunteer
peers. A robust free infrastructure which can anonymize any streaming
connection (such as web browsing or file sharing) would benefit a wide
array of current p2p systems, since the anonymous connection could
seamlessly replace the current connection.

The one-direction communication primitive in Tarzan works similarly to
Onion Routing: it builds an {\em onion} (a layered set of asymmetric
encryptions describing a source routed path through a set of nodes) which
allows those nodes to build a {\em virtual circuit} (each node knows the
node behind and in front but no others, and traffic down the circuit is
unwrapped by a symmetric key at each node). Specifically, this primitive
allows for a forward-only anonymous channel: it can be used for any tcp
communication from an anonymous host to an identified host.

By allowing some nodes to offer a service known as a {\em meeting
place}, we combine two forward-only anonymous connections to get a {\em
double-blinded} channel --- the location of both parties is hidden. This
meeting place concept replaces the earlier concept of a {\em reply
block}, which is a static onion describing the location of a given host.
Reply blocks have anonymity problems (a traffic analysis technique known
as an {\em intersection attack} allows the adversary to examine several
reply blocks and get closer to learning the host's location) as well
as reliability problems (if any node in the reply block path fails,
that reply block has now failed). Meeting places, on the other hand,
offer a more dynamic and secure approach to pseudonymous locations.

At the meeting place, the two sides agree on a {\em data proxy} which
will channel data between them. This separation of meeting place and
data proxy allows pseudonymous servers some level of protection against
connection flooding: the server can choose whether or not to accept a
connection request. The separation also allows nodes which are reliable
but have low bandwidth to provide meeting places. Because both parties
are making connections out towards the meeting place and data proxy,
either or both parties can transparently be behind a firewall or in a
similarly restricted environment.

The initial Tarzan design provides very limited protection from traffic
analysis. Specifically, the threat model we defend against is what we
call the {\em lawyer attack}. Our adversary will be willing to create a
variety of new misbehaving nodes, and will have a limited ability to be
a passive or active adversary (eg from a court order for each node or
small set of nodes), but he will be unwilling to be illegally malicious
in his attempts to locate hosts. Further, he will have no real resources
or understanding of statistics for traffic analysis. For instance, if
an adversary were to watch both end-points of a connection over Tarzan
and correlate timing, he could become convinced that they were linked.