[Freifunk Franken] zentraler oder dezentraler KeyXchange?

So Aug 20 14:51:13 CEST 2017

Hallo zusammen

auf den gestrigen F3 Netze e.V. Sommercamp wurde auch ein wenig über den
dezentralen KeyXchange gesprochen.

Ich hab mit nach Hause genommen, dass den schon gerne die meisten Leuten
hätten es aber aktuell wirklich schwierig ist den fertig zu stellen, es
fehlt einfach die Man-Power. Um genau zu sein ist es aktuell ja kaum
möglich alle Patches einzuspielen geschweige denn eine Beta/Release
hinzubekommen. Da ist es (mittlerweile glaube ich nicht nur mehr) mir
schleierhaft wie man den dezentralen KeyXchange fertig stellen will und
auch warten, pflegen und Bugs entfernen will.
Ich persönlich sehe das aktuell als sehr schwierig an und ich glaube
mittlerweile bin ich da nicht mehr ganz alleine.

Vor einiger Zeit hab ich mal drüber nachgedacht ob man nicht den
zentralen KeyXchange etwas erweitern kann indem er einfach die wireless
Settings mit an die Knoten sendet und die sich drauf konfigurieren.
Wurde dann damit zerschlagen das ja Meshknoten dann nicht wissen wie sie
das Meshnetz erreichen können, da dies ja für jede Hood unterschiedlich
wird.

Gestern kam die Idee dann wieder auf, dass man dies mit dem (auch im
dezentralen KeyXchange geplanten) Hidden AP lösen könnte. Ich versuche
hier mal das Konstrukt möglichst Fachunspezifisch zu erklären so das es
hoffentlich jeder (auch nix Linuxianer) versteht:

- Wir haben den Fall, das ein neuer Knoten einfach per WAN ans Internet
angeschlossen wird:

In diesem Fall werden ganz normal im WebUI die Koordinaten gesetzt, der
Knoten fragt den zentralen KeyXchangeV2 an und bekommt erstmal seine
Gatewayliste zurück. Gleich danach fragt er den KeyXchangeV2 nochmal an
(oder vllt. direkt im ersten Schritt mit, muss man noch überlegen) und
bekommt Wirelesssettings zurück. D.h. er bekommt eine eigene SSID (Name
den das Handy anzeigt) und eine BSSID (womit das Mesh einzigartig wird,
verschiedene Hoods können sich dann techn. nicht mehr vermeshen -> keine
versehentliche Loopprobleme mehr) zurück und kann diese Konfiguration
übernehmen. Daraus folgt das jede Hood auch eine einzigartige SSID bekommt.

- Nun haben wir den Fall, das man einen Meshknoten in Betrieb nehmen will.

Da dieser ja nicht weiß wie die SSID/BSSID lautet (wird ja im ersten
Fall je nach Hood anders gesetzt), kann er sich nicht ins Freifunknetz
verbeinden. Daher müssen andere Knoten einen weiteren Accesspoint
aufmachen (hidden -> Man sieht ihn am Handy nicht) über den man
ebenfalls in Freifunknetz/Internet kommt und IMMER gleich ist. Der
Meshknoten scant nun, nachdem er feststellt das er über WAN kein
Internet hat, nach diesen immer gleichen (in allen Hoods) hidden Netz,
wenn er eins findet bucht er sich dort als Client ein und hat dann
Zugang zum KeyXchangeV2 (über das Freifunknetz&Internet). Er bekommt nun
auch seine SSID/BSSID zugeschickt, kann diese konfigurieren und dann mit
den Knoten meshen der neben ihn steht.

- Der 3. Fall man möchte den Knoten nun in eine neue dezentrale Hood
(Hardhöhe, StPaul, marterlach, etc.) bringen

Bisher hat man hier die Knoten manuell konfigurieren MÜSSEN (kann man
danach immer noch, es bleibt also dezentral!). Jetzt kann man diese Hood
in den KeyXchangeV2 einpflegen lassen und im WebUI kann ein Menü
erstellt werden:
- Lade alle Hoodinformationen herunter
Dies könnte funktionieren sobald der Knoten "irgendwie" Zugang ins
Freifunknetz/Internet hat (entweder weil er per WAN angeschlossen ist
oder im config Netz eingebucht ist). Darin befinden sich dann auch die
dezentralen Hoods, man kann sie im WebUI anwählen und der Knoten
konfiguriert sich dann für diese dezentrale Hood (die Informationen wie
er das machen muss, bekommt er ja vom KeyXchangeV2 geliefert).

Vorteil von KeyXchangeV2 gegenüber den dezentralen KeyXchange:
- Ich persönlich sehe die Umsetzung als deutlich einfacher an
- Ich sehe das ganze als deutlich wartungsärmer und pflegeleichter an
- Wir führen nicht zuviel neues Zeug ein was Probleme bereiten kann

Nachteil von KeyXchangeV2 gegenüber den dezentralen KeyXchange:
- Ganz klar wir behalten eine zentrale Stelle.
Wobei ich dieses Nachteil persönlich entkräften möchte:
Wer aktuell dezentral sein will und nicht Abhängig vom KeyXchange soll
einfach mal nach Fürth oder mittlerweile auch Nürnberg gucken. Folgende
Hoods kann mittlerweile NUR NOCH der Besitzer abschalten und keine
"zentrale Instanz"/"einzelne Person" mehr (höhere Gewalt, Zerstörung,
etc. ausgeschlossen)
- Hardhöhe
- Unterfürberg
- StPaul
- reddog
- Neunhof
- FabLab
- Hugennottenplatz
- marterlach

darin stecken mittlerweile 3 Personen die das Konzept nahezu
selbstständig umgesetzt haben und ich persönlich sehe auch diesen Aufbau
als die Zukunft an. Man ist damit viel flexibler, man tunnelt weniger,
kann viel besser mit Richtfunkstrecken arbeiten,... usw. Nachteil ist
das man zumindest ein Gateway "in der Stadt" immer zumindest ein
bisschen händisch konfigurieren muss.

Ein RFC Patch habe ich heute morgen mal über die Dev-Mailingliste geschickt:
http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/2017-August/012491.html

Vielleicht noch kurz das Thema:
Warum nicht einfach so weitermachen wie bisher? Das hat mehrere Gründe:
- Da jeder Knoten immer noch nicht weiß, in welcher Hood er ist haben
wir immer und immer wieder das Problem das sich Hoods verbinden. Das
muss man einfach mal endlich lösen
- Batman 2013.4 was wir verwenden ist schon sehr veraltet. Leider ist
das neuere Batman nicht mit den alten kompatibel. Man muss also das Netz
von vorne neu aufbauen. Daraus folgt auch, ein vermeshen zwischen den
alten KeyXchange und den "geplanten neuen" KeyXchangeV2 ist NICHT
möglich, dies wäre aber beim dezentralen KeyXchange genau das gleiche
gewesen
- Klar wäre ein allgemeiner Wunsch auch gewesen das Netz weiter zu
dezentralisieren, dies bietet der KeyXchangeV2 eindeutig __NICHT__. Mein
Gefühl sagt mir aber das 90% (oder mehr...?) der Freifunker einfach nur
einen Router aufstellen möchten der geht und dezentralität anscheinend
egal ist... Schade :( Dabei bieten wir in Franken soviele tolle
Möglichkeiten die andere Communitys nicht haben.

Ich würde mir hier gerne eine Diskussion wünschen wie es denn nun mit
Freifunk Franken weiter gehen soll. Ich denke meine persönliche Meinung
hab ich in der Mail ganz gut rüber gebracht, bin mal gespannt was die
Community so denkt.

mfg

Christian

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 819 bytes
Beschreibung: OpenPGP digital signature
URL         : <http://lists.freifunk.net/mailman/private/franken-freifunk.net/attachments/20170820/ffc51264/attachment.sig>