<div class="gmail_quote">Hi Roger. Here's the first draft of the proposed additions to address the arm<br>
wishlist. To start with:<br>
- What more would be useful? I don't do core tor development nor analysis like<br>
Karsten so I'm not sure what you'd like from a monitor for debugging or<br>
network examination. One thought might be a GETINFO option for getting log<br>
entries related to a given connection (would be especially interesting in<br>
case investigating circuit extension failures and such). Probably not<br>
possible since it would require tor to remember log data...<br>
<br>
- Comments like "Wtf? That's utterly useless/wrong!" appreciated! I've naively<br>
included included some things that might not be helpful (like the 'e/E' flag<br>
to indicate if connections are encrypted), not to mention mistakes thanks to<br>
a not-quite-so-perfect understanding of networking, tor, and writing specs.<br>
<br>
- Anything dangerous? Doubt it, but the bandwidth measurements should probably<br>
either be rounded or provided occasionally (say, every second) to address<br>
correlation attacks. I'm sure Sebastian will enthusiastically sink some<br>
paranoia into this later. ;)<br>
<br>
- Should we document how frequently the connection data is updated or have some<br>
'last updated time' parameter?<br>
<br>
- When hosting hidden services I'd imagine some connections are dedicated to<br>
them. If so, lets add a flag to indicate them.<br>
<br>
Cheers! -Damian<br>
<br>
-------------------------------------------------------------------------------<br>
<br>
The following is a proposal for additions to the control-spec's GETINFO<br>
parameters to reveal additional information related to tor connections and<br>
circuits. The intention is to provide a viable alternative to netstat and lsof<br>
for discovering these stats with the following benefits:<br>
<br>
- Performance<br>
Frequently querying this information via external tools has a significant<br>
overhead (especially for busy relays). Tor already has this information cached<br>
so being able to fetch it via the control port would introduce significant<br>
performance benefits for monitoring tools like arm.<br>
<br>
- Authoritative<br>
How does tor view the world? An external perspective of how tor is utilizing<br>
network resources is interesting, but from an auditing perspective it's even<br>
more interesting if this can be used to validate tor's internal accounting.<br>
<br>
- Additional Information<br>
While we can infer some information like the connection type and corresponding<br>
relay from raw connection data, it would be a lot nicer (and more accurate) to<br>
not need to guess. Providing additional information (like per-connection<br>
bandwidth or buffer usage) might also be interesting, assuming we can do so<br>
safely.<br>
<br>
Most of this information is already available to relays (both benign and<br>
malicious), but if you spot some troubling privacy implication then please<br>
speak up! Nothing here should end the world, but we certainly don't want to<br>
make things easier for not-so-well-meaning people.<br>
<br>
-------------------------------------------------------------------------------<br>
<br>
"conn/<Connection identity>" -- Provides entry for the associated<br>
connection, formatted as:<br>
CONN_ID CIRC_ID OR_ID IP PORT TYPE_FLAGS READ WRITE UPTIME BUFF<br>
<br>
none of the parameters contain whitespace, and additional results must be<br>
ignored to allow for future expansion. Parameters are defined as follows:<br>
CONN_ID - Unique identifier associated with this connection.<br>
CIRC_ID - Unique identifier for the circuit this belongs to (0 if this<br>
doesn't belong to any circuit). At most their may be two connections<br>
(one inbound, one outbound) with any given CIRC_ID.<br>
OR_ID - Relay fingerprint, 0 if connection doesn't belong to a relay.<br>
IP/PORT - IP address and port used by the associated connection.<br>
TYPE_FLAGS - Single character flags indicating directionality and type<br>
of the connection (consists of one from each category, may become<br>
longer for future expansion).<br>
I: inbound, i: listening (unestablished inbound),<br>
O: outbound, o: unestablished outbound<br>
C: client related, R: relay related, X: control, D: directory<br>
T: inter-tor connection, t: outside the tor network<br>
E: encrypted traffic, e: unencrypted traffic<br>
For instance, "IRtE" would indicate that this was an established<br>
1st-hop (or bridged) relay connection.<br>
READ/WRITE - Total bytes read/written over the life of this connection.<br>
UPTIME - Time the connection's been established in seconds.<br>
BUFF - Bytes of data buffered for this relay connection.<br>
<br>
"conn/all" -- Newline separated listing of all current connections.<br>
<br>
"info/relay/bw-limit" -- Effective relayed bandwidth limit (currently<br>
RelayBandwidthRate if set, otherwise BandwidthRate).<br>
<br>
"info/relay/burst-limit" -- Effective relayed burst limit.<br>
<br>
"info/relay/read-total" -- Total bytes relayed (download).<br>
<br>
"info/relay/write-total" -- Total bytes relayed (upload).<br>
<br>
"info/relay/buffer-cap" -- Maximum buffer size for relay connections.<br>
<br>
"info/uptime-process" -- Total uptime of the tor process (in seconds).<br>
<br>
"info/uptime-reset" -- Time since last reset (startup or sighup signal, in<br>
seconds).<br>
<br>
"info/descriptor-used" -- Count of file descriptors used.<br>
<br>
"info/descriptor-limit" -- File descriptor limit (getrlimit results).<br>
<br>
"ns/authority" -- Router status info (v2 directory style) for all<br>
recognized directory authorities, joined by newlines.<br>
</div><br>