Close group all look over the same data (raid 1-ish across group drives)
Close group is all connected to each other - knowing every member ip.
If that’s true the attack would be as follows:
Use my small/medium botnet to low-key ddos my group. Not enough to knock them off, just delay their response time so that I’m first to respond to requests for chunks and claim my farm attempt. Repeat for as many nodes I have / groups I’m in.
EDIT: Adding this to the top post because I think it’s even more important than my initial scheme.
just take out all the nodes in the section with a large botnet.
Take out some of the elders so that a bad actor node has a better chance of being promoted to elder status.
which brings up another possible attack. My original idea was to maximize safecoin generation. However, this brings up the idea of getting elders kicked out so you get promoted faster. Bit more of a long con, however, if over time you can greatly increase the chance of getting your nodes promoted to elders. A way worse situation than someone getting more safecoin than they deserve.
Nice… That’s a tricky one. Good catch! Only thing I can think of is one hop relays between group members to mask IP’s. I hope this isn’t a large wrench!
What sort of DDoS are you thinking of? If the clients are behind NATs, presumably you would only be able to reach them via Crust. Afaik, this would mean the botnet trying to establish a new connection via Crust, which would presumably be refused unless it appeared to be in-band traffic.
It sounds like it could give advantage to a malicious node in theory, but I’d say the devil would be in the detail.
Oh well I guess this just raises the bar for participation. The network just prunes the affected machines. Problem solved. Unless such openings are very common. Any statistics available?
I don’t think this is correct. IIUC The routing layer through xor protects this info. The close group knows the xor address of it’s neighbors but not ip addresses. I don’t claim to be an expert on the details though. @neo@mav ?
Thanks draw. I’ve even read that thread before but forgot about dirvine’s comment. As I said, didn’t claim to be an expert on the details . It seemed natural to assume that xor space protected the IP of vaults too. That thread is about 4 years old, so a lot of things may have changed with regard to crust and parsec.
That’s 15 june 2018, not june 2015… And no, that hasn’t changed. For one thing the reason that vaults are in the same section is that their Xor addresses are already the closest. At some point you have to switch to IP (or something else in the future).
My mistake. Wow, 0/2 this morning. Serves me right for running on no coffee.
I still think there might be a level of indirection between managers and storage vaults that is not being considered in the OP’s scenario @draw. I’ll dig around for some figures I’ve seen on GitHub, or maybe you already have the info on hand to set me straight on the matter 0/3.
Another question is: is the effort/cost of setting up that kind of DDOS attack less than what you can earn with your better servicing vault? And also: don’t you need your group members to get the requests to service?
We need to understand the impact too. If the botnet is just sending junk which is immediately discarded by the client, it will take an awful lot of junk to have a meaningful impact.
If you can get the client to do something intensive, it could be a viable vector. Otherwise, it would be mostly just flooding to fill client bandwidth, which probably wouldn’t be so fruitful, especially if the client had a large bandwidth capacity.
Considering the client has no reason to respond to IP addresses outside of the network (section and section neighbours only in fact?), I suspect the client would just drop the request packets and move on. Either that or the botnet nodes would need to find am angle to cause the client to justify doing more work.
As @draw/David said, you need the IP addresses to be known otherwise any consensus would take a very long time with all the hops to get from one XOR address to another.
This is important. Also as you said earlier, the attack has to get through the ISP routing and the home router which would normally block unrequested packets.
The other important think to consider is that DDOS attacks are not so much to tie up the server but the links to the server with too much traffic that legit packets are dropped. So the DDOS has to be above a certain size in order to cause any trouble at all, but once it is that size then because of the node’s slowness its going to stop the node from operating as a functioning unit of the section. Thus it is dropped.
So the original premise of doing this to be the fastest will not be effectual since it will cause the section to be disrupted in its functioning.
Of course the botnet has to be much larger since there is easily 20-40 vaults in a section and 7 that can be directly competing with the vault. So its not attacking one address but 7 to 40 addresses depending on how the chunks are distributed across the section.
This is no longer a small botnet but significant.
What are the costs and benefits for this attempt to earn more.
I thought about this after I wrote the post. A smart botnet operator would use the most well connected nodes to run vaults and the rest as zombies to slow down the of the close group. No way to work out the math on ratios because the math isn’t even out yet.
That is correct. However, because there is no need for a response you spoof the IP as another member of the group. Random group member to port mapping. At least some will seem like a proper connections.that must be handled. Everything is encrypted so anything that does make it to the right ip:port combo could help demote other members of the group. Malicious anything.
EDIT: Realized that because it’s encrypted you won’t be able to get actual messages through (can’t sign them) but things would have to attempt to be decrypted, which uses up some cycles.
A smart attacker wouldn’t want to knock the other nodes out, our totally overwhelm them. Just slow their connection down.If they get kicked out, I would have to start over on a new node. As long as I have a greater percentage chance of being the first to respond (assuming the math worked out) that’s enough.
We don’t want to disrupt, just slow down. We’re not talking about disabling the other nodes, just giving them lots of traffic to wade through.
Something we still aren’t able to math out because we don’t have the numbers yet. But something I think should be kept in mind unless someone brings up something that makes this a non-issue that we haven’t thought of yet.
which brings up another possible attack. My original idea was to maximize safecoin generation. However, this brings up the idea of getting elders kicked out so you get promoted faster. Bit more of a long con, however, if over time you can greatly increase the chance of getting your nodes promoted to elders. A way worse situation than someone getting more safecoin than they deserve.
Not necessarily. These attacks usually work by exploiting edge cases, such as half-opening connections which is cheap to do (takes a single packet) but can exhaust the OS’s capability to accept legit ones.
It’s not necessarily expensive to rent out some of a large botnet for a half hour, especially if it needs to be done once but it could achieve a longer term gain (e.g. demoting an elder to gain a better position.)
Agreed - spoofing would definitely prompt some action and as the lost of IPs is known by the perpetrator, they could ensure they tally.
I am not familiar enough with crust to know how a connectivity between 2 nodes is established. If the first action could be to request confirmation from the originator, the spoof would be obvious pretty quickly (as the real node would reject it). Whether that would create more of an overhead than just attempting to decrypt the packet would be interesting to know.
Perhaps if each pair of nodes prefixed a unique tag/sequence in each packet, it would be simple to reject spoofed packets too. Tbh, you could probably just send them plain text for performance (decrypting the packet will confirm/deny anyway). Anything which would hint that a packet was suspicious would be enough to drop it.
I do wonder what the cost/benefit would be still. I can see how you could get nodes to do more work with the above, but would it be worthwhile? Are there better ways for a botnet to make money, such as being farmers themselves?
Spoofing IP is possible, but not as simple as many think. ou do need to route the packets so generally need to be local or at least get local. CRUST uses encrypted connections so to spoof a connection would mean having to steal the private key as well.
TCP already uses sequence numbers to help with this. However it’s not a n+1, there is an acceptable range. My friend in college used to use this to kick the professor off the network by creating packets as the router ip with sequence numbers increasing by whatever number he needed to make sure he’d be in the range at some point.
It was all a bit above my head, but that’s how he explained it to me. And it worked. Maybe that’s patched? But my understanding was it was something in the protocol level.
Would this prevent a message from being received and having to be handled? I know it wouldn’t actually get a response.
Also, that would not mitigate a half-open connection flood to the ip.
. It seemed natural to assume that xor space protected the IP of vaults too. That thread is about 4 years old, so a lot of things may have changed with regard to crust and parsec.
And no, that hasn’t changed. For one thing the reason that vaults are in the same section is that their Xor addresses are already the closest. At some point you have to switch to IP (or something else in the future).