On 12 Apr (16:01:32), George Kadianakis wrote: > David Goulet <dgoulet@xxxxxxxxx> writes: > > > [ text/plain ] > > On 11 Apr (14:42:02), George Kadianakis wrote: > >> David Goulet <dgoulet@xxxxxxxxx> writes: > >> > >> > [ text/plain ] > >> > On 04 Apr (19:13:39), George Kadianakis wrote: > >> >> Hello, > >> >> > >> >> during March we discussed the cell formats of prop224: > >> >> https://lists.torproject.org/pipermail/tor-dev/2016-March/010534.html > >> >> > >> >> The prop224 topic for this month has to do with the way descriptors get > >> >> uploaded and downloaded, how this is scheduled using time periods and how the > >> >> shared randomness subsystem interacts with all that. > >> >> > >> >> Here are some discussion topics. Lots of text on the first two, less text on the rest: > >> >> > >> >> <snip> > >> >> > >> >> In any case, this is how this might look like: > >> >> > >> >> > >> >> +------------------------------------------------------------------+ > >> >> | | > >> >> | 00:00 12:00 00:00 12:00 00:00 12:00 | > >> >> | SRV#1 TP#1 SRV#2 TP#2 SRV#3 TP#3 | > >> >> | | > >> >> | $ |-----------$-----======|-----------$-----======| | > >> >> | overlap12 overlap23 | > >> >> | | > >> >> +------------------------------------------------------------------+ > >> >> > >> >> Legend: [TP#1 = Time Period #1] > >> >> [SRV#1 = Shared Random Value #1] > >> >> > >> >> <snip> > >> >> > > > > The logic I sketched out above makes it that we would need parameters (from > > the consensus) like so (or hardcode them): > > > > - TIME_PERIOD_ROTATION_TIME (currently 12:00) > > > > [Second email with some more thoughts] > > BTW, currently in prop224 the TIME_PERIOD_ROTATION_TIME is at 00:00 because of > the following paragraph: > > Time periods start with the Unix epoch (Jan 1, 1970), and are > computed by taking the number of whole minutes since the epoch and > dividing by the time period. So if the current time is 2013-11-12 > 13:44:32 UTC, making the seconds since the epoch 1384281872, the > number of minutes since the epoch is 23071364. If the current time > period length is 1500 (the default), then the current time period > number is 15380. It began 15380*1500*60 seconds after the epoch at > 2013-11-11 20:00:00 UTC, and will end at (15380+1)*1500*60 seconds > after the epoch at 2013-11-12 21:00:00 UTC. > > I wonder what's the best way to change this to start at 12:00. > > We could in theory compute the "number of whole minutes since the epoch plus 12 > hours" and use that in the division, but that would be a bit ugly... Is there a > more elegant thing to do? > > We could also in theory change the shared random value generation to happen at > 12:00, and then have TIME_PERIOD_ROTATION_TIME naturally start at 00:00, but > this requires changing prop250. Could it be worth it? :/ I think it's fine we keep the start time at 12:00 here. It's just an offset from the start of the epoch. Furthermore, adding a "rotation time" makes it that we we can control where everything started which doesn't have to be the epoch time at 00:00. We can find the start of the TP with those two (rotation time and lifetime) and then divide that time value by the lifetime to get the nth time period. Also, controling the rotation time is good to have for chutney testing with much more smaller timings. > > >> > >> >> <snip> > >> >> > >> >> + 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 :). > >> > > >> > >> Hm, I see you are calculating the total lifetime here. How often do hidden > >> services refresh (reupload) their descriptor in this case? I think in the > >> current system, hidden services do so every hour. Do we keep this feature? > > > > I think we can re-upload only when needed that is key rotation, IP rotation, > > etc... No need to do that every hour (maybe). > > > >> > >> Let's consider a hidden service that uploads a single descriptor during its > >> overlap period and then disappears completely: should the HSDir keep and serve > >> that descriptor for 36 hours? It's unlikely that the HS is still up and > >> maintaining its intro circuits if it can't keep on refreshing its descriptor. > > > > The issue here is for the HSDir to notice that the HS might be gone? And we > > can't rely on RendPostPeriod value since it's service side. So an operator > > could litterally have set that to 7 hours meaning we might not see any new > > revision counter for that period and still unable to tell if the HS is gone or > > not. > > > > This is why our best bet is to compute a "maximum crazy time" that descriptor > > could be valid. > > > > An other option is to add a valid-until field in the cleartext part of the > > descriptor and the HSDir could use that to expire entries plus a clock skew > > delta. > > > > So if HSDirs always keep descriptors for 36 hours, what happens if an HS > rotates its intro points and publishes a new descriptor just an hour before the > time period changes? Then the HSDir needs to keep and serve that descriptor for > 36 hours, even if it will expire in an hour? Is this OK? Yup basically. That's a bit of a downside of what we have right now also. Uploading at the last hour with new content makes it that we'll expire the descriptor in 48h... > > Could this be another point for doing the valid-until thing? We should think of what does that leak to the network? It would leak the HS clock time (well partially, we can always add some random to it). I don't think it would leak *when* the HS might probably create new IP connections since the overlap period makes it that when that valid-until time is reached, new IPs have been established for a while already. However, it would leak the teardown of the old ones. For a guard, that is useful information to know _when_ an HS will do certain specific network actions. (here killing 3 circuits). > > Currently the proposal says: > > Hidden service directories should accept descriptors [...] and retain them > for at least [TODO: how much?] minutes after the end of the period. > > but that means that HSDirs need to keep track of when the period ends, and > whether a descriptor was uploaded for the current time period or for the > overlay period... I think this will make things much more complicated. IMO, the HSDir should _only_ rely on the revision counter and an expiry time and not trying to try and guess the lifetime of a descriptor from the service perspective. However, here is an idea. Considering teor's argument about HS fingerprinting, we should make the upload happen regurlarly so having RendPostPeriod customizable by an operator is probably a bad idea. We kind of need that _all_ HS expect to behave the same in normal circumstances with their HS desc uploads. Thus, if the RendPostPeriod would become hardcoded (or consensus params), the HSDir would know that the HS is "gone" or have rotated HSDirs after let's say 4 * RendPostPeriod (4 here is abritrary) of not seeing a new revision counter. This makes a cache entry lifetime much smaller! In the end, I see either we use an expiry time that is the _maximum_ lifetime a descriptor can have or an expiry time that is based on the expected maximum time frame we should have received a new revision counter. The latter is fun because we don't need to consider client clock skew since if we happen to purge the descriptor from the cache it's because we think the service is gone or has rotated HSDir thus any client coming our way would fail in the first place to connect to the service by getting the descriptor that should have been updated X hours ago. > > >> > >> Also consider that whatever "maximum acceptable clock skew" we choose, the > >> hidden service needs to keep its introduction circuits up for that time as > >> well, otherwise the descriptor will be useless to the clock skewed clients. > > > > Yup! This is why I think above 6 hours of clock skewed you won't do much as a > > client... maybe even less! > > > >> > >> --- > >> > >> FWIW, I'm personally not sure how to choose the best "maximum acceptable clock skew" > >> value here. My intuition tells me to choose a big number so that even very > >> skewed clients can visit hidden services. I see the following two negatives here: > >> > >> - Hidden services need to retain their old intro circuits for the duration of > >> the acceptable clock skew. > > > > I pretty sure we don't do that currently. However, we could start doing that > > and collect stats on how frequent it is and with how much skew! That would be > > a very useful information to have imo. > > > > Could this somehow cause #16702? Probably not... Hrm... I think it's more an issue of a race between changing IPs and inflight client rather than a client being confused about the time to arrive to the party. But who knows! Cheers! David
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev