[Discuss] [Wien] Fremde Netze

Do Nov 27 03:01:48 CET 2014

Hallo!

Am 2014-11-26 um 21:59 schrieb Matthias Šubik:
> Hallo Erich,
> danke für den Input,
> hier ein paar Notizen, wenn sich da jemand mit weiter beschäftigen will:
>
> On 25.11.2014, at 23:58, Erich N. Pekarek wrote:
> ...
>> Bei Durchsicht der Routing-Tabelle meines Tunnel-Client entdecke ich einige Adressen, die eigentlich im Funkfeuer-Netz nichts verloren haben:
>>
>> 128.0.0.0?
> Meinst Du eine 128.0.0.0/1 Route? Dann solltest Du der Vollständigkeit halber auch eine 0.0.0.0/1 finden.
> Ich bin über den aktuellen Stand nicht informiert, aber dass macht man, um "fremde" 0/0 (default) Routen mit einer spezifischeren Route zu überbieten.
> ...
Danke, gefunden und geklärt! Danke v.a. auch an Gottfried!
>> [RFC1918 Adressen] ... Wenn also diese Adressen, wenn auch nur auf das Funkfeuer-Netz beschränkt, angekündigt werden, kann es sehr leicht zu Kollisionen mit bereits benutzten Ranges kommen.
> Eigentlich sollte es nicht zu Kollisionen kommen, weil der "ordentliche" Router die lokale Route immer der "fernen" vorziehen sollte.
An sich sollte man das vermuten. Die Praxis zeigt, dass solcherlei 
Routen, beim Debuggen schon einmal zu fehlerhaften Annahmen verleiten 
können. Siehe "lokaler" 3G-Stick, 10.0.0.0/8 und Ankündigung einer 
potentiell identischen 10.0.0.0-Adresse .... detto mit 10.0.0.138 und 
Telekom-Modems, ...
>   Ich sehe hier eher das Problem dass wenn sich jemand auf so eine Ankündigung verlässt, dass die dann plötzlich nicht mehr geht, oder nur zeitweise geht. IP Adressen sollten halt eindeutig sein, auch RFC1918-Adressen halt pro "administrativer Einheit".
Wir haben das seinerzeit im Zusammenhang mit der "Zusammenschaltung mit 
anderen Communities" erörtert; obgenannte Beispiele treten hinzu.
>
> Ich würde IMHO nach keine Ankündigungen für RFC1918 ohne Ankündigung und Ansprechpartner in der Gemeinschaft machen, aber ich sehe durchaus Nutzen, es spricht für das Netz, wenn das so funktioniert.
Mit den Ansprechpartnern ist das so eine Sache. Ein Newbie wird 
beispielsweise die Liste der Bridges auf 192.168.222.0/24 weder aktiv 
suchen, noch erwarten.
Die Abstimmung über eine Zuteilung muss auch im Worst case 
(Kommunkationsdefizite) funktionieren. Das zu erreichen ist schwierig.
>   (Es gab auch schon mal die Idee, wenn reine Relay-Knoten nicht mehr extern sichtbar sind, weil externe Erreichbarkeit dort nicht unbedingt notwendig ist. Das wäre aber nur eine spezifische Entscheidung zugunsten einer Nutzung von RFC1918-Adressen).
Ich mache gerne "Wartungsvlans" mit Adressen aus 172.16.0.0/12, aber 
diese anzukündigen liegt mir fern, auch, wenn es praktisch wirken mag.

>
>>
>> Anders verhält es sich mit solchen Adressen, die dem AS eines Providers gehören, wie z.B.:
>> 86.59.13.172 (sil ip range) -> mh
>> 86.59.13.173 (sil ip range) -> mh
>> 86.59.13.174 (sil ip range) -> mh
> Das ist eine interessante Frage, ich würde hier unterscheiden, zwischen statischen Adressen, und echten dynamischen, z.B. von chello. Weil wenn ein Knotenbetreiber seine statischen Adressen so erreichbar machen will, ist das erstens eine Vertrauensentscheidung in das mesh-Netz, und zweitens leicht via WHOIS nachvollziehbar.
Im Prinzip würde ich Dir in diesem Fall zustimmen, muss Dich aber mit 
Deinen eigenen Argumenten konfrontieren:

Diese Ranges wurden a) vom jeweiligen AS-Inhaber nicht für Zweck einer 
zusätzlichen Ankündigung gegenüber unbeteiligten Dritten überlassen, und 
sie sind b) meines Erachtens gegenüber anderen Funkfeuer-Nutzern als ein 
Eingriff in fremdes Routing zu werten und daher weder vom PPA gedeckt, 
noch aus diesen Gründen netzneutral. Du wirst jetzt meinen, dass es sich 
ja nur um ein Wien-weites Netz ohne BGP-Announcement handelt. Ein Nutzer 
der Infrastruktur muss von dieser Manipulation aber nichts wissen.
Und spielen wir den Gedanken weiter: nicht auszudenken, wenn jemand in 
böswilliger Absicht IPs eines Bankinstitutes oder sonstiges ankündigt. 
Ein Router unter fremder Kontrolle reicht da wohl. Sicher, man kann den 
wahren Inhaber der IP ausfindig machen ... und den Betreiber des 
entfremdeten Routers auch ... wird das etwas bringen?
> Eine dynamische Adresse die automatisch angekündigt wäre vergleichbar, aber wenn die IRGENDWO via copy--n-paste in einer mesh-Router-Konfiguration landet, ist die bei einem allfälligen IP-Adressenwechsel für den nächsten Nutzer nicht mehr erreichbar. Das darf nicht sein. Damit sind dynamische Adressen riskant, und schwer nachzuvollziehen, wer jetzt dafür verantwortlich ist.
Wer soll das im Einzelnachprüfen?
>
> Im Vorstand könnten wir gerne nach Vorlage durch die Community eine Richtlinie daraus machen. Aber ich sehe hier halt durchaus Anwendungsfälle für solche Routen. Allerdings gibt es auch neue Gefahren, falls mal jemand 194.232.104.0/24, 173.194.0.0/16, 17.0.0.0/8 oder einen Ausschnitt daraus ankündigt. Und schon sind wir beim Thema RPKI.
Wir haben beide diese Gefahr skizziert. Wie überträgt man eine BPG-RPKI 
auf OLSR?
Ich denke, dass eine Einigung über die (Nicht-)nutzung erforderlich ist.
>
> Anregungen, freiwillige Meldungen usw. von RPKI-Interessenten bitte in der Diskussion ausloten. Hier wäre auch ein Ausblick auf die mit IPv6 allgegenwärtigen Link-Layer IP-Adressen sinnvoll, weil in IPv4 das inzwischen auch in vielen Netzen bereits gemacht wird.
Vielleicht darf ich Dich dazu einladen, RPKI-Überlegungen und 
diesbezügliche Probleme auf discuss -unter Zuhilfenahme des Wiki- zu 
skizzieren?
Vorerst würde ein Vorschlag zu einer Entscheidung in der Sache "fremde 
Ranges" schon genügen.
Sollte eine fremde Route plötzlich aufscheinen, kann man das in der 
Zwischenzeit sicherlich leichter handhaben, wenn die zulässigen Netze 
überschaubar sind (quasi eine Whitelist).
>
> bG
> Matthias
>
LG
Erich