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

[Nick Mathewson]

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.