[tor-bugs] #13207 [Tor]: Is rend_cache_clean_v2_descs_as_dir cutoff crazy high?

[Tor Bug Tracker & Wiki]

#13207: Is rend_cache_clean_v2_descs_as_dir cutoff crazy high?
------------------------+------------------------------------------------
     Reporter:  arma    |      Owner:
         Type:  defect  |     Status:  new
     Priority:  major   |  Milestone:  Tor: 0.2.7.x-final
    Component:  Tor     |    Version:  Tor: 0.2.7
   Resolution:          |   Keywords:  SponsorR, tor-hs, 027-triaged-1-in
Actual Points:          |  Parent ID:  #13209
       Points:  medium  |
------------------------+------------------------------------------------
Changes (by sysrqb):

 * status:  needs_revision => new


Comment:

 Replying to [comment:10 sysrqb]:
 > Please review branch bug13207.

 Ok, that was indeed the wrong approach. It decided that we should assume
 the current descriptor is valid until the end of the current period (based
 on the local clock) plus 24 hours, accounting for clock skew. That really
 is a bad idea.

 New approach: HSDirs should hold descriptors which have a publication time
 of less than 25 hours ago. We shouldn't care if the HSDir thinks it's
 responsible for the descriptor ID because this overrides the the logic for
 keeping descriptors for clients with skewed clocks.

 If we set the cutoff at 25 hours then:
   - If a client's clock is 24 hours behind the service's clock, and the
 HSDir is in between them, then the HSDir should serve the descriptor (if
 it was given one in the past) despite the service publishing new
 descriptors on a new HSDir
     - Unfortunately, the intro points may be invalid
   - If the client's clock is 24 hours ahead of the service's clock, and
 the HSDir's clock where the client sends its query is in between, then the
 HSDir won't have the descriptor. The HSDir where the service publishes its
 descriptor should happily serve it, if anyone asks for it.
     - The service is still publishing its descriptors on the previous
 period's HSDirs
       - Should clients ask HSDirs from the previous period for a
 descriptor? At face value, this seems like a bad idea
   - If the client's clock is 24 hours behind the HSDir's clock, and the
 service is in between them, then the HSDir should serve the descriptor and
 it should still be valid. At some point the service will enter the next
 period and publish new descriptors there, but its old descriptor should
 remain for some time.
     - As above, this may make clients sad when the service changes its
 intro points or goes offline
   - If the client's clock is 24 hours ahead of the HSDir's clock, and the
 service is in between them, then the client will query the current HSDir
 until it enters the next period. There's an amount of time where the
 client queries the next set of HSDirs while the service is publishing to
 the current set.
   - If the HSDir's clock is 24 hours behind the service's clock, and the
 client is in between them, then the HSDir should have a descriptor which
 was published approximately 23 hours earlier (before the service moved to
 the next period)
   - If the HSDir's clock is 24 hours ahead of the service's clock, and the
 client is in between them, then the HSDir will serve the descriptor for 1
 hour before it considered the descriptor expired.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/13207#comment:11>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online