Summary

  • RFC 2979 unterschied eine beabsichtigte Sicherheitsverweigerung vom unbeabsichtigten Scheitern einer standardkonformen Nutzung; für Letzteres sollten Firewall und zugehörige Software einstehen.
  • Die Beispiele Path-MTU-Discovery-Fehler und SMTP-Erweiterungen zeigen, wie ein Vermittler eine Verbindung trotz scheinbar einfacher Regel unterbrechen konnte.

Eine Richtlinienentscheidung ist kein Protokollfehler

Um 2000 traf das Ende-zu-Ende-Ideal auf eine praktische Grenze. Organisationen verbanden wertvolle interne Systeme zunehmend mit Netzen, denen sie nicht vollständig vertrauten, und setzten Firewalls als Prüfstellen ein. Deren Verhalten war jedoch oft unzureichend spezifiziert und unterschied sich je nach Implementierung – mit Folgen, die über die beabsichtigte Sicherheitsrichtlinie hinausgingen.

RFC 2775 hatte „Transparenz“ bereits in mehrere Architekturfragen aufgeteilt: Ende-zu-Ende-Funktionen, Leistung und Adresstransparenz. RFC 2979 fasste die Frage als Betriebsvereinbarung. Die Einführung einer Firewall, eines Tunnels oder einer Zugangsaushandlung durfte eine legitime, standardkonforme Nutzung nicht unbeabsichtigt scheitern lassen, wenn sie ohne diese Einrichtung funktioniert hätte. Tritt der Fehler dennoch auf, sollten Firewall und Begleitsoftware behoben werden – nicht das bestehende Protokoll oder seine Implementierung.

Das verlangte nicht, jedes Paket durchzulassen. Eine Site durfte Zugriffe blockieren, die sie als unzulässig einstufte, selbst wenn sie einem Standard folgten. Zusätzliche Authentisierungs- und Autorisierungsverfahren wie SOCKS waren ebenfalls möglich und durften in bestimmten Konfigurationen verlangt werden; zugleich musste es Konfigurationen geben, in denen sie keine Voraussetzung für die Durchleitung waren. Entscheidend war die Trennung zwischen absichtlicher Ablehnung nach Richtlinie und versehentlichem Bruch durch einen Vermittler, der die Kommunikation nicht verstand.

Eine verworfene ICMP-Fehlermeldung konnte einen gültigen Pfad zum Black Hole machen

Das Beispiel der Path MTU Discovery machte die Regel konkret. Ein IPv4-Sender konnte das Don't-Fragment-Bit setzen. War ein späterer Link zu klein, sendete ein Router ICMP „Destination Unreachable / Fragmentation Needed“ zurück, damit der Sender seine Paketgröße reduzierte. Ließ die Firewall das ausgehende Paket passieren, verwarf aber die passende Antwort, konnte der Sender immer wieder zu große Pakete schicken: ein Black Hole statt einer sinnvollen Sicherheitsentscheidung.

RFC 2979 verlangte nicht, jedes ICMP zuzulassen. Er unterschied den Fehler als Antwort auf legitimen ausgehenden Verkehr von Echo-, Redirect- oder nicht zugehörigen Fehlermeldungen, die eine Site blockieren durfte. Der Kontext zählt: In derselben Protokollfamilie gibt es Steuerinformationen, die für einen gültigen Austausch nötig sind, und Verkehr, den eine Richtlinie ablehnen kann.

SMTP-Erweiterungen konnten eine Dreiecks-Inkompatibilität erzeugen

Bei SMTP fragt der Client per EHLO nach Erweiterungen, der Server kündigt unterstützte Funktionen an, und der Client kann eine davon wählen. Ein Proxy, der EHLO nur in seine Befehlsfreigabe aufnahm, aber die Serverantwort nicht filterte, konnte Client und Server eine Erweiterung vereinbaren lassen, die der Proxy selbst nicht verstand. Beide Endpunkte konnten plausibel handeln – doch der Vermittler hatte einen Austausch zugelassen, den er nicht korrekt weiterleiten konnte.

Die Lehre war nicht, dass jede Firewall jede neue Erweiterung implementieren müsse. RFC 2979 empfahl, Anwendungsprotokolle firewallfreundlich zu gestalten, sofern dies der Anwendung nicht schadete. Er warnte davor, ein neues Protokoll nur deshalb in HTTP einzuschließen, weil Port 80 wahrscheinlich offen war. Ein sicherer Teilumfang, ein geeigneter Traversierungsmechanismus oder ein separat registrierter Port konnten die ehrlichere Wahl sein.

Was der RFC belegt – und was offenbleibt

RFC 2979 ist ein Informational-Memo, kein Internetstandard. Die Entwurfshistorie hält eine IESG-Genehmigung im August 2000 und die Veröffentlichung im Oktober fest. Sie belegt ein dokumentiertes Gestaltungsprinzip und Beispiele, aber weder Produktverbreitung noch Konformitätsraten, weniger Umgehungsversuche oder messbare Sicherheitsverbesserungen.

Der historische Beitrag war eine Verantwortungsgrenze: Sicherheitspolitik darf einen Datenstrom zurückweisen, aber ein versehentlicher Kompatibilitätsbruch soll nicht stillschweigend zur Pflicht der Anwendungsentwickler werden, ihn zu umgehen. Ein Betreiber kann einen Fehler danach einordnen: War die Ablehnung beabsichtigt, oder hat ein Filter, Proxy oder Parser standardkonformes Verhalten beschädigt? Diese Diagnose ist eine heutige Ableitung, keine Messung damaliger Betriebspraxis.

RFC 3093 ist ein benachbartes, aber anderes Dokument. Das Informational RFC vom 1. April 2001 schlug das Firewall Enhancement Protocol vor, das IP/TCP in HTTP kapseln sollte. Es belegt weder ein Scheitern von RFC 2979 noch den Einsatz des Tunnels. Auch Firewall-Filterung ist nicht mit NAT gleichzusetzen: RFC 2979 trennt die Funktionen ausdrücklich, selbst wenn ein Gerät beides leistet.

Quellen: RFC 2979; RFC 2775; RFC 3093; Entwurfshistorie; RFC 1191; RFC 1869.