[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[freehaven-cvs] data section (Section 5)
Update of /home/freehaven/cvsroot/doc/routing-zones
In directory moria.mit.edu:/tmp/cvs-serv7392
Modified Files:
routing-zones.bib routing-zones.tex
Log Message:
data section (Section 5)
add more discussion of AS-level topologies in background section
add a missing reference or two
Index: routing-zones.bib
===================================================================
RCS file: /home/freehaven/cvsroot/doc/routing-zones/routing-zones.bib,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -d -r1.7 -r1.8
--- routing-zones.bib 26 Jan 2004 19:26:40 -0000 1.7
+++ routing-zones.bib 26 Jan 2004 20:35:22 -0000 1.8
@@ -245,3 +245,24 @@
month = {November},
}
+@misc{www-routeviews,
+ key = "RouteViews",
+ title = "{RouteViews}",
+ author = "University of Oregon",
+ howpublished = "{\url{http://www.routeviews.org/}}";,
+}
+
+@Article{Chang2004,
+ author = {H. Chang and R. Govindan and S. Jamin and S. Shenker and W. Willinger},
+ title = {Towards Capturing Representative AS-Level Internet Topologies},
+ journal = {Computer Networks Journal},
+ year = {2004},
+}
+
+@Misc{www-comscore,
+ key = {comscore},
+ Title = {comScore Media Metrix Announces Top 50 U.S. Internet Property Rankings for December 2003},
+ howpublished = {\url{http://www.comscore.com/press/release.asp?press=402}},
+ month = {January 14, },
+ year = {2004},
+}
Index: routing-zones.tex
===================================================================
RCS file: /home/freehaven/cvsroot/doc/routing-zones/routing-zones.tex,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -d -r1.12 -r1.13
--- routing-zones.tex 26 Jan 2004 19:26:40 -0000 1.12
+++ routing-zones.tex 26 Jan 2004 20:35:22 -0000 1.13
@@ -86,9 +86,9 @@
network, so an adversary of a given strength sees less of the network
\cite{econymics,bennett:pet2003,morphmix:fc04}; by arranging the overlay
topology so messages can enter or exit at more places in the network
-(e.g. as opposed to a cascade topology \cite{disad-free-routes});
+(as opposed to a cascade topology \cite{disad-free-routes});
or by \emph{jurisdictional arbitrage} --- coordinating network behavior
-so each transaction includes zones (e.g. jurisdictions) controlled by
+so each transaction includes zones (i.e., jurisdictions) controlled by
several different adversaries.
% would be nice to cite something for jurisdictional arbitrage, but i
% seem to be the only person who's said that phrase in a paper, and
@@ -313,14 +313,35 @@
\subsubsection{AS-level Internet Topology}
-There are many publicly-available places that provide access to
-routing table data. The most prevalent is the Oregon Routeviews
+Paths between end-hosts in the Internet cross a sequence of ASes (or
+jurisdictions); to estimate the sequence of ASes that any given path
+crosses, we must first have a representation of the Internet topology at
+the AS-level (i.e., the ASes that each AS connects to, as well as their
+business relationships with one another). Determining a complete view
+of the AS-level graph is notoriously difficult, because bilateral
+policies may hide edges in the graph from any one particular vantage
+point~\cite{Chang2004}. For example, in
+Figure~\ref{fig:policy_summary}, a routing table captured at Peer 1 will
+not contain any routes with the $AS \leftrightarrow \mbox{Peer} 2$ link,
+since the AS in the center will not readvertise routes learned from one
+peer to another peer.
+
+There are many publicly-available places that provide access to routing
+table data. The most prevalent is the Oregon RouteViews
Project~\cite{www-routeviews}, which maintains a route server that peers
with more than 30 ASes. Each of these ASes sends its routing tables to
-the Routeviews server, which include that AS's best route to each
+the RouteViews server, which include that AS's best route to each
destination prefix. Each AS's routing table is slightly different,
-which means that
+which means that The AS-level topology constructed from the RouteViews
+route server is likely be missing some inter-AS edges due to bilateral
+policies, but the graph is fairly representative enough for our
+purposes. In the future, we could improve our analysis by incorporating
+newer techniques for capturing AS-level topologies~\cite{Chang2004}.
+Knowledge of the AS-level topology is not enough to determine the
+AS-level path between two arbitrary mix nodes; to determine this, we
+need to make further modeling assumptions, which we describe in
+Section~\ref{sec:mix_aspath}.
\section{Modeling Techniques}
@@ -359,7 +380,7 @@
-\subsection{AS-level Mix Network Path Estimation}
+\subsection{AS-level Mix Network Path Estimation}\label{sec:mix_aspath}
If Alice had access to an up-to-date routing
table from every network containing mix nodes, she could construct a
@@ -483,14 +504,41 @@
perform our analysis based on the location of mix nodes today. We then
describe the data we used to generate the AS-level network topology.
-\subsection{Mix Networks}
-How we estimate where Alice and Bob are located. Summary of mix nodes.
-Reference appendix~\ref{sec:mixnode_summary}.
+\subsection{Mix Networks, Senders, and Receivers}
+
+To perform our evaluation of node selection in the Mixmaster and Tor mix
+networks, we use the list of operational mix nodes for each respective
+network; the tables Appendix~\ref{sec:mixnode_summary} provide lists of
+mix nodes for each of these networks.
+
+Since we are also interested in the AS-level paths between the sender
+(Alice) and the mix entry point, and between the mix exit point and the
+reciever (Bob) we must also estimate the ASes where the sender (Alice)
+and receiver (Bob) may typically be located. While usage data for these
+mix networks is not readily available, we can perform reasonable
+approximations by assuming that Alice is located on a home network
+(e.g., a cable modem network, a DSL network, etc.) and that Bob is a
+content host located at a data hosting ISP.
+
+To generate a reasonable, unbiased list of ASes where Alice and Bob may
+be located, we analyze Web logs and summary statistics to generate lists
+of common locations of Web clients and servers. We use the Web server
+logs from {\tt nms.lcs.mit.edu} from January 2004 to generate a list of
+ASes where a typical sender might be located. To generate a list of
+typical receivers, we use the top 25 sites from comScore Media Metrix's
+``Top 50 US Internet Properties'' from December 2003~\cite{www-comscore}.
\subsection{Network Topology}
-Description of routing tables and mix tables.
+To generate an estimate of AS-level topology, we use the routing table
+dump from the {\tt route-views.oregon-ix.net} route server on January
+25, 2004 at 10:22 GMT. The table has 67 external BGP (eBGP) feeds from
+53 ASes (some ASes have multiple eBGP feeds to the route server). We
+use this table to (1)~generate our view of the AS-level topology,
+including inter-AS relationships, and compute pairwise AS-level shortest
+paths, as we described in Section~\ref{sec:mix_aspath}, (2) map IP
+addresses to the ASes where they are located.
\section{Results}\label{sec:results}
@@ -508,6 +556,10 @@
\subsection{Fundamental AS-level Properties of Mix Nodes and Paths}
+Fraction/number of mix paths with overlapping ASes for each network.
+Note that increasing mix path length doesn't necessarily mean more
+anonymity.
+
\subsection{Jurisdictional Attacks on Entry and Exit Paths}
***********************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe freehaven-cvs in the body. http://freehaven.net/