fjl
commented
5 years ago Here's an idea for fixing this problem:
Drop the notion that getting a ticket means you're guaranteed to get registered, i.e. unify the semantics of REGTOPIC and REQTICKET. So you'd try to register, and get denied with a ticket for later. When you come back with the ticket, you can be registered or get another ticket depending only on how old the last entry in the queue is. Ticket hoarding still works with this countermeasure in place, but attackers wouldn't be able to take over the queue because the target lifetime is enforced when registering.
This approach is nice because it allows us to incorporate arbitrary other factors into the waiting time. Example: we may want to require registrants to re-validate tickets often (like every 10s) to ensure registrant nodes are live throughout the entire waiting time.
There is a really simple attack on the topic queue logic the way it is defined right now: The wait period formula is supposed to keep ads in the queue for certain amount of time. Since the new wait period depends only on the time of the last successful registration, an attacker controlling many nodes may request lots of tickets (up to the queue limit) on the same queue concurrently. Those tickets will expire around the same time and can be used to replace all queue content. When this happens, the wait period will jump up to a very high value, i.e. not only will the queue be full with attacker-controlled nodes, the nodes will also stay in the queue for a long time.