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 nickm

Keywords: SponsorR removed
Sponsor: SponsorR

Bulk-replace SponsorR keyword with SponsorR sponsor field in Tor component.

comment:2 Changed 4 years ago by dgoulet

Points: medium

comment:3 Changed 3 years ago by nickm

Milestone: Tor: 0.2.8.x-finalTor: 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 Changed 3 years ago by dgoulet

Milestone: Tor: 0.2.9.x-finalTor: 0.2.???
Severity: Normal
Sponsor: SponsorRNone
Status: newneeds_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 3 years ago by nickm

Sponsor: None

Change Core Tor tickets with sponsor "None" to "", per our practice elsewhere. This will help sorting.

comment:6 in reply to:  4 Changed 3 years ago by asn

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 asn

Actual Points: 2
Points: medium2

comment:8 Changed 3 years ago by stephan

Cc: stephan added

comment:9 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:10 Changed 2 years ago by nickm

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 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:12 Changed 2 years ago by nickm

Keywords: timing needs-design added
Sponsor: SponsorR-can
Note: See TracTickets for help on using tickets.