Re: Proposal: GETINFO controller option for connection information

On Fri, Jul 9, 2010 at 6:38 PM, Nick Mathewson <nickm@xxxxxxxxxxxxx> wrote:

On Tue, Jun 29, 2010 at 11:00 AM, Damian Johnson <atagar1@xxxxxxxxx> wrote:
>> Hm. But we don't necessarily know this. Our "are we client-facing"
>> tests are approximate, not certain, and the only way to tell whether
>> we're intermediate or exiting is to wait and see if we're told to
>> exit.
>
> Understood that client facing tests fail by design when dealing with
> bridges. In the case of the outbound connection component it sounds like
> we'll need to wait until we're either asked to extend the circuit or exit
> before counting it as an 'established circuit' and reporting it.

Or we could drop the false notion that "middle" or "exit" or "entry"
make a partition of established relay or_circuits. (They aren't a
partition because: first, they don't cover or_circuits. A circuit
that has been just extended to us can't be called a middle or an exit.
Second, they aren't exclusive: a circuit that has been extended from
us and used as an exit can be called both a middle _and_ an exit.)
See below for another possibility.

>> In fact, the leaky-pipe topology means that we're potentially
>> intermediate _and_ exiting on a single circuit.
>
> (to save other readers the googling, this means that clients can exit the
> circuit prematurely, such as at a middle node if the exit policy permits it)
>
> You're right, that would mess with the classification. If/when this is
> implemented I'd suggest adding anther classification for middle hops when
> they're first used to exit traffic.

It *IS* implemented server-side. The clients just don't use it.

(Since the point of this design is to safely expose accurate circuit
status info via the control port, we might as well try to expose the
possible states of current circuits, including states that don't
typically occur. Otherwise, if some future weird client started using
them, you'd need to upgrade Tor *and* arm to get an accurate report.)

> The goal of these type flags are to indicate to controllers which circuits
> are sensitive and which are less so. In arm for instance most information
> for client/exit connections are scrubbed. Indicating via a change of the
> circuits status (an UPDATE event) when this begins exiting traffic seems
> good enough to me.

Here's an alternate proposal. The idea of type flags is good, but
instead of the ones in your proposal, let's only use circuit type
flags that have an unambiguous meaning from the point of view of Tor's
spec and implementation.

For instance,
(E)ntry : a connection from a node that doesn't appear to be a Tor server.
E(X)it : has been used for at least one exit stream
(R)elay : has been extended.
Rende(Z)vous : is being used for a rendezvous point
(I)ntroduction : is being used for a hidden service introduction
(N)one of the above: none of the above have happened yet.

These all have nice, clear-cut, easy-to-evaluate meanings, some of
which are mutually exclusive, and some of which aren't.

[...]

>> It sounds like it should be a torrc option saying "Don't stop
>> refetching descriptors when there's no network activity." Actually,
>> do we have one of those already?
>
> Yup, we have FetchUselessDescriptors. However, setting this causes an extra
> load on the directory authorities, hence the desire to be able to do this a
> bit more selectively (for instance just fetching our own descriptor every
> hour but letting the rest go stale).

But fetching our own descriptor is kind of needless; we generated it
ourself, after all. Is it not accessible via the control port? We do
*have* it; it's a static variable in router.c. What am I missing?

yrs,
--
Nick