Opened 4 years ago
Last modified 2 years ago
#16966 needs_information enhancement
Better solution for an HS client descriptor cache entry to expire
Reported by: | dgoulet | Owned by: | |
---|---|---|---|
Priority: | Medium | Milestone: | Tor: unspecified |
Component: | Core Tor/Tor | Version: | |
Severity: | Normal | Keywords: | tor-hs, timing, needs-design |
Cc: | stephan | Actual Points: | |
Parent ID: | Points: | 2 | |
Reviewer: | Sponsor: | SponsorR-can |
Description
With #16389, we've added a 5 minutes timeout for an entry in the client descriptor cache to expire which is not ideal (details here https://trac.torproject.org/projects/tor/ticket/16389#comment:16).
One solution would be to add a counter in the hidden service descriptor that changes at with a new descriptor. To quote arma's in comment above:
Maybe this argues for hidden services putting the nonce into their HS descs anyway, and publishing an updated HS desc every time they lose contact with their intro points, to give clients a way to recognize when the HS has acknowledged that things changed? Yuck.
Child Tickets
Change History (12)
comment:1 Changed 4 years ago by
Keywords: | SponsorR removed |
---|---|
Sponsor: | → SponsorR |
comment:2 Changed 4 years ago by
Points: | → medium |
---|
comment:3 Changed 4 years ago by
Milestone: | Tor: 0.2.8.x-final → Tor: 0.2.9.x-final |
---|
It is impossible that we will fix all 226 currently open 028 tickets before 028 releases. Time to move some out. This is my second pass through the "new" and tickets, looking for things to move to 0.2.9.
comment:4 follow-up: 6 Changed 4 years ago by
Milestone: | Tor: 0.2.9.x-final → Tor: 0.2.??? |
---|---|
Severity: | → Normal |
Sponsor: | SponsorR → None |
Status: | new → needs_information |
Data point. Proposal 224 has a revision-counter in the descriptor so it fixes the expiring time issue.
Now, is adding that mechanism for the current protocol worth the work considering the current next generation effort?
comment:5 Changed 4 years ago by
Sponsor: | None |
---|
Change Core Tor tickets with sponsor "None" to "", per our practice elsewhere. This will help sorting.
comment:6 Changed 3 years ago by
Actual Points: | → 2 |
---|
Replying to dgoulet:
Data point. Proposal 224 has a revision-counter in the descriptor so it fixes the expiring time issue.
So the idea here is that when a client has no usable intro points from an HS descriptor, it refetches a descriptor, and if the received descriptor has a new revision-counter the client marks all intro points as retriable?
Or simpler, everytime a client accepts a new HS descriptor, all enlisted intro points are marked as retriable regardless of their failure cache state?
Now, is adding that mechanism for the current protocol worth the work considering the current next generation effort?
Hmm, I would go with "No, except if someone provides a nice patch". Let's save this mobile performance improvement for next gen hidden services :)
comment:7 Changed 3 years ago by
Actual Points: | 2 |
---|---|
Points: | medium → 2 |
comment:8 Changed 3 years ago by
Cc: | stephan added |
---|
comment:10 Changed 3 years ago by
Keywords: | tor-03-unspecified-201612 added |
---|---|
Milestone: | Tor: 0.3.??? → Tor: unspecified |
Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.
comment:11 Changed 3 years ago by
Keywords: | tor-03-unspecified-201612 removed |
---|
Remove an old triaging keyword.
comment:12 Changed 2 years ago by
Keywords: | timing needs-design added |
---|---|
Sponsor: | → SponsorR-can |
Bulk-replace SponsorR keyword with SponsorR sponsor field in Tor component.