Zusammenfassung

  • Der Drei-Wege-Handshake sollte vor allem verhindern, dass ein altes dupliziertes SYN irrtümlich eine neue Verbindung erzeugt.
  • Jeder Endpunkt wählt eine eigene Initial Sequence Number. Der Antwortende bestätigt die erste und sendet zugleich seine; erst die dritte Nachricht belegt, dass der Initiator die aktuelle Antwort gesehen hat.
  • Quiet Time, TIME-WAIT, geheime ISN-Abstände und SYN-Cookies behandeln alte Daten, Vorhersagbarkeit und Ressourcenbindung. Identität authentifizieren sie nicht.

Ein Segment aus der vorigen Verbindung

Pakete können im Internet verspätet, mehrfach und in anderer Reihenfolge eintreffen. Wird dieselbe Kombination aus zwei Adressen und zwei Ports bald wiederverwendet, kann noch ein SYN der alten Verbindung unterwegs sein. Sein Header trägt keine verlässliche Altersangabe.

RFC 761 beschrieb 1980 deshalb zwei unabhängig gewählte Sequenzräume. Beide TCPs müssen die Initialnummer des anderen lernen. Erst danach lassen sich Daten ordnen und Duplikate einer bestimmten Verbindungsinkarnation zuweisen.

Vier Aussagen in drei Segmenten

A meldet X, B bestätigt X, B meldet Y, A bestätigt Y. B fasst seine zwei Aussagen zusammen: SYN X, SYN Y, ACK X+1, ACK Y+1.

SYN verbraucht eine Stelle im Sequenzraum. Ein reines ACK tut das nicht, sonst müsste jede Bestätigung erneut bestätigt werden. RFC 793 standardisierte 1981 diesen Ablauf mit SYN-SENT, SYN-RECEIVED und ESTABLISHED.

Es gibt keine zentrale Sitzungsnummer. Lokale Entscheidungen werden gemeinsam nutzbar, weil jede Seite sowohl die fremde Wahl als auch die Bestätigung der eigenen erhält.

Die dritte Nachricht beweist die Gegenwart

Nach dem SYN-ACK weiß A, dass B geantwortet hat. B weiß noch nicht, ob A heute hinter dem ersten SYN steht. Das SYN könnte eine alte Kopie sein, deren Absender längst keinen Zustand mehr besitzt.

Das letzte ACK nennt Bs aktuelles Y. RFC 761 bezeichnete den Mechanismus als Tausch zwischen Gedächtnis und Nachrichten: Wer nicht alle früheren Nummern jedes Gegenübers speichern kann, verlangt eine zusätzliche Bestätigung der laufenden Runde.

Dieser Nachweis ist keine Identität. Er zeigt aktuellen TCP-Zustand, aber weder einen Menschen noch eine Organisation oder Anwendungsberechtigung. Ein Beobachter auf dem Pfad kann die Zahlen sehen.

Alte Nummern brauchen eine Frist

Auch nach einem gültigen Start können alte Daten und ACKs zurückkehren. Frühe Spezifikationen setzten die Maximum Segment Lifetime auf zwei Minuten. Verlor ein Host bei einem Absturz sein Sequenzgedächtnis, sollte er eine MSL schweigen. Mit erhaltenem Gedächtnis konnte er hinter den jüngsten Nummern fortfahren.

TIME-WAIT hält nach normalem Abschluss dasselbe Tupel für zwei MSL. Alte Kopien können ablaufen, und das letzte Abschluss-ACK bleibt wiederholbar. Die Wartezeit ist gespeicherte Bedeutung: Sie verhindert, dass ein altes Segment in einer neuen Verbindung gültig wird.

RFC 9293 bewahrt das Modell, hält die Start-Quiet-Time heute aber meist für entbehrlich. Zufällige Ports und ISNs, kürzere effektive Lebensdauer und längere Neustarts senken das Risiko. Bei schnellem Umlauf des 32-Bit-Raums helfen Zeitstempel und PAWS.

Der Mord an TIME-WAIT

RFC 1337 zeigte, wie ein altes Segment ein ACK auslöst, der zustandslose Gegenpunkt mit RST antwortet und dieses RST TIME-WAIT vorzeitig beendet. Wird das Tupel sofort neu geöffnet, können alte Daten in das neue Fenster fallen.

Die Beispiele reichen von falschen Nutzdaten über dauernde Desynchronisation bis zum Verbindungsabbruch. Der Handshake schützt die Initiierung, Fensterprüfungen die laufende Inkarnation und TIME-WAIT den Übergang zwischen Inkarnationen. Das sind ergänzende Grenzen.

Frische Zahlen sind keine beglaubigten Namen

Vorhersagbare ISNs erlaubten blinde gefälschte ACKs. RFC 6528 verbindet einen Zeitzähler mit einer geheimen Funktion über beide Adressen und Ports. Unterschiedliche Vierertupel erhalten von außen nicht erkennbare Abstände, während die Nummern weiter fortschreiten.

Das erschwert einem Angreifer außerhalb des Pfades das Raten. Es schützt nicht vor Beobachtung auf dem Pfad und beantwortet nicht, wer der Kommunikationspartner ist. Dafür bleibt kryptografische Authentisierung nötig.

Zustand im Antwortwert aufbewahren

Ein öffentlicher Server bindet oft schon nach dem ersten SYN Speicher an eine halboffene Verbindung. Viele gefälschte SYNs können diese Warteschlange füllen. RFC 4987 dokumentiert die 1996 öffentlich gewordenen SYN-Floods und verbreitete Gegenmaßnahmen.

Ein SYN-Cookie codiert Tupel, Clientnummer, Zeit, wenige Parameter und ein Geheimnis in die Sequenznummer des SYN-ACK. Der Server muss keinen vollständigen Zustand halten. Erst das abschließende ACK erlaubt Prüfung und Rekonstruktion.

Die Ressource wird also erst gebunden, wenn die Gegenprobe zurückkommt. Begrenzte Bits schränken Optionen ein, und Implementierungen wählen verschiedene Kompromisse.

Hinter den drei Nachrichten steht damit eine Aufgabenteilung: Das Netz transportiert, Endpunkte wählen, Bestätigungen synchronisieren, Zeit entwertet Vergangenes, Geheimnisse erschweren Raten, Cookies verschieben Kosten. Keine dieser Funktionen verleiht allgemeine Identitätsautorität.

Quellen und Beweisgrenzen

Die RFCs belegen Spezifikationen und ausgewählte Fehleranalysen, nicht ein weltweites Einführungsdatum. Die Deutung gegenseitiger Evidenz als Brücke zwischen lokalen Entscheidungen ist eine architektonische Schlussfolgerung aus den Verfahren.