Proposal 171 (revised): Separate streams across circuits by connection metadata

[Robert Hogan]

A lot to digest!


On Tuesday 07 December 2010 16:02:05 you wrote:
> 
>   Generally, all the streams on a session come from a single
>   application.  Unfortunately, isolating streams by application
>   automatically isn't feasible, given the lack of any nice
>   cross-platform way to tell which local process originated a given
>   connection.  (Yes, lsof works.  But a quick review of the lsof code
>   should be sufficient to scare you away from thinking there is a
>   portable option, much less a portable O(1) option.)  So instead, we'll
>   have to use some other aspect of a Tor request as a proxy for the
>   application.

It's hard to credit there isn't a good interface for this. The closest 
Linux gets is taskstats - see http://linux.derkeiler.com/Mailing-
Lists/Kernel/2010-06/msg01125.html, but the requirement here (which is 
shared by programs like wireshark and nearly every network management 
application) is to match inode to pid reliably. 

Interestingly, Unix sockets allow you to collect the gid and uid of the 
process on the other side of the socket. Not the pid unfortunately.

> 
> Design:
> 
>   When a stream arrives at Tor, we have the following data to examine:
>     1) The destination address
>     2) The destination port (unless this a DNS lookup)
>     3) The protocol used by the application to send the stream to Tor:
>        SOCKS4, SOCKS4A, SOCKS5, or whatever local "transparent proxy"
>        mechanism the kernel gives us.
>     4) The port used by the application to send the stream to Tor --
>        that is, the SOCKSListenAddress or TransListenAddress that the
>        application used, if we have more than one.
>     5) The SOCKS username and password, if any.
>     6) The source address and port for the application.
> 

Why not the source address too? Robert Ransom made the point in a previous 
thread that Tor could be serving a local network.

> The "IsolateSOCKSUser" and "IsolateClientAddr" options are on by
>  default; "NoIsolateSOCKSUser" and "NoIsolateClientAddr" respectively
>  turn them off.  The IsolateDestPort and IsolateDestAddr and
>  IsolateClientProtocol options are off by default.  NoIsolateDestPort and
>  NoIsolateDestAddr and NoIsolateClientProtocol have no effect.

Why is IsolateClientProtocol off by default? Seems like a cheap, 
opportunistic way of distinguishing client applications.

> 
>   Handling DNS can be a challenge.  We can get hostnames by one of three
>   means:
> 
>     A) A SOCKS4a request, or a SOCKS5 request with a hostname.  This
>        case is handled trivially using the rules above.
>     B) A RESOLVE request on a SOCKSPort.  This case is handled using the
>        rules above, except that port isolation can't work to isolate
>        RESOLVE requests into a proper session, since we don't know which
>        port will eventually be used when we connect to the returned
>        address.
>     C) A request on a DNSPort.  We have no way of knowing which
>        address/port will be used to connect to the requested address.
> 
>   When B or C is required but problematic, we could favor the use of
>   AutomapHostsOnResolve.
> 

I'm not clear when it will be problematic. Can you clarify?