Re: Control Spec Addition First Draft

[Sebastian Hahn <hahn.seb@xxxxxx>]

Hi Damian,

please find my comments inline below.

On Dec 17, 2009, at 3:24 AM, Damian Johnson wrote:

[snip]
>  - Anything dangerous? Doubt it, but the bandwidth measurements should probably
>  either be rounded or provided occasionally (say, every second) to address
>  correlation attacks. I'm sure Sebastian will enthusiastically sink some
>  paranoia into this later. ;)

As always, I'm very uncomfortable with giving away users'/destinations' ip addresses or ports. I do realize that the same information can be obtained from netstat and friends, but I still think we should actively discourage the use and acquisition of this data. I realize that this is against the intentions of this proposal, but I hope that it is still useful even without client/destination identifying information.

> - When hosting hidden services I'd imagine some connections are dedicated to
>  them. If so, lets add a flag to indicate them.

This is, I think, a misunderstanding of what a connection is. More below.

[snip]
>    "conn/<Connection identity>" -- Provides entry for the associated
>      connection, formatted as:
>        CONN_ID CIRC_ID OR_ID IP PORT TYPE_FLAGS READ WRITE UPTIME BUFF
> 
>      none of the parameters contain whitespace, and additional results must be
>      ignored to allow for future expansion. Parameters are defined as follows:
>        CONN_ID - Unique identifier associated with this connection.
>        CIRC_ID - Unique identifier for the circuit this belongs to (0 if this
>          doesn't belong to any circuit). At most their may be two connections
>          (one inbound, one outbound) with any given CIRC_ID.

Here, the connection identity needs to either include the CIRC_ID, or this is ambigious. Tor mutliplexes many circuits over the same connection, so there is no way to infer the circuit id from a connection id. Also, for exit connections, there may be more than two connections with the same circuit id. What this means: We either want a seperate query to learn about circuits, or we want the conn_id to list all the circuits that it has attached, or we want to only allow queries of this kind when circ id and conn id are both known to the controller

>        OR_ID - Relay fingerprint, 0 if connection doesn't belong to a relay.
>        IP/PORT - IP address and port used by the associated connection.
>        TYPE_FLAGS - Single character flags indicating directionality and type
>          of the connection (consists of one from each category, may become
>          longer for future expansion).
>            I: inbound, i: listening (unestablished inbound),
>              O: outbound, o: unestablished outbound
>            C: client related, R: relay related, X: control, D: directory
>            T: inter-tor connection, t: outside the tor network
>            E: encrypted traffic, e: unencrypted traffic
>          For instance, "IRtE" would indicate that this was an established
>          1st-hop (or bridged) relay connection.

These flags seem to be mostly redundant. Again, they don't necessarily work because a connection can be used for many things. As for the Ee flag, I don't really see the purpose, we certainly shouldn't look at exit traffic going through the connection to decide if it is encrypted or not.

>        READ/WRITE - Total bytes read/written over the life of this connection.
>        UPTIME - Time the connection's been established in seconds.
>        BUFF - Bytes of data buffered for this relay connection.
> 
>    "conn/all" -- Newline separated listing of all current connections.
> 
>    "info/relay/bw-limit" -- Effective relayed bandwidth limit (currently
>      RelayBandwidthRate if set, otherwise BandwidthRate).
> 
>    "info/relay/burst-limit" -- Effective relayed burst limit.
> 
>    "info/relay/read-total" -- Total bytes relayed (download).
> 
>    "info/relay/write-total" -- Total bytes relayed (upload).
> 
>    "info/relay/buffer-cap" -- Maximum buffer size for relay connections.
> 
>    "info/uptime-process" -- Total uptime of the tor process (in seconds).
> 
>    "info/uptime-reset" -- Time since last reset (startup or sighup signal, in
>      seconds).
> 
>    "info/descriptor-used" -- Count of file descriptors used.
> 
>    "info/descriptor-limit" -- File descriptor limit (getrlimit results).
> 
>    "ns/authority" -- Router status info (v2 directory style) for all
>      recognized directory authorities, joined by newlines.
> 

These all sound sane.


Sebastian