[Discuss] [Wien] Fremde Netze

Do Nov 27 09:34:14 CET 2014

Da christoph lösch (= der knotenbetreiber der diese IPs announct) im whois
dieser IP steht, halte ich die diskussion darüber für absolut entbehrlich.

lg Markus

2014-11-27 3:01 GMT+01:00 Erich N. Pekarek <(spam-protected)>:

> 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
>
>
> --
> Discuss mailing list
> (spam-protected)
> https://lists.funkfeuer.at/mailman/listinfo/discuss
>
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.funkfeuer.at/pipermail/discuss/attachments/20141127/c330940a/attachment.htm>