Browse code

import TransportIPnotTCP faq entry

Roger Dingledine authored on 07/02/2011 09:23:39
Showing 1 changed files
... ...
@@ -90,6 +90,8 @@
90 90
     <ul>
91 91
     <li><a href="#EverybodyARelay">You should make every Tor user be a
92 92
     relay.</a></li>
93
+    <li><a href="#TransportIPnotTCP">You should transport all IP packets,
94
+    not just TCP packets.</a></li>
93 95
     </ul>
94 96
 
95 97
     <p>Abuse:</p>
... ...
@@ -1572,6 +1574,74 @@ we move to a "directory guard" design as well.
1572 1574
     Please help on all of these!
1573 1575
     </p>
1574 1576
 
1577
+<hr>
1578
+
1579
+<a id="TransportIPnotTCP"></a>
1580
+<h3><a class="anchor" href="#TransportIPnotTCP">You should transport
1581
+all IP packets, not just TCP packets.</a></h3>
1582
+
1583
+<p>
1584
+This would be handy, because it would make Tor
1585
+more generally useful. It would also solve the whole
1586
+need to socksify applications, and it would resolve the <a
1587
+href="<wikifaq>#HowdoIcheckifmyapplicationthatusesSOCKSisleakingDNSrequests">DNS
1588
+leak problem</a> too. Lastly, it would solve the fact that exit relays
1589
+need to allocate a lot of file descriptors to hold open all the exit
1590
+connections.
1591
+</p>
1592
+
1593
+<p>
1594
+On the other hand, there are six reasons we haven't done this:
1595
+</p>
1596
+
1597
+<li>IP packets reveal OS characteristics. We would still
1598
+need to do IP-level packet normalization, to stop things like
1599
+TCP fingerprinting attacks. This is unlikely to be a trivial
1600
+task, given the diversity and complexity of TCP stacks. In
1601
+fact, it's worse than this: check out the new class of <a
1602
+href="<wikifaq>#DoesTorresistremotephysicaldevicefingerprinting">device
1603
+fingerprinting attacks</a> which we would have to tackle as well.
1604
+</li>
1605
+<li>Application-level streams still need scrubbing. We still need Tor
1606
+to be easy to integrate with user-level application-specific proxies
1607
+such as Privoxy. So it's not just a matter of capturing packets and
1608
+anonymizing them at the IP layer.
1609
+</li>
1610
+<li>Certain protocols will still leak information. For example, we must
1611
+rewrite DNS requests so they are delivered to an unlinkable DNS server
1612
+rather than the DNS server at a user's ISP; thus, we must understand
1613
+the protocols we are transporting.
1614
+</li>
1615
+<li><a
1616
+href="http://crypto.stanford.edu/~nagendra/projects/dtls/dtls.html">DTLS</a>
1617
+(datagram TLS) will be in the 0.9.8 openssl release. We need to design
1618
+a new end-to-end Tor protocol for avoiding tagging attacks and other
1619
+potential anonymity and integrity issues now that we allow drops, resends,
1620
+et cetera.
1621
+</li>
1622
+<li>Exit policies for arbitrary IP packets mean building a secure
1623
+IDS. Our node operators tell us that exit policies are one of the main
1624
+reasons they're willing to run Tor. Adding an Intrusion Detection System
1625
+to handle exit policies would increase the security complexity of Tor,
1626
+and would likely not work anyway, as evidenced by the entire field of IDS
1627
+and counter-IDS papers. Many potential abuse issues are resolved by the
1628
+fact that Tor only transports valid TCP streams (as opposed to arbitrary
1629
+IP including malformed packets and IP floods), so exit policies become
1630
+even <i>more</i> important as we become able to transport IP packets. We
1631
+also need to compactly describe exit policies in the Tor directory,
1632
+so clients can predict which nodes will allow their packets to exit &mdash;
1633
+and clients need to predict all the packets they will want to send in
1634
+a session before picking their exit node!
1635
+</li>
1636
+<li>The Tor-internal name spaces would need to be redesigned. We
1637
+support hidden service ".onion" addresses (and other special addresses,
1638
+like ".exit" which lets the user request a particular exit node), by
1639
+intercepting the addresses when they are passed to the Tor client. Doing
1640
+so at the IP level would require a more complex interface between Tor
1641
+and the local DNS resolver.
1642
+</li>
1643
+</ol>
1644
+
1575 1645
     <hr>
1576 1646
 
1577 1647
     <a id="Criminals"></a>