Re: [tor-talk] Tor's stream isolation features defaults

[Nick Mathewson <nickm@xxxxxxxxxxxx>]

On Sun, May 27, 2012 at 4:56 PM,  <proper@xxxxxxxxxxxxxxx> wrote:
> We like to understand Tor's stream isolation features better. For those who don't know, they will be included in Tor 0.2.3 and are already available in the Tor Alpha 0.2.3. See https://www.torproject.org/docs/tor-manual-dev.html.en for more information on the following flags.
>
> The following questions are simply questions, because for want to understand the features better. No suggestions or criticism.


This all needs better documentation -- I'd like to get a write-up from
an integrator's point of view.  (This isn't a feature that typical end
users should necessarily want to mess with.)

For a good place to start in the meantime, see proposal 171, which
first specified this feature, and the attendant discussion thread
about it on the list.

> IsolateClientProtocol
> Why is it disabled by default?

Most of the stuff you'd want to do with it is better done by having
separate ports--especially if you're using RESOLVE calls.  (This flag
makes it so that socks4 and socks5 sent on the same client port won't
get sent over the same circuit.)

> IsolateDestPort
> Why is it disabled by default?
> Could enabling it confuse servers are applications or is it because of performance/bandwidth?
>
> IsolateDestAddr
> Why is it it disabled by default?
> Could enabling it confuse servers are applications or is it because of performance/bandwidth?

These last two are disabled because they're the wrong choice for lots
applications.  In particular, isolating by port is a bad idea for
separating protocols, although people often think at first glance that
it should be a good idea. For example, if you think that
IsolateDestPort will keep SSH separate from HTTP, you're not right:
it's trivial for a hostile webpage to include an img tag whose URL
specifies port 22, which would make HTTP and SSH requests get over the
same port.

Isolating by destination address is also ridiculously expensive and
slow if you're doing typical HTTP usage, or some other protocol where
a single logical request turns into requests to many different hosts.
Mike's got a more sophisticated approach here that he's aiming to do
in TB; he can link to the best explanation of it better than I can
find out which one is best.

-- 
Nick
_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk