Summary

  • Bei einem Kandidaten-Datagramm von mindestens 21 Byte veranlasst die Übereinstimmung der letzten 16 Byte mit einem der Verbindung zugeordneten Token den Empfänger zum Abbruch; sie authentifiziert den Absender nicht.
  • Er nennt weder Ursache und Zeitpunkt des Zustandsverlusts noch das verantwortliche Backend.
  • Für die Ursachenanalyse müssen Routingentscheidung, Schlüsselversion und letzter intakter Zustand hinzukommen.

Ein Load Balancer verschiebt Verkehr auf ein anderes Backend. Kurz darauf empfängt der Client ein Paket, dessen letzte 16 Byte einem bekannten Reset-Token entsprechen, und beendet die Verbindung. Für diese Reaktion ist das Signal eindeutig. Für die Aussage „der Server hat Zustand verloren“ reicht es nicht.

RFC 9000 §10.3 sieht den Stateless Reset als letztes Mittel eines Endpunkts vor, der nicht auf den Verbindungszustand zugreifen kann. Bei QUIC v1 und den definierten AEAD-Verfahren ist ein Short-Header-Paket unter 21 Byte niemals gültig und muss verworfen werden. Ab 21 Byte vergleicht der Empfänger die letzten 16 Byte mit Tokens aktiver Verbindungs-IDs. Ein Treffer führt zum sofortigen Abbruch, authentifiziert aber weder den Absender noch übermittelt er Grundcode, Backend-Kennung oder Zeitpunkt des ursprünglichen Verlusts.

Das Paket soll schwer von einem gewöhnlichen Short-Header-Paket zu unterscheiden sein. Zufällig wirkende Bytes erschweren die Erkennung durch Beobachter; Größenvorgaben begrenzen Reset-Schleifen. Daher kann auch eine passive Aufzeichnung nicht jedes ähnlich geformte Paket sicher als Reset klassifizieren.

§10.3.1 erlaubt die Ableitung eines Tokens aus statischem Schlüssel und Verbindungs-ID. So kann eine Routingebene ohne vollständigen Zustand ein übereinstimmendes Token erzeugen. Der Client erfährt daraus jedoch weder Schlüsselversion noch Instanz oder vorangegangene Betriebsänderung.

§10.3.2 setzt eine kritische Grenze: Verschiedene Verbindungs-IDs dürfen nicht dasselbe Token erhalten. Kollision oder falsche Wiederverwendung kann einen Fehlalarm auslösen und eine gesunde Verbindung beenden. Ein korrekter Treffer beweist daher nicht die korrekte Zuweisung und Aufbewahrung im gesamten System.

Die Sicherheitsbetrachtung in §21.11 hält auch die Zuschreibung eng. Ein offengelegtes oder schlecht verwaltetes Token kann eine Einschleusung ermöglichen. Die Token-Übereinstimmung allein weist keinen Angriff nach, schließt keinen Betriebsfehler aus und belegt keine erfolgreiche Zustandserhaltung beim Failover.

Als redaktionelle Betriebsempfehlung sollte der Vorfallsbeleg Beobachtungszeit, Adress- und Port-Tupel, Paketlänge und -form, Fingerabdrücke von CID und Token, zugehörige Sequenz, ausgebendes Backend und Schlüsselversion, Load-Balancer-Entscheidung, letztes gültiges Paket, Bereitstellungs- oder Failoverereignisse sowie unabhängige Daten aus dem Zustandsspeicher verbinden.

Diese Chronologie trennt Neustart, Verdrängung, Ablauf, Fehlrouting, verzögerte Replikation, inkonsistente Schlüsselrotation, Kollision und missbräuchliche Einspeisung. Der Reset erklärt den jetzigen Abbruch; die Betriebsdaten erklären die fehlende Zustandsverfügbarkeit.