Proposal: Separate streams across circuits by destination port or destination host
nickm at freehaven.net
Fri Nov 12 05:25:41 UTC 2010
On Sun, Sep 26, 2010 at 9:34 AM, Robert Hogan <robert at roberthogan.net> wrote:
> On Wednesday 25 August 2010 22:12:28 Robert Hogan wrote:
>> - 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
> So after more discussion this list now looks like:
> 1 Socks authentication info (username/pass)
> 2 Socks listener address/port
> 3 Socks protocol
> 4 Socks client IP
> 5 Destination Port (if it is in the LongLivedPort list)
> And the consensus is it should be on by default.
> Adding number 5 to the list would allow users to isolate streams by port 80
> if they chose to designate it a LongLivedPort. I'm not sure if that means
> we should leave it out of the list, if we should defend against 'invalid'
> LongLivedPorts, or if it's something we are happy to allow.
> I think the list above allows stream isolation on requests over TransPort
> and NATDPort - at least to the extent that it will isolate streams on the
> basis of 2, 4 and 5 (if applicable).
Trying to push this forward... The next step here is a revised
proposal. I will lobby intransigently for holding out for an
IsolatePorts option distinct from LongLivedPorts: overloading
"long-lived" to "isolated" leads to nonsense like people deciding to
put port 80 into LongLivedPorts, which is exactly what you don't want
to use LongLivedPorts for.
More information about the tor-dev