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

[Jacob Appelbaum]

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-streams:/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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 793 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20100723/789ee708/attachment.pgp>