Layer 3 Netz über Richtfunk verbreiten.
Bisher gibt es das L3 Netz nur über Internet Tunnel. Dort werden Gateways angeschlossen, die dann mit fastd die "FF VPN nodes" anschließen. Durch ein oder mehrere Gateways wird dann auch das Subnetz definiert.
Wenn zwei Hoods / Subnetze über z.B. Richtfunk verbunden werden sollen, müssen Routing Informationen ausgetauscht werden. Die OLSR Routing Information soll aber nicht direkt in die BATMAN Wolke gesendet werden, weil dann jeder diese Informationen manipulieren kann. Dadurch wäre eine leichte und unschöne Störung des L3-Backbones möglich. Es stand die Überlegung im Raum, ob die OLSR Verbindung durch einen Tunnel über das BATMAN Netz gesendet werden. Tunnel sind dabei aber natürlich overhead und sollten für die gerouteten Nutzdaten nicht verwendet werden.
sOLSR bietet die Möglichkeit die OLSR Daten kryptographisch zu sichern. Ziel soll es sein, dass die Routinginformationen nicht manipuliert werden können. Das Mitlesen oder unterbinden/löschen der Daten ist irrelevant, da olsr dadurch vom Prinzip nicht gestört ist und hierbei nur ein Segment betroffen wäre.
Aktuell scheint sOLSR allerdings jeglichen OLSR Traffic mit einem shared-key zu sichern. Damit es auf unseren Zweck passt, müssten wir dieses erweitern, so dass man neben einer generellen Verschlüsselung auch nur auf einzelnen Interfaces verschlüsselt. Ein weiterer Schritt wäre die sOLSR auch mit einem public-key Mechanismus verwenden zu können.
Wir sollten uns vorher auf jeden Fall olsrdv2 angucken.
Neben den Problem mit dem Olsr sehe ich ein 2. Problem. In den meisten Fällen wird die Richtfunkverbindung nicht wirklich genutzt:
Der rote Client rechts, hat als Gatewayserver im Normalfall einen Gateway in einem Rechenzentrum in diesem Fall Gateway 1. Selbst wenn Client 1 und mit Client 2 Daten austauschen will, wird vermutlich meist die schnelle Rechenzentrum - Rechenzentrum Verbindung von Olsr bevorzugt bevor die Route erst wieder durch das "langsame" DSL zum obigen Olsr Router aufgebaut wird. Von einer Internetverbindung von Client 1 über Gateway 2 brauchen wir hier vermutlich auch nicht nachdenken.
Meine Idee sieht nun folgenden Umbau sowie Vereinfachung des Systems vor:
