Résumé

  • ROV peut rejeter une route contraire aux ROA disponibles sans consulter le propriétaire du préfixe. Le réseau prend sa décision ; l’explication, elle, ne revient pas forcément.
  • iROV propose une autorisation signée à la demande et un mécanisme de retour. Les gains de joignabilité annoncés viennent d’une simulation, pas d’un déploiement mondial.

Le cas est banal et coûteux : en pleine attaque, un opérateur détourne le trafic vers un service d’atténuation, mais la nouvelle annonce ne correspond pas encore au ROA que les validateurs ont en cache. ROV fait alors son travail : le réseau qui applique la validation marque la route invalide et la rejette. Le propriétaire peut ne voir ni le rejet ni son étendue.

C’est cette lacune que Younsoo Kim, Seungjin Baek, Weitong Li, Tijay Chung et Min Suk Kang examinent dans leur article paru à USENIX Security 2026. Kang l’a présenté à NANOG 98. Leur proposition, iROV, permet au validateur de demander au propriétaire une autorisation signée et valable au moment de l’incident. La réponse peut ensuite être « agrafée » à la route ; un autre validateur iROV la vérifie localement, sans solliciter à nouveau le propriétaire. Une interrogation probabiliste limite aussi le volume de requêtes.

Le résultat affiché attire l’œil : la joignabilité passerait de 23 % à presque 90 % lors de changements urgents. Il s’agit du résultat de la simulation des auteurs. Le scénario fixe à 100 % l’adoption d’iROV par les réseaux de niveau 1, pose des hypothèses d’adoption de ROV et de probabilité d’interrogation selon les niveaux, puis applique un modèle simplifié de propagation et de préférence locale. Les auteurs reconnaissent que ce modèle ne reproduit pas toute la diversité des politiques réelles. Leur prototype BIRD/FORT a fonctionné dans un banc d’essai fermé ; ni la simulation ni le prototype ne mesurent un déploiement mondial.

La contrepartie est claire. Une route invalide doit toujours recevoir l’approbation cryptographiquement vérifiable de son propriétaire ; en cas d’échec ou d’absence de réponse, le mécanisme revient au rejet ROV habituel. Mais il faut désormais exploiter le serveur du propriétaire, protéger ses clés, fixer la politique de requêtes, examiner les alertes et réagir si la hausse des requêtes devient elle-même l’incident. Les auteurs ne chiffrent pas ces coûts, qui varient selon les opérateurs.

iROV constitue donc une proposition de conception sérieuse et une question utile aux opérateurs, pas un bouton déjà prêt. À NANOG, la discussion porte sur le retour d’information que ROV devrait fournir et sur les risques acceptables pour l’ajouter. La petite question de gouvernance reste entière : qui fixe les paramètres, qui supporte la charge de réponse et qui définit l’urgence ?

Sources : article USENIX Security 2026 · session NANOG 98 · RFC 6811 : validation ROV · RFC 6482 : ROA. · PDF original