Zusammenfassung

  • Am 24. August 2026 genehmigte der IESG Revision 16 von draft-ietf-masque-connect-udp-listen als Proposed Standard. Zum Beweisstichtag war sie weiterhin ein Internet-Draft in der RFC-Editor-Warteschlange; die Ankündigung nennt Google Quiche und quic-go als interoperable Implementierungen.
  • Das Verfahren hält für eine HTTP-Anfrage ein öffentliches UDP-Tupel stabil und bedient mehrere entfernte IP-/Port-Paare. Dieses Tupel ist eine Erreichbarkeitszuweisung, keine allgemeine Erlaubnis: Aushandlung, Context-Registrierung, Zielrichtlinie und beobachtete Zustellung bleiben getrennte Urteile.

Zwei Pakete erreichen dieselbe Adresse

Ein Browser lässt sich für WebRTC von einem HTTP-Proxy eine öffentliche UDP-Adresse geben. Der durch ICE ausgewählte Partner sendet ein Paket. Kurz darauf trifft ein zweites Paket von einem Scanner ein, der den Port zufällig gefunden hat.

Beide Pakete haben den Socket erreicht. Nur daraus folgt nicht, dass beide in den Tunnel gehören.

Das ist ein Gedankenversuch, kein gemeldeter Vorfall. Er macht die Aufgabe von „Proxying Bound UDP in HTTP“ sichtbar: Der Proxy soll einen stabilen Treffpunkt anbieten, ohne zum offenen Relay zu werden. Nach der Ankunft entscheiden die authentisierte Anfrage, das entfernte Tupel, der Context ID, die Zielregeln und die Empfangswahl des Clients.

Was beschlossen wurde

Die IESG-Mitteilung verzeichnet die Genehmigung am 24. August um 17:58 UTC als Proposed Standard. Das Dokument stammt aus der MASQUE-Arbeitsgruppe.

RFC 9298 bindet eine CONNECT-UDP-Anfrage an einen festen Host und Port. Das passt zu Client-Server-Protokollen wie HTTP/3. WebRTC verwendet ICE und muss gegebenenfalls mehrere Kandidaten erreichen. Mehrere gewöhnliche Anfragen garantieren nach der HTTP-Semantik weder dieselbe Proxy-Instanz noch dieselbe öffentliche Quelladresse. Genau diese Instabilität kann ICE scheitern lassen.

Die Erweiterung hält den Socket in einer Anfrage und benennt wechselnde Gegenstellen in Datagrammen oder registrierten Zuordnungen. Dass Quiche und quic-go interoperieren, ist wertvoller Nachweis laufender Software. Es ist kein Beleg für Browseraktivierung, Produktionsvolumen, universelle Richtlinien oder Konformität aller Implementierungen.

Am 28. August führte Datatracker den Text noch als aktiven Internet-Draft mit IESG-Status RFC Ed Queue. Die IANA-Arbeit lief, die Expertenprüfungen waren in Ordnung; der RFC Editor wartete auf Referenzprüfung und Formatierung. Genehmigung, nummerierter RFC und tatsächliche Einführung sind drei verschiedene Zeitpunkte.

Aushandlung braucht zwei Richtungen

Der Client sendet Connect-UDP-Bind: ?1. Ein unterstützender Proxy antwortet mit demselben wahren Booleschen Wert. Ein Endpunkt aktiviert die Erweiterung erst, nachdem er den Wert gesendet und empfangen hat. Andere Werttypen gelten als nicht vorhandenes Feld.

Ein erfolgreicher HTTP-Status allein belegt die Fähigkeit also nicht. Ebenso wenig darf der Proxy eine Anfrage mit festem Ziel still in einen Mehrparteien-Socket umdeuten.

Die Anfrage kann einen gültigen Host und Port enthalten, die bei fehlender Bind-Unterstützung als Rückfallziel dienen. Für reinen Bind-Betrieb setzt sie beide Zielvariablen auf *. Nur eine Variable mit Stern macht die Anfrage fehlerhaft. Diese Wahl gehört in den Nachweis, denn sie entscheidet auch, ob Context ID 0 noch ein festes Ziel bezeichnet.

Die öffentliche Adresse ist eine Zuweisung

Nach Annahme wählt der Proxy mindestens eine öffentliche IP-Adresse und einen freien UDP-Port, bindet sie an die Anfrage und meldet sie in Proxy-Public-Address. Bei genau einem Tupel müssen IP und Port bis zum Tunnelende stabil bleiben. Bei mehreren ist Stabilität je Adressfamilie empfohlen. Eine spätere Änderung lässt sich über dieses Antwortfeld nicht mitteilen.

Für ICE entsteht ein brauchbarer Kandidat. Eine Identität entsteht nicht. Gewünschter Partner und unbekannter Scanner können denselben Socket erreichen.

Die Telemetrie darf deshalb nicht mehr behaupten, als sie weiß. öffentliche_adresse_zugewiesen belegt die Ressource; paket_empfangen die Erreichbarkeit. Registrierung, Richtlinienentscheidung, Weiterleitung, Client-Zustellung und Anwendungserfolg stehen noch aus.

Context IDs machen die Gegenstelle zu Zustand

Clients vergeben gerade IDs, Proxys ungerade. Im reinen Bind-Modus ist 0 verboten. Nur mit einem echten festen Rückfallziel behält 0 die Bedeutung aus RFC 9298.

Drei Capsules regeln den Lebenszyklus. COMPRESSION_ASSIGN (0x11) schlägt die Bedeutung einer ID vor. COMPRESSION_ACK (0x12) bestätigt die gespeicherte Zuordnung. COMPRESSION_CLOSE (0x13) lehnt sie ab oder beendet sie.

IP-Version 0 erzeugt unkomprimierte Semantik: Jedes Datagramm trägt Adresse und Port. Client zum Proxy bedeutet Ziel, Proxy zum Client bedeutet empfangene Quelle. Version 4 oder 6 erzeugt eine komprimierte Zuordnung; das Tupel wird einmal registriert und danach durch die ID ersetzt.

Eine ID darf nicht doppelt vergeben werden, ein Tupel nicht zwei offene IDs haben und eine geschlossene ID nicht wiederverwendet werden. Nach dem Schließen verspätet eintreffende Daten werden still verworfen. Ein alter Name kann damit keine neue Beziehung autorisieren.

Vor dem ACK darf optimistisch gesendet werden. Der Sender nimmt aber Verlust in Kauf, wenn ASSIGN noch nicht angekommen ist oder abgelehnt wird. Das frühe Senden und die Annahme der Zuordnung sind daher zwei verschiedene Messpunkte.

Der Client besitzt das Veto gegen Unbekannte

Nur der Client kann den unkomprimierten Context anfordern, und nur einer darf offen sein. Er ist weitreichend: Jedes Datagramm kann ein bisher unbekanntes Quelltupel enthalten.

Öffnet der Client ihn nie oder schließt ihn, filtert der Proxy unbekannte Sender. Bereits etablierte komprimierte Zuordnungen bleiben bestehen. Neue darf der Proxy nach dem Schließen nicht anlegen, weil er sonst den ausdrücklichen Ausschluss des Clients umgehen würde.

Die öffentliche Zuweisung bleibt bestehen, während die Berechtigung enger wird. Socket, bekannte Zuordnung und unbekannte Quelle sind eigenständige Zustände.

Die Zielrichtlinie wandert mit dem Ziel

Beim festen CONNECT-UDP kann der Proxy die Adresse vor Tunneleröffnung prüfen. Im gebundenen Betrieb steckt das Ziel im Datagramm oder in der Registrierung, also muss die Prüfung dort stattfinden.

Für jedes unkomprimierte Datagramm kontrolliert der Proxy IP und Port. Für komprimierten Betrieb prüft er das Tupel aus COMPRESSION_ASSIGN und weist verbotene Ziele zurück. Lokale Regeln können Loopback, Link-local, private Netze, Verwaltungsflächen oder bestimmte Dienste schützen.

Der Entwurf schreibt nicht die gesamte Betreiberpolitik vor. Er bestimmt den Mindestpunkt, an dem ein wechselndes Ziel diese Politik nicht überspringen kann.

TURN liefert einen hilfreichen Vergleich. Relay-Zuweisung, Peer-Permissions und Channel Bindings sind verschiedene Zustände. Die Verfahren sind nicht identisch; gemeinsam ist ihnen, dass eine Relay-Adresse keine unbeschränkte Erlaubnis gegenüber allen Peers darstellt.

Kapazitätsgrenzen sind Sicherheitsgrenzen

Jeder offene Context ID kostet Speicher. Jedes durch Fluss- oder Überlastkontrolle verzögerte ACK oder CLOSE belegt Antwortpuffer. Deshalb müssen Endpunkte offene IDs und wartende Antworten begrenzen. Erreicht der Proxy das zweite Limit, muss er den Anfrage-Stream abbrechen.

Zu beobachten sind Konfiguration, Auslastung, Zurückweisungen, Wartedruck, Abbrüche und betroffene Client-Versionen. Ohne diese Daten sieht ein Schutz gegen Speichererschöpfung wie ein zufälliger Fehler aus.

Auch die effektive MTU ändert sich. Unkomprimierte Datagramme tragen Adresse und Port jedes Mal, komprimierte nicht. Ein Wechsel kann DPLPMTUD stören; frühe Kompressionsanforderung vermindert das Risiko. Paketgrößen, Verlust und Pfaderfolg müssen das Ergebnis dennoch bestätigen.

Eine gemeinsame IP verschleiert viele Entscheidungen

RFC 6269 beschreibt die Folgen geteilter IP-Adressen: grobe Zuordnung, gemeinsame Reputation und überbreite Sperren. Hinter einer Proxy-IP können viele Ports, Tunnel, Clients, Context IDs und entfernte Tupel liegen.

Für einen Missbrauchsfall braucht es öffentlichen Port, Tunnelkennung, authentisierten Client, Context-Zustand, Gegenstelle, Richtlinienurteil und tatsächliche Weiterleitung. Ein am Rand verworfenes Scanpaket darf nicht als Nutzerverkehr erscheinen.

Die Beweiskette eines Datagramms

Eine belastbare Spur verbindet:

  1. authentisierte Anfrage und Tunnelidentität;
  2. Bind-Aushandlung in beiden Richtungen;
  3. Rückfallziel oder reiner Bind-Modus;
  4. öffentliches Tupel und Lebensdauer;
  5. Vergabeseite und eindeutige Context ID;
  6. ASSIGN, ACK und CLOSE;
  7. komprimierte oder unkomprimierte Semantik;
  8. exaktes Quell- oder Zieltupel;
  9. Richtlinienversion und Urteil;
  10. Context- und Antwortbudget;
  11. Annahme, Verwerfen oder Puffern;
  12. Senden oder Empfangen am Socket;
  13. Client-Zustellung und ICE- oder Anwendungsergebnis.

Auch eine gültige Zuordnung kann in Verlust oder einem gescheiterten ICE-Test enden. Protokollzustand erlaubt Verarbeitung; beobachtetes Verhalten belegt den nutzbaren Pfad. Running-Code Primacy trennt hier sauber: Das Dokument setzt das gemeinsame Minimum, der Betreiber muss die Wirkung lokal nachweisen.

Quellen