KeyXchange

Wer Fehler findet darf sie behalten. Wer sie nicht haben mag darf sie gerne korrigieren. Ich geh dann mal zum Sport.

KeyXchange

Der KeyXchange hat eine lange Geschichte hinter sich von einem ganz einfachen VPN-Key-Austausch-Punkt über eine manuelle Hood-Zuweisung, über eine automatische Hood-Zuweisung mittels Netmon bis zur automatischen Hood-Zuweisung über Standortdaten vom Knoten bis jetzt zum V2, wo der keyXchange nicht mehr die Hood zuweist sondern nur die Informationen über eine Hood zurück gibt. So Sonder-KeyXchange-Hoods wie die "AUX" lassen wir mal aussen vor.

Der erste keyXchange

Der erste keyXchange kannte nur die Unterscheidung zwischen Gateway und Knoten. Zu der damaligen Zeit gab es nur ein bis zwei Gateways insgesamt. Die Wurzeln hat der keyXchange in Oldenburg.

Der Zweck ist es die Knoten und die Gateways gegenseitig bekannt zu machen. Dazu muss sowohl die IP-Adresse, als auch der kryptographische Schlüssel (Keys) ausgetauscht werden.

Jeder Knoten, der den keyXchange anfragt bekommt automatisch die Liste der Gateways (inkl. IP-Adresse und Key) und jedes Gateway was anfragt bekommt die Liste aller Knoten.

Die ersten Hoods

Das Freifunk Franken Netz ist stetig gewachsen und so führte es zu dem Problem, dass durch Broadcast Traffic (eine Hood ist eine sog. Broadcast-Domain) der Traffic-Overhead im Vergleich zum eigentlich Nutz-Traffic sehr hoch war. Es war bald nicht mehr möglich ein Freifunk-Knoten an einem damals handelsüblichen A-DSL zu betreiben, da die Leitung bereits mit Broadcasts überlastet war.

Der keyXchange wurde erweitert (s. Code). Es kamen die Hood hinzu. Die Anzahl der Physikalischen Gateways wurde zunächst nicht erhöht. Es wurden lediglich neue L2 Subnetze und VPN-Instanzen gestartet. Aus der Perspektive des keyXchanges sind das aber eigenständige Gateways. So wurden jeweils zwei Gateways einer Hood zugeordnet. Dies geschah damals wie heute manuell. Alle paar Tage hat ein freiwilliger das damalige Monitoring-System (das Netmon) durchgesucht, ob es neue Knoten gab und diese dann manuell zu der entsprechenden Hood zugeordnet.

Zu der damaligen Zeit war es unproblematisch, dass mehrere Knoten mittels WiFi zwei Hoods verbinden. Theoretisch existierte dieses Problem aber bereits zu dieser Zeit.

Der Voronoi Algorithmus

Zunehmen mehr Knoten wurden aufgestellt. Die Arbeitslast der manuellen Zuweisung war zu hoch. Die Lösung war, dass der keyXchange um den Voronoi Algorithmus erweitert wurde.

Zu der damaligen Zeit musste jeder Knoten am Netmon registriert werden. Darüber konnten auch Konfigurationen wie z.B. der Standort und der Name gemacht werden (diese werden im Sinne der Dezentralisierung heute direkt am Knoten vorgenommen).

Gateways wurden nach wie vor manuell in den keyXchange eingetragen und manuell einer Hood zugewiesen. Ein Anfragendes Gateways hat ebenfalls nach wie vor die Liste aller Knoten in seiner Hood gemeldet bekommen. Ein Knoten hingegen wurde erst in die Datenbank eingetragen, nachdem der keyXchange den Standort über das Netmon ermittelt hat und die nächstgelegene Hood (voronoi) bestimmt hat. Diese Hood wurde dem Knoten dann automatisch zugewiesen.

In dem ganzen Dunstkreis ist der Sprachgebraucht "V2" inzwischen auch auf die zentralen Gateways und die Firmware, welche diesen keyXchangeV2 benutzen.

Die Netmon Abschaltung

Es war immer ein großes anliegen das Freifunk Netz von so wenig einzelnen Systemen und einzelnen Menschen wie möglich abhängig zu machen. Durch den neuen Voronoi Algorithmus ist aber eine Abhängigkeit vom keyXchange zum Netmon gebaut worden. Es war ein besonders wichtiges Anliegen diese Abhängigkeit aufzulösen.

Dazu mussten die Informationen die der keyXchange vom Netmon benötigt (die Geo-Position des Knotens) in Zukunft direkt von den Knoten kommen. Zu der damaligen Zeit hatten die Knoten kein Web-Interface. Dieses musste erst entwickelt werden. Dabei mussten diverse technische Probleme gelöst werden, wie z.B. die Adressierbarkeit des Web-Interfaces.

Da die Knoten keine eigenen IP Adressen innerhalb des Freifunk-Netzes hatten war der ursprüngliche Weg lediglich die Verwendung von IPv6-Link-Local Adressen. Durch div. Probleme (IPv6 Spezifikation?) kann man mit Web-Browsern keine Link-Local IPv6 Systeme ansteuern. Die Knoten mussten also echte IP Adressen bekommen und das fdff::xxxx Netz war geboren.

Mit dem Web-Interface konnten die Betreiber der Knoten nun den Standort (und weitere Daten) direkt am Knoten eintragen. Mit diesen Informationen melden sich die Knoten am keyXchange, welcher dann mittels voronoi die passende Hood ermitteln kann.

Das Problem, dass zwei Knoten nahe beinander unterschiedlichen Standorten Angaben hatten nahm zu und immer häufiger kam es zu Netz-Störungen da mehrere Hoods versehentlich verbunden wurden, obwohl diese strickt getrennt gehören.

Konzept zum dezentralen keyXchange

Um das Problem zu beheben müssen die WLAN Einstellungen (welche bestimmen, ob ein Knoten mit einem anderen peert) auf jedem Knoten an die entsprechende Hood angepasst werden. Die Information wie eine Hood sein soll und wo diese Hood ist, sollte also von der zentralen Instanz "keyXchange" weg und direkt auf dem Knoten verfügbar sein.

Das erste [Portal:Netz/Konzept:HoodAnnouncement|Konzept] sah vor, dass es Hood- und Gatewayfiles gibt. Diese sollten dann zwischen den Knoten synchronisiert werden und mittels Kryptographie und einem Web-of-Trust abgesichert werden. Dadurch, dass das Web-of-Trust erweiterbar sein sollte, wäre es möglich gewesen weiteren Freifunkern die Berechtigung zuzugestehen neue Hood- und Gatewayfiles anzulegen oder zu bearbeiten. Langfristig wäre es mit möglich gewesen diese Verwaltung in die Breite zu tragen und jedem Freifunker eine Teilhabe zu ermöglichen.

2016 hat es das Konzept sogar bis in die Implementierung geschafft. Die zahlreichen Herausforderungen waren jedoch enorm. Leider waren die dabei gefundenen Probleme aber so groß, dass die Entwicklung stagnierte.

Der keyXchangeV2

Der "dezentrale keyXchange" war ein so großes Unterfangen, dass dies nicht bewältigt werden konnte. Daher wurde der keyXchangeV2 als Zwischenschritt eingeführt. Dieser hatte durch das Entfernen von großen Teilen der Synchron(?) und das Entfernen des Web-of-Trusts deutlich weniger Probleme zu bewältigen.

Im keyXchangeV2 werden die Hoods und die Gateways nach wie vor manuell eingetragen. Die Gateways sind so eingestellt, dass VPN Verbindungen automatisch akzeptiert werden. Die Knoten senden ihren Standort (Koordinaten) an den keyXchangeV2, dieser bestimmt damit die zuständige Hood und erzeugt das Hoodfile. Der Knoten wird nicht in die Datenbank vom keyXchangeV2 eingetragen. Mit dem Hoodfile konfiguriert der Knoten nun die Netzwerk-Parameter und ist dann für den Einsatz bereit.

Dieser Mechanismus funktioniert natürlich nur bei Knoten, die einen VPN Uplink haben. Die längste Zeit der Entwicklung einer Firmware, welche den keyXchangeV2 nutzen kann, wurde damit verbracht, für "Mesh-Knoten" eine ausreichende Lösung zu finden. Diese ist mit dem Config-AP gefunden worden.

keyXchangeV2 ist nun der aktuelle Standard.

Der Ausblick

Obwohl der keyXchangeV2 nur ein Zwischenschritt sein sollte, sind inzwischen nahezu alle Freifunker von der Idee des "dezentralen keyXchanges" abgekommen, weil es schlicht als nicht mehr sinnvoll angesehen wird.

Neues Konzept werden die dezentralen Hoods sein.

Zugriffsberechtige auf den Keyxchange v2

Aktuell haben folgende Personen Zugriff:

fff-netmon2

auf diese VM wird läuft nun der keyxchange. Hier soll die Dokumentation verbessert werden. Aktuell haben Zugriff:

• Fabian (Zugriff auf VM backend, root auf VM, Zugang zur keyxchange Datenbank)
• meskal (Zugriff auf VM backend, root auf VM, Zugang zur keyxchange Datenbank)
• Adrian (root auf VM, Zugang zur keyxchange Datenbank)
• moexe (Zugang zur keyxchange Datenbank)
• Robert (Zugang zur keyxchange Datenbank)
• mifritscher (Zugang zur keyxchange Datenbank)
• McUles (Zugang zur keyxchange Datenbank)