Résumé

  • Une étude publiée en 2026 estime que les UPDATE autour d’événements RPKI reconstruits représentent moins de 1 % du volume observé.
  • La méthode compte toutes les mises à jour d’une fenêtre de convergence comme liées à l’événement, ce qui peut gonfler la part attribuée.
  • Le ratio ne mesure ni la charge de chaque pair, ni les changements de chemin, ni Route Refresh, ni la joignabilité des utilisateurs.

Un faible pourcentage répond à une vraie question

Le résultat mérite d’être reconnu. Samuele Quinzi, Cristel Pelsser et Giuseppe Di Battista estiment le volume d’UPDATE BGP observé autour de changements de ROA dans une étude évaluée par les pairs, publiée dans Proceedings of the ACM on Networking. Le résumé indique que ces mises à jour restent sous 1 % du total observé malgré la croissance du RPKI et de la table de routage. La question est précise : ces événements dominent-ils le flot des messages observés ? Dans la série étudiée, non.

Dans son billet invité sur le blog d’APNIC, Quinzi explique que les auteurs reconstruisent les événements à partir de données historiques, puis comptent tous les UPDATE d’une fenêtre de convergence comme liés. Certains peuvent avoir une autre cause. Cette règle élargit plutôt le numérateur. Le chiffre décrit donc un volume associé dans le temps selon une méthode prudente ; il ne prouve pas que chaque message a été causé par le RPKI.

La stabilité comporte plusieurs unités

Le ratio compare des UPDATE associés aux événements à l’ensemble des UPDATE observés. Il ne mesure pas la part des routeurs touchés, des préfixes dont la validation change, des chemins sélectionnés qui évoluent ni du trafic client interrompu. UPDATE transporte des informations de routage ; il ne dit pas directement si une application reste joignable.

RIPE RIS recueille des données par sessions BGP. Son collecteur RRC00, à Amsterdam, est multihop et de portée globale. « Globale » décrit le périmètre du collecteur, pas un recensement de tous les chemins, du processeur de chaque pair ou de l’expérience de chaque abonné. Le pourcentage agrégé ne montre pas non plus si quelques pairs concentrent les messages.

L’inférence inverse serait tout aussi fragile : un volume élevé d’UPDATE ne prouve pas une perte de service. Volume de messages, charge par pair, changements de chemin, durée de convergence et joignabilité sont liés, mais distincts.

Route Refresh relève d’une autre charge

La RFC 9324 décrit un mécanisme différent : après de nouvelles données de validation, certaines implémentations ont demandé un Route Refresh à leurs pairs pour réévaluer des routes. La RFC indique que cette pratique peut leur transférer une charge importante et recommande de conserver les routes concernées pour éviter des requêtes inutiles. Elle relate aussi des cas où le ROV a été désactivé et des peerings interrompus.

C’est un risque opérationnel précis, pas une description de toutes les implémentations ni une réfutation du ratio d’UPDATE de l’étude. Une requête Route Refresh et les réannonces qui suivent ne se confondent pas avec les UPDATE comptés dans une fenêtre d’événement. Il faut les mesurer séparément.

Élargir l’analyse sans mélanger les mesures

La suite utile consiste à publier des indicateurs distincts : UPDATE par événement et par pair ; requêtes Route Refresh et routes réannoncées ; temps de stabilisation ; fréquence et durée des changements de chemin ; et, si possible, signaux indépendants de joignabilité. Chaque valeur doit préciser son point d’observation, sa période, son dénominateur et le traitement des données manquantes.

L’archive historique du RPKI de RIPE repose sur des instantanés quotidiens ; le billet d’APNIC rappelle que les changements brefs peuvent échapper à cette cadence. RPKI-Flutter observe les événements plus souvent, mais sur une période récente. Le billet indique que les estimations d’UPDATE se ressemblent pendant leur chevauchement. Cela renforce la reconstruction pour le volume comparé, pas pour la charge par pair ou l’expérience utilisateur.

La conclusion juste n’est ni « sans risque » ni « déstabilisateur ». L’étude rassure sur un point limité : les événements RPKI ne représentent pas une grande part des UPDATE observés dans la série. Pour juger la stabilité au sens large, il faut nommer la ressource, le chemin ou le service concerné.

Sources

Sources primaires et références protocolaires :