[Discuss] OLSR Blackhole Problematik

Wolfgang 'Dreamguard' Nagele (spam-protected)
So Dez 25 18:25:52 CET 2005


Hier meine Überlegungen zu der "Blackhole Problematik".

Problem:
OLSR als Routing Protokoll sieht die Möglichkeit vor, das jeder Host zum
einen als Router für seinen Traffic in und über dieses Netz dient, zum
anderen auch das jeder Node sogenannte HNA (Host Network Announce)
Networks besitzt. Hierzu definiert der Node das bei ihm diese Netze
(z.B. 192.168.1.1/28) verfügbar sind. Um eine Default Route zu
definieren können somit Nodes auch eine Route vom Schema 0.0.0.0
definieren wohin jeglicher Traffic gerouted wird, welcher ansonsten
nicht zugestellt werden kann. Dies bedeutet das Hosts im Netz die
Möglichkeit haben ohne Restriktion auf administrativer Seite Traffic aus
dem Netz auf sich zu ziehen, in dem diese das Network 0.0.0.0 bei sich
announcen. Daraus ergibt sich ein sogenanntes "Blackhole" welches den
Traffic zu sich holt, diesen aber dann nicht zustellen (weiterrouten) kann.

Ansatz:
Ein Remote hinterlegtes File mit "allowed Hosts".
Dies erscheint auf den ersten Blick als vielversprechend. Da man durch
einen Cache Mechanismus in der Lage ist das Netz trotzdem dezentral zu
halten.

Der Ansatz sieht folgendes vor:
- Jeder Client erhält ein Plugin (o.ä.) welches
   in definierten Zeitabständen von einem zentralen Server
   ein File mit allowed Hosts abholt.
- Der Client cached den letzten Status so lange bis er einen neuen
   erhält.

Durch den Cache Mechanismus wird das Netz trotzdem unabhängig und
ohne SPOF (Single Point of Failure), der direkten Einfluss auf
den Betrieb haben würde gehalten.

Die Leaks dieses Ansatzes:
- Es gibt keine Möglichkeit die Integrität der Daten zu prüfen.
- Daraus ergibt sich die weitere Einschränkung das es einem
   Angreifer möglich ist gefälschte Daten einzuschleusen.
- Das kann über mehrere Wege geschehen, bei OLSR im speziellen
   ergibt sich dafür aber eine SEHR einfache Möglichkeit, nämlich das
   der Angreifer einfach den Host welcher die Files zur Verfügung stellt
   als HNA announced. Dadurch kann das ganze Netz kompromittiert werden.

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.

Meine Schlussfolgerung daraus ist, das es technisch Sinn machen würde
das Plugin einzuführen - der soziale Aspekt des Netzes darunter aber
leiden würde.

Persönlich sehe ich die technischen Nachteile einer Nicht-Implementation
als so hoch an, das es sich Auszahlen würde den sozialen Aspekt zu
vernachlässigen. Deshalb meine Stimme für eine Einführung von Secure OLSR.

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

lg




Mehr Informationen über die Mailingliste Discuss