Most Powerful Open Source ERP

Re6st Security

Description of the security inside a re6st network
  • Last Update:2024-06-10
  • Version:001
  • Language:en

This page describes the security in a re6st network.

See P-RE6ST.Re6st.Components for the description of the components of re6st network and P-RE6ST.Re6st.Control.Flow.Summary and to get a summary of the control flow of re6st.

Goals

Re6st is a collaborative network so we want to ensure that only good nodes are part of the network. We therefore need a good security to control what nodes are inside the network. For this we need to control who can enter the network and be able to get out a node we no longer trust.

Please note that re6st does not cipher the communication between its nodes and it is up to the application layer to ensure the data transported is secure. This page only describes the internal mechanism of re6st to have trust between its nodes.

 

Entering the network

The registry can be configured to allow anyone to enter the network (anonymous mode) or to allow only chosen nodes to enter the network.

The anonymous mode can be useful inside totally private LAN where we simply want to add IPv6 connectivity to an existing IPv4 network. In this case, the security is only done through who can access the registry.

In non-anonymous mode, the nodes will need a token to enter the network. You can get a token with a special call to the API of re6st registry. You can do this call only from a selected list of IPs (usually only localhost) so that you need to be able to access the registry in order to have a token.

In either mode, the node will get its certificate by calling the API of the registry (with or without a token). The certificate is signed by the CA of the registry. By default, it is valid for one year (but this is configurable).

 

Verification of the certificate

A re6st node will need its certificate to:

  • communicate with the registry and other nodes
  • open tunnels with other nodes

A node willing to enter the network will usually call the registry to get a peer. This call is then only possible when you have a valid certificate. Then, the node will open a tunnel with this peer. The peer will only accept the tunnel if the node has valid certificate.

Even if you know the information to connect to a re6st node, you cannot do so without a valid certificate.

 

Network parameters

In addition to its own certificate, each node will need the network parameters from the registry to be able to communicate with other nodes.

Any communication between 2 re6st nodes requires (in this order):

  • valid certificates
  • uptodate network parameters

This network parameters contain important information such as:

  • minimum re6st protocol version
  • the list of country whose nodes cannot open a tunnel to other countries
  • the HMAC key used by babel

The mechanism to distribute the network parameters when they change is almost instantaneous because the information that you need to update is propagated from each node to its neighbours and then each node will do the update. In total, it takes less than a minute to have all nodes updated.

 

Ejection of a node

If we want to eject a node from the network (e.g. if the client didn't pay, if the node is not cooperative, ...), we can do so by revoking its certificate. The registry maintains a list of revoked certificate and it will refuse to answer a node with a revoked certificate. Moreover, the list of revoked certificate is distributed to all re6st nodes (as part as a "network parameters").

If a node receives a crl list and is currently connected to a now "revoked node", it will immediately kill its tunnel therefore rendering the "revoked node" isolated.

 

Note on HMAC

If a node is connected to a network through the LAN, it means it can still talk to other nodes even if all its tunnel are killed. In this case, we need to update the HMAC used by babeld (see https://re6st.nexedi.com/Re6st-Design-Document.Understanding.Re6st) of the network. When we update HMAC, the nodes need to connect to the registry to get the new value of the HMAC so only non revoked nodes can get the new value of HMAC and the revoked node won't be able to talk to other nodes.

If HMAC is not deployed on a given network (which is the case for some RapidSpace network), as a temporary measure, we can still make sure that all the nodes on the LAN (where is located a node we no longer want) are not talking directly in the LAN anymore. All communication will go through tunnels and then the bad node can't talk anymore.