Pfad - MTU - Entdeckung ( PMTUD ) ist eine Technik zur Bestimmung, in einem Computernetzwerk , die Größe der MTU auf dem Weg zwischen zwei IP - Hosts , um zu vermeiden , Paketfragmentierung . Es ist für ICMP durch RFC 1191 und für ICMPv6 durch RFC 8201 definiert.
Die IP-Fragmentierung beeinträchtigt in der Tat die Leistung von Routern und wirft auch Sicherheitsprobleme auf.
Die MTU-Erkennung für einen bestimmten Pfad funktioniert, indem das DF- Bit (Don't Fragment) des IP-Headers für alle ausgehenden Pakete gesetzt wird. Wenn auf dem von einem solchen Paket eingeschlagenen Pfad einer der gekreuzten Hosts eine MTU aufweist, die kleiner als die Paketgröße ist, wird das Paket verworfen und eine ICMP-Nachricht mit der MTU des Hosts, der es generiert, wird der Reihe nach gesendet die Quelle zu informieren. Diese Nachricht lautet:
Die Quelle passt dann die Größe des nächsten Pakets entsprechend der in der ICMP-Nachricht empfangenen MTU an. Der Vorgang wird wiederholt, bis die Quelle das Ziel erreicht.
Wenn sich die MTU des Pfads nach dem Herstellen der Verbindung ändert und festgestellt wird, dass sie kleiner als zuvor bestimmt ist, wird beim Senden des ersten zu großen Pakets auf dem Pfad eine neue ICMP-Nachricht gesendet, wodurch der PMTUD-Prozess neu gestartet wird. Ebenso kann die Quelle während der Verbindung den Pfad regelmäßig neu erklingen lassen, um herauszufinden, ob der Pfad jetzt eine größere MTU zulässt.
Obwohl selten, können diese Fälle durch Routenänderungen aufgrund dynamischer Routing-Protokolle oder durch menschliches Eingreifen in das Netzwerk verursacht werden.
Trotz seiner Nützlichkeit leidet PMTUd unter einer Reihe von Problemen, die hauptsächlich auf Sicherheitsbeschränkungen, manchmal aber auch auf die Auswirkungen auf die Leistung von Internetübertragungen zurückzuführen sind.
Bei vielen Geräten - wie Routern oder Firewalls - kann der gesamte oder ein Teil des ICMP-Datenverkehrs blockiert werden, entweder standardmäßig oder nach einer Entscheidung eines Administrators. Aufgrund der vielen vorhandenen Sicherheitslücken im Zusammenhang mit ICMP ist es mittlerweile weit verbreitet, ICMP als Ganzes als Sicherheitslücke zu betrachten, genau wie Telnet oder rsh . Das wahllose Filtern aller ICMP-Nachrichten kann jedoch zu schwerwiegenden Fehlfunktionen der Netzwerkinfrastruktur führen.
Wenn ICMP-Nachrichten vom Typ 3 / Code 4 gefiltert werden, schlägt die PMTUd fehl. Hosts, die versuchen, PMTUd auszuführen, senden weiterhin übergroße Pakete, die nicht weitergeleitet werden und für die keine Fehlermeldung die Quelle erreicht. Die Pakete sollen dann in ein "Schwarzes Loch" gesaugt werden.
Dieses Problem ist schwer zu lösen, da Ping oder Traceroute möglicherweise noch funktionieren, wenn die Filterung nur teilweise erfolgt. Ebenso können TCP-Verbindungen initiiert worden sein und funktionieren problemlos, solange keine großen Segmente gesendet werden (z. B. bei interaktiven Übertragungen). Das Hauptsymptom eines Schwarzen Lochs sind TCP-Verbindungen, die sehr lange nicht übertragen werden.
Das Thema wird seit vielen Jahren ausführlich diskutiert, insbesondere in RFC 1435 und RFC 2923. In den frühen 2000er Jahren wurde sogar mit Erfolg eine Initiative gestartet, um mehrere wichtige Websites, die als Schwarze Löcher fungieren, zur Korrektur dieses Verhaltens anzuregen.
Obwohl jedes Protokoll der Transportschicht von PMTUd profitieren kann, ist TCP aufgrund seiner Allgegenwart der erste Verbraucher und daher auch das Protokoll, das am meisten unter seinen Fehlfunktionen leidet. Um diese Tatsache zu veranschaulichen, widmet sich RFC 2923 mit dem Titel TCP-Probleme bei der Pfad-MTU- Erkennung ausschließlich den unglücklichen Interaktionen zwischen TCP und PMTUd.
Eines der wichtigen Themen ist beispielsweise die Beziehung zwischen MTU und MSS . Dieser letzte Parameter gibt bei einer TCP-Übertragung die maximale Segmentgröße an, die eine Quelle empfangen kann. Viele Systeme verlassen sich auf das Ergebnis der PMTUd, um den Wert der MSS zu bestimmen, die am anderen Ende der Verbindung angekündigt werden soll. Mehrere Studien haben jedoch gezeigt, dass asymmetrische Routen im Internet überwiegen, was eine unterschiedliche MTU zwischen dem Hin- und Rückweg für eine bestimmte Übertragung implizieren kann. Durch die Verwendung der PMTUd zur Bestimmung des angekündigten MSS wird somit eine suboptimale Leistung erzielt. Obwohl diese Methode keine RFCs verletzt, ist es vorzuziehen, die MTU der Systemschnittstellen als Grundlage für die MSS zu verwenden.
Weitere Beispiele und ausführlichere Erläuterungen finden Sie in RFC 2923.
Eine der verwendeten Lösungen besteht jedoch darin, die maximale Größe eines Segments so zu begrenzen, dass es kleiner als die von Ethernet ist (1500 Byte). Sie zwingen den Korrespondenten also, nur Segmente mit maximal 1500 Byte zu senden. Diese als MSS Clamping bezeichnete Technik vermeidet die Verwendung von PMTUd.
Das mit MSS Clamping verknüpfte Feld ist eine TCP- Option in einem SYN- Paket, wenn die Kommunikation zwischen zwei Peers initiiert wird.
Der RFC 1191 und der RFC 1981, die PMTUD für IPv4 bzw. IPv6 beschreiben, befassen sich aus Sicherheitsgründen mit mehreren möglichen Angriffen. Am schwerwiegendsten ist der Denial-of-Service mit geringem Volumen, bei dem sich der Angreifer als Empfänger einer legitimen Verbindung mit dem Opfer ausgibt. Der Angreifer sendet dann die ICMP-Nachrichten des Opfers, die den PMTUd-Prozess auslösen, was zu einer Reduzierung der Paketgröße auf die minimale MTU des Protokolls führt (68 Byte in IPv4, 1280 Byte in IPv6, einschließlich IP-Header und Daten). RFCs empfehlen, zehn Minuten zu warten, bevor eine PMTUd-Phase wiederholt wird, um die Paketgröße zu erhöhen. Der Angriff muss also nur alle zehn Minuten eine gefälschte ICMP-Nachricht an das Opfer senden.
Der Durchfluss wird sicherlich sehr stark reduziert, aber die wirklichen Auswirkungen sind anderswo. Um die gleiche Geschwindigkeit beizubehalten, muss das Opfer viele Pakete mit reduzierter Größe senden, was zu einem Sturm von Unterbrechungen an allen Geräten entlang der Übertragung und insbesondere am Opfer führt. Unter dem Einfluss der Überlastung reagiert die Maschine möglicherweise nicht mehr, insbesondere wenn der Angriff auf mehrere Verbindungen wiederholt wurde.
Im Jahr 2005 führte Fernando Gont mehrere Angriffe gegen TCP mithilfe von ICMP-Fehlermeldungen ein, darunter die oben beschriebene. Um dies zu beheben, schlägt er vor, PMTUd in zwei Teile zu unterteilen: Initial Path-MTU und Path-MTU Update. Es wird auch vorgeschlagen, TCP neue Statusvariablen hinzuzufügen: maxsizesent, die Größe des größten gesendeten Pakets, und maxsizeacked, die Größe des größten empfangenen Pakets.
Die Initial Path-MTU ist die Phase zu Beginn der Verbindung, in der TCP keine Kenntnis von der MTU hat. Das Pfad-MTU-Update ist die Phase während der Übertragung, in der TCP bereits Kenntnisse über die MTU hat und daher bei empfangenen ICMP-Nachrichten vorsichtiger sein muss. Beim Empfang einer ICMP-Nachricht, die normalerweise eine MTU-Anpassung beinhaltet, werden neue Überprüfungen eingeführt:
Die Anpassungszeit hängt davon ab, wie oft ein bestimmtes TCP-Segment das RTO (Retransmission Timeout) überschritten hat. Mehrere Segmente, die ohne Ergebnis erneut übertragen werden, sind in der Tat eine klassische Metrik, mit der TCP ein Problem bei der Übertragung erkennt.
Diese Lösung wird seit 2005 von NetBSD und OpenBSD implementiert .
Die PMTUd ist Teil der IETF-Standards . Ein Host, der ICMP korrekt implementiert, unterstützt PMTUd. Die verwendeten Zähler können jedoch von Betriebssystem zu Betriebssystem unterschiedlich sein.
Der RFC 1191 und der RFC 1981 forderten, dass PMTUD nicht weniger als 5 Minuten oder mehr als 1 Minute nach dem Empfang einer ICMP-Nachricht stattfinden sollte. Es wird empfohlen, diese Werte während der Implementierung mit zwei (dh 10 und 2 Minuten) multipliziert zu verwenden.
Linux und FreeBSD folgen dieser Empfehlung.