Dopo oltre due anni di sviluppo, è stato pubblicato il rilascio di riferimento del protocollo Yggdrasil 0.5, che consente di implementare una rete IPv6 privata decentralizzata separata sopra una normale rete globale, per proteggere la privacy, in cui viene utilizzata la crittografia end-to-end. Nella rete Yggdrasil possono essere utilizzate tutte le applicazioni esistenti che supportano IPv6. L'implementazione è scritta in linguaggio Go ed è distribuita con licenza LGPLv3. Sono supportate le piattaforme Linux, OpenWRT, Windows, macOS, FreeBSD, OpenBSD, VyOS e Ubiquiti EdgeRouter.
Yggdrasil sviluppa un nuovo concetto di routing per la creazione di una rete globale decentralizzata, i cui nodi possono connettersi direttamente tra loro in modalità mesh (ad esempio, tramite Wi-Fi o Bluetooth), o interagire sopra le reti IPv6 o IPv4 esistenti (rete sopra rete). Una caratteristica distintiva di Yggdrasil è l'auto-organizzazione del lavoro, che non richiede configurazioni di routing esplicite: le informazioni sulle rotte vengono calcolate sulla base della posizione del nodo nella rete rispetto agli altri nodi. I dispositivi vengono indirizzati tramite un normale indirizzo IPv6, che non cambia in caso di spostamento del nodo (in Yggdrasil viene utilizzato un intervallo di indirizzi inutilizzati 0200::/7).
L'intera rete Yggdrasil è considerata non come un insieme di sottoreti disconnesse, ma come un'unica struttura ad albero radicato, che ha una 'radice' e ogni nodo ha un genitore e uno o più discendenti. Questa struttura ad albero consente di costruire un percorso verso un nodo di destinazione, rispetto a un nodo sorgente, utilizzando il meccanismo 'locator', che determina il percorso ottimale verso il nodo dalla radice. Le informazioni sull'albero vengono distribuite tra i nodi e non vengono memorizzate in modo centralizzato.
Per proteggere dall'analisi del traffico nella rete viene utilizzata la crittografia end-to-end (i nodi di transito non possono determinare il contenuto), ma non viene garantita l'anonimato: collegandosi tramite Internet, i nodi peer con cui si interagisce direttamente possono determinare l'indirizzo IP reale, quindi per garantire l'anonimato si consiglia di collegare i nodi tramite Tor o I2P.
Nonostante il progetto sia ancora in fase di sviluppo alpha, è già abbastanza stabile per l'uso quotidiano, ma non garantisce la retrocompatibilità tra le versioni. Per Yggdrasil, la comunità supporta un insieme di servizi, inclusa una piattaforma per il posizionamento di contenitori Linux per hosting i propri siti, un motore di ricerca YaCy, un server di comunicazione Matrix, un server IRC, DNS, un sistema VoIP, un tracker BitTorrent per mappare i punti di connessione, un gateway per IPFS e un proxy per accedere alle reti Tor, I2P e clearnet.
Nella nuova versione:
- È stata aggiunta la possibilità di autenticare la connessione ai peer utilizzando una password. La password è impostata tramite il parametro "password=", ad esempio, "tls://a.b.c.d:12345?password=123456abcdef".
- È stata aggiunta la possibilità di utilizzare il protocollo QUIC, basato su UDP, per interagire con i peer. Per utilizzare QUIC, si deve specificare lo schema URI quic:// nelle direttive Listen e Peers, ma il supporto per QUIC non è ancora stato testato a fondo come TCP e TLS.
- È stata aggiunta l'opzione PrivateKeyPath che consente di memorizzare la chiave privata in formato PEM, separatamente dal file di configurazione principale. Per esportare la chiave in un file separato, è possibile utilizzare l'opzione "-exportkey".
- È stato implementato un nuovo schema di routing, che non è retrocompatibile con le versioni precedenti (i nodi con Yggdrasil 0.5 non possono interagire con gli host basati su Yggdrasil 0.4), ma risolve gran parte dei problemi di stabilità e scalabilità presenti nella versione 0.4, riducendo significativamente anche il consumo di memoria e il traffico in assenza di attività di rete.
Nella nuova implementazione, per tracciare le relazioni e i nodi viene utilizzata una struttura probabilistica, il filtro di Bloom. La tabella hash distribuita (DHT) non è più utilizzata per lo scambio di dati di routing e per l'associazione delle chiavi pubbliche in una rete ad albero.
Per mantenere la coerenza locale e ridurre la dipendenza dai percorsi verso i nodi radice, i nodi ora trasmettono separatamente informazioni su ciascun link, che vengono tracciate nelle strutture CRDT. Anziché seguire il routing dalla sorgente, si applica un routing basato su un algoritmo goloso (le richieste vengono indirizzate al nodo vicinissimo).
I formati utilizzati per la negoziazione delle connessioni e per la distribuzione multicast sono stati rielaborati per una migliore scalabilità. Il codice di gestione dei collegamenti è stato ristrutturato per un tracciamento più affidabile dello stato dei nodi. È stato garantito il monitoraggio separato degli intervalli tra le riconnessioni per ogni nodo configurato.
Per la rilevazione di guasti, invece di inviare periodicamente richieste di keepalive separate, vengono impiegati messaggi di conferma della ricezione del traffico, che consentono di ridurre il traffico durante l'inattività della rete (riducendo ad esempio il consumo energetico sui dispositivi mobili escludendo il traffico in idle).
Fonte: opennet.ru
