[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: Control Spec Addition First Draft
Thanks Sebastian! You're right - I can't think of any valid use cases
for needing the ip address/port of client and exit connections so
dropping that from the proposal.
That said, I think it's a mistake to drop those connections entirely
since some of their attributes *are* of legitimate usefulness:
- Existance
At the very least it'd be nice if Tor indicated their existence (ie,
I'd say "yea, an exit connection exists on this circuit but we won't
tell you where it goes."). This would be useful, for instance, if the
relay operator has misconfigured their firewall to block some of the
outbound ports permitted by their exit policy (arm would show this as
RELAY -> YOU -> UNESTABLISHED, and provide a warning to indicate the
issue).
- Bandwidth
For auditing the most interesting attribute of connections, imho, is
the bandwidth. If, says 10 KB/s is coming in and 1 MB/s is going out
on a circuit that's a good indicator that something is *very* wrong
(I'd start suspecting a security issue, personally). If we rounded all
bandwidth measurements (say, to the nearest KB) would this be
sufficient to prevent entry/exits from correlating this data to attack
anonymity?
- Uptime
If connections are being cycled abnormally quickly (say, all
connection longevity is under thirty seconds) this could indicate the
ISP (or other middlemen like the great firewall) are sending reset
packets to kill the relay's attempts to make exit connections.
I'd be willing to backpedal from requesting this information if others
think it's dangerous. However, unlike addresses / ports I think this
is useful information so I'd rather not see it stripped without
reason. Cheers! -Damian
PS. Is the BUFF field useful to anyone? I don't care about it, but
thought it might be useful for indicating some issues.
-------------------------------------------------------------------------------
"conn/<Circuit identity>/<Connection identity>" -- Provides entry for the
associated connection, formatted as:
CONN_ID CIRC_ID OR_ID IP PORT L_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 except in the case
of exit connections.
OR_ID - Relay fingerprint, 0 if connection doesn't belong to a relay.
IP/PORT - IP address and port used by the associated connection, 0 if
connection is used for relaying client or exit traffic.
L_PORT - Local port used by the connection, 0 if connection is used for
relaying client or exit traffic.
TYPE_FLAGS - Single character flags indicating directionality and type
of the connection (consists of one from each category, may become
longer for future expansion).
Connection Directionality:
I: inbound, i: listening (unestablished inbound),
O: outbound, o: unestablished outbound
Usage Type:
C: client traffic, R: relaying traffic,
X: control, H: hidden service, D: directory
Destination:
T: inter-tor connection, t: outside the tor network
For instance, "IRt" would indicate that this was an established
1st-hop (or bridged) relay connection.
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.
On Wed, Mar 3, 2010 at 6:52 PM, Sebastian Hahn <hahn.seb@xxxxxx> wrote:
>
> Hey,
>
> my comments inline below.
>
> On Jan 24, 2010, at 1:58 AM, Damian Johnson wrote:
>>
>> Hi all. This proposal doesn't seem to be going anywhere so thought I should give it one last nudge before moving on to more worthwhile work. The issue's sticking point seems to be a difference of opinion about what constitutes relay evilness. Nick, Jake, and Sebastian all believe in a hard line stance against any retrieval of connection information (netstat, lsof, etc). I disagree, and think this is harmless unless stored or communicated. Unless this can be resolved I think it's obvious the proposal isn't going anywhere.
>>
>> Please note that I'm discussing relay to relay connections at the moment. If we can't even agree on that then client and exit connections are a moot point (and besides, I agree they should definitely be hidden from relay operators - personally I think it's the responsibility of client applications like vidalia and arm to scrub this data, but that's a different discussion...).
>
> This seems to change the original intent of the proposal, which was (afaiui) to get a listing of all connections from Tor. I wouldn't mind doing that at all. It does, however, depend on the implementation of proposal 163 (detecting clients), because otherwise Tor itself cannot reliably differentiate in all cases.
>
>> Just to be clear I agree this proposal should be killed if it poses a threat to Tor users. However, I don't believe it does and still have yet to hear an example of any sort of threat it aggravates. Without that I'm a bit puzzled at the source of objections. If the chief issue is legal or not wanting to risk the appearance of supporting snooping that's fine (strikes me as political posing if there's no actual benefits to users, but cest la vi).
>
> If you change it to be explicit about the fact that you do not want to show exit/guard connections, I think this would be ok. It needs to be actually spelt out, though.
>
>> My bias is toward safety for relay operators and I'm glad to see others biased toward user privacy pushing back. Hopefully we'll be able to find something acceptable to all parties concerned but if not it won't be the end of the world. Cheers! -Damian
>
> Just to see if others are interested in moving this along, or if everyone wants to kill it.
>
> Sebastian