[tor-dev] Revisiting prop224 overlap descriptor logic and descriptor lifetimes
desnacked at riseup.net
Wed Jun 15 10:48:44 UTC 2016
David Goulet <dgoulet at ev0ke.net> writes:
> [ text/plain ]
> On 13 Jun (15:48:39), George Kadianakis wrote:
>> Hello people,
>> I invite you to check out another round of time period-related prop224 spec
>> changes, based on our discussions in Montreal. These new changes simplify the
>> overlap descriptor publishing logic, and improve the caching lifetime of
>> descriptors in HSDirs.
>> You can find them in my branch `prop224-montreal-timeperiods` or here:
> Couple of things.
> Section 2.2.2., about this TODO:
> [TODO: Control republish period using a consensus parameter?]
> Right now, we have RendPostPeriod for such a thing and some random added to
> it. As we discussed, a service changing that value will make it different from
> all others and thus more noticeable. But, we cleared out some uses cases where
> it could be useful such as a service load balancing and republishing a new
> descriptor often to change its intro points or keys.
I think HSes rotating intro points or keys should publish a new descriptor
regardless of the value of RendPostPeriod. This is not mentioned in prop224 tbh
(maybe it should), but this is also what little-t-tor does currently (it marks
the descriptor as dirty when rotating intro points).
> Making this a consensus params is a good idea imo but we should also provide
> an option to override it. Maybe it could make sense to _only_ have the option
> to change it if you are a NonAnonymous service for instance?
> Section 18.104.22.168:
> [TODO: What to do when we run multiple hidden services in a single host?]
> This could be quite "obvious" at the Guard. Building at least 12 short live
> circuits is a give away here that I'm running HSes. Apart from adding some
> random offset for each HS (which even then...), I'm not sure how to address
> this. Even now, we just upload all decriptors at the same RendPostPeriod.
> Maybe it's not too big of a problem?
Indeed, I'm also unsure on how to handle this properly.
> Section 2.2.5:
> "Hidden services MUST also keep their introduction circuits alive..."
> Does that mean service keeps them open (and the keys) until the descriptor
> expires on the HSDir? That is a service uploads a desc at 23:00 but then at
> 00:00 it creates a new descriptor using the new SRV so it should keep the
> intro points open until 02:00 (23:00 + 3 hours lifetime)?
Yes, that's what I mean. I will try to add an example to the proposal to make
it more clear.
More information about the tor-dev