La version 0.5 d'Yggdrasil, une implémentation d'un réseau privé fonctionnant sur Internet

Après plus de deux années de développement, une version de référence du protocole Yggdrasil 0.5 a été publiée, permettant de déployer un réseau IPv6 privé décentralisé au-dessus d'un réseau global standard, afin de protéger la vie privée, utilisant le chiffrement de bout en bout. Tous les applications existantes prenant en charge IPv6 peuvent être utilisées dans le réseau Yggdrasil. L'implémentation est écrite en Go et est distribuée sous la licence LGPLv3. Les plateformes prises en charge incluent Linux, OpenWRT, Windows, macOS, FreeBSD, OpenBSD, VyOS et Ubiquiti EdgeRouter.

Yggdrasil développe un nouveau concept de routage pour créer un réseau décentralisé global, où les nœuds peuvent se connecter directement entre eux en mode réseau maillé (par exemple, via Wi-Fi ou Bluetooth), ainsi que fonctionner au-dessus des réseaux IPv6 ou IPv4 existants (un réseau dans un autre réseau). Une caractéristique distinctive de Yggdrasil est l'auto-organisation du fonctionnement, ne nécessitant aucune configuration explicite de routage — les informations sur les itinéraires sont calculées en fonction de la position d'un nœud dans le réseau par rapport aux autres nœuds. Les appareils sont adressés via une adresse IPv6 standard, qui ne change pas lorsque le nœud se déplace (Yggdrasil utilise une plage d'adresses non utilisée 0200::/7).

L'ensemble du réseau Yggdrasil est considéré non comme un rassemblement de sous-réseaux disparates, mais comme un arbre couvrant structuré unique, ayant une « racine », chaque nœud ayant un parent et un ou plusieurs descendants. Cette structure arborescente permet de construire un itinéraire vers un nœud de destination par rapport à un nœud source, en utilisant un mécanisme « locator » qui définit le chemin optimal vers le nœud depuis la racine. Les informations sur l'arbre sont distribuées entre les nœuds et ne sont pas stockées de manière centralisée.

Pour se protéger contre l'analyse du trafic, un chiffrement de bout en bout est appliqué dans le réseau (les nœuds de transit ne peuvent pas déterminer le contenu), mais l'anonymat n'est pas garanti — en se connectant via Internet, les nœuds pairs avec lesquels une interaction directe a lieu peuvent déterminer l'adresse IP réelle. Par conséquent, pour garantir l'anonymat, il est recommandé de connecter les nœuds via Tor ou I2P.

Bien que le projet soit encore en phase alpha, il est déjà suffisamment stable pour une utilisation quotidienne, sans garantir la compatibilité descendante entre les versions. Pour Yggdrasil, la communauté prend en charge un ensemble de services, y compris une plateforme pour l'hébergement de conteneurs Linux pour d'hébergement ses sites Web, un moteur de recherche YaCy, un serveur de communication Matrix, un serveur IRC, un système DNS, un système VoIP, un tracker BitTorrent, une carte des points de connexion, une passerelle vers IPFS et un proxy pour accéder aux réseaux Tor, I2P et clearnet.

Dans la nouvelle version :

• Ajout de la possibilité d'authentification des connexions aux pairs à l'aide d'un mot de passe. Le mot de passe est défini via le paramètre «password=», par exemple, «tls://a.b.c.d:12345?password=123456abcdef».
• Ajout de la possibilité d'utiliser le protocole QUIC, basé sur UDP, pour interagir avec les pairs. Pour utiliser QUIC, il faut spécifier le schéma URI quic:// dans les directives Listen et Peers, mais le support de QUIC n'est pas encore aussi bien testé que TCP et TLS.
• Ajout de l'option PrivateKeyPath permettant de stocker une clé privée au format PEM, séparément du fichier de configuration principal. Pour exporter la clé dans un fichier distinct, l'option «-exportkey» peut être utilisée.
• Mise en œuvre d'un nouveau schéma de routage, non compatible avec les versions précédentes (les nœuds avec Yggdrasil 0.5 ne peuvent pas interagir avec les hôtes basés sur Yggdrasil 0.4), mais résolvant la plupart des problèmes de stabilité et de scalabilité présents dans la branche 0.4, tout en réduisant significativement la consommation de mémoire et le trafic en l'absence d'activité réseau.

  Dans la nouvelle mise en œuvre, une structure probabiliste de filtre de Bloom est utilisée pour suivre les relations et les nœuds. La table de hachage distribuée (DHT) n'est plus utilisée pour l'échange de données de routage et l'association des clés publiques dans un réseau en arbre.

  Pour maintenir la cohérence locale et réduire la dépendance aux routes vers les nœuds racine, les nœuds transmettent désormais séparément des informations sur chaque lien, qui sont suivies dans des structures CRDT. Au lieu de la routage d'origine, un routage basé sur un algorithme glouton est utilisé (les requêtes sont dirigées vers le nœud voisin le plus proche).

  Les formats utilisés pour l'accord des connexions et la diffusion multicast ont été retravaillés pour une meilleure évolutivité. Le code de gestion des connexions a été refondu pour un suivi plus fiable de l'état des pairs. Un suivi séparé des intervalles entre les reconnections a été mis en place pour chaque pair configuré.

  Pour détecter les pannes, plutôt que d'envoyer périodiquement des requêtes keepalive isolées, des messages avec accusé de réception du trafic sont utilisés, permettant d'éliminer le trafic en cas d'inactivité réseau (ce qui, par exemple, réduit la consommation d'énergie sur les appareils mobiles en éliminant le trafic au repos).

Source : opennet.ru