On 01/12/17 12:16, teor wrote: > >> On 1 Dec 2017, at 21:56, Michael Rogers <michael@xxxxxxxxxxxxxxxx> 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
Attachment:
0x9FC527CC.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev