> On 5 Apr 2016, at 02:54, David Goulet <dgoulet@xxxxxxxxx> 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
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev