FEDAnet project

The goal of the FEDAnet project is to build an (overlay) computer network to let people (which means individuals) have mutually agreed communications with no intervention from any uninvited (and unwanted) third party. This means there must be no central authority of any kind, and all communications must be encrypted at the infrastructure level.

Technically FEDAnet is supposed to be a virtual private network (VPN) that uses IPv6 internally and connects its nodes over the IPv4 Internet.

Every network needs its own servers and infrastructure, but only a small fraction of users are capable of running the infrastructure. From the other hand, entities that serve a lot of people become what is known a single point of failure; furthermore, they tend to use the power (gained along with their userbase) to impose their own rules. Hence, in FEDAnet the number of users (points) per node is technically limited. Strictly speaking, the limit is 253 individuals using a single node (the point ID is an unsigned 8-bit number, with 3 values reserved for special purposes). Node masters are expected to provide the access only to their friends and relatives, or at least to people they know in person (internet "friends" are not considered as being personally known). No “open” nodes must appear, and no paid access is expected as well; a node providing point access to arbitrary people should expect to get banned by other nodes. So, a person willing to connect to FEDAnet will have three choices:

• run his/her own node;
• find a friend, a relative or a colleague who already runs a node and ask for a point access to the node;
• find a computer networking hobbyist among friends and relatives, and convince him/her to run a node.

Running a node will require certain level of knowledge and some effort, yet it is important to make it possible for any individual who's dedicated enough. To achieve this, all software must be written in plain C (some C++ is acceptable for programs that don't listen to network ports), must have no external dependencies, neither at compile time nor in runtime, and must link statically, so their “installation” turns to be simple copying of an executable binary to an appropriate location.

In order to run a node you will need:

• A Linux machine; node software will only run on Linux (and maybe some *BSD systems as well, but definitely not on Windows nor on Mac). Please be prepared to keep the machine running and being online 24x7, it is very important.
• Ability to get a UDP port accessible from Internet, and hold the port for long time, like several days. Hardly you have a routable IP address at home nowadays, but if your I.S.P. uses a so-called full-cone NAT, this will be sufficient. Restricted-cone NAT should be sufficient for a single-person node, but not for a node which serves other people. Symmetric NAT, unfortunately, won't suffice even for that. In case your home connectivity has insufficient capabilities, you'll need to find a Linux machine with a routable IP address (e.g., like a VPS or a VDS) where you'll be allowed to run a program called fedaproxy: it will take a UDP port and forward packets to/from your home machine where the node actually runs. A program to test the type of your connectivity is expected to be published soon.

Besides that, you'll need to generate your very own node key. This may take several weeks on a reasonably fast computer.

Depending on a hash of the public key, a master node key is assigned a rank; the higher the rank is, the more (average) time it takes to generate the key. Each node makes its own decision what minimal rank must other nodes have in order to be recognized. This makes a node to be of some value for its owner.

For internal addressing, IPv6 address block FEDA::0/16 is going to be used (hence the name of the network). This block is a subnet of FEC0::0/10, which was defined by rfc3513 as “site-local addresses”, but was “deprecated” in this role a bit later by rfc3879. As the time of this writing (Nov. 2024), IANA whois server says the following about the block:

inet6num:     fec0:0:0:0:0:0:0:0/10
descr:        Reserved by IETF

remarks:      http://tools.ietf.org/html/rfc3879

source:       IANA

It is highly unlikely the block will get reused for any other "special" purpose; anyway, FEDAnet's internals are not Internet so perhaps we'll be able to use these addresses even then. In the worst possible case they may decide to give the addresses a role special enough that routers will threat them in some special manner, like they do right now for link-local addresses. If such a horrible commitee-made decision will ever take into effect, we'll perhaps have to switch, e.g., to FCDA::0/16, and our usage will even be (partially) compliant with rfc4193, at least making no conflicts. Never mind, let's just hope they will not come up with another brilliant idea which effectively steal huge amounts of time from thousands of innocent developers (the very usual thing for commitees, but let's just hope for the better).

A node ID consists of 10 bytes (actually, these are the last 10 bytes of the node's public key, so they look pretty random). In FEDAnet, the node ID is used as a part of every IP address. For example, if your node has the ID 49feb618794a8e1e4439, then your node will use the address block FEDA:49FE:B618:794A:8E1E:4439::0/96. This leaves you 32 bits for the address' node-local part, but don't get too impatient. There are also points who use the node, and the point number is a 8-bit unsigned. So, the next byte in the address will be the point number; e.g., if you assign someone with the point number 139 (hexadecimal 8B), then your poor user will have to use addresses from FEDA:49FE:B618:794A:8E1E:4439:8B00:0000/104. Don't worry, a /104 subnet still contains 2²⁴ = 16777216 IPv6 addresses. Looks more than enough for an individual, and your point definitely must be an individual.

You, being the node master, will need a point number for yourself, too; usually this will be the number 1, but you, at your option, can pick any other point number, they are all yours. Only keep in mind there are 3 reserved values: 0x00, 0xfe and 0xff. These must not be assigned to points. The point number 0 (ZeroPoint) will be used to refer to the node itself; for instance, ZeroPoint's key may be used to sign other keys and otherwise act on behalf of the node, which makes it possible to use the master key on rare occasions only. Within the IPv6 addresses, ZeroPoint will perhaps be used for the node's own infrastructure.

A lot of technical decisions are still to be made for FEDAnet; however, some decisions are already made, so here they are:

• The Monocypher library, version 4.0.2, will be used for all the cryptography (except for the proof-of-work hash). Later versions may only be used in case they maintain 100% backward compatibility. The set of cryptographic algorithms used in FEDAnet is not subject to change even in case someone manages to break them; if FEDAnet will become insecure one day because of broken cryptography, it will mean the whole project has to be abandoned. Yes, this is far better than to waste time and effort trying to make the cryptography framework “replaceable” and/or “pluggable”. We've got enough of SSL/TLS, no?
• To compute the hash of a node's master public key, the yespower hash implementation, version 1.0.1, will be used, with the hash size set to 32, the parameter r set to 32 and the parameter N set to 65536. This means a single hash computation will take 256 MB of RAM, used actively enough that swapping of that memory is not an option. The personality string is set to NULL.
• The rank of the node key is the number of first bits of the hash, that match the pattern 0xFEDAFEDAFE....
• Cryptography certificates used by FEDAnet will be of exactly three types:
  • A node's master “certificate” contains the node ID, the public key and the yespower hash of the public key. Actually, it could contain only the public key because both the node ID and the hash are naturally derived from it. Strictly speaking, this is not a certificate at all, as it doesn't use any signatures. It even contains nothing like dates, because there's nothing to “reissue” here, and the node itself only exists as long as its master key is recognized.
  • A point's key certificate signed by the node's master key contains the node ID, the node public key, the yespower hash of the key, the point ID (an integer from 0 to 255), the issuing date (in minutes (sic!) since EPOCH), the signed_by value set to -1, and the master's digital signature for the feda_cert_info data structure (see below).
  • A point's key certificate signed by the PointZero key contains the node ID, the node public key, the yespower hash of the key, the point ID (an integer from 0 to 255), the issuing date (in minutes since EPOCH), the feda_cert_info data for the PointZero, the master's signature for it, the signed_by value set to 0, and the PointZero's digital signature for the feda_cert_info data structure of the point being certified.
• The feda_cert_info structure is as follows (u_chr is a typedef for unsigned char):

  struct feda_cert_info { /* all numbers are to be stored big-endian */
      u_chr feda[4];              /* magic number 0xFEDACE87 */
      u_chr node_id[node_id_size];
      u_chr point_id;
      u_chr signer_id;            /* 0xFF if signed by the node's master key,
                                     0x00 if signed by the PointZero's key   */
      u_chr timestamp[4];         /* minutes since epoch, a.k.a. unixtime/60 */
      u_chr key[public_key_size]; /* the key being certified */
  };
  

• Certificate issuing date is stored as a 32-bit integer containing minutes since EPOCH, which means the traditional unixtime divided by 60 (dropping the remainder). This allows not to waste extra 4 bytes making the date field 64-bit.
• A certificate is to be considered valid as long as its master public key hash has the appropriate prefix (rank no less than the minimum set for the checking node), the digital signature(s) are valid and there's no certificate for the same node+point with a later issuing date. There's no such thing as a “certificate lifetime” a.k.a. “validity period”; a certificate can be rewoked by issuing a new certificate for the same point, but remains valid for any checking party who haven't seen the newer certificate yet.

There will be some mechanics that makes it possible to avoid direct communication between nodes located in the same country; such nodes should relay all traffic to each other via a third node, physically located in a different country. Details are yet to be determined.