[Discuss] OLSR Blackhole Problematik

Andreas Marksteiner (spam-protected)
So Dez 25 22:45:32 CET 2005


Hallo Leute,

> Conclusion:
> Der Ansatz ist im Grundzug interessant, im Detail allerdings nicht  
> gangbar.
> Die sichere Variante des ganzen wäre mit dem Secure OLSR Plugin von
> Andreas Tonnesen machbar, welche einen Hashing Algoritmus (SHA1)
> verwendet um die Daten zu signieren. Wenn man allerdings Daten  
> signiert
> ist es nötig einen Shared Key (oder Certificate Autority, etc.)
> einzurichten und damit wird es unmöglich das Netz dezentral zu halten.
> Weil bei einer CA die CA für den Betrieb benötigt wird, und bei Shared
> Key Varianten der "Free Network" Gedanke leidet, weil ALLE User den  
> Key
> benötigen wenn sie irgendwie teilnehmen möchten.

- was passiert, wenn ein Teil vom Netz abgetrennt wird, die CA nicht  
mehr erreichbar ist und das kleine Netz eigenständig existiert? In  
diesem Fall nur mehr als Netzwerk für die beteiligten Knoten, was ja  
eigentlich auch der Sinn eines freier Netzinfrastruktur ist - nicht  
nur der Internet Access.
- das hindert wiederum einen Teilnehmer im Netz mit gültigem  
Zertifikat daran fälschlicherweise eine default Route zu announcen  
(zumindest, bis er ausgesperrt wird)
- wie komme ich zu einem gültigen Zertifikat, wenn ich die CA Stelle  
anfangs ja gar nicht erreichen kann (weil ich meinen Knoten erstmalig  
ins Netz hänge)
- detto, wie komme ich zu einem neuen Zertifikat, wenn meines als  
ungültig erklärt wird (z.B. weil ich zwischenzeitlich das Netz  
gestört habe)


> Bitte um Feedback. Bzw. neue Ideen - wir suchen leute die hierfür
> villeicht neue Ansätze haben.

- unterbinden des Problems im Ansatz durch Anpassung des OLSR  
Protokolls hinsichtlich der Black Hole Problematik - es sollten schon  
gar keine falschen default routen announced werden können bzw. solche  
Informationen nicht ungeprüft verwendet/weitervermittelt werden
- es werden nur Clients mit FunkFeuer OLSRd im Netz akzeptiert bzw.  
nur routen von solchen weitergegeben
- der OLSRd selbst könnte die Gültigkeit von Default Routen prüfen  
und in die Routenauswahl einbeziehen (z.B. über Erreichbarkeit einer  
IP im Internet)
- an ein BlackHole angrenzende Knoten sollten diese Falschinformation  
erkennen & filtern (wie auch immer ist zu Überlegen)

--> ein Plugin für den offiziellen OLSRd zur Prüfung der Gültigkeit  
von default routen. Damit kann jeder entscheiden, ob er das Plugin  
auf seinem Knoten verwenden will und damit das BlackHole Problem löst.


Grüße, Andi.



Mehr Informationen über die Mailingliste Discuss