[or-cvs] r18649: {projects} Add section on the performance and security implications of (projects/performance)

sjm217 at seul.org sjm217 at seul.org
Thu Feb 19 12:31:14 UTC 2009


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}},
 }
 
+ at 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}}
+}
+
+ at TechReport{DTLS,
+  author =       {Rescorla, E. and Modadugu, N.},
+  title =        {Datagram Transport Layer Security},
+  institution =  {IETF},
+  year =         {2006},
+  type =         {RFC},
+  number =       {4347},
+  month =        {April}
+}
+
+ at 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}},
+}
+
+ at 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}},
+}
+
+ at 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},
+}
+
+ at 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},
+}
+
+ at 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
 



More information about the tor-commits mailing list