Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

discv5: ticket hoarding attack #111

Closed
fjl opened this issue Aug 19, 2019 · 1 comment · Fixed by #120
Closed

discv5: ticket hoarding attack #111

fjl opened this issue Aug 19, 2019 · 1 comment · Fixed by #120

Comments

@fjl
Copy link
Collaborator

fjl commented Aug 19, 2019

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.

@fjl
Copy link
Collaborator Author

fjl commented Aug 19, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant