Zusammenfassung

  • draft-liu-sidrops-rpki-rtr-over-quic-04 nennt „0-RTT“-Recovery als Vorteil, verlangt aber normativ, dass Client, Server und TLS Early Data abschalten oder zurückweisen.
  • Unabhängige QUIC-Streams verkürzen Transportblockaden; einen vollständigen RPKI-Cache belegen erst Protocol Version, Session ID, Serial Number, die erwartete Stream-Menge und das letzte End of Data.

Revision 04 erschien am 7. September 2026. Sie ist ein Individual Internet-Draft mit beabsichtigtem Standards-Track-Status, kein von SIDROPS angenommener Text, kein IETF-Konsens und kein RFC. Datatracker nennt weder RFC stream noch verantwortlichen AD oder Telechat. Der WG-Draft 8210bis definiert das Basisprotokoll; sein Prozessstatus darf nicht auf das individuelle QUIC-Mapping übertragen werden.

Die Einleitung begründet den Wechsel mit Geschwindigkeit und Multiplexing. Bei einem bereits bekannten Server könne der Client die RTR-Anfrage im ersten Paket mitsenden und „0-RTT“ erreichen. Router oder Cache könnten damit nahezu sofort ihre RPKI-Synchronisierung wieder aufnehmen. Mehrere Streams sollen außerdem TCP-artiges Head-of-Line Blocking vollständig beseitigen.

Section 3.1 setzt eine andere Norm. RTRoQUIC-Implementierungen MUST NOT Early Data nutzen. Clients MUST NOT early_data anbieten, Server MUST es ablehnen und TLS-1.3-Stacks MUST 0-RTT deaktivieren. Der Widerspruch steht seit Revision 03 im Text und blieb in 04 bestehen.

Session Resumption ist keine Rettung für die Formulierung. RFC 9001 erlaubt Resumption auch bei abgeschaltetem 0-RTT. Sie kann Handshake-Arbeit reduzieren, ohne Application Data vor Abschluss zuzulassen. QUIC 0-RTT bezeichnet gerade diese frühe Datenübertragung mit gespeichertem Zustand. Die Einleitung verspricht sie, die Norm verbietet sie.

Der Sicherheitsgrund ist Replay. Early Data besitzt nicht dieselben Eigenschaften wie reguläre Application Data. Weil RPKI-Daten BGP-Bewertungen speisen, lehnt der Draft dieses Risiko ab. Das kann vernünftig sein. Dann darf der verbotene Pfad aber nicht in Recovery-SLAs oder Investitionsrechnungen auftauchen.

Beim Multistream-Mapping entsteht eine zweite Beleglücke. Im einfachen Modus laufen alle RTR-PDUs über einen bidirektionalen Stream. Im parallelen Modus trägt der Control Channel Serial Notify, Serial Query, Reset Query, Cache Reset und Error Report. Data Channels tragen Cache Response, Payload und End of Data.

Payload kann auf IPv4 Prefix, IPv6 Prefix, Router Key und ASPA verteilt werden. Verlust in einem QUIC-Stream stoppt die anderen nicht. Drei beendete Streams machen jedoch keinen vollständigen Cache, solange der vierte fehlt.

Revision 04 verlangt Cache Response und End of Data auf jedem Data Channel. Der zuerst empfangene Cache Response gilt, der zuletzt empfangene End of Data gilt. Damit wird die erwartete Stream-Menge Teil der Transaktion. Ohne bekannte Mitgliedschaft hat „zuletzt“ keine überprüfbare Bedeutung.

QUIC ordnet Bytes pro Stream, nicht über alle Streams gemeinsam. Ein Commit beim ersten End of Data kann einen partiellen Snapshot installieren. Ein Commit beim letzten funktioniert nur, wenn Erzeugung, Query-Bindung, Reset, Schließung, Fehler und erwartete Anzahl der Streams interoperabel feststehen.

8210bis erklärt die Autorität der Markierung. Die Serial Number ist die logische Version eines Caches. Die Session ID bezeichnet seinen Nummernraum. Zusammen mit Protocol Version entsteht die Identität. Vor Abschluss einer validierten Aktualisierung darf der Cache keine neuen Daten senden. Nach End of Data darf der Router den aktuellen Stand dieses Caches als vollständig ansehen und seine Serial Number fortschreiben.

Diese Atomizität darf durch Parallelisierung nicht verschwinden. Ein korrektes Router-Key-PDU belegt nicht, dass ASPA und Prefix Withdrawals derselben Version angekommen sind. TLS authentisiert den konfigurierten Peer, nicht die Vollständigkeit seiner Transaktion.

Die Nummern gelten nur lokal. Serial Numbers sind zwischen Caches oder Protokollversionen nicht vergleichbar und müssen Reset nicht überleben. Der Basisdraft warnt, dass fälschlich wiederverwendete Session IDs einen Router unbemerkt out of sync lassen können, wenn spätere Änderungen seinem alten Zustand nicht widersprechen. QUIC-Verschlüsselung repariert keinen falschen Cache-Epoch.

Mehrere bevorzugte Caches schaffen eine weitere Grenze. Ein VRP wird wirksam, sobald der erste bevorzugte Cache es liefert, und bleibt, bis der letzte es zurückzieht. Der Abschluss einer RTRoQUIC-Session ist deshalb nicht der Abschluss der globalen Router-Sicht. Belege werden pro Cache und für ihre Union benötigt.

Auch downstream bleiben Entscheidungen getrennt. PDU-Empfang, lokale Installation, BGP-Neubewertung, Best Path, RIB, FIB und Paketergebnis sind verschiedene Tatsachen. Ein schneller verschlüsselter Transport besitzt keine Entscheidungsgewalt über sie.

Der Draft sieht zudem TCP-Fallback vor, wenn UDP blockiert ist. Monitoring muss QUIC-Fehler, TCP-Start, Authentisierung, ersten Cache Response, letzten End of Data, Commit und BGP-Neubewertung einzeln messen. Ein grünes „RTR connected“ verbirgt die veraltete Sicht.

Running-Code Primacy verlangt einen reproduzierbaren Test: Zwei unabhängige Implementierungen wählen dieselbe RTR-Version, authentisieren die richtigen Endpunkte, verweigern 0-RTT, kennen dieselbe Stream-Menge, überstehen selektiven Verlust und committen genau eine Version beim echten letzten End of Data. Vier Pfeile im Schaubild sind kein solcher Nachweis.

Die minimale Spezifikation kann Stream-Zahl, Zertifikatspolitik, Cache-Präferenz und Fallback lokal lassen. Transaktionsidentität darf sie nicht lokal lassen. Version, Cache, Session ID, Serial Number, Query, Stream-Set und Abschluss brauchen eine gemeinsame Bindung.

Führung sollte daher nicht den Namen QUIC genehmigen. Sie sollte eine mit dem erlaubten Protokoll gemessene Verbesserung, einen atomaren Commit, getesteten TCP-Fallback, Cache-Diversität, Rollback und einen Beleg bis zur Routingwirkung verlangen.

Quellen