Proposal: Separate streams across circuits by destination port or destination host

[Robert Hogan]

So this is my take on the thread so far:

- We've zoned in on the fact that this proposal is really about isolating 
applications on circuits rather than ports on circuits.

- Isolating by destination address is likely to increase the number of 
circuits the client builds by some scary quantity.

- There is a potential attack if we isolate by port number alone. A 
malicious website could server resources over a variety of port numbers, 
learn our exit nodes for each, and then presumably correlate our activity 
on port 443/80 with our activity on any services we use that it happens to 
provide on any of the other ports.

- We can achieve some/a lot of the benefits sought by the proposal if we 
isolate streams based on the information provided by the socks request 
itself. The things people have suggested are:
  1 Socks authentication info (username/pass)
  2 Socks listener address/port
  3 Socks protocol
  4 Socks client IP
  5 Info in /proc/pid/cmdline garnered from the client's port number

My own view is that 1 to 4 above could be used to determine the choice of 
circuit even in the absence of an IsolateStreamsBy* option. 5 is ugly and 
generally won't work if running as a 'tor' user so can be discarded.

I think the only argument for making item 1 optional would be so that 
people know about it. Maybe it can be an option and on by default. 

Thoughts?


On Friday 23 July 2010 16:03:09 Jacob Appelbaum wrote:
> Hello,
> 
> Nick blessed me as a co-proposal editor last night at PETS2010; I've
> given the following proposal an initial number of 171.
> 
> The proposal in question will be updated in my git repository until it
> is accepted into master:
> https://gitweb.torproject.org/ioerror/tor.git/blob/refs/heads/isolated-s
> treams:/doc/spec/proposals/171-separate-streams-by-port-or-host.txt
> 
> Here's the proposal in question:
> 
> Filename: 171-separate-streams-by-port-or-host.txt
> Title: Separate streams across circuits by destination port or
> destination host
> Author: Robert Hogan, Jacob Appelbaum, Damon McCoy
> Created: 21-Oct-2008
> Modified: 22-Jul-2010
> Status: Draft
> 
> Motivation:
> 
> Streams are currently attached to circuits without regard to their
> content, destination host, or destination port. We propose two options,
> IsolateStreamsByPort and IsolateStreamsByHost to change the default
> behavior.
> 
> The contents of some streams will always have revealing plain text
> information; these streams should be treated differently than other
> streams that may or may not have unencrypted PII content. DNS, with the
> exception of DNSCurve, is always unencrypted. It is reasonable to assume
> that other protocols may exist that have a similar issue and may cause
> user concern. It is also the case that we must balance network load
> issues and stream privacy. The Tor network will not currently scale to
> one circuit per connection nor should it anytime soon.
> 
> Circuits are currently created with a few constraints and are rotated
> within a reasonable time window. This allows a rogue exit nodes to
> correlate all streams on a given circuit.
> 
> Design:
> 
> We propose two options for isolation of streams that lessen the
> observability and linkability of the Tor client's traffic.
> 
> IsolateStreamsByPort will take a list of ports or optionally the keyword
> 'All' in place of a port list. The use of the keyword 'All' will ensure
> that all connections attached to streams will be isolated to separate
> circuits by port number.
> 
> IsolateStreamsByHost will take a boolean value. When enabled, all
> connections, regardless of port number will be isolated with separate
> circuits per host. If this option is enabled, we should ensure that the
> client has a reasonable number of pre-built circuits to ensure perceived
> performance. This should also intentionally limit the total number of
> circuits a client will build to ten circuits to prevent abuse and load
> on the network. This is a trade-off of performance for anonymity. Tor
> will issue a warning if a client encounters this
> limit.
> 
> Security implications:
> 
> It is believed that the proposed changes will improve the anonymity for
> end user stream privacy.  The end user will no longer link all of their
> traffic at a single exit node during a given time window.
> 
> Specification:
> 
> The Tor client circuit selection process is not entirely specified. Any
> client circuit specification must take these changes into account.
> 
> Compatibility:
> 
> The proposed changes should not create any compatibility issues. New Tor
> clients will be able to take advantage of this without any modification
> to the network.
> 
> Implementation:
> 
> It is further proposed that IsolateStreamsByPort will be enabled by
> default for port 22, 53, and port 80.
> 
> It is further proposed that IsolateStreamsByHost will be disabled by
> default.
> 
> Implementation notes:
> 
> The implementation of this option may want to consider cases where the
> same exit node is shared by two or more circuits and
> IsolateStreamsByPort is in force. Since the purpose of the option is to
> reduce the opportunity of Exit Nodes to attack traffic from the same
> source on multiple ports, the implementation may need to ensure that
> circuits reserved for the exclusive use of given ports do not share the
> same exit node.
> 
> Performance and scalability notes:
> 
> It is further proposed that IsolateStreamsByPort will be enabled by
> default for all ports after a reasonable assessment is performed.
> Specifically, we should determine the impact this option has on Tor
> clients and the Tor network.