[or-cvs] [tor/master 3/4] Rename proposal 171 file

Tue Dec 7 15:58:02 UTC 2010

Author: Nick Mathewson <nickm at torproject.org>
Date: Sat, 27 Nov 2010 15:59:08 -0500
Subject: Rename proposal 171 file
Commit: c4d2a55a888b437803916ec0de3b4882b60d0a6c

---
 .../171-separate-streams-by-port-or-host.txt       |   99 --------------------
 doc/spec/proposals/171-separate-streams.txt        |   99 ++++++++++++++++++++
 2 files changed, 99 insertions(+), 99 deletions(-)
 delete mode 100644 doc/spec/proposals/171-separate-streams-by-port-or-host.txt
 create mode 100644 doc/spec/proposals/171-separate-streams.txt

diff --git a/doc/spec/proposals/171-separate-streams-by-port-or-host.txt b/doc/spec/proposals/171-separate-streams-by-port-or-host.txt
deleted file mode 100644
index d71a5c2..0000000
--- a/doc/spec/proposals/171-separate-streams-by-port-or-host.txt
+++ /dev/null
@@ -1,99 +0,0 @@
-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: 30-Aug-2010
-Status: Draft
-
-Motivation:
-
-Streams are currently attached to circuits without regard to their content,
-destination host, or destination port. We propose three options,
-IsolateBySOCKSUser, 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 application 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 node 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
-application connections attached to streams will be isolated to separate
-circuits by port number.
-
-IsolateStreamsByHost will take a boolean value. When enabled, all application
-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.
-
-IsolateBySOCKSUser will take a boolean value. When enabled, all application
-connections, regardless of port number will be isolated with separate circuits
-per SOCKS username. This options ensures that any two streams that were created
-with different SOCKS usernames will be sent over different circuits.  The empty
-username will be treated as its own username different from all other usernames.
-
-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 streams at a single
-exit node during a given time window.
-
-There is a possible attack where a hostile web page possibly in collusion with
-an exit node contains image links for images at (say) "evil.example.com:53" and
-"evil.example.com:31337", and thereby (if they're lucky) correlate port-80
-circuits with port-53 and port-31337 circuits.
-
-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.
-
-Circuits should not be shared by unique clients. Tor should check to ensure
-that peer IP addresses are identical when they connect to the SOCKS listener or
-the TransPort listener before sharing a circuit. If the addresses are not
-identical, Tor should ensure that the circuits are not shared.
-
-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.
diff --git a/doc/spec/proposals/171-separate-streams.txt b/doc/spec/proposals/171-separate-streams.txt
new file mode 100644
index 0000000..d71a5c2
--- /dev/null
+++ b/doc/spec/proposals/171-separate-streams.txt
@@ -0,0 +1,99 @@
+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: 30-Aug-2010
+Status: Draft
+
+Motivation:
+
+Streams are currently attached to circuits without regard to their content,
+destination host, or destination port. We propose three options,
+IsolateBySOCKSUser, 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 application 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 node 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
+application connections attached to streams will be isolated to separate
+circuits by port number.
+
+IsolateStreamsByHost will take a boolean value. When enabled, all application
+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.
+
+IsolateBySOCKSUser will take a boolean value. When enabled, all application
+connections, regardless of port number will be isolated with separate circuits
+per SOCKS username. This options ensures that any two streams that were created
+with different SOCKS usernames will be sent over different circuits.  The empty
+username will be treated as its own username different from all other usernames.
+
+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 streams at a single
+exit node during a given time window.
+
+There is a possible attack where a hostile web page possibly in collusion with
+an exit node contains image links for images at (say) "evil.example.com:53" and
+"evil.example.com:31337", and thereby (if they're lucky) correlate port-80
+circuits with port-53 and port-31337 circuits.
+
+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.
+
+Circuits should not be shared by unique clients. Tor should check to ensure
+that peer IP addresses are identical when they connect to the SOCKS listener or
+the TransPort listener before sharing a circuit. If the addresses are not
+identical, Tor should ensure that the circuits are not shared.
+
+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.
-- 
1.7.1


