[Freifunk Franken] zentraler oder dezentraler KeyXchange?

Christian Dresel fff at chrisi01.de
So Aug 20 16:11:37 CEST 2017


hi

On 20.08.2017 15:55, Peter J. Philipp wrote:
> Also um mitzureden brauch ich auch leider ein bisschen mehr information,
> ich hab eine Konzeption aber die ist vielleicht falsch.
> 
> Was tut der jetzige keyexchange?  Ich hab ein wenig gesucht auf dem wiki

aktuell meldet sich jeder Router der am WAN im Internet hängt beim
keyxchange (PHP Script mit MySQL Datenbank hinten dran) an und sendet
ihn die im WebUI eingegebenen Koordinaten. Der KeyXchange berechnet dann
zu welcher Hood (=Layer2 Netz) diese Koordinaten gehören und sendet die
Gateways (=VPN Endpunkte) zurück zu dem sich der Router verbinden soll,
mehr tut er nicht. Da der Router dadurch nicht weiß zu welcher Hood
(Layer2 Netz) er gehört, sind die WLAN Settings immer gleich

Script am Router dazu:
https://github.com/FreifunkFranken/firmware/blob/master/src/packages/fff/fff-vpn-select/files/usr/sbin/vpn-select

Und das Repo zum KeyXchange:
https://github.com/FreifunkFranken/VPNkeyXchange

> aber nichts richtiges gefunden.  Soweit ich weiss
> beherbergt er die schlüssel zum access ans freifunk franken netz.
> 
> Ich würde immer vorschlagen etwas zu machen so wie das DNS system mit
> root-knoten und hierarchisch es nach
> unten auf die wr-841 (im minimalsten sinn) knoten zu propagieren.  Aber
> vielleicht ist das immer noch zu zentral,
> im Internet sind ja die DNS root-knoten verteilt wo es 13 ursprüngliche
> und die mit IP-Anycast methoden dann auf

kann ich leider auf die schnelle nicht beurteilen wie das laufen
würde/soll/wird. Versteh dazu das Konzept aktuell nicht.

> hunderte verteilt wurden.  Auch würde ich es um DNSSEC bauen mit 2
> Schlüssel Lösungen.  (muss da sein).
> 
> Frage ist.  Wieviel mehr kann ein wr-841 ertragen an RAM Benutzung und
> wieviel freien raum haben wir auf der flash?

~120kbyte Flash und RAM je nach Hood paar wenige MB glaub ich

mfg

Christian

> 
> Ich sehe das so das wenn ein dezentraler key-knoten isoliert wird (also
> abgeschnitten vom netz) das er weiter machen
> kann mit einer cache (wie eine DNS cache) vom eigentlichen root-knoten.
> 
> Ich kann helfen so einen server zu bauen wenn er in C geschrieben wird,
> sonst nicht.  Ich hab einen DNSSEC fähigen
> DNS server gebaut also vor-erfahrung, also sollte so ein key exchange
> auch möglich sein.
> 
> Gruss,
> -peter
> 
> 
>> Am 20.08.2017 um 15:25 schrieb Tim Niemeyer <tim at tn-x.org
>> <mailto:tim at tn-x.org>>:
>>
>> Hi Christian
>>
>> Am Sonntag, den 20.08.2017, 14:51 +0200 schrieb Christian Dresel:
>>> 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.
>> Ne, du hast leider völlig Recht. :(
>>
>>> 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.
>> "Zerschlagen" klingt so heftig..
>>
>>> 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) 
>> Ein Schritt wäre mMn sinnvoll.
>>
>>> 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.
>> Hinweis für die Leser: Das wäre beim dezentralen keyXchange genauso.
>>
>>> - 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
>> Problem ...
>>
>>> 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 
>> ... weil der Knoten hier zwischen zwei Hoods liegen könnte und dann
>> immer hin und her "roamen"/"handovern" würde. Das würde dazu führen,
>> dass die Kommunikation dann kaputt geht, weil die Subnetze anders sind.
>>
>> Das Konzept vom dezentralen KeyXchange sieht genau deswegen da ja auch
>> vor, dass die Daten von Knoten zu Knoten kopiert werden. Im Fall des
>> roamen geht im schlimmsten Fall die aktuelle Websession (der Download)
>> kaputt. Das wäre über einen simplen retry leicht handhabbar.
>>
>> Man kann mit dem Problem vielleicht leben oder sogar irgendwie
>> drumherum bauen. Immerhin würde es heute vermutlich sehr selten (wenn
>> überhaupt) passieren, aber ich hoffe in Zukunft doch schon deutlich
>> öfter.
>>
>>> 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).
>> Wenn man da schon das WebUI anfasst, wäre ich dafür, dass die
>> Information zu den dezentralen Hoods nicht im keyXChangeV2 liegen
>> sondern vom Benutzer eingegeben werden. Man könnte dies in einem
>> Oneliner verpacken:
>> hh.freifunk;00:DE:AD:BE:EF:01;13;...
>>
>> Dann wäre man unabhängig von dem zentralen Ding.
>>
>>>
>>> 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.
>>
>> Ich finde diesen echten dezentralen Ansatz auch viel viel besser! Aber
>> leider sehe ich nicht, dass wir es schaffen werden alle Freifunk Knoten
>> in so ein Konzept zu überführen.
>>
>>> Ein RFC Patch habe ich heute morgen mal über die Dev-Mailingliste
>>> geschickt:
>>> http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/2017-Aug
>>> ust/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
>> Richtig.
>>
>>> - 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
>> Wobei man das Batman theoretisch auch ohne Änderung des KeyXchange's
>> einführen könnte. Da es aber ein Bruch des Meshings (auch zu den
>> Gateways hin) bedeutet, ist es ein hoher Aufwand und bindet viele
>> Ressourcen. Diesen Schritt mit einem neuen keyXchange zu verknüpfen
>> macht daher mMn nur Sinn, denn dann muss der Aufwand nur einmal gemacht
>> werden.
>>
>>> - Klar wäre ein allgemeiner Wunsch auch gewesen das Netz weiter zu
>>> dezentralisieren, dies bietet der KeyXchangeV2 eindeutig __NICHT__. 
>> Ich würde mir wünschen, dass wir das weitere dezentralisieren nicht aus
>> dem Auge verlieren. Einige von uns haben das ja auch nicht und haben
>> den von dir oben gezeigten neuen Ansatz erprobt. Das ist ja auch ein
>> großer Fortschritt, der halt leider nur noch nicht in der Breite
>> angekommen ist (und so aktuell vermutlich auch nicht ankommen wird).
>>
>>> 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 :(
>> Ja, das Gefühl habe ich leider auch. Vielleicht sollte man da nicht nur
>> von der technischen Seite, sondern auch mit mehr Aufklärung ran gehen?
>>
>>> Dabei bieten wir in Franken soviele tolle
>>> Möglichkeiten die andere Communitys nicht haben.
>> Da solltest du mehr Werbung für machen. :)
>>
>>> 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.
>> Ich hoffe Stark, dass du noch mehr Rückmeldung bekommst.
>>
>> Hier nochmal meine Meinung etwas zusammen gefasst:
>> - Wir müssen die dezentralen Gateways in der Stadt weiter vorran
>> bringen
>> - Wir dürfen die Masse dabei nicht auf der Strecke lassen
>> - Die Entwicklung der Hood's ist noch nicht abgeschlossen
>>  der letzte Schritt, die ESSID, fehlt noch
>> - Bisher war geplant die korrekten ESSID's mit dem dezentralen
>> keyXchange in die Hoods zu kriegen
>> - Wenn es eine einfache Bessere Lösung gibt, dann her damit
>> - Der keyXchangeV2 ist eine einfachere, aber keine bessere Lösung
>> - Mit dem Ressourcen Problem hast du leider Recht
>>
>> Ich würde mir wünschen, wenn man vielleicht den keyXchangeV2 als
>> Zwischenschritt bis zum dezKeyXchange einbauen könnte, aber so, dass er
>> technisch keine Alternative sondern ein erster Schritt ist. Wenn das
>> Config-AP beim keyXchangeV2 so gebaut werden würde, dass es beim
>> dezKeyXchange 1:1 nutzbar wäre, wäre das ein Traum.
>>
>> Tim
>>
>>> mfg
>>>
>>> Christian
>>>
>>> _______________________________________________
>>> franken mailing list
>>> franken at freifunk.net <mailto:franken at freifunk.net>
>>> http://lists.freifunk.net/mailman/listinfo/franken-freifunk.net
>> _______________________________________________
>> franken mailing list
>> franken at freifunk.net <mailto:franken at freifunk.net>
>> http://lists.freifunk.net/mailman/listinfo/franken-freifunk.net
> 
> 
> 
> _______________________________________________
> franken mailing list
> franken at freifunk.net
> http://lists.freifunk.net/mailman/listinfo/franken-freifunk.net
> 

-------------- 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/3447e1dc/attachment.sig>


Mehr Informationen über die Mailingliste franken