Zusammenfassung

  • TCP-AO kann Resets authentifizieren, solange beide Endpunkte den Verbindungszustand und die zugehörigen Verkehrsschlüssel besitzen.
  • Nach einem Neustart wird ein nicht prüfbarer Reset verworfen; veralteter Zustand wird durch Lebenszeichen oder Anwendungswiederherstellung entfernt.

Der Neustart erzeugt eine Asymmetrie

Vor dem Ausfall kennen beide Seiten die TCP-Verbindung, die anfänglichen Sequenznummern und die daraus abgeleiteten Schlüssel. Ein Reset innerhalb dieses gemeinsamen Kontexts kann authentifiziert werden.

Ein neu gestarteter Router kann zwar weiterhin wissen, dass er TCP-AO mit seinem Nachbarn verwendet, aber den konkreten Verbindungszustand verloren haben. RFC 5925 sagt: Ist das Paar der anfänglichen Sequenznummern unbekannt, etwa bei einem Reset nach dem Neustart, soll der Reset ohne Authentifizierung gesendet werden. Der Peer, der TCP-AO verlangt, kann das Segment nicht prüfen und verwirft es.

Eine Seite erklärt die Verbindung für beendet, während die andere den alten Zustand noch hält, aber keine akzeptierbare Bestätigung erhalten hat.

Warum auch der ehrliche Reset abgewiesen wird

Würde man den nicht authentifizierten Reset als Ausnahme akzeptieren, könnte ein Angreifer dieselbe Nachricht fälschen und eine geschützte Sitzung beenden. Aus dem Paket allein lässt sich die Absicht des Absenders nicht erkennen.

Die Folge ist eine langsamere Bereinigung. Der überlebende Endpunkt kann veralteten Zustand behalten, bis seine eigenen Lebenszeichen feststellen, dass kein Fortschritt mehr stattfindet. RFC 5925 empfiehlt TCP- oder Anwendungs-Keepalives und verlangt, dass Implementierungen übermäßigen TCP-Verbindungszustand erkennen und zum Schutz des Speichers löschen können.

Quellen