[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #25552 [Core Tor/Tor]: prop224: Onion service rev counters are useless and actually harmful for scalability
#25552: prop224: Onion service rev counters are useless and actually harmful for
scalability
-----------------------------------------------+---------------------------
Reporter: asn | Owner: dgoulet
Type: defect | Status: assigned
Priority: Medium | Milestone: Tor:
| 0.3.4.x-final
Component: Core Tor/Tor | Version: Tor:
| 0.3.1.9
Severity: Normal | Resolution:
Keywords: tor-hs prop224 034-roadmap-master | Actual Points:
Parent ID: | Points: 4
Reviewer: | Sponsor:
-----------------------------------------------+---------------------------
Comment (by dgoulet):
Replying to [comment:7 teor]:
> > So as long as we get the new functionality into HSDirs before the next
long-term-stable, the "far future" will just be a matter of waiting some
months for intermediate stable versions to die out.
>
> But hang on, do clients require descriptors to have revision counters?
So here is the fun part of this. Client do look at the revision counter
when caching but only to decide if they have a newer one in their cache or
not. Thus, a revision counter always to 0 for instance wouldn't affect the
client cache.
As for HSDir, they won't accept a descriptor with a revision counter that
is lower or equal with the one they have in their cache. Meaning that 034+
services will still need to put the revision counter in their descriptor
for a while until <= 032 is phased out. Not putting the revision counter
in the descriptor for specific HSDir is not trivial amount of engineering
work.
Now, this is where it gets messy. When decoding the plaintext part of a
descriptor (where the rev. counter is), we hard require the counter to be
in it (notice the `EQ(1)`):
{{{
T1(str_rev_counter, R3_REVISION_COUNTER, EQ(1), NO_OBJ),
}}}
Thus, as long as we have 032 and 033 HSDirs and clients on the network, we
can't remove the counter from the descriptor else they won't be able to
store/access 034+ services as every descriptor will fail to be decoded.
Thus to summarize, the only thing we can do for now is make HSDir use a
replaycache instead of revision counter, make client ignore revision
counter and make the revision counter optional in the descriptor when
decoding it.
But we MUST make the service put the rev counter regardless, with the
current mechanism, in the descriptor for a while else it will break client
and HSDir <= 033.
Or a more nuclear option, we bump the descriptor version to 4 which won't
have the revision counter which will effectively make 034+ the birth of
the onion service v4 :P...... not ideal ;).
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25552#comment:16>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs