On 05 Apr (12:59:36), Tim Wilson-Brown - teor wrote:
On 5 Apr 2016, at 02:54, David Goulet dgoulet@ev0ke.net wrote: So, this basically gives a space of 12 hours between the SRV generation and the start of the next time period. We can then easily fit an overlap period of 6 hours before the next time periods starts.
You've implicitly adjusted hsdir-overlap-begins to 75 here. I think that's ok, but it does need to be modified in the spec.
Hidden Service behavior:
Example 1: Our hidden service boots up at 14:00 of TP#1. In this case, we are nowhere close to the overlap period, so the hidden service should just publish its TP#1 descriptor to the HSDir hash ring using SRV#1 (which at that point should be in consensuses as "shared-rand-current-value").
The hidden service might also want to calculate its overlap OFFSET (as specified in [TIME-OVERLAP]) and schedule a time callback for publishing its TP#2 descriptors.
Example 2: Our hidden service boots up at 03:00 of TP#1. That's outside of the overlap period again, but this time the hidden service needs to use the SRV from "shared-rand-previous-value" because the SRV was rotated at midnight.
Example 3: Our hidden service boots up at 09:00 of TP#1. That's inside the overlap period, so the hidden service should calculate its overlap OFFSET and compare it with the current time.
If it has not passed, then we are in the exact same case as Example 2.
If the overlap OFFSET _has_ passed, then the hidden service needs to act as Example 2, and _also_ publish its TP#2 descriptors to a second set of HSDirs using SRV#2.
I think these are all the cases for the hidden service, but I would like to formalize this in a way that can be written in the spec. Particularly, I'm not sure how to formalize which SRV to pick at a given time point.
It sounds simple as:
"If we are before to the overlap period, use the time period shared random value (TP1 == SRV1). If we are in the overlap period, upload two descriptors using _both_ SRVs."
Plausible?
Almost: it needs to say "overlap offset for the next blinded key" (the overlap varies based on the specific key).
Client behavior
My current intuition with regards to client behavior is that they should always fetch descriptors from the HSDirs of the _current_ time period. They should not concern themselves with the overlap stuff _at all_. The overlap system is there so that by the time the new time period starts, all the HSDirs have received the descriptors and are ready to help the clients. Clients should never notice the overlap stuff happening.
100% agreed.
Clock skew though might bring reachability issue where the client tries descriptor #1 but it's been an hour that the #2 is suppose to be used (TP2). But, we can probably solve that by having the HS keep its IPs open for the descriptor #1 for a period of X hours to accomodate those confused clients.
(I bet X could be between 4 to 6 hours at best. Altough, I have no clue how much a client can function with that big of a skew.)
Anyway, the point is that it's not the cliet job to adjust imo.
Clients can use a consensus and HS descriptors that are 24 hours out of date: NETWORKSTATUS_ALLOW_SKEW
This doesn't seem to be used anywhere.
REND_CACHE_MAX_SKEW
This is imo way to big. https://trac.torproject.org/projects/tor/ticket/13207
We should take the opportunity of 224 implementation to come up with something that make sense imo. Could be 24h but I doubt it right now.
So our skew should be at least that much.
For this reason I think we can remove this paragraph from the spec:
When a client is looking for a service, it must calculate its key both for the current and for the subsequent period, to decide whether the next period's key is valid yet.What do you think?
Rip it off :).
It seems like an extra complication. I can't see how it helps clients to have 12 HSDirs to choose from for some random time between 0 and 6 hours each period.
(If we decide it does later, we can add the feature in a client update. We just need to make sure that HSDirs will answer queries for descriptors that aren't valid yet, which makes sense to do for client skew anyway.)
HSDir behavior
Currently the spec says the following:
Hidden service directories should accept descriptors at least [TODO: how much?] minutes before they would become valid, and retain them for at least [TODO: how much?] minutes after the end of the period.
After discussion with David, we thought of chopping off the first part of that paragraph and not imposing any such weak restrictions for accepting descriptors (see #18332).
We still have not decided about the second part of that paragraph, that is how long descriptors should be retained after the end of the period. We currently think clock skew is the only thing that can bring clients to the wrong HSDir after the end of the period. Maybe an hour is OK? David suggested 12 hours. The current Tor is doing 48 hours... Any ideas?
It should at least be 24 hours (maximum possible) with an adjustment of at the _very_ least the overlap period. If the overlap period is 6 hours, we can then add the "maximum clock skew" we think is reasonable and we would end up with an OK value imo.
Descriptor maximum lifetime: 24 hours Overlap period span: 6 hours (taken from your diagram) Maximum acceptable clock skew: 6 hours (dgoulet opinion!)
Thus we are talking of a 36 hours lifetime in the cache. Let's work with that as a baseline :).
Let's make it 24 + 24 + 6 = 54 hours instead, based on the 24 hour skew allowed for current clients. (See above.)
I'm still doubtful :).
David
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev