commit 8de9c40b7347436202bc75e2a4d3020e43e2d595
Author: Karsten Loesing <karsten.loesing(a)gmx.net>
Date: Thu Jul 12 13:44:16 2012 +0200
Move #2754 report sources to tech-reports.git.
---
task-2754/data.bib | 45 ---
task-2754/data.tex | 772 ----------------------------------------------------
2 files changed, 0 insertions(+), 817 deletions(-)
diff --git a/task-2754/data.bib b/task-2754/data.bib
deleted file mode 100644
index caec3b8..0000000
--- a/task-2754/data.bib
+++ /dev/null
@@ -1,45 +0,0 @@
-@misc{dirspec,
- author = {Roger Dingledine and Nick Mathewson},
- title = {Tor directory protocol, version 3},
- note = {\url{https://gitweb.torproject.org/tor.git/blob_plain/HEAD:/doc/spec/dir-spec.txt}},
-}
-
-@inproceedings{loesing2009measuring,
- title = {Measuring the {Tor} Network from Public Directory Information},
- author = {Karsten Loesing},
- booktitle = {Proc.\ HotPETS},
- year = {2009},
- month = Aug,
- address = {Seattle, WA},
- note = {\url{https://metrics.torproject.org/papers/hotpets09.pdf}},
-}
-
-@inproceedings{loesing2010case,
- title = {A Case Study on Measuring Statistical Data in the {Tor} Anonymity Network},
- author = {Karsten Loesing and Steven J. Murdoch and Roger Dingledine},
- booktitle = {Proc.\ Workshop on Ethics in Computer Security Research},
- year = {2010},
- month = Jan,
- address = {Tenerife, Canary Islands, Spain},
- note = {\url{https://metrics.torproject.org/papers/wecsr10.pdf}},
-}
-
-@techreport{hahn2010privacy,
- title = {Privacy-preserving Ways to Estimate the Number of Tor Users},
- author = {Sebastian Hahn and Karsten Loesing},
- institution = {The Tor Project},
- year = {2010},
- month = Nov,
- type = {Technical Report},
- note = {\url{https://metrics.torproject.org/papers/countingusers-2010-11-30.pdf}},
-}
-
-@techreport{loesing2009analysis,
- title = {Analysis of Circuit Queues in {Tor}},
- author = {Karsten Loesing},
- institution = {The Tor Project},
- year = {2009},
- month = Aug,
- note = {\url{https://metrics.torproject.org/papers/bufferstats-2009-08-25.pdf}},
-}
-
diff --git a/task-2754/data.tex b/task-2754/data.tex
deleted file mode 100644
index 1a2745d..0000000
--- a/task-2754/data.tex
+++ /dev/null
@@ -1,772 +0,0 @@
-\documentclass{article}
-\usepackage{url}
-\usepackage[pdftex]{graphicx}
-\usepackage{graphics}
-\usepackage{color}
-\begin{document}
-\title{Overview of Statistical Data in the Tor Network}
-\author{Karsten Loesing}
-\maketitle
-
-\section{Introduction}
-
-Statistical analysis in the Tor network can be performed using various
-kinds of data.
-In this report we give an overview of three major data sources for
-statistics in the Tor network:
-First, we recap measuring the Tor network from public directory
-information \cite{loesing2009measuring} in Section~\ref{sec:serverdesc}
-and explain the sanitzation process of (non-public) bridge directory
-information in Section~\ref{sec:bridgesan}.
-Second, we describe the numerous aggregate statistics that relays publish
-about their usage \cite{loesing2010case}
-in Sections~\ref{sec:bytehist} to \ref{fig:connbidirect}.
-Third, we delineate the output of various Tor services like BridgeDB,
-GetTor, or
-Tor Check as well as specific measurement tools like Torperf in
-Sections~\ref{sec:torperf} to \ref{sec:exitlist}.
-All data described in this report are available for download on the
-metrics
-website.\footnote{\texttt{https://metrics.torproject.org/data.html}}
-
-\section{Server descriptors and network statuses}
-\label{sec:serverdesc}
-
-Relays in the Tor network report their capabilities by publishing server
-descriptors to the directory authorities.
-The directory authorities confirm reachability of relays and assign flags
-to help clients make good path selections.
-Every hour, the directory authorities publish a network status consensus
-with all known running relays at the time.
-Both server descriptors and network statuses constitute a solid data basis
-for statistical analysis in the Tor network.
-We described the approach to measure the Tor network from public directory
-information in \cite{loesing2009measuring} and provide interactive
-graphs on the metrics
-website.\footnote{\texttt{https://metrics.torproject.org/graphs.html}}
-In this section, we briefly describe the most interesting pieces of the
-two descriptor formats that can be used for statistics.
-
-\paragraph{Server descriptors}
-
-The server descriptors published by relays at least once every 18 hours
-contain the necessary information for clients to build circuits using a
-given relay.
-These server descriptors can also be useful for statistical analysis of
-the Tor network infrastructure.
-
-We assume that the majority of server descriptors are correct.
-But when performing statistical analysis on server descriptors, one has to
-keep in mind that only a small subset of the information written to server
-descriptors is confirmed by the trusted directory authorities.
-In theory, relays can provide false information in their server
-descriptors, even though the incentive to do so is probably low.
-
-Figure~\ref{fig:serverdesc} shows an example server descriptor.
-The following data fields in server descriptors may be relevant to
-statistical analysis:
-
-\begin{figure}
-\begin{verbatim}
-router blutmagie 192.251.226.206 443 0 80
-platform Tor 0.2.2.20-alpha on Linux x86_64
-opt protocols Link 1 2 Circuit 1
-published 2010-12-27 14:35:27
-opt fingerprint 6297 B13A 687B 521A 59C6 BD79 188A 2501 EC03 A065
-uptime 445412
-bandwidth 14336000 18432000 15905178
-opt extra-info-digest 5C1D5D6F8B243304079BC15CD96C7FCCB88322D4
-opt caches-extra-info
-onion-key
-[...]
-signing-key
-[...]
-family $66CA87E164F1CFCE8C3BB5C095217A28578B8BAF
- $67EC84376D9C4C467DCE8621AACA109160B5264E
- $7B698D327F1695590408FED95CDEE1565774D136
-opt hidden-service-dir
-contact abuse(a)blutmagie.de
-reject 0.0.0.0/8:*
-reject 169.254.0.0/16:*
-reject 127.0.0.0/8:*
-reject 192.168.0.0/16:*
-reject 10.0.0.0/8:*
-reject 172.16.0.0/12:*
-reject 192.251.226.206:*
-reject *:25
-reject *:119
-reject *:135-139
-reject *:445
-reject *:465
-reject *:563
-reject *:587
-reject *:1214
-reject *:4661-4666
-reject *:6346-6429
-reject *:6660-6999
-accept *:*
-router-signature
-[...]
-\end{verbatim}
-\vspace{-1em}
-\caption{Server descriptor published by relay \texttt{blugmagie} (without
-cryptographic keys and hashes)}
-\label{fig:serverdesc}
-%----------------------------------------------------------------
-\end{figure}
-
-\begin{itemize}
-\item \textit{IP address and ports:} Relays provide their IP address
-and ports where they accept requests to build circuits and directory
-requests.
-These data fields are contained in the first line of a server descriptor
-starting with \verb+router+.
-Note that in rare cases, the IP address provided here can be different
-from the IP address used for exiting to the Internet.
-The latter can be found in the exit lists produced by Tor Check as
-described in Section~\ref{sec:exitlist}.
-\item \textit{Operating system and Tor software version:} Relays include
-their operating system and Tor software version in their server
-descriptors in the \verb+platform+ line.
-While this information is very likely correct in most cases, a few relay
-operators may try to impede hacking attempts by providing false platform
-strings.
-\item \textit{Uptime:} Relays include the number of seconds since the
-last restart in their server descriptor in the \verb+uptime+ line.
-\item \textit{Own measured bandwidth:} Relays report the bandwidth that
-they are willing to provide on average and for short periods of time.
-Relays also perform periodic bandwidth self-tests and report their actual
-available bandwidth.
-The latter was used by clients to weight relays in the path selection
-algorithm and was sometimes subject to manipulation by malicious relays.
-All three bandwidth values can be found in a server descriptor's
-\verb+bandwidth+ line.
-With the introduction of bandwidth scanners, the self-reported relay
-bandwidth in server descriptors has become less
-relevant.\footnote{\url{http://gitweb.torproject.org/torflow.git/}}
-\item \textit{Relay family:} Some relay operators who run more than one
-relay organize their relays in relay families, so that clients don't pick
-more than one of these relays for a single circuit.
-Each relay belonging to a relay family lists the members of that family
-either by nickname or fingerprint in its server descriptor in the
-\verb+family+ line.
-\item \textit{Exit policy:} Relays define their exit policy by including
-firewall-like rules which outgoing connections they reject or accept in
-the \verb+reject+ and \verb+accept+ lines.
-\end{itemize}
-
-These are just a subset of the fields in a server descriptor that seem
-relevant for statistical analysis.
-For a complete list of fields in server descriptors, see the directory
-procol specification \cite{dirspec}.
-
-\paragraph{Network statuses}
-
-Every hour, the directory authorities publish a new network status that
-contains a list of all running relays.
-The directory authorities confirm reachability of the contained relays and
-assign flags based on the relays' characteristics.
-The entries in a network status reference the last published server
-descriptor of a relay.
-
-The network statuses are relevant for statistical analysis, because they
-constitute trusted snapshots of the Tor network.
-Anyone can publish as many server descriptors as they want, but only the
-directory authorities can confirm that a relay was running at a given
-time.
-Most statistics on the Tor network infrastructure rely on network statuses
-and possibly combine them with the referenced server descriptors.
-Figure~\ref{fig:statusentry} shows the network status entry referencing
-the server descriptor from Figure~\ref{fig:serverdesc}.
-In addition to the reachability information, network statuses contain the
-following fields that may be relevant for statistical analysis:
-
-\begin{figure}
-\begin{verbatim}
-r blutmagie YpexOmh7UhpZxr15GIolAewDoGU
- lFY7WmD/yvVFp9drmZzNeTxZ6dw 2010-12-27 14:35:27 192.251.226.206
- 443 80
-s Exit Fast Guard HSDir Named Running Stable V2Dir Valid
-v Tor 0.2.2.20-alpha
-w Bandwidth=30800
-p reject 25,119,135-139,445,465,563,587,1214,4661-4666,6346-6429,
- 6660-6999
-\end{verbatim}
-%----------------------------------------------------------------
-\vspace{-1em}
-\caption{Network status entry of relay \texttt{blutmagie}}
-\label{fig:statusentry}
-\end{figure}
-
-\begin{itemize}
-\item \textit{Relay flags:} The directory authorities assign flags to
-relays based on their characteristics to the line starting with \verb+s+.
-Examples are the \verb+Exit+ flag if a relay permits exiting to the
-Internet and the \verb+Guard+ flag if a relay is stable enough to be
-picked as guard node
-\item \textit{Relay version:} The directory authorities include the
-version part of the platform string written to server descriptors in the
-network status in the line starting with \verb+v+.
-\item \textit{Bandwidth weights:} The network status contains a bandwidth
-weight for every relay in the lines with \verb+w+ that clients shall use
-for weighting relays in their path selection algorithm.
-This bandwidth weight is either the self-reported bandwidth of the relay
-or the bandwidth measured by the bandwidth scanners.
-\item \textit{Exit policy summary:} Every entry in a network status
-contains a summary version of a relay's exit policy in the line starting
-with \verb+p+.
-This summary is a list of accepted or rejected ports for exit to most IP
-addresses.
-\end{itemize}
-
-\section{Sanitized bridge descriptors}
-\label{sec:bridgesan}
-
-Bridges in the Tor network publish server descriptors to the bridge
-authority which in turn generates a bridge network status.
-We cannot, however, make the bridge server descriptors and bridge network
-statuses available for statistical analysis as we do with the relay server
-descriptors and relay network statuses.
-The problem is that bridge server descriptors and network statuses contain
-bridge IP addresses and other sensitive information that shall not be made
-publicly available.
-We therefore sanitize bridge descriptors by removing all potentially
-identifying information and publish sanitized versions of the descriptors.
-The processing steps for sanitizing bridge descriptors are as follows:
-
-\begin{enumerate}
-\item \textit{Replace the bridge identity with its SHA1 value:} Clients
-can request a bridge's current descriptor by sending its identity string
-to the bridge authority.
-This is a feature to make bridges on dynamic IP addresses useful.
-Therefore, the original identities (and anything that could be used to
-derive them) need to be removed from the descriptors.
-The bridge identity is replaced with its SHA1 hash value.
-The idea is to have a consistent replacement that remains stable over
-months or even years (without keeping a secret for a keyed hash function).
-\item \textit{Remove all cryptographic keys and signatures:} It would be
-straightforward to learn about the bridge identity from the bridge's
-public key.
-Replacing keys by newly generated ones seemed to be unnecessary (and would
-involve keeping a state over months/years), so that all cryptographic
-objects have simply been removed.
-\item \textit{Replace IP address with IP address hash:} Of course, the IP
-address needs to be removed, too.
-It is replaced with \verb+10.x.x.x+ with \verb+x.x.x+ being the 3 byte
-output of \verb+H(IP address | bridge identity | secret)[:3]+.
-The input \verb+IP address+ is the 4-byte long binary representation of
-the bridge's current IP address.
-The \verb+bridge identity+ is the 20-byte long binary representation of
-the bridge's long-term identity fingerprint.
-The \verb+secret+ is a 31-byte long secure random string that changes once
-per month for all descriptors and statuses published in that month.
-\verb+H()+ is SHA-256.
-The \verb+[:3]+ operator means that we pick the 3 most significant bytes
-of the result.
-\item \textit{Replace contact information:} If there is contact
-information in a descriptor, the contact line is changed to
-\verb+somebody+.
-\item \textit{Replace nickname with Unnamed:} The bridge nicknames might
-give hints on the location of the bridge if chosen without care; e.g.\ a
-bridge nickname might be very similar to the operators' relay nicknames
-which might be located on adjacent IP addresses.
-All bridge nicknames are therefore replaced with the string
-\verb+Unnamed+.
-\end{enumerate}
-
-Figure~\ref{fig:bridgeserverdesc} shows an example bridge server
-descriptor that is referenced from the bridge network status entry in
-Figure~\ref{fig:bridgestatusentry}.
-For more details about this process, see the bridge descriptor sanitizer
-and the metrics database
-software.\footnote{\texttt{https://metrics.torproject.org/tools.html}}
-
-\begin{figure}
-\begin{verbatim}
-router Unnamed 10.74.150.129 443 0 0
-platform Tor 0.2.2.19-alpha (git-1988927edecce4c7) on Linux i686
-opt protocols Link 1 2 Circuit 1
-published 2010-12-27 18:55:01
-opt fingerprint A5FA 7F38 B02A 415E 72FE 614C 64A1 E5A9 2BA9 9BBD
-uptime 2347112
-bandwidth 5242880 10485760 1016594
-opt extra-info-digest 86E6E9E68707AF586FFD09A36FAC236ADA0D11CC
-opt hidden-service-dir
-contact somebody
-reject *:*
-\end{verbatim}
-\vspace{-1em}
-\caption{Sanitized bridge server descriptor}
-\label{fig:bridgeserverdesc}
-%----------------------------------------------------------------
-\end{figure}
-
-\begin{figure}
-\begin{verbatim}
-
-r Unnamed pfp/OLAqQV5y/mFMZKHlqSupm70 dByzfWWLas9cen7PtZ3XGYIJHt4
- 2010-12-27 18:55:01 10.74.150.129 443 0
-s Fast Guard HSDir Running Stable Valid
-\end{verbatim}
-\vspace{-1em}
-\caption{Sanitized bridge network status entry}
-\label{fig:bridgestatusentry}
-%----------------------------------------------------------------
-\end{figure}
-
-\section{Byte histories}
-\label{sec:bytehist}
-
-Relays include aggregate statistics in their descriptors that they upload
-to the directory authorities.
-These aggregate statistics are contained in extra-info descriptors that
-are published in companion with server descriptors.
-Extra-info descriptors are not required for clients to build circuits.
-An extra-info descriptor belonging to a server descriptor is referenced by
-its SHA1 hash value.
-
-Byte histories were the first statistical data that relays published about
-their usage.
-Relays report the number of written and read bytes in 15-minute intervals
-throughout the last 24 hours.
-The extra-info descriptor in Figure~\ref{fig:extrainfo} contains the byte
-histories in the two lines starting with \verb+write-history+ and
-\verb+read-history+.
-More details about these statistics can be found in the directory protocol
-specification~\cite{dirspec}.
-
-\begin{figure}
-\begin{verbatim}
-extra-info blutmagie 6297B13A687B521A59C6BD79188A2501EC03A065
-published 2010-12-27 14:35:27
-write-history 2010-12-27 14:34:05 (900 s) 12902389760,
- 12902402048,12859373568,12894131200,[...]
-read-history 2010-12-27 14:34:05 (900 s) 12770249728,12833485824,
- 12661140480,12872439808,[...]
-dirreq-write-history 2010-12-27 14:26:13 (900 s) 51731456,
- 60808192,56740864,54948864,[...]
-dirreq-read-history 2010-12-27 14:26:13 (900 s) 4747264,4767744,
- 4511744,4752384,[...]
-dirreq-stats-end 2010-12-27 10:51:09 (86400 s)
-dirreq-v3-ips us=2000,de=1344,fr=744,kr=712,[...]
-dirreq-v2-ips ??=8,au=8,cn=8,cz=8,[...]
-dirreq-v3-reqs us=2368,de=1680,kr=1048,fr=800,[...]
-dirreq-v2-reqs id=48,??=8,au=8,cn=8,[...]
-dirreq-v3-resp ok=12504,not-enough-sigs=0,unavailable=0,
- not-found=0,not-modified=0,busy=128
-dirreq-v2-resp ok=64,unavailable=0,not-found=8,not-modified=0,
- busy=8
-dirreq-v2-share 1.03%
-dirreq-v3-share 1.03%
-dirreq-v3-direct-dl complete=316,timeout=4,running=0,min=4649,
- d1=36436,d2=68056,q1=76600,d3=87891,d4=131294,md=173579,
- d6=229695,d7=294528,q3=332053,d8=376301,d9=530252,max=2129698
-dirreq-v2-direct-dl complete=16,timeout=52,running=0,min=9769,
- d1=9769,d2=9844,q1=9981,d3=9981,d4=27297,md=33640,d6=60814,
- d7=205884,q3=205884,d8=361137,d9=628256,max=956009
-dirreq-v3-tunneled-dl complete=12088,timeout=92,running=4,
- min=534,d1=31351,d2=49166,q1=58490,d3=70774,d4=88192,md=109778,
- d6=152389,d7=203435,q3=246377,d8=323837,d9=559237,max=26601000
-dirreq-v2-tunneled-dl complete=0,timeout=0,running=0
-entry-stats-end 2010-12-27 10:51:09 (86400 s)
-entry-ips de=11024,us=10672,ir=5936,fr=5040,[...]
-exit-stats-end 2010-12-27 10:51:09 (86400 s)
-exit-kibibytes-written 80=6758009,443=498987,4000=227483,
- 5004=1182656,11000=22767,19371=1428809,31551=8212,41500=965584,
- 51413=3772428,56424=1912605,other=175227777
-exit-kibibytes-read 80=197075167,443=5954607,4000=1660990,
- 5004=1808563,11000=1893893,19371=130360,31551=7588414,
- 41500=756287,51413=2994144,56424=1646509,other=288412366
-exit-streams-opened 80=5095484,443=359256,4000=4508,5004=22288,
- 11000=124,19371=24,31551=40,41500=96,51413=16840,56424=28,
- other=1970964
-\end{verbatim}
-%----------------------------------------------------------------
-\vspace{-1em}
-\caption{Extra-info descriptor published by relay \texttt{blutmagie}
-(without cryptographic signature and with long lines being truncated)}
-\label{fig:extrainfo}
-\end{figure}
-
-\section{Directory requests}
-
-The directory authorities and directory mirrors report statistical data
-about processed directory requests.
-Starting with Tor version 0.2.2.15-alpha, all directories report the
-number of written and read bytes for answering directory requests.
-The format is similar to the format of byte histories as described in the
-previous section.
-The relevant lines are \verb+dirreq-write-history+ and
-\verb+dirreq-read-history+ in Figure~\ref{fig:extrainfo}.
-These two lines contain the subset of total read and written bytes that
-the directory mirror spent on responding to any kind of directory request,
-including network statuses, server descriptors, extra-info descriptors,
-authority certificates, etc.
-
-The directories further report statistics on answering directory requests
-for network statuses only.
-For Tor versions before 0.2.3.x, relay operators had to manually enable
-these statistics, which is why only a few directories report them.
-The lines starting with \verb+dirreq-v3-+ all belong to the directory
-request statistics (the lines starting with \verb+dirreq-v2-+ report
-similar statistics for version 2 of the directory protocol which is
-deprecated at the time of writing this report).
-The following fields may be relevant for statistical analysis:
-
-\begin{itemize}
-\item \textit{Unique IP addresses:} The numbers in \verb+dirreq-v3-ips+
-denote the unique IP addresses of clients requesting network statuses by
-country.
-\item \textit{Network status requests:} The numbers in
-\verb+dirreq-v3-reqs+ constitute the total network status requests by
-country.
-\item \textit{Request share:} The percentage in \verb+dirreq-v3-share+ is
-an estimate of the share of directory requests that the reporting relay
-expects to see in the Tor network.
-In \cite{hahn2010privacy} we found that this estimate isn't very useful
-for statistical analysis because of the different approaches that clients
-take to select directory mirrors.
-The fraction of written directory bytes (\verb+dirreq-write-history+) can
-be used to derive a better metric for the share of directory requests.
-\item \textit{Network status responses:} The directories also report
-whether they could provide the requested network status to clients in
-\verb+dirreq-v3-resp+.
-This information was mostly used to diagnose error rates in version 2 of
-the directory protocol where a lot of directories replied to network
-status requests with \verb+503 Busy+.
-In version 3 of the directory protocol, most responses contain the status
-code \verb+200 OK+.
-\item \textit{Network status download times:} The line
-\verb+dirreq-v3-direct-dl+ contains statistics on the download of network
-statuses via the relay's directory port.
-The line \verb+dirreq-v3-tunneled-dl+ contains similar statistics on
-downloads via a 1-hop circuit between client and directory (which is the
-common approach in version 3 of the directory protocol).
-Relays report how many requests have been completed, have timed out, and
-are still running at the end of a 24-hour time interval as well as the
-minimum, maximum, median, quartiles, and deciles of download times.
-\end{itemize}
-More details about these statistics can be found in the directory protocol
-specification~\cite{dirspec}.
-
-\section{Connecting clients}
-
-Relays can be configured to report per-country statistics on directly
-connecting clients.
-This metric includes clients connecting to a relay in order to build
-circuits and clients creating a 1-hop circuit to request directory
-information.
-In practice, the latter number outweighs the former number.
-The \verb+entry-ips+ line in Figure~\ref{fig:extrainfo} shows the number
-of unique IP addresses connecting to the relay by country.
-More details about these statistics can be found in the directory protocol
-specification~\cite{dirspec}.
-
-\section{Bridge users}
-
-Bridges report statistics on connecting bridge clients in their extra-info
-descriptors.
-Figure~\ref{fig:bridgeextrainfo} shows a bridge extra-info descriptor
-with the bridge user statistics in the \verb+bridge-ips+ line.
-
-\begin{figure}
-\begin{verbatim}
-extra-info Unnamed A5FA7F38B02A415E72FE614C64A1E5A92BA99BBD
-published 2010-12-27 18:55:01
-write-history 2010-12-27 18:43:50 (900 s) 151712768,176698368,
- 180030464,163150848,[...]
-read-history 2010-12-27 18:43:50 (900 s) 148109312,172274688,
- 172168192,161094656,[...]
-bridge-stats-end 2010-12-27 14:56:29 (86400 s)
-bridge-ips sa=48,us=40,de=32,ir=32,[...]
-\end{verbatim}
-\vspace{-1em}
-\caption{Sanitized bridge extra-info descriptor}
-%----------------------------------------------------------------
-\label{fig:bridgeextrainfo}
-\end{figure}
-
-Bridges running Tor version 0.2.2.3-alpha or earlier report bridge users
-in a similar line starting with \verb+geoip-client-origins+.
-The reason for switching to \verb+bridge-ips+ was that the measurement
-interval in \verb+geoip-client-origins+ had a variable length, whereas the
-measurement interval in 0.2.2.4-alpha and later is set to exactly
-24~hours.
-In order to clearly distinguish the new measurement intervals from the old
-ones, the new keywords have been introduced.
-More details about these statistics can be found in the directory protocol
-specification~\cite{dirspec}.
-
-\section{Cell-queue statistics}
-
-Relays can be configured to report aggregate statistics on their cell
-queues.
-These statistics include average processed cells, average number of queued
-cells, and average time that cells spend in circuits.
-Circuits are split into deciles based on the number of processed cells.
-The statistics are provided for circuit deciles from loudest to quietest
-circuits.
-Figure~\ref{fig:cellstats} shows the cell statistics contained in an
-extra-info descriptor by relay \texttt{gabelmoo}.
-An early analysis of cell-queue statistics can be found in
-\cite{loesing2009analysis}.
-More details about these statistics can be found in the directory protocol
-specification~\cite{dirspec}.
-
-\begin{figure}
-\begin{verbatim}
-cell-stats-end 2010-12-27 09:59:50 (86400 s)
-cell-processed-cells 4563,153,42,15,7,7,6,5,4,2
-cell-queued-cells 9.39,0.98,0.09,0.01,0.00,0.00,0.00,0.01,0.00,
- 0.01
-cell-time-in-queue 2248,807,277,92,49,22,52,55,81,148
-cell-circuits-per-decile 7233
-\end{verbatim}
-%----------------------------------------------------------------
-\vspace{-1em}
-\caption{Cell statistics in extra-info descriptor by relay
-\texttt{gabelmoo}}
-\label{fig:cellstats}
-\end{figure}
-
-\section{Exit-port statistics}
-
-Exit relays running Tor version 0.2.1.1-alpha or higher can be configured
-to report aggregate statistics on exiting connections.
-These relays report the number of opened streams, written and read bytes
-by exiting port.
-Until version 0.2.2.19-alpha, relays reported all ports exceeding a
-threshold of 0.01~\% of all written and read exit bytes.
-Starting with version 0.2.2.20-alpha, relays only report the top 10 ports
-in exit-port statistics in order not to exceed the maximum extra-info
-descriptor length of 50 KB.
-Figure~\ref{fig:extrainfo} on page \pageref{fig:extrainfo} contains
-exit-port statistics in the lines starting with \verb+exit-+.
-More details about these statistics can be found in the directory protocol
-specification~\cite{dirspec}.
-
-\section{Bidirectional connection use}
-\label{sec:bidistats}
-
-Relays running Tor version 0.2.3.1-alpha or higher can be configured to
-report what fraction of connections is used uni- or bi-directionally.
-Every 10 seconds, relays determine for every connection whether they read
-and wrote less than a threshold of 20 KiB.
-Connections below this threshold are labeled as ``Below Threshold''.
-For the remaining connections, relays report whether they read/wrote at
-least 10 times as many bytes as they wrote/read.
-If so, they classify a connection as ``Mostly reading'' or ``Mostly
-writing,'' respectively.
-All other connections are classified as ``Both reading and writing.''
-After classifying connections, read and write counters are reset for the
-next 10-second interval.
-Statistics are aggregated over 24 hours.
-Figure~\ref{fig:connbidirect} shows the bidirectional connection use
-statistics in an extra-info descriptor by relay \texttt{zweifaltigkeit}.
-The four numbers denote the number of connections ``Below threshold,''
-``Mostly reading,'' ``Mostly writing,'' and ``Both reading and writing.''
-More details about these statistics can be found in the directory protocol
-specification~\cite{dirspec}.
-
-\begin{figure}
-\begin{verbatim}
-conn-bi-direct 2010-12-28 15:55:11 (86400 s) 387465,45285,55361,
- 81786
-\end{verbatim}
-%----------------------------------------------------------------
-\vspace{-1em}
-\caption{Bidirectional connection use statistic in extra-info descriptor
-by relay \texttt{zweifaltigkeit}}
-\label{fig:connbidirect}
-\end{figure}
-
-\section{Torperf output files}
-\label{sec:torperf}
-
-Torperf is a little tool that measures Tor's performance as users
-experience it.
-Torperf uses a trivial SOCKS client to download files of various sizes
-over the Tor network and notes how long substeps take.
-Torperf can be downloaded from the metrics
-website.\footnote{\texttt{https://metrics.torproject.org/tools.html}}
-
-Torperf can produce two output files: \verb+.data+ and \verb+.extradata+.
-The \verb+.data+ file contains timestamps for nine substeps and the byte
-summaries for downloading a test file via Tor.
-Figure~\ref{fig:torperf} shows an example output of a Torperf run.
-The timestamps in the upper part of this output are seconds and
-nanoseconds since 1970-01-01 00:00:00.000000.
-
-Torperf can be configured to write \verb+.extradata+ files by attaching
-a Tor controller and writing certain controller events to disk.
-The content of a \verb+.extradata+ line is shown in the lower part of
-Figure~\ref{fig:torperf}.
-The first column indicates if this circuit was actually used to fetch
-the data (\verb+ok+) or if Tor chose a different circuit because this
-circuit was problematic (\verb+error+).
-For every \verb+error+ entry there should be a following \verb+ok+ entry,
-unless the network of the Torperf instance is dead or the resource is
-unavailable.
-The circuit build completion time in the \verb+.extradata+ line is the
-time between Torperf sent a SOCKS request and received a SOCKS response in
-the \verb+.data+ file.
-The three or more hops of the circuit are listed by relay fingerprint and
-nickname.
-An \verb+=+ sign between the two means that a relay has the \texttt{Named}
-flag, whereas the \verb+~+ sign means it doesn't.
-
-\begin{figure}
-\begin{verbatim}
-# Timestamps and byte summaries contained in .data files:
-1293543301 762678 # Connection process started
-1293543301 762704 # After socket is created
-1293543301 763074 # After socket is connected
-1293543301 763190 # After authentication methods are negotiated
- # (SOCKS 5 only)
-1293543301 763816 # After SOCKS request is sent
-1293543302 901783 # After SOCKS response is received
-1293543302 901818 # After HTTP request is written
-1293543304 445732 # After first response is received
-1293543305 456664 # After payload is complete
-75 # Written bytes
-51442 # Read bytes
-
-# Path information contained in .extradata files:
-ok # Status code
-1293543302 # Circuit build completion time
-$2F265B37920BDFE474BF795739978EEFA4427510=fejk4 # 1st hop
-$66CA87E164F1CFCE8C3BB5C095217A28578B8BAF=blutmagie3 # 2nd hop
-$76997E6557828E8E57F70FDFBD93FB3AA470C620~Amunet8 # 3rd hop
-\end{verbatim}
-%----------------------------------------------------------------
-\vspace{-1em}
-\caption{Torperf output lines for a single request to download a 50~KiB
-file (reformatted and annotated with comments)}
-\label{fig:torperf}
-\end{figure}
-
-\section{BridgeDB pool assignment files}
-
-BridgeDB is the software that receives bridge network statuses containing
-the information which bridges are running from the bridge authority,
-assigns these bridges to persistent distribution rings, and hands them out
-to bridge users.
-BridgeDB periodically dumps the list of running bridges with information
-about the rings, subrings, and file buckets to which they are assigned to
-a local file.
-The sanitized versions of these lists containing SHA-1 hashes of bridge
-fingerprints instead of the original fingerprints are available for
-statistical analysis.
-
-\begin{figure}
-\begin{verbatim}
-bridge-pool-assignment 2011-03-13 14:38:03
-00b834117566035736fc6bd4ece950eace8e057a unallocated
-00e923e7a8d87d28954fee7503e480f3a03ce4ee email port=443
- flag=stable
-0103bb5b00ad3102b2dbafe9ce709a0a7c1060e4 https ring=2 port=443
- flag=stable
-[...]
-\end{verbatim}
-%----------------------------------------------------------------
-\vspace{-1em}
-\caption{BridgeDB pool assignment file from March 13, 2011}
-\label{fig:bridgeassignments}
-\end{figure}
-
-Figure~\ref{fig:bridgeassignments} shows a BridgeDB pool assignment file
-from March 13, 2011.
-Every such file begins with a line containing the timestamp when BridgeDB
-wrote this file.
-Subsequent lines always start with the SHA-1 hash of a bridge fingerprint,
-followed by ring, subring, and/or file bucket information.
-There are currently three distributor ring types in BridgeDB:
-
-\begin{enumerate}
-\item \texttt{unallocated}: These bridges are not distributed by BridgeDB,
-but are either reserved for manual distribution or are written to file
-buckets for distribution via an external tool.
-If a bridge in the \texttt{unallocated} ring is assigned to a file bucket,
-this is noted by \verb+bucket=$bucketname+.
-\item \texttt{email}: These bridges are distributed via an e-mail
-autoresponder. Bridges can be assigned to subrings by their OR port or
-relay flag which is defined by \verb+port=$port+ and/or \verb+flag=$flag+.
-\item \texttt{https}: These bridges are distributed via https server.
-There are multiple https rings to further distribute bridges by IP address
-ranges, which is denoted by \verb+ring=$ring+.
-Bridges in the \texttt{https} ring can also be assigned to subrings by
-OR port or relay flag which is defined by \verb+port=$port+ and/or
-\verb+flag=$flag+.
-\end{enumerate}
-
-\section{GetTor statistics file}
-
-GetTor allows users to fetch the Tor software via email.
-GetTor keeps internal statistics on the number of packages requested
-every day and writes these statistics to a file.
-Figure~\ref{fig:gettor} shows the statistics file for December 27, 2010.
-The \verb+None+ entry stands for requests that don't ask for a specific
-bundle, e.g.\ requests for the bundle list.
-
-\begin{figure}
-\begin{verbatim}
-2010-12-27 - None:167 macosx-i386-bundle:0 macosx-ppc-bundle:0
- source-bundle:2 tor-browser-bundle:0 tor-browser-bundle_ar:0
- tor-browser-bundle_de:0 tor-browser-bundle_en:39
- tor-browser-bundle_es:0 tor-browser-bundle_fa:5
- tor-browser-bundle_fr:0 tor-browser-bundle_it:0
- tor-browser-bundle_nl:0 tor-browser-bundle_pl:0
- tor-browser-bundle_pt:0 tor-browser-bundle_ru:0
- tor-browser-bundle_zh_CN:77 tor-im-browser-bundle:0
- tor-im-browser-bundle_ar:0 tor-im-browser-bundle_de:0
- tor-im-browser-bundle_en:1 tor-im-browser-bundle_es:0
- tor-im-browser-bundle_fa:0 tor-im-browser-bundle_fr:0
- tor-im-browser-bundle_it:0 tor-im-browser-bundle_nl:0
- tor-im-browser-bundle_pl:0 tor-im-browser-bundle_pt:0
- tor-im-browser-bundle_ru:0 tor-im-browser-bundle_zh_CN:0
-\end{verbatim}
-%----------------------------------------------------------------
-\vspace{-1em}
-\caption{GetTor statistics file for December 27, 2010}
-\label{fig:gettor}
-\end{figure}
-
-\section{Tor Check exit lists}
-\label{sec:exitlist}
-
-TorDNSEL is an implementation of the active testing, DNS-based exit list
-for Tor exit
-nodes.\footnote{\texttt{https://www.torproject.org/tordnsel/dist/}}
-Tor Check makes the list of known exits and corresponding exit IP
-addresses available in a specific format.
-Figure~\ref{fig:exitlist} shows an entry of the exit list written on
-December 28, 2010 at 15:21:44 UTC.
-This entry means that the relay with fingerprint \verb+63Ba..+ which
-published a descriptor at 07:35:55 and was contained in a version 2
-network status from 08:10:11 uses two different IP addresses for exiting.
-The first address \verb+91.102.152.236+ was found in a test performed at
-07:10:30.
-When looking at the corresponding server descriptor, one finds that this
-is also the IP address on which the relay accepts connections from inside
-the Tor network.
-A second test performed at 10:35:30 reveals that the relay also uses IP
-address \verb+91.102.152.227+ for exiting.
-
-\begin{figure}
-\begin{verbatim}
-ExitNode 63BA28370F543D175173E414D5450590D73E22DC
-Published 2010-12-28 07:35:55
-LastStatus 2010-12-28 08:10:11
-ExitAddress 91.102.152.236 2010-12-28 07:10:30
-ExitAddress 91.102.152.227 2010-12-28 10:35:30
-\end{verbatim}
-\vspace{-1em}
-\caption{Exit list entry written on December 28, 2010 at 15:21:44 UTC}
-\label{fig:exitlist}
-\end{figure}
-
-\bibliography{data}
-\bibliographystyle{plain}
-
-\end{document}
-
