[Discuss] private IPs im Mesh (war: Re: [Wien] Hag10 reaktiviert, verbindet nicht mit HH10)

[Erich N. Pekarek]

Hallo!

Am 2016-06-22 um 11:11 schrieb Matthias Šubik:
>> On 22.06.2016, at 10:56, Erich N. Pekarek <(spam-protected)> wrote:
> ...
>>> aherkommen, 
>> Im Gegenteil: Bitte unbedingt filtern!
>> Dass "viele andere auch daherkommen", mag u.U. das Cert interessieren,
>> aber sicher nicht den jeweiligen Nodebetreiber.
> Wenn wir uns an das Pico-Peering-Agreement richten (was offen gesagt vage ist),
> dann “nix filtern, was mich nicht stört”.
Das PPA gegen RFCs aufzufahren, halte ich für gewagt.
Erstens ist das PPA an Communities und nicht an Einzelne gerichtet.
Zweitens könnte nicht zu filtern im schlimmsten Fall einen
Straftatbestand ermöglichen.
Drittens ist der Eingriff in ein lokales Routing von Außen, wenn damit
nicht gerechnet werden muss, auf alle Fälle ein Störfaktor, da dies für
den Einzelnen im Einzelfall nur schwer beherrschar ist.
>
> D.h. :
> ...
>> Fiktive Geschichte 1:
>> Anna nützt zwei verschiedene WLANs: eines mit interner IP-Range
>> 192.168.1.0/24, die DHCP-Server ihres Provider-CPE stammt.
> Annas/Clemens/xy Mesh Router muss einfach klipp und klar source-filtering machen.
> Weil lokale IPs sollte kein Router rausleiten, bzw. keine Verbindung von außen für ein privates Netz nehmen. Weil normalerweise würde (TCP) ja alleine vom (D)NAT verhindert.
> Ein ungewollter Handshake mit einem anderen privaten Netz sollte also auf beiden privaten Seiten verhindert werden.
In keiner Standardkonfiguration ist das der Fall. Maßgeblich ist das
Routing über den Default-Gateway - und der lässt sich über OLSR in der
Konstellation quasi alles unterschieben, respektive ist er vorgeschaltet.
Die Sorgfaltspflicht liegt im Beispiel beim fiktiven Clemens (er
unterlässt das Filtern) und beim fiktivem Bernd (er setzt eine aktives
Tun, indem er eine Route ankündigt), nicht bei der fiktiven Anna (sie
ist bloße Nutzerin ohne Fachkenntnisse).

>
> ...
>> Auch die vom Vergabeberechtigten nicht genehmigte Ankündigung anderer
>> Ranges, wie sie hier zeitweise praktiziert wird sehe ich prinzipiell
>> skeptisch, da für Außenstehende nicht differenzierbar quasi-lokal "in
>> ein fremdes Routing" eingriffen wird.
> Wenn wir ein “nicht vergabeberechtigte” Ankündigung haben, ok. Aber es steht jedem frei, seine (berechtigt) öffentliche Adresse aus gutem Grund im mesh anzukündigen. 
Bei Funkfeuer-IPs ist die Berechtigung zweifelsfrei geklärt. Bei IPs von
anderen Providern hat dieser Interesse daran, dass das Routing wie von
ihn vorgesehen abläuft. Das Ankündigen "eigener" (also vom Provider in
Zusammenhang mit einem von ihm bereitgestellten Anschluss zugewiesener)
IPs über das OLSR-Netz beeinflusst dieses Routing aber für alle
Teilnehmer des Mesh. Dass dahinter ein berechtigtes Interesse stehen
kann, stellt noch keine (implizite) Erlaubnis dar.
> Das ist die Idee vom pico-peering … jeder macht mit, und jeder macht das, was er braucht, um erreichbar zu sein.
Darum möchte das PPA auch, dass Communities die Regeln nach ihrem Bedarf
für ihre Teilnehmer anpassen.
Eine unmittelbare Anwendbarkeit ist nicht gegeben, weil die Bestimmungen
des PPA viel zu unbestimmt sind.
> Eine Teststellung, eine Ersatzbrücke für einen toten Link, all das geht, wenn das mesh “frei” ist. 
>
> Wir verhindern nur traffic, der nachweislich böse ist. Nix anderes sollte sein. 
Ab wann ist Traffic böse? OLSR ermöglicht jederzeit eine Beeinflussung
des Routings und öffnet damit Tür und Tor für MitM-Angriffe.
Das Mesh an sich ist damit "potentiell böse", solange das Routing nicht
abgesichert ist. (Ein Weg wäre Kryptographie in der Art, dass ein
OSLR-Plugin eigene Daten anhand eines pro Device eindeutigen Key
signiert. (Was derzeit nicht realistisch erscheint).
>
> Alles andere würde bedeuten wir machen es ordentlich, d.h. z.B. BOGON-Liste auf jedem Node up-to-date halten.
Bitte dies in die Konzept-Diskussion aufnehmen.
>
> bG
> Matthias
>
>
>
LG
Erich