Zusammenfassung

  • RFC 793 akzeptierte in synchronisierten Zuständen einen RST innerhalb des Empfangsfensters; RFC 5961 beschränkt den sofortigen Reset auf die exakte Übereinstimmung mit RCV.NXT.
  • Ein im Fenster liegender, aber nicht exakter RST erhält eine Challenge ACK und wird verworfen. Der echte Peer kann seinen Zustand bestätigen, ein blinder Absender sieht die Frage gewöhnlich nicht.

Der Fehler lag in einer doppelten Bedeutung des Empfangsfensters. Es sollte entscheiden, ob Bytes zum Datenstrom gehören könnten. Nach der ursprünglichen Regel von RFC 793 beantwortete dasselbe Kriterium bei gesetztem RST-Bit aber auch eine folgenreichere Frage: Darf der gesamte Verbindungszustand verschwinden? Ein Angreifer außerhalb des Pfades musste den Verkehr nicht sehen. Er konnte Sequenznummern ausprobieren, bis eine davon in das Fenster fiel.

RFC 5961 fügte 2010 keine Kryptografie hinzu, sondern ordnete die Entscheidung neu. Ein RST außerhalb des Fensters wird weiterhin still verworfen. Entspricht seine Sequenznummer exakt dem nächsten erwarteten Byte RCV.NXT, wird die Verbindung zurückgesetzt. Liegt er nur irgendwo im Fenster, sendet der Empfänger eine Bestätigung mit SEQ=SND.NXT und ACK=RCV.NXT, verwirft das verdächtige Segment und verarbeitet spätere Pakete normal weiter.

Diese Antwort heißt Challenge ACK, weil sie eine Behauptung in eine Zustandsfrage verwandelt. Hat der entfernte Endpunkt tatsächlich geschlossen oder neu gestartet und besitzt den alten Kontrollblock nicht mehr, kann der empfangene ACK einen neuen RST auslösen, dessen Nummer aus der Bestätigung abgeleitet ist. Dieser zweite RST kann den erwarteten Wert exakt treffen. Der blinde Injektor beobachtet die Herausforderung dagegen nicht und kann seine grobe Vermutung gewöhnlich nicht in die präzise Antwort verwandeln.

Historisch entscheidend ist die Trennung von Zulässigkeit und Autorität. Eine Nummer im Fenster ist Grund genug, zu reagieren, aber nicht Grund genug für eine unumkehrbare Zustandsänderung. Zwischen Ignorieren und Zerstören entstand eine dritte, reversible Handlung: nachfragen und den bestehenden Zustand zunächst bewahren.

Bei einem unerwarteten SYN im synchronisierten Zustand folgt RFC 5961 demselben Gedanken. Der Empfänger sendet unabhängig von der Sequenznummer eine Challenge ACK und beendet die Verarbeitung des Segments. Ein gefälschtes SYN erzeugt meist nur einen zusätzlichen ACK, den der etablierte Peer als Duplikat behandelt. Ein wirklich neu gestarteter Peer hat seinen alten Zustand verloren und kann anders reagieren, sodass das Ende der alten Verbindung bestätigt wird.

Die Grenze der Abwehr bleibt sichtbar. Sie authentifiziert keine Identität und schützt nicht vor einem Angreifer auf dem Pfad, der aktuelle Sequenz- und Bestätigungsnummern beobachtet. Das Dokument nennt zudem einen seltenen Neustartfall mit derselben Adresse, demselben Port und einer zufällig besonderen Initialnummer. Blinde Angriffe werden schwieriger; TCP wird dadurch nicht kryptografisch.

Auch die Normstärken unterscheiden sich. Die RST- und SYN-Abwehr wird empfohlen, die engere ACK-Prüfung gegen Dateninjektion ist optional. RFC 9293 bleibt die heutige TCP-Basisspezifikation und verweist auf RFC 5961 als Robustheitsverbesserung. Die Reparatur liegt als nachvollziehbare Schicht über dem älteren Vertrag.

Primärquellen