Zusammenfassung

  • Vor der Validierung einer Peer-Adresse darf ein antwortender QUIC-Endpunkt höchstens dreimal so viele Bytes senden, wie er von dieser Adresse empfangen hat.
  • Das Konto begrenzt Verstärkung mit gefälschter Quelladresse in einer bestimmten Phase; es authentifiziert weder den Client noch beseitigt es andere Denial-of-Service-Risiken.
  • Bytezähler und Validierungsübergang sind nötig, um regelkonformes Warten von Verlust oder Überlastung zu unterscheiden.

Ein Server empfängt ein Initial-Datagramm, baut seinen Handshake-Flight und verbraucht den erlaubten Kredit. Weitere Bytes sind bereit, der Pfad kann erreichbar und der Prozess unbelastet sein. Trotzdem muss der Server auf zusätzliche Client-Bytes oder die Validierung der Adresse warten.

Diese Sicherheitsgrenze setzt RFC 9000. Ein Angreifer kann die Quelladresse eines Opfers fälschen und einen Server dazu bringen, Verkehr dorthin zu senden. Um diese Reflexion zu begrenzen, darf ein Endpunkt an eine unvalidierte Adresse höchstens das Dreifache der von ihr empfangenen Daten schicken.

Das ist ein kumulatives Konto. Empfangene Bytes erhöhen die Obergrenze, gesendete Bytes verbrauchen Budget. Die Regel multipliziert nicht jedes Eingangspaket unabhängig und lässt sich nicht aus dem letzten Datagramm allein ableiten.

Abschnitt 8.1 wendet die Rechnung beim Verbindungsaufbau an. Der Server zählt alle Nutzdatenbytes in Datagrammen, die eindeutig der Verbindung zugeordnet sind. Geht ein Initial- oder Handshake-Paket des Servers verloren, ist der Kredit trotzdem verbraucht. Hat der Client für alles Gesendete Bestätigungen gesehen, fehlt ihm womöglich ein Grund für weitere Pakete. RFC 9000 beschreibt den möglichen Stillstand am Anti-Amplification-Limit.

Ein Betriebsnachweis sollte deshalb Empfang, Versand, aktuelle Obergrenze, Restbudget, Blockierungszeit und noch ausstehenden Handshake-Flight enthalten. Ohne diese Daten sehen Verlust, ausgeschöpftes Budget und Ressourcenknappheit wie derselbe Timeout aus.

Auch die Adressvalidierung macht nur eine begrenzte Aussage. Beim Aufbau können ein empfangenes Handshake-Paket oder ein erfolgreich geprüftes Initial-Token den Zustand ändern. Retry kann verlangen, dass der Client ein an die behauptete Adresse gesendetes Token zurückgibt. Auf einem neuen Pfad prüft Abschnitt 8.2 mit PATH_CHALLENGE und passender PATH_RESPONSE die Erreichbarkeit eines bestimmten Adresspaares. Eine bloße Bestätigung genügt nicht, weil sie gefälscht werden kann.

Das identifiziert nicht den Nutzer der Adresse. Es zeigt Empfangsfähigkeit oder erfüllt eine Tokenregel, authentifiziert aber weder Person noch Gerät, Konto oder Anwendung. Nach erfolgreicher Validierung kann der Endpunkt die dreifache Obergrenze überschreiten. Überlastungs- und Flusskontrolle, Kryptozustand und Anwendungspolitik bleiben wirksam; dieses Konto ist jedoch keine dauerhafte Ratenbegrenzung.

Ebenso wenig ist es vollständiger DDoS-Schutz. Abschnitt 21.2 von RFC 9000 behandelt Denial of Service beim Handshake; Abschnitt 21.9 behandelt Missbrauch, der Verarbeitung oder Verbindungszustand verbraucht. Getrennt davon beschreibt Abschnitt 21.3 verbleibende Verstärkungsrisiken durch Tokens und neu zugeteilte Adressen. Eine Bandbreitengrenze vor Validierung bewertet weder CPU noch Zustandstabellen, authentifizierte Fluten oder Last nach der Validierung.

Als redaktionelle Betriebsempfehlung sollten drei Fragen getrennt bleiben: Welche Evidenz validiert die Adresse? Wie lautet der exakte Kontostand? Zeigen unabhängige Paket-, CPU-, Speicher- und Zustandsmetriken Druck? Diese Trennung verhindert, dass Erreichbarkeit zu Identität oder einer allgemeinen Sicherheitsgarantie umgedeutet wird.

Der empfohlene vollständige Nachweis enthält: Verbindungs- und Pfadkennung; lokales und entferntes IP/Port-Paar; Beobachtungszeit; Validierungszustand, -übergang und -methode; von der unvalidierten Adresse empfangene und an sie gesendete Bytes; aktuelle Dreifachgrenze und Restbudget; ausstehende Handshake-Flight-Bytes; Retry- oder Token-Ergebnis; gegebenenfalls PATH_CHALLENGE/PATH_RESPONSE-Ergebnis; Verlust- und Wiederholungskontext; ersten und letzten Zeitstempel der Limitblockierung; Ergebnis nach der Validierung; sowie getrennte Indikatoren für CPU, Speicher, Verbindungszustand und Paketrate.