On 6 Dec 2017, at 05:12, Michael Rogers michael@briarproject.org wrote:
On 01/12/17 12:16, teor wrote:
On 1 Dec 2017, at 21:56, Michael Rogers michael@briarproject.org wrote:
On 30/11/17 12:55, Nick Mathewson wrote:
When a Tor instance that is running an onion service is IDLE, it does the minimum to try to remain responsive on the onion service: It keeps its introduction points open if it can. Once a day, it fetches new directory information and opens new introduction points.
If a client connects to the service, the service will need to build a circuit to the rendezvous point. Does it fetch up-to-date directory information before doing so?
Interesting question.
It's not required, because the INTRODUCE cell contains all the rendezvous point details. But I think we should be consistent, and fetch a consensus and enough microdescs before performing any client or service activity, just like we do when bootstrapping. Otherwise, we'll end up with weird bugs.
Could/should this be done by reusing the existing bootstrapping process, i.e. by reverting back to an earlier stage in the process and repeating the rest of the process?
Yes, this is what Tor already does when its clock changes or its directory documents expire. We'll just have to make sure we don't break it!
If so, there's a delay that may let the client know the service was idle. Is that a problem?
Mobile clients typically have high latency already. If enough clients do this, it won't be a problem.
If the service needs to fetch a consensus and microdescs before it can respond to a rendezvous cell, the delay could be far longer than the difference in latency between a mobile phone and a laptop. So my point is that the client will be able to tell that the service was woken from idle by the rendezvous cell, which might have implications for the service's anonymity.
For example, it lets the client know that the service isn't running on the same device as another service the client recently connected to, otherwise the device wouldn't have been idle. Maybe that's unavoidable, or not worth avoiding, but I just wanted to flag the issue.
We try to avoid attacks like this. Or, if we can't, we try to minimise their effect.
But when multiple onion services or clients share a tor instance, they also share the state of the consensus, directory documents, and guards.
Our best answer is probably: "don't share a tor instance if you want unlinkable onion services".
Or: "don't IDLE if you want unlinkable onion services". (Also, never lose your network connection.)
3.2. Changing the hibernation state
We add the following new possible values to the SIGNAL controller command: "SLEEP" -- enter the sleep state, after an appropriate shutdown interval.
"IDLE" -- enter the idle state "SLEEPWALK" -- If in sleep or idle, start probing for directory information in the sleep-update or idle-update state respectively. Remain in that state until we've probed for directory information, or until we're told to IDLE or SLEEP again, or (if we're idle) until we get client activity. Has no effect if not in sleep or idle. "WAKEUP" -- If in sleep, sleep-update, idle, idle-update, or shutdown:sleep state, enter the live state. Has no effect in any other state.How does the controller find out when the Tor instance next needs to fetch directory information (or post a hidden service descriptor) so it can send a SLEEPWALK command at the right time? Or should the controller just send the command periodically, maybe once an hour?
I'm trying to work out what the use case is here, and why SLEEPWALK is a good solution,
If the controller sends SLEEPWALK, and Tor has nothing to do, it should immediately return to IDLE or SLEEP.
If the controller puts the Tor instance in IDLE mode, it doesn't need to issue a SLEEPWALK command every hour, because Tor will do the minimum it needs to do to be connected.
Maybe I've misunderstood the proposal, but I thought the intent was that Tor wouldn't fetch anything in IDLE mode, and wouldn't automatically change from IDLE to IDLE_UPDATING - it would need a SLEEPWALK signal to tell it to change to IDLE_UPDATING, and then it would automatically change back to IDLE when it was done.
LIVE fetches directory documents so it always has a live consensus. IDLE fetches directory documents just often enough to stay online. SLEEP fetches nothing.
I'm guessing that although limiting CPU wakeups is outside the scope of this proposal, the SLEEPWALK mechanism is meant to be compatible with some future changes where the device will be allowed to go into a sleep state from which Tor can't wake it, and the controller will use the platform's alarm API to schedule a SLEEPWALK signal to wake Tor so it can perform its periodic tasks.
The more options that Tor provides, and the more unusual things a controller tries to do, the more clients will stick out due to delays. So I don't think SLEEPWALK is a good idea, because it allows every different controller to pick a different update interval.
Rather than the controller picking an interval, would it be better for Tor to specify (maybe in its response to the IDLE signal) when it next needs to be woken?
Or, "the latest time it can be woken to have directory documents with property X", where X is some combination of: * a live consensus * a reasonably live consensus * enough non-expired descriptors to build circuits
So if IDLE doesn't meet your needs, it would help us to know why. If there's enough demand for it, it may be better to add a "WARM" state, where Tor checks for directory documents whenever a consensus expires, and otherwise acts like IDLE.
Within the scope of this proposal that sounds like a good solution. But if we're looking ahead to changes that allow the device to sleep without shutting down Tor or disabling its network connectivity, then the controller will need to be responsible for managing sleeps and wakeups, which fits better with [my guess as to the intent of] the SLEEPWALK mechanism than a WARM state.
We do need a use case here :-)
And yes, I agree that the controller should be able to manage wakeups.
T