Summary

  • Der Novemberentwurf zu DoS-Risiken bei MoQ-Relays ergänzt ein konkretes Szenario: Ein Relay nennt vielen Clients per GOAWAY einen fremden Host. Dieser erhält ihre Verbindungsversuche, selbst wenn er kein MoQT anbietet.
  • Der MoQT-Transportentwurf verlangt, dass ein Client die nicht leere New Session URI aus dem serverseitigen GOAWAY auf dem Kontrollstrom für seine neue Sitzung verwendet. Die Zielangabe beweist keine Befugnis des Ziels.

Ein Relay mit großem Publikum bereitet eine Verlagerung vor. Es teilt den Clients mit, wohin sie wechseln sollen. Trägt es den Server eines Dritten ein, versuchen viele Clients fast gleichzeitig, dort eine Verbindung aufzubauen. Der neu eingefügte Abschnitt in Revision 02 sagt ausdrücklich, dass das Opfer MoQT überhaupt nicht unterstützen muss. Eine später scheiternde Sitzung nimmt dem Host die Last der ersten Verbindungsversuche nicht ab.

Abschnitt 9.2 des Arbeitsgruppenentwurfs erlaubt dem Server, im GOAWAY des Kontrollstroms eine neue URI mitzugeben. Ist sie nicht leer, muss der Client sie für die neue Sitzung benutzen. Umgekehrt darf ein Client dem Server auf diesem Weg keine nicht leere URI vorgeben. Die Länge ist auf 8192 Byte begrenzt, ein weiteres GOAWAY auf demselben Kontrollstrom ist unzulässig. Diese Schranken prüfen weder Besitz noch Zustimmung des genannten Hosts. Auf einem Anfragestrom gilt eine andere Regel: Der Absender sollte nur diese konkrete Anfrage an der angegebenen URI wiederholen. Die Gefahr einer Massenbewegung betrifft den serverseitigen Kontrollstrom.

Die Juli-Version 01 enthielt den Absatz über fremde Ziele noch nicht. Im November kam somit ein bestimmter Weg hinzu, Last auf einen Außenstehenden abzuwälzen. Der Risikoentwurf fordert, dass Clients vor dem Folgen einer neuen URI eine Aussage über deren Autorität erhalten; die konkrete Regel soll in der Transportspezifikation stehen. TLS kann einen ungeeigneten Endpunkt später ablehnen, nachdem der erste Versuch bereits beim Ziel ankam. Die offiziellen Dokumente nennen keinen beobachteten Angriff und keine Messung der Überlast. Der IETF-Eintrag führt das Papier als individuellen Internet-Draft.

Ein brauchbarer Betriebsnachweis verbindet ursprüngliches Relay, neue URI, Zulassungsregel, Zahl und Zeitpunkt der Verbindungsversuche und Last beim Empfänger. Eine bloße Erfolgsmeldung zur Migration unterschlägt, wer die Rechnung erhielt.