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

starslights stars at
Fri Jul 23 18:37:11 UTC 2010

Le vendredi 23 juillet 2010 17.03:09, vous avez écrit :
> 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:
> ams:/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.

Hi  Jacob,

Thanks very much to sahre with us, it look a good idea for me, some site still 
resitant against ssl and little help for security will welcome....

I will give a try.

I will give my feedback, best regrads

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 230 bytes
Desc: This is a digitally signed message part.
URL: <>

More information about the tor-dev mailing list