On 05 Apr (12:59:36), Tim Wilson-Brown - teor wrote: > > > 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 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@xxxxxxxxxxxxxxxxxxxx > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev