[tor-dev] Proposal 286: Controller APIs for hibernation access on mobile

[Michael Rogers]

On 01/12/17 12:16, teor wrote:
> 
>> On 1 Dec 2017, at 21:56, Michael Rogers <michael at 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?

>> 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.

>>> 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.

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?

> 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.

Cheers,
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x9FC527CC.asc
Type: application/pgp-keys
Size: 4660 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20171205/e1451cc8/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20171205/e1451cc8/attachment.sig>