Résumé

  • draft-liu-sidrops-rpki-rtr-over-quic-04 présente une reprise « 0-RTT », puis exige que clients, serveurs et piles TLS désactivent ou rejettent Early Data.
  • QUIC peut sécuriser et paralléliser le transport ; il ne prouve pas à lui seul qu’une vue RPKI est entière. Cette preuve dépend encore de la version, du Session ID, du Serial Number, de l’ensemble des flux et du dernier End of Data attendu.

La révision 04 date du 7 septembre 2026. C’est un Internet-Draft individuel dont l’en-tête vise le Standards Track. Datatracker ne lui attribue ni flux RFC, ni adoption par un groupe, ni Area Director responsable, ni telechat. Le texte de base 8210bis appartient, lui, à SIDROPS. Son statut ne se transmet pas au mapping RTRoQUIC : celui-ci reste une proposition, pas un choix de l’IETF, un inventaire de code ou une mesure de production.

L’introduction construit un argument de vitesse. QUIC intègre TLS 1.3 et offre plusieurs streams indépendants. Avec un serveur déjà connu, explique-t-elle, le client peut placer une requête RTR dans le premier paquet et obtenir une reprise « 0-RTT ». Le routeur ou le cache pourrait alors reprendre « presque instantanément » la synchronisation de la base de vérification RPKI.

La section normative sur l’établissement ferme cette possibilité. Les implémentations RTRoQUIC MUST NOT utiliser Early Data. Le client MUST NOT envoyer early_data dans ClientHello. Le serveur MUST le rejeter. La pile TLS 1.3 MUST désactiver le 0-RTT. Les révisions 03 et 04 conservent simultanément le bénéfice annoncé et l’interdiction.

La reprise de session ne sauve pas la phrase. RFC 9001 précise que la reprise TLS peut fonctionner lorsque le 0-RTT est désactivé. Elle peut économiser du calcul sans autoriser des données applicatives avant la fin de la poignée de main. Le 0-RTT QUIC est justement l’envoi précoce qui réutilise l’état d’une connexion antérieure. C’est ce chemin que l’introduction mobilise et que la règle retire.

Le motif de sécurité est sérieux. Early Data n’offre pas la même protection contre le rejeu ni la même propriété de confidentialité historique que les données ordinaires. Les auteurs estiment que des informations servant à valider les annonces BGP ne doivent pas accepter ce compromis. Une telle prudence peut être justifiée. Elle interdit cependant de calculer le temps de reprise avec un raccourci qui n’existe plus dans le protocole autorisé.

Le second problème naît du parallélisme. Le mapping simple place tous les PDU RTR dans un stream bidirectionnel créé par le routeur. L’ordre est unique. L’option multistream sépare un Control Channel — Serial Notify, Serial Query, Reset Query, Cache Reset et Error Report — de plusieurs Data Channels destinés au Cache Response, aux données et au End of Data.

Les données peuvent être distribuées en quatre familles : préfixes IPv4, préfixes IPv6, Router Keys et ASPA. La perte sur un stream QUIC ne bloque pas les octets d’un autre. C’est un avantage réel. Mais le cache ne devient pas complet parce que trois flux sur quatre ont fini.

La révision 04 exige que chaque Data Channel reçoive Cache Response et End of Data. Le premier Cache Response reçu est retenu ; le dernier End of Data reçu devient la fin valable. « Dernier » suppose donc un ensemble connu. Si les deux extrémités ne savent pas quels streams appartiennent à la réponse, elles ne peuvent pas savoir si une fin manque encore.

QUIC garantit l’ordre à l’intérieur d’un stream, pas un ordre total entre streams. Imaginez que les canaux IPv4, IPv6 et Router Key terminent, tandis que le canal ASPA attend une retransmission. Valider le premier End of Data installerait une vue partielle. Attendre le dernier peut préserver l’atomicité, à condition de définir la création, l’appartenance, la fermeture, le reset et l’erreur de chaque canal.

8210bis explique la portée du marqueur. Le Serial Number représente la version logique d’un cache. Le Session ID nomme son espace de numérotation. Il faut aussi la Protocol Version pour savoir si deux valeurs se correspondent. Le cache ne doit pas diffuser une mise à jour avant d’avoir achevé sa propre validation. Dans l’échange ordonné, le routeur n’avance son Serial Number qu’après End of Data, quand il peut conclure qu’il a reçu toutes les données courantes de ce cache.

Le passage à quatre streams ne peut pas diluer ce sens. Une Router Key correctement décodée n’atteste pas que les ASPA et les retraits de préfixes de la même transaction sont arrivés. L’ordre des horloges murales ne remplace pas l’ordre transactionnel. Il faut rattacher chaque PDU à la session, à la version et au commit commun.

Ces identifiants restent locaux. Le Serial Number n’est pas comparable entre deux caches ou deux versions de protocole et peut disparaître après reset. Le draft de base avertit qu’une réutilisation erronée du Session ID peut laisser le routeur désynchronisé si les changements suivants ne contredisent pas son état ancien. TLS peut authentifier le pair configuré ; il ne corrige pas un epoch de cache mal créé.

Avec plusieurs caches préférés, le périmètre se rétrécit encore. 8210bis donne au VRP un effet dès que le premier cache préféré le fournit et le conserve jusqu’au retrait par le dernier. La fin d’une session RTRoQUIC n’est donc pas la fin de la vue RPKI globale du routeur. Il faut une comptabilité par cache et une preuve du résultat de leur combinaison.

La chaîne aval garde ses propres décisions. Recevoir un PDU de préfixe n’est pas réévaluer toutes les routes BGP concernées. Installer un VRP ne prouve pas l’état Valid, Invalid ou NotFound d’une route donnée. La décision de politique ne prouve pas la sélection RIB, la sélection ne prouve pas la programmation FIB, et le FIB ne prouve pas le service. La vitesse du transport ne reçoit aucune autorité sur ces étapes.

Le fallback fait partie du vrai scénario. Si le blocage UDP empêche QUIC, la révision 04 recommande une session RTR fondée sur TCP. C’est utile à la continuité, mais cela impose des horodatages distincts : échec QUIC, début TCP, poignée de main, authentification, réponse du cache, commit. Un simple voyant « RTR connecté » cacherait l’intervalle que le projet prétend réduire.

Running-Code Primacy donne le test décisif. Deux implémentations indépendantes doivent choisir la même version RTR, authentifier les bons endpoints, refuser le 0-RTT comme prescrit, convenir de l’ensemble des Data Channels, tolérer la perte sur un flux, reconnaître le dernier End of Data attendu et commettre une seule version. Quatre flèches parallèles dans une figure ne suffisent pas.

Le minimum interopérable peut laisser au site le nombre de streams, la politique de certificats, la préférence des caches et le fallback. Il ne peut pas laisser l’identité de la transaction dans les habitudes locales. Le mapping doit dire comment une requête se rattache à tous les canaux, comment comparer les Cache Response dupliqués, comment traiter des End of Data contradictoires et ce qu’autorise exactement l’avancement du Serial Number.

Dire que QUIC « élimine complètement » le head-of-line blocking dépasse donc la preuve. Il évite qu’une perte sur un stream bloque la livraison d’un autre. L’application peut encore attendre le flux requis le plus lent, manquer de crédit, perdre la connexion, refuser une version, détecter des données corrompues ou retarder l’installation. Le parallélisme modifie l’attente ; il ne supprime pas la barrière de commit.

La décision de direction n’est pas QUIC contre TCP. Elle porte sur la preuve qui ferme la période de vue périmée. La bonne preuve nomme le cache, la Protocol Version, le Session ID, le Serial Number, tous les streams attendus et les données commises, puis montre l’effet réel sur la politique de routage.

Sources