[tor-dev] Revisiting prop224 time periods and HS descriptor upload/downloads

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

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

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160405/9a0b2f46/attachment.sig>