Private IPv4-Adressen im Internet?

[Marco Moock]

Hallo NG,

mir ist heute durch Zufall aufgefallen, dass private IPv4-Adressen
scheinbar von manchen Providern doch durch das Internet geroutet und
nicht wie eigentlich erwartet von einem Provider verworfen werden.

m@ryz:~$ traceroute khv.swl.su
traceroute to proxy.swl.su (80.87.193.248), 64 hops max
1 10.0.0.254 0,908ms 0,762ms 0,701ms #eigener Router mit NAT
2 192.168.17.1 6,952ms 6,924ms 7,389ms #Router beim Provider ohne NAT
3 85.208.244.5 7,853ms 9,254ms 8,053ms
4 80.81.192.94 45,945ms 45,450ms 46,872ms
5 217.67.176.54 59,535ms 50,121ms 49,207ms
6 83.69.219.34 47,440ms 47,505ms 46,395ms
7 172.17.23.57 48,345ms 46,363ms 48,202ms
8 172.17.23.97 48,113ms 55,291ms 47,253ms
9 172.31.141.16 47,239ms 46,411ms 56,238ms
10 * * *

Der 2. Eintrag ist der Router vom Provider. Der macht zwar kein CG-NAT
(ich habe eine öffentliche IPv4-Adresse), aber die
ICMP-Antwort kommt von einer privaten Adresse. Ich vermute, dass der
Provider private Netze als Transportnetze in seinem Netz nutzt, um
Netze zu sparen. Dass das bei ihm intern durchgeht, ist klar.

Was mich aber wundert, sind die Einträge 7, 8 und 9.
Diese gehen definitiv über mehrere Netze hinweg und werden von den
Provider akzeptiert, obwohl es private Adressen aus dem Bereich
172.16.0.0/12 sind, wie sie in RFC1819 beschrieben sind.

Von mir dort hin geht natürlich keine Verbindung (so soll es ja sein),
mache ich ein traceroute ist der Provider-Router der, der zuletzt eine
Antwort schickt)

Warum werden diese Pakete nicht von den Providern verworfen, sondern
in andere AS geroutet?

Gruß
Marco

[Juergen Ilse]

Hallo,

Marco Moock <mo...@posteo.de> wrote:
> mir ist heute durch Zufall aufgefallen, dass private IPv4-Adressen
> scheinbar von manchen Providern doch durch das Internet geroutet und
> nicht wie eigentlich erwartet von einem Provider verworfen werden.
>
> m@ryz:~$ traceroute khv.swl.su
> traceroute to proxy.swl.su (80.87.193.248), 64 hops max
> 1 10.0.0.254 0,908ms 0,762ms 0,701ms #eigener Router mit NAT
> 2 192.168.17.1 6,952ms 6,924ms 7,389ms #Router beim Provider ohne NAT
> 3 85.208.244.5 7,853ms 9,254ms 8,053ms
> 4 80.81.192.94 45,945ms 45,450ms 46,872ms
> 5 217.67.176.54 59,535ms 50,121ms 49,207ms
> 6 83.69.219.34 47,440ms 47,505ms 46,395ms
> 7 172.17.23.57 48,345ms 46,363ms 48,202ms
> 8 172.17.23.97 48,113ms 55,291ms 47,253ms
> 9 172.31.141.16 47,239ms 46,411ms 56,238ms
> 10 * * *
>
> Der 2. Eintrag ist der Router vom Provider. Der macht zwar kein CG-NAT
> (ich habe eine öffentliche IPv4-Adresse), aber die
> ICMP-Antwort kommt von einer privaten Adresse.

Die Antwort kommt da von der deinem Router zugewandten Interface-Adresse.
Das bedeutet aber nicht, dass die Adresse im Internet geroutet wird.

Selbiges fuer die Eintraege 7 und 8 (wobei selbst solche Adressen aus
den Netzen anderer Provider auftauchen koennten, auch wenn das eine
haessliche Moelichkeit waere). Das heisst dann aber noch immer nicht,
dass die Adressen im Internet geroutet werdeen, denn Routing basiert
auf den *ZIELADRESSEN", und die Zieladdressen der ICMP-Fehlermeldungen
(die letztlich von traceroute hier ausgewertet werden) ist ja jeweils
*deine* *public* IP-Adresse ...

> Ich vermute, dass der Provider private Netze als Transportnetze in
> seinem Netz nutzt, um Netze zu sparen.

Was spricht dagegen?

> Dass das bei ihm intern durchgeht, ist klar.
> Was mich aber wundert, sind die Einträge 7, 8 und 9.

OOPS! Da hatte ich doch glatt versehentlich eine uebersehen ...

> Diese gehen definitiv über mehrere Netze hinweg und werden von den
> Provider akzeptiert, obwohl es private Adressen aus dem Bereich
> 172.16.0.0/12 sind, wie sie in RFC1819 beschrieben sind.

Als *QUELLADRESSE* ja, aber Routing passiert normalerweise basierend
aauf der *ZIELADRESSE* der Pakete, und die Zieladresse der ICMP-Antwort,
die von traceroute ausgewertet wird, ist die *public* IP deines NAT-
Routers.

> Warum werden diese Pakete nicht von den Providern verworfen, sondern
> in andere AS geroutet?

Weil auf der internen Infrastruktur des Providers die route bekannt ist,
und die anderen Provider auf ihren Backbones vielleicht (u.a. aus Per-
formancegruenden) keine Filterung durchfuehren, und somit RFC1918-Adressen
als Quell-Adressen im Backbone *nicht* ausfiltern.

So etwas muss nicht *immer* durchgehen, ber wenn es durchgeht, liegt es
an dem oben genannten.

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Marco Moock]

Am Mittwoch, 29. Dezember 2021, um 14:27:45 Uhr schrieb Juergen Ilse:

> > Ich vermute, dass der Provider private Netze als Transportnetze in
> > seinem Netz nutzt, um Netze zu sparen.
>
> Was spricht dagegen?

Es ist ungewöhnlich und ursprünglich nicht so gedacht gewesen, aus
heutiger Sicht aber klar nachvollziehbar.

> > Dass das bei ihm intern durchgeht, ist klar.
> > Was mich aber wundert, sind die Einträge 7, 8 und 9.
>
> OOPS! Da hatte ich doch glatt versehentlich eine uebersehen ...
>
> > Diese gehen definitiv über mehrere Netze hinweg und werden von den
> > Provider akzeptiert, obwohl es private Adressen aus dem Bereich
> > 172.16.0.0/12 sind, wie sie in RFC1819 beschrieben sind.
>
> Als *QUELLADRESSE* ja, aber Routing passiert normalerweise basierend
> aauf der *ZIELADRESSE* der Pakete, und die Zieladresse der
> ICMP-Antwort, die von traceroute ausgewertet wird, ist die *public*
> IP deines NAT- Routers.

Darauf, dass das Routing im Normalfall anhand der Quell-Adresse
abläuft, hätte ich selbst kommen sollen.

> > Warum werden diese Pakete nicht von den Providern verworfen, sondern
> > in andere AS geroutet?
>
> Weil auf der internen Infrastruktur des Providers die route bekannt
> ist, und die anderen Provider auf ihren Backbones vielleicht (u.a.
> aus Per- formancegruenden) keine Filterung durchfuehren, und somit
> RFC1918-Adressen als Quell-Adressen im Backbone *nicht* ausfiltern.

Und genau das wundert mich, denn das macht der Provider doch sicherlich
auch bei anderen Netzen, um IP-Spoofing zu verhindern. Eigentlich würde
hier eine Whitelist ausreichen. Diese beinhaltet nur die Netze des
Kunden und für IPv6 noch link-local und Multicast (für NDP).

[Marc Haber]

Marco Moock <mo...@posteo.de> wrote:
>Am Mittwoch, 29. Dezember 2021, um 14:27:45 Uhr schrieb Juergen Ilse:
>> Als *QUELLADRESSE* ja, aber Routing passiert normalerweise basierend
>> aauf der *ZIELADRESSE* der Pakete, und die Zieladresse der
>> ICMP-Antwort, die von traceroute ausgewertet wird, ist die *public*
>> IP deines NAT- Routers.
>
>Darauf, dass das Routing im Normalfall anhand der Quell-Adresse
>abläuft, hätte ich selbst kommen sollen.

Hast Du das jetzt absichtlich mißverstanden oder hat Jürgen Dich
verwirrt?

>> Weil auf der internen Infrastruktur des Providers die route bekannt
>> ist, und die anderen Provider auf ihren Backbones vielleicht (u.a.
>> aus Per- formancegruenden) keine Filterung durchfuehren, und somit
>> RFC1918-Adressen als Quell-Adressen im Backbone *nicht* ausfiltern.
>
>Und genau das wundert mich, denn das macht der Provider doch sicherlich
>auch bei anderen Netzen, um IP-Spoofing zu verhindern. Eigentlich würde
>hier eine Whitelist ausreichen. Diese beinhaltet nur die Netze des
>Kunden und für IPv6 noch link-local und Multicast (für NDP).

Dass die Router eines anderen Providers Dir ICMP-Fehlemeldungen¹ mit
iher lokalen Interfaceadresse schicken können bedeutet nicht dass Du
sie eindeutig adressieren kannst. Das musst Du ja auch nicht.

Ob man als ISP solche eingehenen Pakete filtern möchte, dürfte
diskutierba sein. Filtert man sie aus, haben Traceroutes an dieser
Stelle drei Reihen mit Sternen, da werden halbwissende Kunden genauso
Trouble Tickets für aufmachen wie für die site local addresses hier.

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[Juergen Ilse]

Hallo,

Marco Moock <mo...@posteo.de> wrote:

"reverse path filtering" ist auf den Links zum Endkunden ueblich, aber
im Backbone waere das ein ziemlich sicheres Mittel, in Probleme zu kommen.
Symmetrisches Routing mag in der Erfahrung eines typischen Endkunden oder
LAN-Betreibers als der Normalfall erscheinen, generell im Internet ist es
eher der Ausnahmefall. Und filtern anhand der Quelladresse kostet Resourcen,
das moechte man tunlichst *nicht* auf Backbone-Routern haben.

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Marco Moock]

Am Mittwoch, 29. Dezember 2021, um 19:48:17 Uhr schrieb Marc Haber:

> >Darauf, dass das Routing im Normalfall anhand der Quell-Adresse
> >abläuft, hätte ich selbst kommen sollen.
>
> Hast Du das jetzt absichtlich mißverstanden oder hat Jürgen Dich
> verwirrt?

Eigentlich wusste ich das, ich hatte es aber beim Schreibens des
Textes nicht auf dem Schirm und habe daher den Text etwas blöd
formuliert.

> Dass die Router eines anderen Providers Dir ICMP-Fehlemeldungen¹ mit
> iher lokalen Interfaceadresse schicken können bedeutet nicht dass Du
> sie eindeutig adressieren kannst. Das musst Du ja auch nicht.
>
> Ob man als ISP solche eingehenen Pakete filtern möchte, dürfte
> diskutierba sein. Filtert man sie aus, haben Traceroutes an dieser
> Stelle drei Reihen mit Sternen, da werden halbwissende Kunden genauso
> Trouble Tickets für aufmachen wie für die site local addresses hier.

Dann ist das aber nicht das Problem meines Providers und genau das
würde ich als Provider meinem Kunden mitteilen. Wenn im AS des Ziels
der traceroute eine FW steht, die ICMP droppt kommen bei mir diese
Pakete auch nicht an, auch nicht das Problem meines Providers.

RF1918-Adressen sind eigentlich nicht für die globale Kommunikation
gedacht, daher wäre ein Filtern dieser meines Erachtens völlig normal
und auch angebracht, denn antworten wäre aufgrund der RF1918-Adresse
nicht möglich.

--
Marco

[Marco Moock]

Am Mittwoch, 29. Dezember 2021, um 19:24:44 Uhr schrieb Juergen Ilse:

> "reverse path filtering" ist auf den Links zum Endkunden ueblich, aber
> im Backbone waere das ein ziemlich sicheres Mittel, in Probleme zu
> kommen.

Was wären das für Probleme?
An allen eingehenden interfaces aus anderen autonomen Systemen werden
private Adressen (egal ob Ziel oder Quelle) rausgefiltert. Klar würde
das die Latenz erhöhen, aber würde es sonst noch Probleme bereiten?

[Juergen Ilse]

Hallo,

Marco Moock <mo...@posteo.de> wrote:

> RF1918-Adressen sind eigentlich nicht für die globale Kommunikation
> gedacht, daher wäre ein Filtern dieser meines Erachtens völlig normal
> und auch angebracht, denn antworten wäre aufgrund der RF1918-Adresse
> nicht möglich.

Das was bei dir an an ICMP Fehlermeldungen ankommt, hat als Source zwar
eine RFC1918-Adresse, aber es ist nicht sinnvoll, auf so etwas zu aant-
worten. Also wo ist das Problem?

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Marco Moock]

Am Mittwoch, 29. Dezember 2021, um 22:08:10 Uhr schrieb Juergen Ilse:

> Das was bei dir an an ICMP Fehlermeldungen ankommt, hat als Source
> zwar eine RFC1918-Adresse, aber es ist nicht sinnvoll, auf so etwas
> zu aant- worten. Also wo ist das Problem?

Es gibt kein wirkliches "Problem", es ist nur ungewöhnlich, daher
habe ich den Thread aufgemacht.
traceroute nutzt ja nur ICMP um den Weg herauszufinden, eigentlich auch
nicht Ziel von ICMP gewesen.

[Juergen Ilse]

Hallo,

Marco Moock <mo...@posteo.de> wrote:

> Am Mittwoch, 29. Dezember 2021, um 19:24:44 Uhr schrieb Juergen Ilse:
>
>> "reverse path filtering" ist auf den Links zum Endkunden ueblich, aber
>> im Backbone waere das ein ziemlich sicheres Mittel, in Probleme zu
>> kommen.
>
> Was wären das für Probleme?

Zwischen verschiedenen Providern ist "symmetrisches Routing" eher der
Ausnahmefall als der Normalfall. Wenn man also zu einer bestimmten
Zieladdresse eine Route ueber den einen Uplink hat, koennen die Ant-
worten von dieser IP-Adresse ueber einen anderen Uplinkk wieder herein-
kommen. Wuerde man dann "reverse path filtering" im Backbone betreiben,
wuerden diese Antwortpakete abgelehnt, weil sie "ueber den falschen
Link" eintreffen. "reverse path filtering" heisst, akzeptiere Pakete
von einer bestimmten IP-Adresse auf einem Interface nur dann, wenn
du auch selbst Pakete an diese IP-Adresse ueber dieses Interface routen
wuerdest. Das funktioniert und verhindert IP-Spoofing, solange man nur
symmetrisches Routing hat. Auf redundanten Anbindungen muss das schon
nicht mehr unbedingt zutreffwen. Im globalen Routing ist so etwas sogar
eher der Ausnahmefall. "reverse path filtering" kostet auf vielen
Routern deutlich weniger Leistung als "normaales Filtern nach Adressen",
weil es auf vielen Geraeten hardwareunterstuetzt ist.

> An allen eingehenden interfaces aus anderen autonomen Systemen werden
> private Adressen (egal ob Ziel oder Quelle) rausgefiltert.

Das wird nicht unbedingt gemacht, denn der ISP sollte RFC1918-Adressen
erst gar nicht ins BAckbone, sprich bis zur Verbindung zu anderen Pro-
vidern hineinlassen. Wenn i.d.R. RFC1918-Adressen gar nicht ins Back-
bone hineingelangen, muss man sie im Backbone auch nicht filtern. Wenn
aber RFC1918-Adressen irgendwo als "Transfernetzadressen" in der ISP-
Infrastruktur verwendet werden, koennen sie durchaus mal als *Quell-
Adressen* auftauchen. Was die Provider allerdings (sinvollerweise)
immer tun, ist das ausfiltern von Routen fuer RFC1918-Adressen und
anderer fuer Sonderzwecke reservierter Adressen im BGP. so dass die
Router sich weigern, Routing-Informationen fuer solche Adressen von
anderen Providern zu lernen.

> Klar würde das die Latenz erhöhen, aber würde es sonst noch Probleme
> bereiten?

Spielt das eine Rolle? Es kostet Leistung und es ist unnoetig (bis auf
"kosmetische Unterschiede"), also welchen Grund sollte es fuer das filtern
von RFC1918-Adressen als Quelladressen geben? Man kann es machen, aber
zwingende Gruende gibt es dafuer nicht.

Tschuess,
Juergen Ilse (juergenqusenet-verwaltung.de)

[Marc Haber]

Marco Moock <mo...@posteo.de> wrote:
>Am Mittwoch, 29. Dezember 2021, um 19:48:17 Uhr schrieb Marc Haber:
>
>> >Darauf, dass das Routing im Normalfall anhand der Quell-Adresse
>> >abläuft, hätte ich selbst kommen sollen.
>>
>> Hast Du das jetzt absichtlich mißverstanden oder hat Jürgen Dich
>> verwirrt?
>
>Eigentlich wusste ich das, ich hatte es aber beim Schreibens des
>Textes nicht auf dem Schirm und habe daher den Text etwas blöd
>formuliert.

Ich sage es nochmal: Routing im Normalfall erfolgt anhand der
ZIEL-Adresse.

>Dann ist das aber nicht das Problem meines Providers und genau das
>würde ich als Provider meinem Kunden mitteilen. Wenn im AS des Ziels
>der traceroute eine FW steht, die ICMP droppt kommen bei mir diese
>Pakete auch nicht an, auch nicht das Problem meines Providers.

In dieser Pauschalität ICMP zu droppen ist "ich mache mutwillig das
Internet kaputt". Das macht zum Glück heute kein Provider mehr.

[Marc Haber]

Marco Moock <mo...@posteo.de> wrote:
>traceroute nutzt ja nur ICMP um den Weg herauszufinden, eigentlich auch
>nicht Ziel von ICMP gewesen.

Wirr ist dieser Satz.

[Marc Haber]

Marco Moock <mo...@posteo.de> wrote:
>An allen eingehenden interfaces aus anderen autonomen Systemen werden
>private Adressen (egal ob Ziel oder Quelle) rausgefiltert.

Warum sollte man das tun? Bei Quelladressen tut es nicht weh (kann
halt nicht beantwortet werden, mei), Zieladressen sollten gar nicht
erst ankommen, weil man die site local Adressen ja nicht announced.

[Bonita Montero]

Am 29.12.2021 um 20:53 schrieb Marco Moock:

> RF1918-Adressen sind eigentlich nicht für die globale Kommunikation
> gedacht, daher wäre ein Filtern dieser meines Erachtens völlig normal
> und auch angebracht, denn antworten wäre aufgrund der RF1918-Adresse
> nicht möglich.

Es findet ja in deinem Fall auch keine Kommunikation mit diesen Adressen
statt. Das was _in_ den ICMP-Antworten steht kann beliebig sein.

[Marco Moock]

Am Donnerstag, 30. Dezember 2021, um 13:24:19 Uhr schrieb Marc Haber:

> In dieser Pauschalität ICMP zu droppen ist "ich mache mutwillig das
> Internet kaputt". Das macht zum Glück heute kein Provider mehr.

Hat das denn mal ein Provider gemacht?
Ich kenne das nur von Firewalls in Firmen und Schulen, wo man aus
"Sicherheitsgründen" (die mir bis heute keiner erläutern konnte) ICMP
blockiert hat.

[Marc Haber]

Marco Moock <mo...@posteo.de> wrote:
>Am Donnerstag, 30. Dezember 2021, um 13:24:19 Uhr schrieb Marc Haber:
>> In dieser Pauschalität ICMP zu droppen ist "ich mache mutwillig das
>> Internet kaputt". Das macht zum Glück heute kein Provider mehr.
>
>Hat das denn mal ein Provider gemacht?

Bestimmt. Hab ich aber verdrängt. Ich weiß noch, dass Ebay und Yahoo
beim Aufkommen von PPPoE-DSL durchaus problematisch waren, dass man
wegen der durch die kaputtgegangene PMTU-Discovery verursachten
Probleme die MSS Size herabgesetzt hat und dass die Vertriebler meines
damaligen Arbeitgebers das hauseigene SDSL damit beworben haben, dass
Ebay und Yahoo ohne Klimmzüge funktionieren.

War eine finstere Zeit, die meisten Firewalladmins haben das
inzwischen gelernt.

Die "Sicherheitsgründe" entstanden z.B. aus dem ping of death oder der
Attack Amplification durch Broadcast-Pings.

[Juergen Ilse]

Hallo,

Marco Moock <mo...@posteo.de> wrote:

Ob traceroute icmp oder udp verwendet, haengt wohl von der Implementierung
ab, die ausgewerteten Antworten der "Hops" sind allerdings tatsaechlich
immer ICMP. Wenn du traceroutes interpretierst, ist dir hoffentlich klar,
das du nur "den Hinweg" siehst, auf welchem Weg Pakete vom Ziel zurueck
zu dir kommen, darueber sagt traceroute nicht unbedingt etwas aus.

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Juergen Ilse]

Hallo,

Marc Haber <mh+usene...@zugschl.us> wrote:
> Marco Moock <mo...@posteo.de> wrote:
>>Am Mittwoch, 29. Dezember 2021, um 19:48:17 Uhr schrieb Marc Haber:
>>
>>> >Darauf, dass das Routing im Normalfall anhand der Quell-Adresse
>>> >abläuft, hätte ich selbst kommen sollen.
>>>
>>> Hast Du das jetzt absichtlich mißverstanden oder hat Jürgen Dich
>>> verwirrt?
>>
>>Eigentlich wusste ich das, ich hatte es aber beim Schreibens des
>>Textes nicht auf dem Schirm und habe daher den Text etwas blöd
>>formuliert.
>
> Ich sage es nochmal: Routing im Normalfall erfolgt anhand der
> ZIEL-Adresse.
>
>>Dann ist das aber nicht das Problem meines Providers und genau das
>>würde ich als Provider meinem Kunden mitteilen. Wenn im AS des Ziels
>>der traceroute eine FW steht, die ICMP droppt kommen bei mir diese
>>Pakete auch nicht an, auch nicht das Problem meines Providers.
>
> In dieser Pauschalität ICMP zu droppen ist "ich mache mutwillig das
> Internet kaputt". Das macht zum Glück heute kein Provider mehr.

Das "ICMP ist boese und muss gedropped werden" war der Grund, warum
es damals bei aufkommen von DSL (und damit PPPoE) zuerst Probleme
gab, einige Server direkt zu erreichen (es aber ueber den Prox des
Providers funktionierte). Das Problem war das (damals bereits uebliche)
PMTUD in Zusammenhang mit und unangebrachter ICMP-Filterung in der
Firewall vor dem Server. Als Workaround fuer TCP Kommunikation hat
sich dann "TCP MSS Clamping" etabliert, aber fuer andere IP-Protokolle
ist das keine Loesung. Wer ICMP filtert, sollte *sehr* genau wissen
was er tut, um nicht wichtige Netzwerkkommunikation zu sabotieren.

Ich hatte mal als Workaround fuer per PPPoE angebundene Kunden den
Router so konfiguriert, dass er bei "zu grossen" Paketen in Kunden-
richtung mit gesetztem DF-Bit vor der Verarbeitung das DF-Bit ge-
loescht hat. Keine schoene Loesung, aber fuer solche Faelle ein
moegloicher Workaround (der allerdings den Router ggfs. hoeher
belastet).

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Marco Moock]

Am Donnerstag, 30. Dezember 2021, um 16:43:18 Uhr schrieb Juergen Ilse:

> Ob traceroute icmp oder udp verwendet, haengt wohl von der
> Implementierung ab, die ausgewerteten Antworten der "Hops" sind
> allerdings tatsaechlich immer ICMP. Wenn du traceroutes
> interpretierst, ist dir hoffentlich klar, das du nur "den Hinweg"
> siehst, auf welchem Weg Pakete vom Ziel zurueck zu dir kommen,
> darueber sagt traceroute nicht unbedingt etwas aus.

Ob IMCP, UDP oder gar TCP hängt von der Implementierung ab, ändert aber
im Normalfall nichts an den Antworten. Ist aber hilfreich, wenn man
Firewall im Weg hat, die bestimmte Protokolle blockieren.
Und ja, mit ist klar, dass hier nur der Hinweg gezeigt wird, denn die
Router antworten ja mit ICMP TTL exceeded.

[Marco Moock]

Am Donnerstag, 30. Dezember 2021, um 16:54:56 Uhr schrieb Juergen Ilse:

> Das "ICMP ist boese und muss gedropped werden" war der Grund, warum
> es damals bei aufkommen von DSL (und damit PPPoE) zuerst Probleme
> gab, einige Server direkt zu erreichen (es aber ueber den Prox des
> Providers funktionierte). Das Problem war das (damals bereits
> uebliche) PMTUD in Zusammenhang mit und unangebrachter ICMP-Filterung
> in der Firewall vor dem Server. Als Workaround fuer TCP Kommunikation
> hat sich dann "TCP MSS Clamping" etabliert, aber fuer andere
> IP-Protokolle ist das keine Loesung. Wer ICMP filtert, sollte *sehr*
> genau wissen was er tut, um nicht wichtige Netzwerkkommunikation zu
> sabotieren.

Ich mache bei mir z.B. absichtlich kein MSS-Clamping, einige wenige
Seiten sind von betroffen, aber mich interessiert das nicht.

> Ich hatte mal als Workaround fuer per PPPoE angebundene Kunden den
> Router so konfiguriert, dass er bei "zu grossen" Paketen in Kunden-
> richtung mit gesetztem DF-Bit vor der Verarbeitung das DF-Bit ge-
> loescht hat. Keine schoene Loesung, aber fuer solche Faelle ein
> moegloicher Workaround (der allerdings den Router ggfs. hoeher
> belastet).

Kann man machen, aber wieder andere Geräte haben dann nicht die
Fähigkeit, fragmentierte Pakete zu verarbeiten (FB 7170 für VoIP). Bei
IPv6 fällt dies zudem weg, da hier kein Router unterwegs fragmentiert,
sondern nur der Absender, der per ICMPv6 benachrichtigt werden muss.

Da hatten wir geschäftlich auch ein VPN, wo anfangs ICMPv6 blockiert
war (nun nicht mehr), das machte da logischerweise auch Probleme.
Dabei sollte man eben nur die Typen filtern, die man nicht haben will
(z.B. Router-Advertisements).

[Juergen Ilse]

Hallo,

Marco Moock <mo...@posteo.de> wrote:

> Am Donnerstag, 30. Dezember 2021, um 16:54:56 Uhr schrieb Juergen Ilse:
>
>> Das "ICMP ist boese und muss gedropped werden" war der Grund, warum
>> es damals bei aufkommen von DSL (und damit PPPoE) zuerst Probleme
>> gab, einige Server direkt zu erreichen (es aber ueber den Prox des
>> Providers funktionierte). Das Problem war das (damals bereits
>> uebliche) PMTUD in Zusammenhang mit und unangebrachter ICMP-Filterung
>> in der Firewall vor dem Server. Als Workaround fuer TCP Kommunikation
>> hat sich dann "TCP MSS Clamping" etabliert, aber fuer andere
>> IP-Protokolle ist das keine Loesung. Wer ICMP filtert, sollte *sehr*
>> genau wissen was er tut, um nicht wichtige Netzwerkkommunikation zu
>> sabotieren.
>
> Ich mache bei mir z.B. absichtlich kein MSS-Clamping, einige wenige
> Seiten sind von betroffen, aber mich interessiert das nicht.
>
>> Ich hatte mal als Workaround fuer per PPPoE angebundene Kunden den
>> Router so konfiguriert, dass er bei "zu grossen" Paketen in Kunden-
>> richtung mit gesetztem DF-Bit vor der Verarbeitung das DF-Bit ge-
>> loescht hat. Keine schoene Loesung, aber fuer solche Faelle ein
>> moegloicher Workaround (der allerdings den Router ggfs. hoeher
>> belastet).
>
> Kann man machen, aber wieder andere Geräte haben dann nicht die
> Fähigkeit, fragmentierte Pakete zu verarbeiten (FB 7170 für VoIP).

Bei VOIP werden i.d.R. bewusst *kleine* Pakete verwendet. Die "route-map"
loeschte das DF-Bit aber nur, wenn die Link-MTU zum Endkunden ueber-
schitten wurde, sprich bei VOIP waeren die Pakete unveraendert durchgegangen.

> Bei IPv6 fällt dies zudem weg, da hier kein Router unterwegs fragmentiert,
> sondern nur der Absender, der per ICMPv6 benachrichtigt werden muss.

Das ist mir duchaus bewusst, dass PMTUD bei IPv6 *immer* stattfindet und
damit *alle* Pakete wie bei IPv4 mit gesetztem DF-Bit behandelt werden.
Das ist der Grund, weshalb es bei IPv6 auch gar kein DF-Bit mehr gibt
(alle Pakete wwerden so behandelt, als haetten sie ein gesetztes DF-Bit).

> Da hatten wir geschäftlich auch ein VPN, wo anfangs ICMPv6 blockiert
> war (nun nicht mehr),

ICMP6 komplett zu blockieren ist eine relativ sichere Methode, die IPv6
Kommunikation komplett zu unterdruecken. ICMP6 auf dem lokalen Host selbst
komplett zu unterdruecken (ohne zu wissen, was man tunlichst nicht filtern
sollte) sorgt dafuer, dass der Host noch nicht einmal mehr im Netz bekannt
oder gar erreichbar ist (weil selbst das "neighbor discovery" auf ICMP6
basiert, und ohne neighbor discover gibt es keine IPv6 Kommunikation).

> Dabei sollte man eben nur die Typen filtern, die man nicht haben will
> (z.B. Router-Advertisements).

Dabei ist ein entsprechender Switch, der das am Switchport ausfiltert
sehr hilfreich (ja das gibt es, allerdings nicht im "billig unmanged"
Segment).

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)

[Marc Haber]

Juergen Ilse <ne...@usenet-verwaltung.de> wrote:
>ICMP6 komplett zu blockieren ist eine relativ sichere Methode, die IPv6
>Kommunikation komplett zu unterdruecken. ICMP6 auf dem lokalen Host selbst
>komplett zu unterdruecken (ohne zu wissen, was man tunlichst nicht filtern
>sollte) sorgt dafuer, dass der Host noch nicht einmal mehr im Netz bekannt
>oder gar erreichbar ist (weil selbst das "neighbor discovery" auf ICMP6
>basiert, und ohne neighbor discover gibt es keine IPv6 Kommunikation).

Bei Peer-To-Peer-Links oder Links mit nur zwei Teilnehmern braucht man
nicht notwendigerweise NDP.

Nicht alles ist Ethernet.