[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[or-cvs] r24193: {website} revise TransportIPnotTCP answer (in website/trunk: docs/en getinvolved/en)
Author: arma
Date: 2011-02-07 08:34:57 +0000 (Mon, 07 Feb 2011)
New Revision: 24193
Modified:
website/trunk/docs/en/faq.wml
website/trunk/getinvolved/en/volunteer.wml
Log:
revise TransportIPnotTCP answer
Modified: website/trunk/docs/en/faq.wml
===================================================================
--- website/trunk/docs/en/faq.wml 2011-02-07 08:23:39 UTC (rev 24192)
+++ website/trunk/docs/en/faq.wml 2011-02-07 08:34:57 UTC (rev 24193)
@@ -1532,7 +1532,7 @@
<a href="<page getinvolved/volunteer>#Research">research section of the
volunteer page</a>: "Tor doesn't work very well when relays
have asymmetric bandwidth (e.g. cable or DSL)". It might be that <a
- href="<wikifaq>#YoushouldtransportallIPpacketsnotjustTCPpackets.">switching
+ href="<page docs/faq>#TransportIPnotTCP">switching
to UDP transport</a> is the simplest answer here — which alas is
not a very simple answer at all.
</p>
@@ -1581,31 +1581,29 @@
all IP packets, not just TCP packets.</a></h3>
<p>
-This would be handy, because it would make Tor
-more generally useful. It would also solve the whole
-need to socksify applications, and it would resolve the <a
-href="<wikifaq>#HowdoIcheckifmyapplicationthatusesSOCKSisleakingDNSrequests">DNS
-leak problem</a> too. Lastly, it would solve the fact that exit relays
-need to allocate a lot of file descriptors to hold open all the exit
-connections.
+This would be handy, because it would make Tor better able to handle
+new protocols like VoIP, it could solve the whole need to socksify
+applications, and it would solve the fact that exit relays need to
+allocate a lot of file descriptors to hold open all the exit connections.
</p>
<p>
-On the other hand, there are six reasons we haven't done this:
+We're heading in this direction: see <a
+href="https://trac.torproject.org/projects/tor/ticket/1855";>this trac
+ticket</a> for directions we should investigate. Some of the hard
+problems are:
</p>
-<li>IP packets reveal OS characteristics. We would still
-need to do IP-level packet normalization, to stop things like
-TCP fingerprinting attacks. This is unlikely to be a trivial
-task, given the diversity and complexity of TCP stacks. In
-fact, it's worse than this: check out the new class of <a
+<li>IP packets reveal OS characteristics. We would still need to do
+IP-level packet normalization, to stop things like TCP fingerprinting
+attacks. Given the diversity and complexity of TCP stacks, along with <a
href="<wikifaq>#DoesTorresistremotephysicaldevicefingerprinting">device
-fingerprinting attacks</a> which we would have to tackle as well.
+fingerprinting attacks</a>, it looks like our best bet is shipping our
+own user-space TCP stack.
</li>
-<li>Application-level streams still need scrubbing. We still need Tor
-to be easy to integrate with user-level application-specific proxies
-such as Privoxy. So it's not just a matter of capturing packets and
-anonymizing them at the IP layer.
+<li>Application-level streams still need scrubbing. We will still need
+user-side applications like Torbutton. So it won't become just a matter
+of capturing packets and anonymizing them at the IP layer.
</li>
<li>Certain protocols will still leak information. For example, we must
rewrite DNS requests so they are delivered to an unlinkable DNS server
@@ -1614,10 +1612,10 @@
</li>
<li><a
href="http://crypto.stanford.edu/~nagendra/projects/dtls/dtls.html";>DTLS</a>
-(datagram TLS) will be in the 0.9.8 openssl release. We need to design
-a new end-to-end Tor protocol for avoiding tagging attacks and other
-potential anonymity and integrity issues now that we allow drops, resends,
-et cetera.
+(datagram TLS) basically has no users, and IPsec sure is big. Once we've
+picked a transport mechanism, we need to design a new end-to-end Tor
+protocol for avoiding tagging attacks and other potential anonymity and
+integrity issues now that we allow drops, resends, et cetera.
</li>
<li>Exit policies for arbitrary IP packets mean building a secure
IDS. Our node operators tell us that exit policies are one of the main
@@ -1633,12 +1631,10 @@
and clients need to predict all the packets they will want to send in
a session before picking their exit node!
</li>
-<li>The Tor-internal name spaces would need to be redesigned. We
-support hidden service ".onion" addresses (and other special addresses,
-like ".exit" which lets the user request a particular exit node), by
-intercepting the addresses when they are passed to the Tor client. Doing
-so at the IP level would require a more complex interface between Tor
-and the local DNS resolver.
+<li>The Tor-internal name spaces would need to be redesigned. We support
+hidden service ".onion" addresses by intercepting the addresses when
+they are passed to the Tor client. Doing so at the IP level will require
+a more complex interface between Tor and the local DNS resolver.
</li>
</ol>
Modified: website/trunk/getinvolved/en/volunteer.wml
===================================================================
--- website/trunk/getinvolved/en/volunteer.wml 2011-02-07 08:23:39 UTC (rev 24192)
+++ website/trunk/getinvolved/en/volunteer.wml 2011-02-07 08:34:57 UTC (rev 24193)
@@ -665,7 +665,7 @@
encryption. This is nice and simple, but it means all cells
on a link are delayed when a single packet gets dropped, and
it means we can only reasonably support TCP streams. We have a <a
- href="https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ#YoushouldtransportallIPpacketsnotjustTCPpackets.";>list
+ href="<page docs/faq>#TransportIPnotTCP">list
of reasons why we haven't shifted to UDP transport</a>, but it would
be great to see that list get shorter. We also have a proposed <a
href="<gitblob>doc/spec/proposals/100-tor-spec-udp.txt">specification