MANRS : une ROA par route, le test des ressources historiques

Résumé

À RIPE 93, Andrei Robachevsky a décrit un projet de groupe de travail qui ferait du ROV une exigence MUST et demanderait une ROA valide pour chaque préfixe annoncé par un participant MANRS.
Certains opérateurs ne peuvent pas produire cette preuve seuls : les détenteurs historiques sans accord ARIN n’ont pas accès au RPKI d’ARIN, et les clients qui louent des préfixes peuvent ne pas avoir créé de ROA.

Analyse

L’opérateur annonce la route. Mais qui a le droit de signer la preuve qui l’autorise ? C’est la question cachée dans le « 100 % » évoqué pour la couverture RPKI du programme MANRS.

Le 27 octobre, à RIPE 93, Andrei Robachevsky a présenté le travail du groupe chargé de revoir le programme MANRS pour les opérateurs de réseau. Le texte n’avait pas connu de révision substantielle depuis le lancement du programme en 2014. Pour rendre les règles plus lisibles et vérifiables, le groupe séparait les exigences de leur guide de mise en œuvre et d’audit, avec les mots normatifs MUST et MUST NOT de l’IETF. Dans le projet décrit, le ROV serait un MUST et l’inscription IRR un SHOULD.

Pour l’action sur l’information de routage, le groupe discutait d’une couverture RPKI de 100 % : chaque préfixe annoncé par un participant devrait avoir une ROA valide.

Ce n’était pas encore une règle MANRS. Robachevsky a parlé d’un dernier appel interne, puis d’une consultation plus large. Il voulait que le texte recueille l’avis de la communauté au-delà du groupe de travail et des seuls participants actuels. Le transcript officiel de RIPE distingue bien les propositions des questions encore ouvertes.

Le sondage MANRS de mars 2026 donne le contexte de cette révision : 38 personnes ont répondu, surtout des opérateurs. Les priorités publiées étaient la précision des exigences et la qualité de l’audit ; 50 % des répondants ont placé le programme des opérateurs en tête des sujets à revoir. Le rapport ne précise pas combien de personnes avaient été invitées. Son taux de réponse reste donc inconnu.

La difficulté RPKI a une frontière administrative précise. Selon ARIN, les détenteurs de ressources historiques qui n’ont pas signé d’accord ne peuvent utiliser ni son RPKI ni son IRR. Ceux qui concluent un accord peuvent accéder à ces services. ARIN précise aussi qu’une ROA ne peut couvrir que les ressources figurant dans le certificat du détenteur. Un opérateur qui annonce le préfixe d’un tiers ne peut pas créer cette autorisation depuis son propre certificat.

Robachevsky a cité deux cas : certains détenteurs historiques dans la région d’ARIN n’ont pas accès au RPKI ; et des opérateurs annoncent des préfixes loués par leurs clients, qui n’ont pas toujours créé de ROA. Dans BGP, l’annonce passe par l’opérateur. Dans le registre, l’acte qui manque peut dépendre du client ou du détenteur. Pourtant, c’est l’opérateur qui risque de porter l’étiquette de non-conformité.

L’IRR reste dans le tableau, mais à un autre rang : un SHOULD dans le projet, face au MUST proposé pour le ROV. Certaines équipes s’appuient encore sur l’IRR et le groupe n’avait pas arrêté quels registres ou objets devaient compter. Remplacer sans nuance le RPKI par une entrée IRR effacerait la distinction du projet. Écarter l’IRR effacerait les pratiques qui servent encore à construire des filtres et à documenter les annonces.

MANRS est passé de neuf opérateurs en 2014 à environ 1 400, selon Robachevsky à RIPE 93. Il a défendu un socle adopté largement plutôt qu’un badge réservé aux réseaux capables de satisfaire le test le plus sévère. Une liste de membres plus petite peut afficher de meilleurs scores tout en laissant les préfixes les plus difficiles hors du périmètre.

La crédibilité du « 100 % » dépend donc du chemin vers la conformité : quels préfixes exigent une ROA, qui doit la créer, quelle solution s’applique quand le détenteur contrôle le registre et quel délai est accordé aux membres existants. Sans ces réponses, la règle déplace la responsabilité sans produire la ROA manquante.