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

HIP34: Validator Node Security #223

Closed
jamiew opened this issue Jun 30, 2021 · 8 comments
Closed

HIP34: Validator Node Security #223

jamiew opened this issue Jun 30, 2021 · 8 comments
Labels
closed/withdrawn stale Old and needs attention

Comments

@jamiew
Copy link
Contributor

jamiew commented Jun 30, 2021

Author(s): @Bx64, @cryptomaniac79
Start Date: 2021-06-01
Category: Technical
Initial PR: #211
Tracking Issue: this
Status: In Discussion
Discord channel: #hip-34-validator-node-security on https://discord.gg/helium

Rendered view:

https://github.com/helium/HIP/blob/master/0034-validator-node-security.md

Summary:

As validators will take over all activities regarding consensus on the Helium network, the pool of actors in charge of validating transactions and creating blocks is significantly reduced from the current situation (46K+ hotspots and growing fast) to a small pool of (expected) several hundreds of nodes, which significantly decreases the targets that need to be interfered with in order to impact consensus in one's own favor. Having these nodes IPs (and with that, location and hosting provider information) be publicly visible, traceable and targetable on the Helium network therefore poses a significantly increased security risk compared to the current situation. If the validator nodes are compromised, so is the progress of the chain meaning the chain could completely (and perhaps unrecoverably) stall.

@GP-Colorado
Copy link

I don't want to make the suggestion, but wonder whether, given the relative ease with which a DDoS attack could be used to increase earnings of unaffected validators, thought is being given to postponing the go-live pending mitigation of the vulnerability?

@abhay
Copy link
Contributor

abhay commented Jul 1, 2021

[...] the relative ease with which a DDoS attack [...]

I'm curious about your definition of relative ease? I think this HIP proposes a potential attack that would be easier to perform on the consumer grade ISPs that hotspots live on today.

@GP-Colorado
Copy link

My impression was that, having static ip addresses in hand, an experienced hacker would not have difficulty mounting such an attack. However, as it has literally been decades since I worked in IT network security, and I have never attempted an attack, I should not have used the term "relative ease". Thank you.

@jamiew
Copy link
Contributor Author

jamiew commented Jul 1, 2021

I think this is worth investigating and wargaming some possible solutions, particularly ones that could be rolled out quickly.

I am interested in committing DeWi funds into bounties for this. If there is anyone reading this that has familiarity with dealing with some mentioned attacks – DDoS, DMCA/CP claims, etc – please get in touch

However I don't think this vector is severe enough to merit delaying validator launch, since:

  • Abhay's point that you could also just DDoS current CG more easily
  • the current CG is really struggling and there's network risk in delaying validator launch
  • there are a large number of mainnet validators already committed (700+) – so presumably a large diversity of hosting providers and configurations

@GP-Colorado
Copy link

GP-Colorado commented Jul 1, 2021

I don't disagree. The points that you cite are reasonable. I am just a bit surprised (not doubtful), that, if I am understanding correctly, an attack on a pool of what I imagine is >10K hot spots eligible for election to CG would be easier than an attack on the validators, the count of which is an order of magnitude smaller.

@jamiew
Copy link
Contributor Author

jamiew commented Oct 25, 2021

I love this idea but I'm not sure if it needs to be a HIP. Additionally, discord & github discussion have quieted down. I would love to issue a grant to fund work like this, though, and the grants committee has expressed interest in seeing proposals like this.

@Bx64 @cryptomaniac79 @GP-Colorado any interest in keeping this HIP open or should we move on?

@jamiew jamiew added the stale Old and needs attention label Oct 25, 2021
@Bx64
Copy link
Contributor

Bx64 commented Oct 26, 2021

Hi @jamiew, we have attempted to reach out to developers to get a first prototype going but were unable to get people to work on the erlang p2p codebase. I'm afraid we cannot move forward until we do. We are OK with this being closed, perhaps until someone comes along who feels they can tackle the code side of the HIP.

@jamiew
Copy link
Contributor Author

jamiew commented Feb 8, 2022

Per author comment, closing this one as inactive too. Thank you for your submission!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed/withdrawn stale Old and needs attention
Projects
None yet
Development

No branches or pull requests

4 participants