[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[freehaven-cvs] draft is basically done
Update of /home/freehaven/cvsroot/doc/routing-zones
In directory moria.mit.edu:/tmp/cvs-serv32101
Modified Files:
network-tables.tex routing-zones.tex
Log Message:
draft is basically done
just waiting on the results for that table.
Index: network-tables.tex
===================================================================
RCS file: /home/freehaven/cvsroot/doc/routing-zones/network-tables.tex,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -d -r1.6 -r1.7
--- network-tables.tex 26 Jan 2004 19:26:40 -0000 1.6
+++ network-tables.tex 28 Jan 2004 06:38:47 -0000 1.7
@@ -1,3 +1,39 @@
+
+
+
+%%\begin{table}
+\begin{small}
+%%\caption{Tor nodes as of January 2004}
+%%\label{table:tor-network}
+\begin{center}
+\begin{tabular}{|l|l|l|l|}
+\multicolumn{4}{c}{{\bf Tor nodes as of January 2004}} \\
+\multicolumn{4}{c}{{\em (exit nodes in boldface)}} \\
+\hline
+Name & IP address & Country & Autonomous System \\
+\hline
+{\bf moria.mit.edu} & {\bf 18.244.0.188} & {\bf US} & {\bf 3 (Massachusetts Institute of Technology)} \\
+{\bf cassandra.eecs.harvard.edu} & {\bf 140.247.60.133} & {\bf US} & {\bf 11 (Harvard University)} \\
+{\bf ovmj.org} & {\bf 128.10.19.51} & {\bf US} & {\bf 17 (Purdue University)} \\
+anon.inf.tu-dresden.de & 141.76.46.90 & Germany & 680 (DFN-IP service G-WiN) \\
+code13.unixpunx.org & 205.158.23.142 & US & 2828 (XO Communications) \\
+{\bf peertech.org} & {\bf 207.36.86.132} & {\bf US} & {\bf 3064 (CyberGate Technologies, Inc)} \\
+{\bf anon.itys.net} & {\bf 209.221.142.117} & {\bf US} & {\bf 3742 (Semaphore Corporation)} \\
+tor.noreply.org & 62.116.124.106 & Austria & 5424 (ATnet) \\
+{\bf c3po.cs.byu.edu} & {\bf 128.187.170.212} & {\bf US} & {\bf 6510 (Brigham Young University)} \\
+{\bf nymip.org} & {\bf 66.92.0.206} & {\bf US} & {\bf 23504 (Speakeasy Inc)} \\
+{\bf gw.provos.org} & {\bf 66.92.17.34} & {\bf US} & {\bf 23504 (Speakeasy Inc)} \\
+{\bf www.peerfear.org} & {\bf 66.93.132.237} & {\bf US} & {\bf 23504 (Speakeasy Inc)} \\
+{\bf petra.felter.org} & {\bf 69.20.9.201} & {\bf US} & {\bf 27357 (Rackspace.com)} \\
+{\bf incognito.shmoo.com} & {\bf 69.5.78.151} & {\bf US} & {\bf 29699 (Pro Hosters L.L.C)} \\
+\hline
+\end{tabular}
+\end{center}
+\end{small}
+%%\end{table}
+
+
+
%%\begin{table}
\begin{small}
%%\caption{Mixmaster nodes as of January 2004}
@@ -63,33 +99,3 @@
\end{center}
\end{small}
%%\end{table}
-%%\begin{table}
-\begin{small}
-%%\caption{Tor nodes as of January 2004}
-%%\label{table:tor-network}
-\begin{center}
-\begin{tabular}{|l|l|l|l|}
-\multicolumn{4}{c}{{\bf Tor nodes as of January 2004}} \\
-\multicolumn{4}{c}{{\em (exit nodes in boldface)}} \\
-\hline
-Name & IP address & Country & Autonomous System \\
-\hline
-{\bf moria.mit.edu} & {\bf 18.244.0.188} & {\bf US} & {\bf 3 (Massachusetts Institute of Technology)} \\
-{\bf cassandra.eecs.harvard.edu} & {\bf 140.247.60.133} & {\bf US} & {\bf 11 (Harvard University)} \\
-{\bf ovmj.org} & {\bf 128.10.19.51} & {\bf US} & {\bf 17 (Purdue University)} \\
-anon.inf.tu-dresden.de & 141.76.46.90 & Germany & 680 (DFN-IP service G-WiN) \\
-code13.unixpunx.org & 205.158.23.142 & US & 2828 (XO Communications) \\
-{\bf peertech.org} & {\bf 207.36.86.132} & {\bf US} & {\bf 3064 (CyberGate Internet Technologies, Inc)} \\
-{\bf anon.itys.net} & {\bf 209.221.142.117} & {\bf US} & {\bf 3742 (Semaphore Corporation)} \\
-tor.noreply.org & 62.116.124.106 & Austria & 5424 (ATnet) \\
-{\bf c3po.cs.byu.edu} & {\bf 128.187.170.212} & {\bf US} & {\bf 6510 (Brigham Young University)} \\
-{\bf nymip.org} & {\bf 66.92.0.206} & {\bf US} & {\bf 23504 (Speakeasy Inc)} \\
-{\bf gw.provos.org} & {\bf 66.92.17.34} & {\bf US} & {\bf 23504 (Speakeasy Inc)} \\
-{\bf www.peerfear.org} & {\bf 66.93.132.237} & {\bf US} & {\bf 23504 (Speakeasy Inc)} \\
-{\bf petra.felter.org} & {\bf 69.20.9.201} & {\bf US} & {\bf 27357 (Rackspace.com)} \\
-{\bf incognito.shmoo.com} & {\bf 69.5.78.151} & {\bf US} & {\bf 29699 (Pro Hosters L.L.C)} \\
-\hline
-\end{tabular}
-\end{center}
-\end{small}
-%%\end{table}
Index: routing-zones.tex
===================================================================
RCS file: /home/freehaven/cvsroot/doc/routing-zones/routing-zones.tex,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -d -r1.28 -r1.29
--- routing-zones.tex 28 Jan 2004 05:00:04 -0000 1.28
+++ routing-zones.tex 28 Jan 2004 06:38:47 -0000 1.29
@@ -777,7 +777,7 @@
for each network and, for each sender/receiver pair, observed the number
of times the path from the sender to the entry node traversed at least
one AS on both paths. Tables~\ref{tab:as_obs_ee_tor}
-and~\ref{tab:as_obs_ee_mm} shows the probability, for each sender and
+and~\ref{tab:as_obs_ee_mm} show the probability, for each sender and
receiver, the likelihood of this event. The table also shows the AS
that was traversed upon both entry and exit most often. We see that
each pair of sender and receiver has at least some subset of entry and
@@ -786,7 +786,8 @@
upon both entry and exit most often was {\em always} a tier-1 ISP.
These results suggest that the sender in a mix network should exercise
-care when selecting entry and exit nodes to avoid this scenario. These
+care when selecting entry and exit nodes to avoid choosing entry and
+exit paths that traverse the same AS. These
results suggest that it is certainly {\em possible} for an intelligent
sender to select entry and exit nodes such that the entry and exit paths
do not traverse the same AS on entry and exit (e.g., between Speakeasy
@@ -796,18 +797,7 @@
likely to be eavesdropped by a single AS at both entry and exit.
-\subsection{Secondary Attacks}
-Even if you do something intelligent about selecting exit nodes, will
-this choice provide the adversary information about where Alice is
-coming from (i.e., what her direct upstream ISP is?)
-
-(I actually don't think it's too big of a deal, because it simply just
-tells the adversary where Alice is *not*, but there are plenty of places
-Alice could still be...)
-
-
-
-\section{Design Recommendations and Future Work}
+\section{Design Recommendations and Future Work}\label{sec:design}
In light of our analysis, which has shown that certain ASes have
considerable easvesdropping capabilities on mix networks, we propose two
@@ -821,7 +811,18 @@
Our results suggest that, to reduce the probability of eavesdroping
attacks using dispersity, designers and users of mix networks should
take into account the underlying AS-level paths of the underlying mix
-network path.
+network path. Mix network paths can be made more if senders increase
+the jurisdictional independence of the paths they use, by explicitly
+choose entry and exit nodes to avoid traversing the same AS upon entry
+and exit to the mix network.
+
+
+Even if you do something intelligent about selecting exit nodes, will
+this choice provide the adversary information about where Alice is
+coming from (i.e., what her direct upstream ISP is?) (I actually don't
+think it's too big of a deal, because it simply just tells the adversary
+where Alice is *not*, but there are plenty of places Alice could still
+be...) Deserves more attention.
\subsection{Improving Jurisdictional Independence with Node Placement}
@@ -849,6 +850,7 @@
excellent direction for future work.
+
%% B. How do these results change as we change our assumptions
%% about the set of nodes from which you can select:
@@ -871,16 +873,50 @@
\section{Conclusion}
- This area has been overlooked in the past; considering network
- level paths is important when defending against a GPA, esp. in
- low-latency networks.
+In this paper, we have proposed that, when designing for dispersity,
+mix networks should consider the underlying AS-level paths. Our paper
+brings to light several interesting, important results:
- We have provided some first steps in looking at network-level
- paths for node selection and its implications for GPA.
+\begin{itemize}
+\item While conventional wisdom and previous systems have proposed
+ selecting nodes from disjoint IP address prefixes to select nodes in
+ different jurisdictions, we have shown that this technique is not
+ sufficient to achieve jurisdictional independence.
- Proposed some design recommendations for Tor (or, depending on
- our results, found that the Tor selection works reasonably
- well).
+\item We have analyzed the AS-level path properties of existing mix
+ networks and have found the likelihood of crossing the same AS more
+ than once along a mix network path to be a near certainty. We have
+ also observed that the liklihood that a single AS will usually be
+ able to observe more than 75\% of the edges along a mix path for paths
+ longer than 3 nodes.
+
+\item We have analyzed common entry and exit paths to existing mix
+ network topologies and shown that, in general, given random entry and
+ exit node selection, a single AS will be able to observe both the
+ entry and exit path to the mix network between 10\% and 30\% of the time.
+ However, achieving jurisdictional independence for entry and exit
+ paths is possible, as long as the sender chooses entry and exit
+ nodes with jurisdictional independence in mind.
+\end{itemize}
+
+This paper also creates several possibilities for future work, as we
+have discussed in Section~\ref{sec:design}. We believe that our work
+brings to light an important insight that will guide the design and
+deployment of anonymity networks in the future: to improve mix networks,
+designers must have a better understanding of Internet topology. This
+paper is an important first step in this direction.
+
+
+%% This area has been overlooked in the past; considering network
+%% level paths is important when defending against a GPA, esp. in
+%% low-latency networks.
+
+%% We have provided some first steps in looking at network-level
+%% paths for node selection and its implications for GPA.
+
+%% 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
@@ -890,6 +926,8 @@
\bibliography{routing-zones}
\begin{appendix}
+\section{Summary of Endpoints}\label{sec:send_recv}
+\input{endpoint-tables}
\section{Summary of Mix Networks}\label{sec:mixnode_summary}
\input{network-tables}
\end{appendix}
***********************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe freehaven-cvs in the body. http://freehaven.net/