Update of /home/freehaven/cvsroot/doc/routing-zones
In directory moria.mit.edu:/tmp/cvs-serv16274
Modified Files:
routing-zones.bib routing-zones.tex
Log Message:
writeup of node-level analysis
path analysis coming soon.
Index: routing-zones.bib
===================================================================
RCS file: /home/freehaven/cvsroot/doc/routing-zones/routing-zones.bib,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -d -r1.8 -r1.9
--- routing-zones.bib 26 Jan 2004 20:35:22 -0000 1.8
+++ routing-zones.bib 26 Jan 2004 23:45:51 -0000 1.9
@@ -266,3 +266,12 @@
month = {January 14, },
year = {2004},
}
+
+@inproceedings {freedman:ccs02,
+ title = "Tarzan: A Peer-to-Peer Anonymizing Network Layer",
+ author = "Michael J. Freedman and Robert Morris",
+ booktitle = "Proceedings of the 9th {ACM} {C}onference on {C}omputer and {C}ommunications {S}ecurity",
+ address = "Washington, D.C.",
+ month = nov,
+ year = "2002"
+}
Index: routing-zones.tex
===================================================================
RCS file: /home/freehaven/cvsroot/doc/routing-zones/routing-zones.tex,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -d -r1.15 -r1.16
--- routing-zones.tex 26 Jan 2004 21:04:03 -0000 1.15
+++ routing-zones.tex 26 Jan 2004 23:45:51 -0000 1.16
@@ -281,7 +281,7 @@
advertise the routes learned from its provider to its customer, but not
to other peers.
-\begin{figure}
+\begin{figure}[t]
\begin{small}
\begin{verbatim}
Network Next Hop Metric LocPrf Weight Path
@@ -543,23 +543,105 @@
\section{Results}\label{sec:results}
-[We should of course take a look at these questions abstractly, to get a
-feel for how to answer them, but I'd like to get results on the actual
-real-world networks too. We need a cool new name for "zone-based
-attack".] Then we can see how stable the properties are: can we change
-things a lot by adding a few nodes, or do we need significant membership
-changes? -RD]
+In this section, we present the results of our analysis. First, we
+discuss the fundamental robustness properties of existing mix networks
+and how these properties would change in response to increased numbers
+and diversity of mix nodes. This analysis is independent of our model
+for mix network users (i.e., senders and receivers), since we are only
+examining properties of the mix nodes themselves. (To the extent
+possible, a user should try to minimize the ASes that can observe
+mutiple edges along a mix network path.) Second, we use our estimates
+for typical locations of senders and receivers to determine the
+robustness properties of current node selection algorithms in mix
+networks; again, we note how these properties change as the number and
+diversity of mix nodes increases.
+%% [We should of course take a look at these questions abstractly, to get a
+%% feel for how to answer them, but I'd like to get results on the actual
+%% real-world networks too. We need a cool new name for "zone-based
+%% attack".] Then we can see how stable the properties are: can we change
+%% things a lot by adding a few nodes, or do we need significant membership
+%% changes? -RD]
%% I can easily make a list of current
%% Tor nodes, current Mixminion nodes, current Mixmaster nodes, and we
%% can compare robustness of the network to zone-based attacks.
\subsection{Fundamental AS-level Properties of Mix Nodes and Paths}
+In this section, we explore the extent to which the nodes and paths are
+independent. First, we analyze the ASes in which the mix nodes are
+located, for the existing Tor and Mixmaster networks. Next, we examine
+the path properties between pairs of existing mix nodes and characterize
+the extent to which the AS-level paths pairwise mix nodes traverse
+common ASes. Finally, we analyze the extent to which these properties
+are dependent on the current set of nodes in each mix network;
+specifically, we examine how these robustness properties change in
+response to increased mix node diversity (i.e., more mix nodes, and more
+mix nodes in more diverse geographic locations).
+
+\subsubsection{Node properties}
+
+The tables in Appendix~\ref{sec:mixnode_summary} show that both the
+Mixmaster and Tor networks have multiple nodes in the same AS. Tor has
+three mix nodes in AS 23504 (Speakeasy DSL), and Mixmaster has two nodes
+each in ASes 3269 (Telecom Italia), 6939 (Hurricane Electric), 7132
+(SBC), 23504 (Speakeasy DSL), and 24940 (Hetzner Online). This lack of
+jurisdictional independence in node placement it not surprising; in
+particular, it seems to reflect the fact that these network nodes are
+operated by {\em volunteers}, many of whom commonly operate mix nodes
+from their Internet connections at home (i.e., DSL providers, etc.).
+However, the fact that there both of these networks have multiple nodes
+located in the same jurisdiction suggests that users of these mix
+networks should exercise caution when selecting mix nodes (particularly
+the entry and exit nodes).
+
+Previous work (and conventional wisdom) has suggested that selecting
+nodes from disjoint subsets of the IP address space will achieve
+independence in node placement; it is clear from our survey of Mixmaster
+and Tor that these types of prefix-based mechanisms are, in general,
+ineffective, and they can lead the user of the mix network into a false
+sense of security. For example, Tarzan suggests subdividing the node
+space into {\tt /16} prefixes, and subsequently into {\tt /24} prefixes
+and selecting nodes from distinct subsets of the IP prefix space to
+reduce the liklihood that two mix nodes are in the jurisdiction of a
+single AS~\cite{freedman:ccs02}. Unfortunately, this technique does not
+necessarily increase the likelihood of jurisdictional independence: of
+the five pairs Mixmaster nodes that are located in the same AS, three of
+these pairs (those in ASes 3269, 7132, and 23504) not only have distinct
+{\tt /16} prefixes, they also have distinct {\tt /8} prefixes.
+Simiarly, one of the Tor network nodes in AS 23504 has a distinct {\tt
+/16} prefix. This suggests that, to achieve jurisdictional
+independence, a mix network should explicitly consider the actual AS of
+a host, not simply its IP address.
+
+Finally, we note that all of the Tor network's exit nodes are currently
+located in the United States. In practice, this network could achieve
+greater jurisdictional independence by increasing exit node
+participation outside of the US.
+
+
+\subsubsection{Path properties}
+
+\begin{table}[t]
+\begin{tabular}{r|p{1.25in}|p{0.5in}p{0.5in}p{0.5in}p{0.5in}}
+{\bf Mix Network} & \parbox{1.25in}{{\centering\bf \# of \\ AS-disjoint Edges}} &
+\multicolumn{4}{c}{{\bf \# of Edges with $n$ common ASes}} \\
+& & \parbox{0.5in}{\centering 1} & \parbox{0.5in}{\centering 2} & \parbox{0.5in}{\centering 3} & \parbox{0.5in}{\centering 4+} \\ \hline
+Tor \\
+Mixmaster\\
+\end{tabular}
+\vspace{0.1in}
+\caption{Characterizing jurisdictional independence in today's mix
+ networks.}
+\label{tab:path_ind}
+\end{table}
+
Fraction/number of mix paths with overlapping ASes for each network.
Note that increasing mix path length doesn't necessarily mean more
-anonymity.
+anonymity. Table~\ref{tab:path_ind}.
+
+\subsubsection{Effects of Membership Diversity}
\subsection{Jurisdictional Attacks on Entry and Exit Paths}
@@ -626,6 +708,9 @@
Proposed some design recommendations for Tor (or, depending on
our results, found that the Tor selection works reasonably
well).
+%temporary spacer while we don't have a conclusion to make sure things
+% don't look ridiculous, aesthetically
+\vspace{6in}
%\section*{Acknowledgements}
***********************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe freehaven-cvs in the body. http://freehaven.net/