[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[or-cvs] r18649: {projects} Add section on the performance and security implications of (projects/performance)
Author: sjm217
Date: 2009-02-19 07:31:13 -0500 (Thu, 19 Feb 2009)
New Revision: 18649
Modified:
projects/performance/performance.bib
projects/performance/performance.tex
Log:
Add section on the performance and security implications of a UDP/IPsec transport for Tor
Modified: projects/performance/performance.bib
===================================================================
--- projects/performance/performance.bib 2009-02-19 08:47:05 UTC (rev 18648)
+++ projects/performance/performance.bib 2009-02-19 12:31:13 UTC (rev 18649)
@@ -59,3 +59,74 @@
note = {\url{http://archives.seul.org/or/dev/Dec-2008/msg00005.html}},
}
+@mastersthesis{reardon-thesis,
+ title = {Improving {Tor} using a {TCP}-over-{DTLS} Tunnel},
+ author = {Reardon, Joel},
+ school = {University of Waterloo},
+ year = {2008},
+ month = {September},
+ www_tags = {selected},
+ www_abstract_url = {http://hdl.handle.net/10012/4011},
+ www_section = {Anonymous communication},
+ www_pdf_url = {http://uwspace.uwaterloo.ca/bitstream/10012/4011/1/thesis.pdf},
+ note = {\url{http://hdl.handle.net/10012/4011}}
+}
+
+@TechReport{DTLS,
+ author = {Rescorla, E. and Modadugu, N.},
+ title = {Datagram Transport Layer Security},
+ institution = {IETF},
+ year = {2006},
+ type = {RFC},
+ number = {4347},
+ month = {April}
+}
+
+@TechReport{tor-l3-approach,
+ author = {Kiraly, C. and Bianchi G. and Lo Cigno, R.},
+ title = {Solving Performance Issues in Anonymization Overlays with a {L}3 approach},
+ institution = {University of Trento},
+ year = {2008},
+ number = {DISI-08-041},
+ month = {September},
+ note = {version 1.1, \url{http://disi.unitn.it/locigno/preprints/TR-DISI-08-041.pdf}},
+}
+
+@Misc{daytona,
+ author = {Prashant Pradhan and Srikanth Kandula and Wen Xu and Anees Shaikh and Erich Nahum},
+ title = {Daytona: A User-Level {TCP} Stack},
+ year = {2002},
+ note = {\url{http://nms.lcs.mit.edu/~kandula/data/daytona.pdf}},
+}
+
+@InProceedings{tcptiming,
+ author = {Kohno, Tadayoshi and Broido, Andre and {claffy}, {kc}},
+ title = {Remote Physical Device Fingerprinting},
+ booktitle = {IEEE Symposium on Security and Privacy},
+ pages = {211--225},
+ year = {2005},
+ address = {Oakland, CA, US},
+ month = {May},
+ publisher = {IEEE Computer Society},
+}
+
+@inproceedings{HotOrNot,
+ title = {Hot or Not: Revealing Hidden Services by their Clock Skew},
+ author = {Steven J. Murdoch},
+ booktitle = {CCS '06: Proceedings of the 9th ACM Conference on Computer and Communications Security},
+ pages = {27--36},
+ year = {2006},
+ month = {October},
+ address = {Alexandria, VA, US},
+ publisher = {ACM Press},
+}
+
+@TechReport{IPsec,
+ author = {Kent, S. and Seo, K.},
+ title = {Security Architecture for the Internet Protocol},
+ institution = {IETF},
+ year = {2005},
+ type = {RFC},
+ number = {4301},
+ month = {December}
+}
\ No newline at end of file
Modified: projects/performance/performance.tex
===================================================================
--- projects/performance/performance.tex 2009-02-19 08:47:05 UTC (rev 18648)
+++ projects/performance/performance.tex 2009-02-19 12:31:13 UTC (rev 18649)
@@ -204,6 +204,42 @@
Also, because the majority of cells sent in Tor are encrypted by a key not known by the attacker, the probability that an attacker can guess what a cell might be is extremely small.
The exception is a padding cell, which has no circuit ID and a zero length payload, however Tor does not currently send padding cells, other than as a periodic keep-alive.
+\section{End-to-end congestion avoidance}
+
+Tor currently uses two levels of congestion avoidance -- TCP flow control per-link, and a simple windowing scheme per-circuit.
+It has been suggested that this approach is causing performance problems, because the two schemes interact badly.
+Also, it is known that multiplexing multiple streams over a single TCP link gives poorer performance than keeping them separate.
+Experiments show that moving congestion management to be fully end-to-end offers a significant improvement in performance.
+
+There have been two proposals to resolve this problem, but their underlying principle is the same: use an unreliable protocol for links between Tor nodes, and perform error recovery and congestion management between the client and exit node.
+Joel Reardon~\cite{reardon-thesis} proposed using DTLS~\cite{DTLS} (a UDP variant of TLS), as the link protocol, a cut-down version of TCP to give reliability and congestion avoidance, but largely using the existing Tor cell protocol.
+Csaba Kiraly \detal~\cite{tor-l3-approach} proposed using IPSec~\cite{ipsec} to replace the Tor cell and link protocol.
+
+Each approach has their own strengths and weaknesses.
+DTLS is relatively immature, and Reardon noted deficiencies in the OpenSSL implementation of the protocol.
+However, the largest missing piece from this proposal is a high-quality, privacy preserving TCP stack, under a compatible license.
+Prior work has shown that there is a substantial privacy leak from TCP stack and clockskew fingerprinting~\cite{tcptiming,HotOrNot}.
+Therefore to adopt this proposal, Tor would need to incorporate a TCP stack, modified to operate in user-mode and to not leak identity information.
+
+Reardon built a prototype around the TCP-Daytona stack~\cite{daytona}, developed at IBM Labs, and based on the Linux kernel TCP stack.
+This implementation is not publicly available and its license is unclear, so it is unlikely to be suitable for use in Tor.
+Writing a TCP stack from scratch is a substantial undertaking, and therefore other attempts have been to move different operating system stacks into user-space.
+While there have been some prototypes, the maturity of these systems have yet to be shown.
+
+Kiraly \etal rely on the operating system IPsec stack, and a modification to the IKE key exchange protocol to support onion routing.
+As with the proposal from Reardon, there is a risk of operating system and machine fingerprinting from exposing the client TCP stack to the exit node.
+This could be resolved in a similar way, by implementing a user-mode IPsec stack, but this would be a substantial effort, and would lose some of the advantages of making use of existing building blocks.
+
+A significant issue with moving from TLS as the link protocol is that it is incompatible with Tor's current censorship-resistance strategy.
+Tor impersonates the TLS behaviour of HTTPS web-browsing, with the intention that it is difficult to block Tor, without blocking a significant amount of HTTPS.
+If Tor were to move to an unusual protocol, such as DTLS, it would be easier to block just Tor.
+Even IPsec is comparatively unusual on the open Internet.
+
+One option would be to modify the link protocol so that it impersonates an existing popular encrypted protocol.
+To avoid requiring low-level operating system access, this should be a UDP protocol.
+There are few options available, as TCP is significantly more popular.
+Voice over IP is one fruitful area, as these require low latency and hence UDP is common, but further investigation is needed.
+
\subsection*{Acknowledgements}
% Mike Perry provided many of the ideas discussed here
@@ -215,7 +251,7 @@
Other items to add in somewhere:
-UDP transport
+%UDP transport
Mike and Fallon's proposal