Control Spec Addition First Draft
Damian Johnson
atagar1 at gmail.com
Sun Dec 20 22:24:31 UTC 2009
Hi Sebastian, thanks for the feedback!
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.
>
Disagree for the following reasons:
- As mentioned on IRC: all Internet facing applications (browsers, email
clients, tor) are attack vectors for my system. Tor's developers are good,
but I'm not so sure that they're infallible (sorry Nick) and hence the
process can't be blindly trusted - that's why I think transparency is the
best way to go. With hundreds of connections to relatively unknown
destinations tor is already the bane of network based IDS so it would be
nice if we could provide some accounting to system administrators that tor
is behaving as it should. For instance say the tor process claims a big
outbound connection taking 90% of your bandwidth that can't be accounted for
as belonging to a circuit. If you aren't using it as a client that would
be... bad.
- I agree that for correlation attacks this data is of concern in the event
that numerous relays store or share this information. However, for an
individual relay operator having this data shouldn't pose *any* threat to
tor users (if it does... we have an issue). From what I can tell this
proposal doesn't do anything that makes correlation attacks more dangerous
since netstat running in a cron job is all they need (assuming they own a
big chunk of the relays).
- Tor was designed with a certain level of distrust of relays. Beyond that
the best we can do is discourage them from risky behaviour (ie, running
outdated versions, looking at exit traffic, sharing connection data, etc).
By including connection types controllers will have the opportunity to tell
relay operators "Oi! Please don't look at these exit connections unless you
have a damn good reason.". As it stands I don't have a way of telling them
apart, and hence can't even hide them by default.
- As you mentioned we can't (and imho shouldn't) prevent relay operators
from seeing the connections made to/from their own system. This proposal
doesn't seem to exasperate any privacy issues while providing some nice
benefits (performance and some handy bits of extra data that'll make
security anomalies far easier to detect).
This is, I think, a misunderstanding of what a connection is. More below.
>
No, the hidden service question isn't. I'm assuming that when hosting hidden
services there's some connections dedicated to providing that service. If
so, a TYPE_FLAG should probably be included since they don't really belong
to any of the other groups. Changed proposal to include one till someone
tells me this is wrong.
Here, the connection identity needs to either include the CIRC_ID, or this
> is ambigious...
>
Thanks for the catch! Made the following three corrections:
- Changed signature to "conn/<Circuit identity>/<Connection identity>" to
avoid ambiguity. I'm assuming that in general people will use the "conn/all"
to discover the circuit/connection ids (actually, can't think of a use for
getting a single connection - just including it to conform with other
control-spec GETINFO options).
- Noted that more than two connections could have the same circuit ID in the
case of exit connections.
- Including a L_PORT (local port) parameter - wasn't mentioned but
definitely an oversight.
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.
Yea, I wasn't sure if they should be like argument flags (given a default if
excluded) or always explicitly stated. Opted for the later since in general
explicit is better than implicit, and this way implementers (like TorCtl)
won't need to hard code any defaults. Both minor points and glad to discuss
more if people disagree.
Yes, if this was only associated with a connection it wouldn't work, but
circuit/connection combinations should be unique so issue fixed there.
As for the Ee flag I'm suspecting that it would have use for client
connections since any unencrypted traffic there is sniffable. This isn't
important to the use cases I care about so we can drop it if others think
it's a bad idea.
Here's the revised proposal:
-------------------------------------------------------------------------------
"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.
L_PORT - Local port used by the 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, H: hidden
service,
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.
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.
-------------------------------------------------------------------------------
Cheers! -Damian
On Sat, Dec 19, 2009 at 11:43 PM, Sebastian Hahn <hahn.seb at web.de> wrote:
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20091220/a08f1fb8/attachment.htm>
More information about the tor-dev
mailing list