[tor-dev] Revisiting prop224 time periods and HS descriptor upload/downloads
Tim Wilson-Brown - teor
teor2345 at gmail.com
Tue Apr 5 02:59:36 UTC 2016
> On 5 Apr 2016, at 02:54, David Goulet <dgoulet at 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."
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:
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.)
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the tor-dev