Security Nodes to protect the network?

Features
1

Although limited on the Alpha network and in the last several testnets, a normal PC is normally able to start and run between 20 and 50 Vaults without causing any trouble when it comes to CPU usage. Is this desired? No, not really. Running a Vault in a group of Vaults (close nodes) comes with quite some responsibility. A Vault needs to sign messages and route chunks up to 1MB max. in size. This means running several Vaults could add up quite fast in bandwidth terms choking the connection and making the Vaults less reliable and the network overall slower.

There is a but… in this story. It isn’t desired to run several Vaults that slow down the network but what if we could run the most simple nodes without ever routing a chunk? Signing messages and verifying data isn’t really big on bandwidth. It’s actually so low that running several Vaults isn’t a problem as long as they don’t route chunks. But is it wishful?

Every P2P-network has it’s weakness. And most P2P-networks where attacked over the last 15 years. Think of transaction spamming on Bitcoin or 51% attacks on the smaller coins. Could SAFE be attacked? You bet. No matter how good the code is, even SAFE has it’s weak spot. When the network is below 10.000 nodes it’s quite easy for any organisation to start a whole bunch of “low bandwidth” nodes on cloud services in a try to slow the network down or to get it out of balance. If we have 10.000 or maybe 20.000 nice people running a Vault at home we’re still vulnerable. Is there something we can do about it? I think the answer is yes.

Every group on the network should be open to several “security nodes”. These are nodes that don’t route chunks, keeping them very low in bandwidth. It allows people at home to run several instances of them next to a normal vault without hurting farming. And how does it add to security? Well, if a country or group wants to attack SAFE it could be done by starting a big group of slow nodes in the cloud or over some botnets. Some of these botnets have over a million nodes in them. Imagine they attack SAFE while we’re only at 350.000 nodes. They might not target a group but for sure they can hurt the network.

Now imagine if every group allows several security nodes as I proposed above. How would they help the network? First of all they add nodes to the network. So instead of 350.000 nodes we might see 600.000 nodes where a big part of them are just security nodes. It allows people at home to add security to the network this way. So even when we see some weird behaviour on the network and we feel “something is wrong” we could simply ask the community to start several security nodes next to their vaults to add security and stability to the network. These nodes are just like the normal Vaults but they have a flag added that they would like to start as a security node. When they join they wait for a group to pick them up.

Just a thought.

18 Likes
2

You’re thinking like us in house now, nice one. It’s interesting for sure and worthwhile. The current issue is making node joining not cheap to prevent spam start of millions of nodes or targeting addresses by huge spam starting nodes etc.

Having nodes also be able to not hold xfer as much data is also data chains related.

What you are looking at here though comes up time to time, so well worth poking around at.

12 Likes
3

This does seem to be very much part of data chains (from what I’ve absorbed) as in message priorities can be delegated by the network given a nodes performance so that slow bandwidth is basically, as @anon40790172 proposed, a security node that handles mainly messages. On top of ranking, misbehaving nodes can be banned. Props to @anon40790172 for always wearing his thinking cap :slight_smile:

5 Likes
4

How can you make node joining not cheap?

What springs to mind is using Safecoin. But then it’s too alienating for people who don’t have Safecoin and want to run a node?

I guess the alternative is some kind of hashcash system?

1 Like
5

I think in many ways really (this is one of the less difficult things to consider).

  • Charge safecoin (not so keen)
  • Create joining token earned as a safecoin is and times out quickly
  • Delay start of node from initial group to final group by a time period defined by network need for nodes
  • Force node to relay X messages based on network load
  • Force node to bootstrap for X number of clients
  • Force node to transmit group data during churn whilst building a rank to vote (zero weighted initially)
  • Require a proof of work direct (waste power, again not so keen)
  • Force relocation of a node as it increases rank (complex)
  • Force relocation with breadcumbs (to allow tracking of rank over time)

There are a few methods that can be used here, best is linked with network requirements of nodes and the safecoin farm rate already gives us that info so we are looking there just now in some pre-rfc work (it’s been ongoing since a few months back with data chains and disjoint groups etc.) , amongst a load of other things of course :wink:

11 Likes
6

Not good, impacts negatively on desire to help the network.

Not clear what you mean here.

Maybe you could require a coin is “frozen” until node stops or has been running for “X” amount of work/transactions/messages

I would see this as just one solution rather than 3 separate solutions

Sounds like significant work in coding and testing, while other options may give similar/better results

These seem to be a lot of work and/or wasteful. Some nodes will naturally get more work and others little work. Even though the XOR space provides randomisation over IP space there will still be a statistical spread of work load with some getting more work than others. This means a ranking/relocation scheme may actually work against the benefits of zero storage (security) nodes.

I do rather like the idea of using network load to help determine what difficulty to use.

Also another option to charging a safecoin is to “link” the zero storage node to a signed in launcher. In order to have a signed in launcher you need a validated account. That is an account that has paid a coin in order to permanently store its details.

This then allows each signed launcher to have one zero storage node and then the user can have other non-zero storage nodes (vaults)

Another option is to freeze a coin for zero storage nodes. The coin is then unfrozen when the node stops OR when the node has performed X amount of work. The X amount can be dependent on the network’s need for nodes. Thus if someone floods the network with 1,000,000 nodes they require 1,000,000 coins and those coins would be frozen for a long time since there is little work for them to do due to the number of nodes now.

5 Likes
7

Security nodes could be activated by the network during a local or network wide crisis.

During vault setup, the user is prompted to decide whether he/she would allow this behavior (opt-in by default). This would enable “validated” vaults/accounts that the network has determined to have sufficient bandwidth to spawn one or more security nodes to assist with any given security task. With this capability the network can dynamically recruit security nodes as needed without user interaction. Minimizing the chances that the network will fail to handle a security related task for lack of volunteers who otherwise have to manually activate a security node upon network request.

Would be as follows:

  1. User joins the network (in whatever way we determine that best avoids node flooding).

  2. During vault setup, the user is asked if they would like to help automatically secure the network when needed (the opt-in option is default).

  3. The network evaluates the users’ vault as usual.

  4. If the vault performs X amount of work well, the network assigns it the security tag if the user has chose to opt-in.

  5. Now if the network experiences a sudden need for security nodes, it will immediately create a security node on the users machine (that are in most cases ephemeral).

This should be fairly easy to implement no? Thoughts?

7 Likes
8

I think some of the ideas here are very good and worth looking at. There are a few RFC’s coming in the area and we should use the rfc and dev forum to dig deeply. At the moment we are less concerned about any security missing links, I feel they are well covered for now, but there are choices.

A lot of this is routing type code with a strong overlap to vaults, so the considerations I feel will be the usual MaidSafe approach.

Search for the natural answer, this will be less code, clear up some hard logic (remove any cache/timer etc.) and provide stronger guarantees. I think there will be at least three quite nice RFC’s here (not too in depth or convoluted) which will be

  1. Boostrap method/type on the network (including bootstrap cache)
  2. Client connections (secured and anonymised)
  3. RelayNode and reward

Also looking at securing nodes and what exact purpose they bring and how they increase performance as well as securing the network further. It is very likely increasing performance is the most encouraging aspect of many of these, security should come naturally as all the big components to do that are in place/being implemented, at least in terms of consensus and group security with data security in data chains etc.

So we will push some RFC’s to a pre-rfc thread on the dev forum and we can all tear them to pieces, it will be a massive help to have more eyes on and also spread knowledge far and wide. Nice all round

[EDIT I must add all this attention to deeper levels of the network is 100% going to pay of for everyone involved. This is the project expanding now I feel and great that it does]

12 Likes
9

Correct me if I’m wrong.
Definitely see the point made above, was actually thinking somewhat like this last week.

We need hundreds of thousands of vaults to counterfeit attacks from big parties…
Nothing keeps a medium cpu farm away to run 100000 vaults for a month and switch them of in a second. Doing this once a month when only 20000 vaults are online won’t completely shutdown the network maybe, but definitely result in many broken packages, service unavailable etc which is no good marketing.

Any ideas how this could be prevented first year? Maybe the botnet holders could help us in place of attacking us :smiley:

10

If the incentive structure is right, they just might! :smile:

2 Likes
11

The other hand it’s maybe preferred big companies with fiber running as much vaults as possible.

12

Nice question :thumbsup:

This kind of problem is very related to having differing size vaults etc. we lose quorum. When we lose quorum (as with any decentralised system) then the system fails.

So we have a real good approach here I think in this community. Data Chains and xor consensus, two pretty powerful things. This essentially takes the problem of going below quorum and reduces the problem to - when at least one member of a group survives [echos of Robert the Bruce] . This is true in a great many cases.

So in SAFE we have a kademlia type network, but not with a refresh time (to agree data etc.) this is continuous in SAFE ( so a big difference from normal KAD and a hugely important one).

Then we have consensus based on xor distance from network addresses so no leader election paradigms like raft / paxos etc. Again different, our leader is mathematically chosen.

Then we have data chains where we can prove network data, but not only that, we have a note of data that should exist, even if we do not have it (important in segmentation/partitions etc.). So we cannot update this data in a broken network if the block already exists, regardless of us getting to the data (and remembering xor partitions are not linear they are non euclidean distances so a split happens across groups, not between groups).

So taking all this into account, I think we are probably well on the way to something that challenges long held beliefs, but I suppose we know that as a community we are innovating not mimicking :slight_smile:

Given the above then having huge numbers of node for security/cleanup/burden removal of consensus decisions all becomes much more real and available. It increases availability, consistency and more.

As we iterate faster the core algorithms will appear from the complexity that exists today, then we can mathematically model much of this (remember it’s all probability based decision trees) and improve it even further to remove all magic numbers :slight_smile: I think therefore that perhaps some “well known” or perceived thought experiments can bear fruit because at the moment if the current RFC’s are in place then perhaps even losing a large % of the network at once may not do as much harm as we think.

Good thing is we can try this by killing 80% of a testnet we host (like Alpha) and measure it (we do these kinda things in a less formal way). When the RFC’s are in place these results will be very interesting.

12 Likes
13

I think a key requirement for a secure network is: If you make decisions for the network (i.e. vote as part of a group), you must have invested in the network (e.g. CPU, bandwidth, Safecoin, disk space). If it’s easy to get lots of votes, an attacker can do it and compromise the network. If we can make sure that to get 50% of the votes in the network, you e.g. have to provide more bandwidth and processing power than the rest of the network, then that makes an attack really expensive.

Another key point is: You must not be able to decide in advance where in the network (under which node name) to make that investment. If you can know what name you end up with before you decide to pay or do work, you can start lots of nodes and kill all except those that end up in one targeted group. And then you don’t have to overpower the rest of the whole network but only the rest of that one group.

So I think it’s dangerous to just assign one vote to every node right from the beginning, and it’s dangerous to give a new node its permanent name right away. Being able to run lots of nodes, with one vote each, on your machine doesn’t make the network more, but less secure: The botnet can also run lots of malicious vaults on each of its physical nodes!

That’s why I currently favour either:

  • pay a Safecoin, then be assigned a network name and allowed to join as a node, or:
  • be allowed to join immediately, have a vote with a weight proportional to the total amount of work you did for the network since you joined (i.e. start without voting rights), and be forced to relocate (i.e. be assigned a new node name) periodically (perhaps with exponentially increasing stays at the same place).

The first option would at least make every vote correspond to an up-front direct investment. The second one would make the vote correspond to how much service you actually provided for the network (relocation is necessary so you can’t target a group).

The other options would certainly also provide some amount of protection, but I’m always anxious to get to a simple formula in the end, that allows us to put the cost of an attack in relation to the total value or power of the network.

14 Likes
14

@AndreasF @dirvine I think the weighted vote system makes a lot of sense, it’s very in line with the core principle of proof of resource so seems quite familiar/natural and obviously has a noble use for the security of the network. You got my +1 on weighted vote :smile:

3 Likes
15

You got my +1 on weighted vote

That’s actually a +799: it’s weighted by the number of posts you created. :smiley:

8 Likes
16

I’m a trustworthy node!!! Now I truly feel special :hugging:

6 Likes
17

I’m a fan of requiring safecoin to join the network. It seems the simplest, most straightforward approach.

Maybe there could be a safecoin faucet that new clients would automatically connect to, to retrieve a token, in advance of joining the network. Then, in the event of an attack, we could simply shut down the faucet.

18

An easy way is to have your node zero weighted and wait till you earn a safecoin (we do not know how long though, only the network will).

The joining token approach is very similar to that, but the joining token is like a safecoin that will die out and cannot be hoarded (to launch a huge attack with millions of safecoins and fast joining etc.). The key is to force these nodes to do work to ease the network strain though, so perhaps relay is good.

I will have a pre-rfc very soon to allow us to rip it to bits and see if we cannot make it even simpler (it’s already pretty simple).

14 Likes
19

Great reply! You’ve thought about this a lot :slight_smile:

1 Like