Fragilité des données IRR d'AFRINIC: enjeux des enregistrements obsolètes, miroirs et récursifs

Quand plusieurs registres répondent à la même route

Le travail du route-server commence avant l'aube car l'échange veut ses filtres prêts avant le début de la journée d'affaires. Il extrait de plusieurs sources du Registre de routage Internet, rafraîchit les données miroirs, développe les AS-SET membres, construit des listes de préfixes et des contrôles d'origine, et émet la configuration qui décidera quelles annonces l'échange transmet. La plupart des matins sont sans incident. Ce matin, le travail s'arrête sur un préfixe IPv4 administré par AFRINIC dont l'histoire change selon la source interrogée.

Une source IRR a un objet route pour le préfixe avec un AS d'origine qui appartient à un ancien fournisseur. Une autre a un objet plus récent pour un réseau client qui indique qu'il a été déplacé vers un centre de données régional. Une troisième source reflète une entrée plus ancienne qui semble encore plausible car le nom du mainteneur ressemble au détenteur de la ressource. Un AS-SET fourni par le client se développe différemment selon l'ordre des sources. Dans un développement, le préfixe est couvert par le cône client d'un revendeur. Dans un autre, il disparaît car un route-set référence un AS-SET qui existe dans un dépôt différent.

Un contrôle RPKI public aide pour une partie de la question mais n'explique pas pourquoi les vues IRR divergent ni quelle relation opérationnelle est actuelle. L'ingénieur de l'échange peut rejeter la route, l'accepter, faire une exception manuelle, demander des lettres ou reporter le ticket. Aucun de ces choix n'est gratuit.

Voilà la scène pratique derrière la fragilité du Registre de routage Internet. Le problème n'est pas seulement qu'un objet route unique peut être erroné, obsolète ou difficile à corriger. Le problème plus large est que les données de politique de routage sont distribuées à travers plusieurs dépôts avec des historiques, des règles de mise à jour, des pratiques d'authentification, des calendriers de mise en miroir, des habitudes de nettoyage et des réputations sociales différents. Un opérateur ou un IXP consomme rarement « l'IRR » comme une base de données unique.

Il consomme un ensemble sélectionné de sources, dans un ordre sélectionné, via des outils qui font des hypothèses sur les doublons, la récursion, l'appartenance aux route-sets et la préférence de source. Lorsque ces hypothèses entrent en collision avec des enregistrements contradictoires, la conception de la base de données devient un événement économique.

Les parties concernées sont plus larges que les ingénieurs réseau. Un fournisseur de transit doit savoir quelle source croire avant de provisionner. Un fournisseur de cloud a besoin de confiance avant d'annoncer l'espace client. Un route-server d'IXP a besoin de filtres qui protègent les entités sans exclure les réseaux locaux légitimes. Un courtier doit expliquer pourquoi des enregistrements IRR obsolètes ne feront pas baisser le prix ou retarder le transfert. Un acheteur, un prêteur ou un assureur doit savoir si l'acceptation opérationnelle survivra à la diligence raisonnable.

Un client achetant de la connectivité ne se soucie pas de la syntaxe RPSL, mais il ressentira le coût si les routes ne sont pas acceptées rapidement.

AFRINIC est le test de stress utile car son environnement institutionnel rend le coût caché visible. La région a connu une longue crise de gouvernance, des litiges, des questions de mise sous séquestre, des turbulences électorales et des préoccupations publiques sur l'intégrité des enregistrements d'adresses historiques. La rareté de l'IPv4 a rendu chaque bloc routable plus important économiquement. Dans ce contexte, les données de routage adjacentes au registre ne sont pas une annexe administrative. Elles font partie de l'infrastructure de confiance du marché. Si les données sont cohérentes, les tiers peuvent dire oui à moindre coût.

Si elles sont fragmentées, chaque entité doit décider combien de risque juridique, opérationnel et de réputation absorber.

Le bon cadre n'est pas la loyauté institutionnelle. Il ne s'agit pas de faire confiance à AFRINIC, ou à tout autre RIR, parce qu'il revendique un mandat communautaire. Il ne s'agit pas non plus de faire confiance aux IRR privés parce que les opérateurs les utilisent depuis des années.

La question est plus difficile: lorsque plusieurs bases de données donnent des réponses plausibles mais contradictoires sur la politique de routage autour d'une ressource numérique rare, quelle réponse doit être utilisée par un fournisseur, un exchange, une plateforme cloud, un courtier, un acheteur, un prêteur ou un client, et qui paie lorsque la réponse est fausse?

RPSL a rendu la politique de routage lisible, pas auto‑validante

Le système du Registre de routage Internet est né d'un besoin opérationnel raisonnable. BGP permet aux réseaux d'annoncer des routes, mais il ne fournit pas, par lui‑même, une explication publique complète de ce qu'un réseau a l'intention d'originer, de transiter ou d'accepter. La politique de routage est trop importante pour être laissée uniquement dans des configurations de routeur privées et des fils de discussion électroniques. RPSL, défini dans la RFC 2622, a donné aux opérateurs un langage structuré pour exprimer cette politique. Il comprend des objets tels que route, route6, aut‑num, as‑set, route‑set et mntner.

Ce ne sont pas des instruments juridiques. Ce sont des objets de base de données conçus pour que les relations de routage puissent être décrites sous une forme que les logiciels peuvent interroger.

Cette distinction est souvent la première victime de l'automatisation. Un objet route associe un préfixe à un système autonome d'origine. Un objet route6, décrit dans l'extension multiprotocole de la RFC 4012, joue un rôle comparable pour IPv6. Un objet mntner identifie le mainteneur qui peut authentifier les modifications apportées à d'autres objets. Les AS‑SET et les route‑sets permettent aux opérateurs de décrire des collections de réseaux ou de routes, souvent de manière récursive. À partir de ces éléments, un réseau peut générer des filtres pour un client ou un pair.

La syntaxe est étroite, mais les conséquences sont vastes car la sortie devient la politique du routeur.

La promesse initiale était la coordination. Si les opérateurs publiaient leurs politiques de routage prévues dans des registres publics ou semi‑publics, d'autres opérateurs pourraient prendre des décisions plus sûres. Les filtres pourraient être générés plutôt que construits à la main. Les modifications pourraient être examinées par rapport à un modèle de politique visible. Les erreurs seraient plus faciles à détecter. La coordination à l'échelle de l'Internet disposerait d'une grammaire commune.

La RFC 2725, écrite à mesure que les préoccupations de sécurité autour de l'IRR grandissaient, a capturé le changement: à mesure que les données IRR devenaient plus utiles pour les opérations, leurs exigences d'intégrité et de sécurité devenaient plus fortes. Une base de données de coordination peu maintenue est une chose. Une base de données qui alimente des filtres en est une autre.

RPSL n'a pas rendu les données auto‑validantes. Il a rendu les données lisibles. Cette différence compte dans chaque litige IRR fragmenté. Si un objet route existe dans un dépôt, l'objet peut être analysé. Il peut être mis en miroir. Il peut être comparé à une annonce. Il peut être intégré dans une liste de préfixes. Mais l'existence de l'objet ne prouve pas que le détenteur de la ressource l'a autorisé, que l'AS d'origine est toujours d'actualité, que le mainteneur représente toujours la partie concernée, qu'un doublon ailleurs est faux, ou qu'une expansion de route‑set à travers des sources reflète les relations commerciales actuelles.

Le format rend une affirmation lisible par machine. Il ne rend pas l'affirmation vraie.

Cette limitation avait moins d'importance autrefois car les enjeux étaient plus faibles et la culture opérationnelle était davantage axée sur les relations. Le marché moderne est moins indulgent. L'IPv4 est rare; l'automatisation est plus profonde; l'intégration dans le cloud, les route‑servers, les services de sécurité gérés, le peering à distance et les transferts d'adresses dépendent tous de preuves externes reproductibles. Un enregistrement qui aidait autrefois les ingénieurs à coordonner influence désormais la capacité à déplacer du capital, de la connectivité et des relations clients.

La leçon institutionnelle est simple mais inconfortable. Une base de données de registre qui affecte les filtres ne peut pas être gouvernée comme si elle n'était qu'un tableau d'affichage pratique. Pourtant, elle ne doit pas non plus être transformée en un point de contrôle discrétionnaire large sur l'activité du marché. La légitimité de la base de données vient de l'étroitesse et de la fiabilité de sa fonction de grand livre. Elle doit enregistrer, authentifier et exposer les déclarations opérationnelles de manière à réduire l'incertitude.

Elle ne doit pas prétendre que chaque entrée de politique de routage est un jugement de propriété, un plébiscite communautaire ou un instrument de souveraineté institutionnelle.

C'est pourquoi la fragmentation est si coûteuse. Si le même vocabulaire RPSL apparaît dans plusieurs dépôts, chacun avec un modèle d'autorité différent, alors le marché reçoit des déclarations qui semblent comparables mais qui reposent sur des fondations différentes. L'objet route dans une source peut être étroitement lié à un enregistrement de détenteur de RIR. L'objet route dans une autre peut avoir été créé par un opérateur réseau il y a des années sous une pratique de mainteneur moins restrictive. Un objet mis en miroir peut être en retard par rapport à la source ou préserver une vue supprimée.

Un route‑set peut faire référence à des objets qui n'existent que si l'outil interroge les bons dépôts. La grammaire commune masque la différence institutionnelle sous‑jacente.

La fragmentation transforme un outil de coordination en péage de marché

La fragmentation est parfois décrite comme une nuisance pour les outils de filtrage. C'est trop peu dire. Dans un marché d'adresses rares, des données IRR fragmentées sont un système de péage. Elles facturent chaque partie qui doit enquêter, expliquer, concilier, remplacer, documenter ou assurer autour d'enregistrements contradictoires. Le péage n'est pas payé à un collecteur unique. Il est payé en travail, retard, décotes de risque, échecs d'intégration, blocages de peering, exceptions manuelles, examens juridiques et méfiance entre contreparties.

Le premier coût est la recherche. Un opérateur ne peut pas simplement demander si un préfixe a un objet IRR. Il doit demander quelles sources sa politique reconnaît, si ces sources sont autoritatives pour la région de la ressource, si les copies miroir sont à jour, si les doublons doivent être fusionnés ou traités comme des conflits, et si un objet dans une source privée ou non‑RIR doit être autorisé à remplacer une entrée manquante ou obsolète dans une source liée au RIR. Un petit réseau voit seulement un ticket. Un grand opérateur voit un ensemble de règles.

Entre les deux se trouve un coût de transaction qui décide souvent si le petit réseau obtient un service rapidement.

Le deuxième coût est l'explication. Lorsqu'un client dit « l'objet route est là », le fournisseur doit demander où. Si l'objet est dans RADB mais pas dans l'IRR du RIR concerné, est‑ce suffisant? S'il est dans une source AFRINIC mais qu'un doublon dans une autre source pointe vers une origine différente, quel objet gagne? Si le client a un AS‑SET qui s'étend sur plusieurs dépôts, le fournisseur accepte‑t‑il toutes les sources ou seulement celles d'une liste préférée? Si le précédent fournisseur du client a créé des objets dans son propre mainteneur, le client doit‑il les supprimer avant qu'un nouveau fournisseur n'accepte la route?

Chaque question est raisonnable. Ensemble, elles donnent à la connectivité l'impression d'être un litige par un autre nom.

Le troisième coût est la compétence asymétrique. Les grands opérateurs peuvent maintenir des équipes dédiées aux registres, établir des politiques spécifiques aux sources, exécuter des contrôles réguliers des objets obsolètes, surveiller les différences de filtres et savoir qui contacter. Les petits FSI africains, les universités, les agences publiques et les entreprises peuvent ne pas avoir cette capacité. Ils peuvent hériter d'anciens enregistrements de sous‑traitants. Ils peuvent compter sur les fournisseurs pour créer des objets.

Ils peuvent ne pas savoir qu'un doublon dans un IRR distant affectera un route‑server dans un marché différent. La fragmentation favorise donc les acteurs ayant une échelle suffisante pour gérer l'ambiguïté. Elle punit ceux pour qui l'accessibilité Internet devrait être une infrastructure ordinaire.

Le quatrième coût est le pouvoir de négociation. Si un acheteur d'espace IPv4 découvre que le bloc a des entrées IRR contradictoires, il peut exiger une décote ou un séquestre. Si un prêteur constate que le service dépendant d'adresses d'un emprunteur repose sur des exceptions manuelles chez les opérateurs, il peut considérer l'actif comme une garantie moins fiable. Si un fournisseur cloud exige un nettoyage avant l'intégration, le détenteur peut perdre du temps de migration ou négocier en position de faiblesse. Les enregistrements fragmentés n'ont pas besoin d'être malveillants pour changer le prix.

Ils doivent seulement rendre l'actif plus difficile à utiliser.

Le cinquième coût est la sécurité. Les doublons obsolètes peuvent préserver d'anciennes revendications d'origine. Les sources faiblement authentifiées peuvent donner une légitimité apparente à des routes qui devraient être contestées. Les AS‑SET trop larges peuvent inclure des clients en aval qui n'appartiennent plus. Le décalage des miroirs peut faire apparaître un enregistrement corrigé comme non résolu. Si les opérateurs réagissent en ignorant complètement les données IRR, ils perdent une couche défensive utile. S'ils réagissent en faisant aveuglément confiance à chaque source, ils élargissent la surface d'attaque.

S'ils réagissent en ne faisant confiance qu'à une liste étroite de sources, les réseaux légitimes ayant des enregistrements incomplets peuvent être exclus. La fragmentation force la politique de sécurité à choisir entre des préjudices imparfaits.

Le sixième coût est la confiance institutionnelle. Dans un environnement de registre stable, les opérateurs tolèrent un certain désordre car ils savent comment la correction fonctionne. Sous stress, chaque ambiguïté est lue plus sombrement: objet obsolète, contrôle faible des enregistrements, lacune administrative, verrouillage du détenteur ou contournement du grand livre régional? L'histoire récente d'AFRINIC rend ces questions plus difficiles à écarter. Le problème de données devient un problème de gouvernance parce que les tiers ne séparent pas les bases de données des institutions qui les maintiennent ou négligent de le faire.

La fragmentation change donc le sens économique d'un enregistrement IRR. Dans un environnement unifié et bien gouverné, l'enregistrement réduit le coût de la confiance de routage. Dans un environnement fragmenté, l'enregistrement peut déplacer le coût vers l'extérieur. Le route‑server, le fournisseur, la plateforme cloud, le courtier et l'acheteur deviennent des arbitres non rémunérés des conflits de base de données. Ils ne sont pas bien placés pour faire ce travail, mais le système de routage ne leur donne aucune échappatoire. Les paquets ont besoin d'une décision.

La sélection de source est une décision économique déguisée en ingénierie

La RFC 7454, le document sur les opérations et la sécurité BGP, traite la sélection de source comme une préoccupation pratique pour les opérateurs. Elle discute du filtrage des préfixes, des filtres clients dérivés des registres de routage, de la récursion des AS‑SET, de la nécessité de rafraîchir les filtres et de la difficulté de choisir les sources IRR à utiliser. Le texte est opérationnel, mais l'implication économique est grande: une règle de sélection de source est une politique de confiance.

Elle décide quelles affirmations de base de données sont suffisamment bon marché pour être utilisées et quelles affirmations nécessitent une escalade manuelle ou un rejet.

Considérons un opérateur qui accepte les objets AFRINIC, RIPE, APNIC, ARIN et RADB lors de la construction des filtres. Cette politique maximise l'inclusivité. Elle réduit les tickets de support des clients dont les données vivent dans des sources plus anciennes ou non régionales. Elle augmente également l'exposition aux doublons obsolètes, aux historiques d'autorisation plus faibles et aux surprises de récursion inter‑sources. Considérons maintenant un opérateur qui préfère uniquement la source RIR pertinente pour chaque préfixe et ignore les IRR privés lorsqu'un IRR RIR existe.

Cette politique peut améliorer l'alignement de l'autorité, mais elle peut bloquer des clients légitimes dont les enregistrements étaient historiquement maintenus ailleurs ou dont les objets créés par le fournisseur vivent en dehors de la source régionale. Un troisième opérateur peut utiliser un ordre de préférence de source, acceptant le premier objet correspondant. Cette règle est efficace jusqu'à ce que la source préférée soit obsolète et qu'une source moins préférée soit à jour.

Ces choix semblent techniques parce qu'ils sont encodés dans des scripts. Ils sont économiques parce qu'ils répartissent le coût de l'incertitude. Une politique de source stricte oblige les clients à nettoyer leurs enregistrements avant de recevoir le service. Cela peut améliorer la base de données, mais cela transfère le travail au client et peut exclure les petits réseaux. Une politique souple permet aux routes d'être acceptées plus rapidement, mais elle transfère le risque au réseau de l'opérateur et à ses pairs.

Une politique d'exception manuelle préserve la flexibilité, mais elle crée un avantage pour les initiés et des goulots d'étranglement de support. Il n'y a pas de politique de source neutre. Il n'y a que différentes façons de répartir les coûts.

Pour les préfixes administrés par AFRINIC, la sélection de source est particulièrement sensible car les enregistrements de la région peuvent porter plusieurs histoires à la fois. Un préfixe peut avoir un ancien objet route dans un IRR commercial parce qu'un fournisseur l'a créé bien avant que le détenteur n'utilise les outils IRR d'AFRINIC. Il peut avoir un objet lié à AFRINIC créé lors d'un nettoyage ultérieur. Il peut avoir des références de route‑set qui supposent un outillage de style RIPE parce qu'un fournisseur européen a maintenu la politique du client. Il peut avoir des entrées IRR privées utilisées par un fournisseur cloud ou DDoS.

Chaque source peut être plausible du point de vue de la partie qui l'a créée. La plausibilité n'est pas la même chose que l'autorité actuelle.

Les préférences de source conflictuelles affectent également la concurrence entre fournisseurs. Si la politique d'un fournisseur dominant accepte un ensemble plus large de sources, il peut intégrer les clients plus rapidement qu'un petit fournisseur avec des filtres plus stricts. Si une plateforme cloud exige un type de nettoyage et qu'un fournisseur de transit en exige un autre, le client peut choisir le chemin de moindre friction administrative plutôt que le meilleur service technique.

Si un route‑server d'IXP utilise des règles de source conservatrices, les membres ayant des enregistrements désordonnés peuvent éviter le peering multilatéral et rester dépendants du transit. La politique de base de données façonne alors indirectement la structure du marché.

La sélection de source peut également devenir une forme cachée de choix juridictionnel. Un objet route pour un préfixe administré par AFRINIC dans un dépôt non AFRINIC peut être plus facile à créer ou à préserver qu'un objet lié aux enregistrements de détenteur d'AFRINIC. Un opérateur qui accepte cet objet ne transfère pas formellement l'autorité loin d'AFRINIC, mais il décide qu'une source non AFRINIC peut soutenir la confiance opérationnelle. Dans les cas normaux, cela peut être inoffensif. Dans les cas contestés, cela compte.

Le marché peut router selon la base de données la plus facile à utiliser, et non selon celle qui reflète le mieux le grand livre des ressources.

La solution n'est pas d'exiger une liste de sources universelle. Les opérateurs ont des tolérances au risque, des bases de clients et des environnements juridiques différents. La solution est la transparence et des attentes plus étroites. Les opérateurs et les exploitants de route‑server devraient publier comment ils utilisent les sources, comment ils traitent les doublons, à quelle fréquence ils rafraîchissent les miroirs, comment ils gèrent les conflits entre données RIR et non RIR, et quelles preuves sont nécessaires pour les exceptions.

Les registres devraient publier suffisamment de métadonnées pour permettre aux opérateurs de distinguer l'autorité des sources plutôt que de deviner. Les clients devraient pouvoir apprendre à l'avance si leur posture IRR passera les filtres d'un réseau donné. Une règle de sélection de source cachée est une règle de marché cachée.

Dans le cas d'AFRINIC, la priorité institutionnelle devrait être de rendre la source liée à AFRINIC suffisamment prévisible pour que les opérateurs aient moins de raisons de chercher dans les bases de données la réponse qu'ils préfèrent. Cela ne signifie pas faire d'AFRINIC un gouverneur du marché. Cela signifie renforcer la fonction de grand livre afin que la source régionale devienne un point de référence à faible coût. Protéger le grand livre, pas le gardien: la valeur du registre réside dans le fait de rendre la confiance moins chère, pas dans la transformation de la préférence de source en pouvoir discrétionnaire.

Le décalage des miroirs et les doublons obsolètes créent une fausse continuité

Les données IRR voyagent souvent via des miroirs. La mise en miroir est utile car les opérateurs ont besoin d'un accès local, rapide et résilient aux informations du registre. Elle crée également une nouvelle classe de fragilité. Un miroir peut accuser un retard par rapport à la source faisant autorité. Il peut préserver une vue après une correction. Il peut échouer silencieusement. Il peut mettre à jour une source tandis qu'une autre reste obsolète. Il peut donner à l'automatisation l'impression qu'un enregistrement existe toujours ou a toujours une certaine origine alors que le dépôt sous‑jacent a évolué.

Le décalage des miroirs est facile à sous‑estimer car la plupart des retards sont inoffensifs. Si un rafraîchissement de filtre est en retard de quelques heures par rapport à une mise à jour de routine d'un AS‑SET, rien de dramatique ne se produit. Le problème n'est pas le délai moyen. C'est le retard lors de changements contestés ou économiquement significatifs. Un détenteur supprime un objet obsolète après avoir quitté un ancien fournisseur. Le route‑set de l'ancien fournisseur référence toujours l'objet via un miroir.

Un route‑server d'IXP se rafraîchit à partir d'une copie en retard et continue d'accepter une route que le détenteur croit avoir retirée. Ou un client crée un nouvel objet pour une migration, mais le miroir choisi par le fournisseur de transit n'a pas rattrapé son retard, donc le ticket stagne. La différence entre une vue à jour et une vue obsolète devient une interruption d'activité.

Les doublons obsolètes sont plus durables que le décalage des miroirs. Un objet en double peut rester dans une autre source longtemps après la fin de la relation commerciale d'origine. L'ancien fournisseur peut l'avoir créé pour un client et ne l'avoir jamais nettoyé. Le client peut ne pas savoir qu'il existe. Le mainteneur peut être injoignable. La source peut avoir peu d'incitations à le supprimer car l'objet n'est pas lié au grand livre des ressources de cette source. Des années plus tard, les filtres automatisés voient encore une revendication plausible de préfixe‑origine.

Si le détenteur actuel veut changer de fournisseur, il peut devoir expliquer pourquoi l'ancien objet ne devrait pas régir l'acceptation. Si un acteur malveillant veut une couverture, l'ancien objet peut fournir juste assez d'ambiguïté pour ralentir le rejet.

La fausse continuité est le danger économique. Un objet obsolète fait apparaître une relation passée comme présente. Un objet mis en miroir fait apparaître une vue corrigée comme non résolue. Un AS‑SET récursif qui inclut un ancien client en aval fait apparaître un ancien client comme faisant partie du cône actuel. La base de données n'a pas besoin de dire « ceci fait autorité ». Elle a seulement besoin d'être consommée par suffisamment d'outils pour créer une dépendance. Dans un marché où la vitesse compte, la continuité apparente est précieuse.

Elle permet à une partie de dire « les données ont toujours été ainsi », même si la survie des données est un échec de maintenance.

Le contexte d'AFRINIC augmente le prix de la fausse continuité. Les préoccupations d'intégrité des enregistrements historiques signifient que les données dormantes ou obsolètes ne sont pas simplement encombrantes. Elles peuvent devenir une ombre probante autour de l'espace IPv4 rare. Un acheteur examinant un bloc de la région AFRINIC peut demander si d'anciens objets IRR survivent dans des sources non régionales. Un fournisseur cloud peut demander si une origine précédente apparaît encore là où il consomme. Un courtier peut avoir besoin de nettoyer d'anciennes références de route‑set avant de conclure.

Un fournisseur peut refuser d'accepter une nouvelle origine tant que l'ancienne n'est pas supprimée. Chaque étape est rationnelle, mais ensemble, elles transforment le nettoyage fragmenté de la base de données en une condition préalable au marché.

Les doublons obsolètes créent également des incitations perverses. Une partie qui bénéficie de l'ambiguïté peut avoir peu de raisons de supprimer les anciennes données. Un ancien fournisseur peut ne pas prioriser le nettoyage pour un client perdu. Un revendeur peut préférer des AS‑SET larges car ils facilitent l'intégration. Une source faible peut préférer le volume et la commodité à des contrôles d'autorité rigoureux. Une source stricte peut supprimer des enregistrements mais n'avoir aucun pouvoir sur les copies ailleurs.

Le résultat est une externalité négative: le coût des données obsolètes est supporté par le détenteur actuel, le nouveau fournisseur et les réseaux qui doivent filtrer en toute sécurité, pas nécessairement par la partie qui a laissé l'enregistrement obsolète derrière elle.

La réponse pratique devrait être une discipline de cycle de vie. Les enregistrements utilisés pour les filtres de routage ont besoin d'horodatages, de provenance de source, de visibilité des suppressions, de statut de mise en miroir et d'indicateurs de conflit que les outils peuvent comprendre. Les opérateurs ont besoin de rapports d'objets obsolètes qui montrent quand une paire préfixe‑origine apparaît dans plusieurs sources avec des origines ou des mainteneurs différents.

Les registres et les principaux opérateurs IRR devraient faciliter le nettoyage pour les détenteurs qui peuvent montrer l'autorité actuelle, tout en préservant suffisamment d'historique d'audit pour empêcher la réécriture furtive. Les logiciels de route‑server devraient exposer les conflits plutôt que de les cacher derrière des règles de première correspondance. Rien de tout cela ne nécessite de transformer l'IRR en tribunal de la propriété. Cela nécessite d'admettre que les données obsolètes ne sont pas neutres lorsque les filtres les consomment.

Il y a aussi un point culturel. Les ingénieurs tolèrent souvent des registres désordonnés parce que l'Internet a toujours fonctionné sur un mélange de données formelles et de solutions de contournement informelles. Cette tolérance était utile dans un réseau en croissance. Elle l'est moins lorsque des blocs IPv4 rares, l'intégration dans le cloud et la diligence financière dépendent d'enregistrements que les étrangers ne peuvent pas interpréter facilement. Dans cet environnement, un doublon obsolète n'est pas seulement un vieil objet. C'est une créance sur le coût de confiance de quelqu'un d'autre.

L'authentification sans autorisation ne règle pas la confiance

Les discussions sur la sécurité de l'IRR commencent souvent par l'authentification. L'utilisateur contrôlait‑il l'identifiant du mainteneur? Le mot de passe, la clé PGP, le compte portail ou toute autre méthode étaient‑ils valides? La mise à jour a‑t‑elle été soumise via le canal approprié? Ces questions comptent. Une base de données qui ne peut pas authentifier les mises à jour n'est pas assez fiable pour la génération de filtres. Mais l'authentification n'est pas l'autorisation. La RFC 2725 a attiré l'attention sur cette séparation il y a plus de deux décennies, et la distinction reste centrale dans l'économie fragmentée de l'IRR.

L'authentification prouve le contrôle d'un identifiant. L'autorisation demande si le détenteur de l'identifiant avait le droit de faire cette déclaration particulière de politique de routage pour cette ressource particulière à ce moment particulier. Un ancien sous‑traitant peut encore contrôler un mainteneur. Un fournisseur de transit peut avoir été autorisé à créer un objet route pour un client pendant le service mais pas à le conserver après la résiliation. Un revendeur peut avoir l'autorité d'inclure un client en aval dans un AS‑SET pour un produit mais pas d'autoriser un nouvel AS d'origine.

Une boîte aux lettres d'entreprise peut exister après le départ de l'employé qui l'utilisait. Un compte de registre peut être techniquement valide alors que l'autorité d'entreprise sous‑jacente est contestée. Des contrôles de connexion solides réduisent l'usurpation d'identité; ils ne répondent pas au mandat.

La fragmentation multiplie le problème car chaque source peut tracer la ligne entre authentification et autorisation différemment. Un dépôt peut lier étroitement la création d'objets route à un détenteur de ressource ou à un modèle d'autorisation hiérarchique. Un autre peut permettre la création sur la base du contrôle du mainteneur et de la confirmation de l'AS d'origine. Un troisième peut préserver d'anciens objets sous des pratiques héritées. Un quatrième peut permettre aux mainteneurs de fournisseurs de créer des objets client pour la commodité opérationnelle.

Lorsque les filtres consomment tous ces objets comme des données RPSL comparables, le marché perd de vue les différentes hypothèses d'autorité derrière les enregistrements.

Pour les préfixes de la région AFRINIC, la distinction n'est pas théorique. Le stress de gouvernance, les litiges et les préoccupations d'intégrité des enregistrements rendent les questions de mandat plus susceptibles de se poser. Qui peut agir pour une entreprise en redressement judiciaire, en liquidation ou en litige de conseil? Qui peut mettre à jour les enregistrements pendant une période supervisée par un tribunal? Que se passe‑t‑il lorsqu'une allocation historique est liée à une institution publique dont les opérations réseau actuelles ont été externalisées?

Comment un registre ou un opérateur doit‑il traiter un mainteneur contrôlé par un fournisseur de services qui n'a plus le client? Ce sont des questions d'autorisation. Un mot de passe de mainteneur valide ne peut pas y répondre seul.

L'économie de cette distinction est sévère car les marchés aiment les identifiants. Les identifiants sont rapides. Ils s'intègrent dans les logiciels. Ils permettent de fermer les tickets. L'autorisation est plus lente. Elle implique des contrats, des lettres, une autorité d'entreprise, des enregistrements de registre, un contexte historique et parfois le droit. Un marché sous pression sera tenté d'accepter l'authentification comme substitut à l'autorisation parce que le retard est coûteux. Cette tentation crée une surface d'attaque pour quiconque peut préserver ou obtenir des identifiants sans autorité actuelle.

Elle crée également une barrière pour les détenteurs légitimes qui manquent d'anciens identifiants mais peuvent prouver le droit actuel.

L'erreur inverse est également coûteuse. Si chaque mise à jour IRR nécessite une nouvelle preuve complète de l'autorité sur la ressource, les modifications de routage de routine deviennent trop coûteuses. Les petits opérateurs éviteront de mettre à jour les enregistrements. Les fournisseurs maintiendront des AS‑SET larges pour réduire les frictions. Les clients compteront sur des lettres privées et des exceptions manuelles. Les filtres deviendront moins précis car le coût d'une publication précise est trop élevé. L'objectif n'est pas la documentation maximale.

C'est une autorisation proportionnelle: plus de preuves pour les changements qui modifient le risque ou le sens économique, moins de friction pour la maintenance de routine stable, une correction rapide lorsque l'autorité obsolète est évidente, et un préavis clair lorsque des parties peuvent être affectées.

En pratique, cela signifie que les sources IRR devraient exposer le contexte d'autorité, pas seulement le contenu de l'objet. Un objet route créé sous authentification directe du détenteur de la ressource devrait être distinguable de celui créé par un mainteneur de fournisseur. Un enregistrement lié à la confirmation de l'AS d'origine devrait être distinguable d'un objet historique hérité. Un enregistrement contesté ou récemment corrigé devrait porter un statut suffisamment visible pour que les opérateurs le traitent avec prudence. Les preuves privées n'ont pas besoin d'être publiées.

Mais la base de données ne devrait pas forcer chaque utilisateur en aval à déduire l'autorité de la syntaxe de l'objet et des noms de mainteneur.

C'est là que le principe de continuité étroite compte. Les registres devraient agir comme des utilities de continuité, pas comme des gouverneurs discrétionnaires de chaque usage du marché. Ils devraient maintenir le grand livre assez fiable pour que les tiers puissent interpréter les déclarations opérationnelles. Ils devraient résister au blanchiment de mandat, où une invocation large de la communauté ou de la gestion transforme la coordination technique en contrôle institutionnel des résultats commerciaux.

Mais ils devraient également résister à l'échec inverse, où une hygiène d'authentification faible permet à de vieux identifiants et à des sources fragmentées de gouverner l'accessibilité présente. Une utility étroite a encore besoin de procédures solides. Elle utilise la procédure pour protéger la confiance, pas pour accumuler un pouvoir discrétionnaire.

La récursion des AS‑SET fait voyager les petites erreurs loin

Les AS‑SET sont l'une des parties les plus utiles et les plus dangereuses de l'écosystème IRR. Ils permettent à un réseau de publier un ensemble d'ASN qui doivent être traités comme faisant partie de son cône client ou de sa politique de routage. Un fournisseur de transit peut demander un AS‑SET à un client, le développer de manière récursive, trouver les ASN à l'intérieur, puis construire des filtres pour les préfixes associés à ces ASN. Sans ce mécanisme, la maintenance des filtres clients serait beaucoup plus manuelle. Avec lui, un seul route‑server ou opérateur peut traiter de nombreuses relations de routage automatiquement.

Le danger est la récursion. Un AS‑SET peut inclure d'autres AS‑SET. Ces AS‑SET peuvent vivre dans différentes sources. Ils peuvent inclure des ASN clients obsolètes, des revendeurs en aval, des route‑sets ou des objets maintenus sous différentes normes d'autorité. L'expansion peut dépendre de la source. Un outil qui recherche toutes les sources peut produire un ensemble plus large qu'un outil qui se limite aux sources préférées. Un outil qui s'arrête à la première correspondance peut traiter une base de données comme décisive. Un outil qui échoue en mode fermé peut rejeter des clients légitimes.

Un outil qui échoue en mode ouvert peut accepter des routes via une chaîne que personne n'a récemment auditée. La mise en garde de la RFC 7454 sur la récursion des AS‑SET et les filtres dérivés de l'IRR n'est pas une note de bas de page académique. C'est le point opérationnel auquel la fragmentation de la base de données devient une configuration de routeur.

Dans un cas de la région AFRINIC, le problème de récursion peut être masqué par un empilement commercial ordinaire. Un petit FSI achète du transit auprès d'un opérateur régional. L'AS‑SET de l'opérateur inclut un revendeur. Le revendeur inclut des ASN clients. Certains de ces clients ont des préfixes d'AFRINIC, d'autres d'autres régions, certains loués ou délégués, certains déplacés vers des fournisseurs cloud ou DDoS. Les objets ont été créés sur de nombreuses années par différents mainteneurs.

Lorsqu'un route‑server d'IXP développe l'AS‑SET de haut niveau, il peut toute une histoire de relations commerciales, pas seulement la politique actuelle du membre. Si l'expansion est trop large, des clients obsolètes peuvent rester routables. Si elle est trop étroite, des clients en aval légitimes peuvent disparaître.

L'effet économique est l'échelle. Un seul objet route obsolète affecte une revendication préfixe‑origine. Un membre AS‑SET obsolète peut affecter de nombreux préfixes. Un route‑set large peut affecter tous les préfixes associés à plusieurs ASN. Un objet récursif dans une source de confiance peut des données moins fiables d'une autre source. Le rayon de l'erreur croît à chaque niveau d'indirection. Cela fait de l'hygiène des AS‑SET un enjeu de marché. Le coût d'un ensemble inexact est supporté non seulement par le mainteneur, mais aussi par chaque fournisseur, route‑server, client et pair qui dépend de son expansion.

La récursion crée également de l'opacité. Un client peut ne pas savoir pourquoi le filtre d'un fournisseur inclut ou exclut une route. La réponse peut être enfouie dans une règle de sélection de source à plusieurs niveaux de profondeur. Le ticket de support peut dire « IRR mismatch » alors que le vrai problème est que l'AS du client manque dans un ensemble en aval, ou qu'un AS‑SET en double dans une autre source est préféré, ou qu'une ancienne entrée de revendeur est encore en expansion. Les parties argumentent sur le préfixe visible tandis que la cause se trouve dans une chaîne cachée d'objets RPSL.

Pour les fournisseurs cloud et les grands réseaux de contenu, le problème des AS‑SET recoupe l'échelle d'intégration. Ils doivent vérifier de nombreux clients et éviter de devenir des points d'origine pour un espace douteux. Une gestion stricte des AS‑SET réduit le risque d'abus mais augmente la friction client. Une gestion souple améliore la vitesse d'intégration mais peut une politique obsolète ou trop large. Pour les courtiers et les acheteurs, la prolifération des AS‑SET est un bruit de diligence.

Un bloc peut sembler propre dans les enregistrements de détenteur mais apparaître dans des route‑sets associés à d'anciens fournisseurs, revendeurs ou clients. Avant que l'argent ne bouge, quelqu'un doit déterminer si ces références sont opérationnellement significatives, obsolètes ou nuisibles.

La bonne politique n'est pas d'abandonner les AS‑SET. Ils restent pratiques et largement utilisés. La politique est de traiter l'expansion récursive comme une chaîne de confiance avec des maillons faibles visibles. Les outils devraient rapporter les chemins de source, les noms d'ensembles en double, les références inter‑sources, l'âge de l'expansion, les croissances inhabituelles et les conflits avec les données connues de détenteur ou d'origine. Les opérateurs devraient éviter d'accepter une récursion arbitraire à travers toutes les sources sans considérer l'autorité.

Les registres devraient aider les détenteurs à trouver où leurs préfixes et ASN apparaissent dans des ensembles qu'ils ne contrôlent pas. Les principaux IXP et opérateurs devraient publier comment ils gèrent la récursion inter‑sources. Plus un marché dépend de l'automatisation, plus l'automatisation doit expliquer ses hypothèses.

Pour AFRINIC, la récursion des AS‑SET a une dimension de développement régional. Le peering local et le transit régional deviennent moins chers lorsque les filtres peuvent être construits de manière prévisible. Si les petits réseaux ne peuvent pas faire fonctionner leurs AS‑SET à travers les échanges et les fournisseurs, ils peuvent rester dépendants de quelques fournisseurs qui comprennent déjà les rituels. Si des ensembles obsolètes ou trop larges créent des préoccupations de sécurité, les opérateurs de route‑server peuvent resserrer les règles de manière à exclure les mêmes petits réseaux.

Une bonne gouvernance des AS‑SET n'est donc pas seulement une commodité de sécurité. Elle fait partie de la réduction du coût de participation à l'économie de routage.

AFRINIC transforme l'ambiguïté des bases de données en risque institutionnel

Chaque RIR fait face à des données IRR fragmentées. AFRINIC n'est pas unique parce qu'il a des objets route, des enregistrements obsolètes ou des opérateurs qui ne sont pas d'accord sur la politique de source. Il est distinctif parce que l'ambiguïté des bases de données repose sur un stress institutionnel qui a déjà rendu les contreparties sensibles à la continuité. Une crise de gouvernance change la façon dont les défauts techniques ordinaires sont tarifés. Dans une institution calme, un doublon IRR obsolète peut être traité comme un ménage.

Dans une institution stressée, le même doublon peut être interprété comme une preuve que le grand livre ne peut pas policer ses frontières.

L'histoire récente d'AFRINIC comprend des litiges, une gouvernance contestée, une incertitude liée à la mise sous séquestre, des turbulences électorales, une élection de 2025 annulée après des préoccupations signalées d'irrégularités, et des efforts ultérieurs pour restaurer la fonction du conseil. Elle comprend également des préoccupations publiques sur l'intégrité des enregistrements IPv4 historiques et le détournement d'adresses. Ces faits ne doivent pas être utilisés pour condamner chaque enregistrement ou chaque opérateur de la région. Ils ne prouvent pas qu'un objet IRR donné est faux. Mais ils changent le coût de la preuve.

Un tiers regardant un préfixe administré par AFRINIC peut poser plus de questions parce que l'institution autour du grand livre a été visiblement mise à rude épreuve.

C'est là que les données IRR fragmentées deviennent un risque institutionnel. Si un préfixe a une origine dans une source liée à AFRINIC, une autre dans un IRR commercial, et une référence obsolète dans un AS‑SET maintenu par un ancien fournisseur, le conflit technique est aussi un signal de gouvernance. Il dit que le marché ne peut pas facilement voir quelle institution, quelle source et quelle chaîne d'autorité devraient régler la revendication opérationnelle. Dans une région où les adresses sont rares et le registre a été sous pression, cette incertitude attire des primes de risque.

Le danger ne concerne pas seulement les mauvais acteurs. Les réseaux légitimes souffrent de la même décote. Une université publique avec de vieux enregistrements peut être traitée comme suspecte lorsqu'elle change de fournisseur. Un petit FSI peut perdre une opportunité de transit parce que son AS‑SET se développe de manière incohérente. Une agence gouvernementale peut faire face à des semaines d'examen parce que les contacts historiques ne répondent plus. Un centre de données peut avoir du mal à amener l'espace client dans un échange local parce qu'une autre source pointe encore vers un opérateur international.

Ce ne sont pas nécessairement des échecs du personnel d'AFRINIC ou d'un seul opérateur IRR. Ce sont des échecs d'un système de confiance fragmenté à rendre la légitimité ordinaire peu coûteuse.

Le stress institutionnel encourage également l'expansion du mandat. Un registre sous critique peut être tenté de prouver sa vigilance en affirmant un contrôle plus large sur les données de routage, l'utilisation des adresses ou le comportement du marché. Le langage de la souveraineté communautaire peut rendre cette expansion naturelle: parce que le registre sert une région, il devrait décider plus de questions au nom de la région. Mais la coordination technique ne devient pas légitime simplement en invoquant la communauté.

Si le registre devient un gouverneur discrétionnaire du marché, il augmente les enjeux de capture, de litige et de conflit politique. S'il se retire dans une tenue de registres passive alors que des données fragmentées gouvernent l'accessibilité, il échoue au marché d'une autre manière. La voie étroite est une fiabilité renforcée du grand livre sans un gardiennage plus large.

Cette voie nécessite de reconnaître les couches séparées. Le registre des ressources numériques d'AFRINIC est le grand livre durable. Les données IRR sont une publication de politique de routage adjacente à ce grand livre. RPKI et les ROA fournissent des preuves cryptographiques d'origine de route via un mécanisme différent. Les annonces BGP montrent le routage observé, pas l'autorité. Les contrats et les ordonnances judiciaires peuvent décider des droits entre les parties, mais ils ont besoin d'une traduction en signaux opérationnels. Confondre ces couches produit un excès ou une négligence.

Les garder séparées permet à chacune de faire son travail.

Par exemple, si un préfixe contesté de la région AFRINIC a des entrées IRR contradictoires, le registre ne devrait pas avoir à trancher chaque litige commercial avant qu'un enregistrement opérationnel puisse changer. Mais il devrait fournir des procédures claires pour l'autorité de source, les avis, les étiquettes de statut, le signalement des conflits et la correction. Si un détenteur montre qu'un objet obsolète dans une source contrôlée par AFRINIC ne reflète plus sa délégation, le chemin de correction devrait être rapide et vérifiable.

Si un doublon persiste ailleurs, les opérateurs devraient avoir suffisamment de métadonnées de source pour savoir que la source AFRINIC a une posture d'autorité différente. Si une ordonnance judiciaire affecte qui peut agir pour le détenteur, le registre devrait mapper cette ordonnance au grand livre avec soin plutôt que de transformer les filtres de route en instruments juridiques ad hoc.

L'objectif institutionnel est la continuité. Les réseaux ne devraient pas avoir à attendre un calme parfait de gouvernance avant que leurs données de routage deviennent utilisables. La turbulence de gouvernance ne devrait pas non plus être autorisée à transformer des enregistrements IRR ambigus en levier privé. Un registre étroit, procédural et transparent réduit la valeur de la capture institutionnelle. Moins il y a de discrétion attachée à l'ambiguïté de la base de données, moins il y a de prix à contrôler l'institution.

La rareté de l'IPv4 transforme l'ambiguïté en prime

La rareté de l'IPv4 est la force qui convertit la fragilité de l'IRR d'une nuisance technique en un problème économique. Lorsque les adresses étaient abondantes, un bloc en désordre pouvait parfois être remplacé, renuméroté ou ignoré. L'épuisement a changé cela. Un bloc IPv4 routable porte désormais des dépendances clients, un historique de réputation, des listes blanches de pare‑feu, des hypothèses de géolocalisation, des attentes de DNS inverse, des mappings cloud et une valeur d'actif. La capacité à faire accepter ce bloc par les fournisseurs, les IXP et les plateformes cloud fait partie de ce que vaut le bloc.

Un bloc d'adresses n'est pas précieux simplement parce qu'il apparaît dans un registre. Il est précieux parce que les contreparties croient qu'il peut être utilisé. L'utilisabilité dépend d'un empilement de preuves: enregistrements de détenteur de registre, autorité contractuelle, historique de routage, objets IRR, AS‑SET, statut RPKI, réputation d'abus, DNS inverse, approbations d'intégration cloud et filtres d'opérateur. Les données IRR fragmentées se situent au milieu de cet empilement.

Elles sont suffisamment proches des opérations pour affecter l'accessibilité et suffisamment proches du registre pour influencer les perceptions de légitimité. Lorsqu'elles sont en conflit, le bloc devient moins liquide.

Un acheteur voit cela comme un risque de nettoyage. S'il acquiert le bloc, les anciens objets route resteront‑ils? Une ancienne origine apparaîtra‑t‑elle encore dans les filtres? Le vendeur pourra‑t‑il supprimer les doublons obsolètes de sources qu'il ne contrôle pas? Les fournisseurs cloud accepteront‑ils rapidement la nouvelle origine? Un prêteur finançant la transaction considérera‑t‑il la posture de routage comme stable? Chaque réponse incertaine peut changer le prix, les conditions de séquestre ou le calendrier de clôture. Le marché n'a pas besoin de croire que les enregistrements IRR sont des titres de propriété.

Il a seulement besoin de croire que de mauvais enregistrements IRR peuvent retarder la valeur.

Un courtier voit cela comme un risque d'exécution. Les courtiers vendent de la confiance autant qu'ils vendent des introductions. Un bloc avec des données de registre propres mais un historique IRR désordonné nécessite plus d'explications. Si le courtier ne peut pas montrer que le préfixe sera accepté par les principaux fournisseurs de transit et plateformes, l'acheteur peut le décoter. Si le courtier s'appuie sur un objet obsolète pour montrer la routabilité, l'acheteur peut découvrir plus tard que l'acceptation opérationnelle était basée sur des preuves fragiles.

Les données IRR fragmentées transforment le courtage en une forme de diligence sur le routage.

Un prêteur voit cela comme une incertitude de garantie. Les entreprises dépendantes des adresses ne mettent pas toujours en gage des blocs IPv4 de manière simple, mais les prêteurs se soucient toujours de savoir si les actifs réseau qui soutiennent les flux de trésorerie sont stables. Si la capacité d'une entreprise à servir ses clients dépend de préfixes qui nécessitent des exceptions de route manuelles, l'actif est plus faible. Si des enregistrements IRR contradictoires pourraient permettre à un ancien fournisseur ou demandeur de créer de la confusion, le risque est plus élevé.

Si l'environnement du registre est stressé, le prêteur peut demander plus de contrôles. Des données de routage ambiguës deviennent un coût de financement.

Un client voit cela comme une fiabilité de service. Les entreprises, les agences publiques et les utilisateurs cloud ne veulent pas apprendre la différence entre RADB, AFRINIC, la récursion AS‑SET et RPKI. Ils veulent que le réseau de leur fournisseur fonctionne. Lorsqu'une migration échoue parce qu'un route‑server rejette un préfixe, le client subit un retard et de la méfiance. Le fournisseur peut blâmer le registre, l'ancien fournisseur, le nouveau fournisseur ou une source de base de données. Le client entend seulement que l'actif d'adresse était plus difficile à utiliser que promis.

La rareté intensifie la question distributive. Les réseaux plus riches peuvent acheter de l'expertise. Les petits réseaux peuvent payer par le retard. Les opérateurs africains essayant de construire une interconnexion locale peuvent faire face au scepticisme de plateformes mondiales habituées à une documentation plus stricte. Les réseaux du secteur public avec d'anciennes allocations peuvent avoir du mal à se moderniser car les vieux enregistrements ne correspondent pas aux structures d'approvisionnement actuelles. Les universités et les réseaux de recherche peuvent hériter d'enregistrements d'une époque plus informelle.

La prime de marché pour des données IRR propres n'est donc pas seulement une récompense pour une bonne hygiène. C'est aussi une pénalité pour la complexité historique.

La conclusion politique devrait être modeste. AFRINIC ne devrait pas se faire l'arbitre de chaque prix de transfert, location, mise en gage ou décision d'intégration cloud. Cela transformerait un registre en superviseur de marché. Mais il devrait comprendre que les données de routage adjacentes au registre affectent ces décisions. Si la source régionale est prévisible, si les enregistrements obsolètes peuvent être trouvés et corrigés, si l'autorité de source est visible, et si les opérateurs peuvent compter sur des procédures claires, la prime de rareté attachée à l'ambiguïté diminue.

Une bonne gouvernance IRR rend les marchés IPv4 moins féodaux. Une mauvaise gouvernance IRR permet à ceux qui ont une connaissance privée d'extraire de la valeur de l'incertitude des autres.

RPKI aide, mais ne dissout pas la dépendance à l'IRR

RPKI et les autorisations d'origine de route sont souvent présentées comme l'alternative plus propre à l'IRR. Elles sont plus propres pour une question spécifique. Un ROA permet à un détenteur de ressource, dans le cadre du système de certificats de ressources, de déclarer quel AS peut originer un préfixe jusqu'à une longueur maximale définie. Les réseaux effectuant une validation d'origine de route peuvent classer les annonces comme valides, invalides ou non trouvées. C'est une amélioration puissante par rapport aux enregistrements textuels non authentifiés ou faiblement authentifiés.

Elle réduit une classe d'incertitude autour de l'autorité d'origine.

Mais RPKI ne dissout pas le problème IRR. Les opérateurs utilisent encore les données IRR pour les filtres clients, l'expansion des AS‑SET, la politique des route‑sets, les attentes de préfixe maximum et la documentation de la politique de routage. Un ROA peut dire qu'un AS est autorisé à originer un préfixe. Il ne décrit pas le cône client complet derrière un AS de transit. Il ne nettoie pas les AS‑SET obsolètes. Il ne supprime pas les objets route en double des IRR privés. Il n'explique pas pourquoi un dépôt dit qu'un ancien fournisseur origine toujours le bloc.

Il ne dit pas à un courtier si de vieilles références IRR retarderont l'intégration du client chez un opérateur. Il ne décide pas si un objet créé par un fournisseur doit être supprimé après la résiliation du contrat.

RPKI est donc un comparateur et un substitut partiel, pas le centre du problème de fragmentation des sources. Il peut fournir des preuves plus solides pour les revendications préfixe‑origine. Il peut aider les opérateurs à rejeter les annonces incompatibles avec les ROA. Il peut réduire la dépendance à des données IRR faibles pour un sous‑ensemble de décisions. Pourtant, l'économie de routage reste plurielle. Certains réseaux appliquent strictement la ROV. Certains surveillent. Certains utilisent des filtres IRR plus lourdement que RPKI. Certains exigent les deux.

Certains acceptent RPKI pour l'origine mais exigent encore des AS‑SET pour le filtrage du cône client. Le marché n'est pas gouverné par un seul interrupteur de validation.

Dans le cas d'AFRINIC, la valeur de RPKI peut être particulièrement élevée parce que le stress institutionnel rend les preuves d'origine vérifiables par machine attrayantes. Un ROA peut rassurer un fournisseur qu'un détenteur a publié une autorisation d'origine actuelle. Il peut aider un fournisseur cloud à distinguer une nouvelle origine légitime d'un objet IRR obsolète. Il peut donner à un acheteur un élément de diligence plus propre. Mais il ne répond pas à toutes les questions de fragmentation des sources. Un préfixe peut avoir un ROA valide et apparaître encore dans de vieux AS‑SET.

Un route‑server peut utiliser des filtres dérivés de l'IRR qui rejettent la route avant même que RPKI n'ait de l'importance. Un fournisseur peut exiger un enregistrement IRR pour le provisionnement même si RPKI est valide. Les cultures opérationnelles changent lentement.

Il y a aussi une économie politique de la substitution. Si un registre ou une communauté de normes dit « utilisez RPKI et ignorez l'IRR », il peut sous‑estimer les dépendances opérationnelles existantes. Si les opérateurs disent « l'IRR fonctionne assez bien », ils peuvent préserver des chaînes d'autorité faibles. La voie réaliste est l'empilement. RPKI devrait réduire la charge placée sur l'IRR pour la validation d'origine. L'IRR devrait rester utile pour la politique de routage et l'expression du cône client. Là où les deux sont en conflit, les opérateurs devraient avoir des politiques claires sur le signal qui gouverne quelle décision.

Un ROA valide ne devrait pas automatiquement nettoyer chaque AS‑SET obsolète. Un objet IRR obsolète ne devrait pas automatiquement l'emporter sur des preuves d'origine actuelles solides. Chaque signal a un travail.

Cette approche en couches évite également de transformer RPKI en un instrument de propriété trop large. Un ROA n'est pas un acte de propriété, tout comme un objet route n'est pas un acte de propriété. C'est une autorisation de routage cryptographique avec une signification opérationnelle définie. La tentation dans un marché rare est de laisser l'artefact le plus fort devenir la réponse générale à tous les litiges. Ce serait une erreur.

RPKI peut réduire l'ambiguïté sur l'origine de la route, mais les contrats, les enregistrements de registre, l'autorité d'entreprise, les ordonnances judiciaires, les délégations clients et le nettoyage IRR comptent toujours. Le fait qu'une couche soit plus forte n'élimine pas le besoin de cohérence entre les couches.

Pour l'automatisation des route‑servers et du transit, l'amélioration pratique est une politique consciente des conflits. Un système devrait pouvoir dire: le ROA valide cette origine, la source IRR liée à AFRINIC la soutient, un IRR non régional a un doublon obsolète, et un AS‑SET dans une autre source référence encore l'ancien fournisseur. C'est un meilleur signal de marché qu'une acceptation ou un rejet binaire. Il permet à l'opérateur d'accepter la route tout en ouvrant un ticket de nettoyage, ou de rejeter seulement si le conflit atteint un seuil de risque défini. L'objectif n'est pas plus de données pour elles‑mêmes.

L'objectif est un jugement moins cher et plus cohérent.

L'essor de RPKI devrait donc rendre la gouvernance IRR plus disciplinée, pas inutile. À mesure que des preuves d'origine plus solides deviennent disponibles, les données IRR restantes devraient être utilisées pour ce qu'elles font le mieux et nettoyées là où elles causent de la confusion. Le défi d'AFRINIC est de soutenir cette transition sans l'utiliser pour étendre le discrétionnaire. Une sécurité de routage plus forte devrait protéger la fiabilité du grand livre. Elle ne devrait pas donner à l'opérateur du grand livre un mandat plus large pour gouverner les relations de marché par implication.

La question de confiance est différente pour chaque contrepartie

L'expression « à quelle base de données peut‑on faire confiance? » semble singulière. En pratique, la confiance dépend de la contrepartie et de la décision. Un fournisseur, un IXP, un fournisseur cloud, un courtier, un acheteur, un prêteur et un client posent tous des questions différentes aux données IRR. La fragmentation est coûteuse parce que le même conflit doit être traduit dans chaque contexte décisionnel.

Un fournisseur demande s'il peut accepter en toute sécurité l'annonce d'un client. Il se soucie de prévenir les détournements, d'éviter les fuites de routes, de satisfaire la politique interne, de limiter la charge de support et de provisionner les revenus. Il peut accepter un mélange de preuves IRR et RPKI si la relation client est forte. Il peut être plus strict pour les clients nouveaux ou petits. Pour le fournisseur, la confiance dans la base de données est un filtre de risque client. Si les sources sont en conflit, la réponse conservatrice peut être de retarder le service jusqu'à ce que le client nettoie ses enregistrements.

Le coût tombe sur le client.

Un route‑server d'IXP pose une question plus communautaire. Il doit protéger de nombreux entités à la fois. Une mauvaise route peut se propager via le peering multilatéral. Une route rejetée peut réduire la valeur de l'échange pour un membre légitime. Le route‑server est souvent plus guidé par des règles car il ne peut pas négocier privément chaque cas sans nuire à la prévisibilité. Pour l'IXP, la confiance dans la base de données est une politique de risque partagé. La fragmentation des sources peut soit réduire la valeur du peering local, soit augmenter le risque accepté par tous les membres.

Un fournisseur cloud demande s'il peut annoncer l'espace client à grande échelle sans devenir un canal de blanchiment pour des préfixes douteux. Il a besoin d'une intégration standardisée. Il peut préférer des preuves solides de registre et RPKI, mais il rencontre encore des enregistrements IRR lors de la diligence et du filtrage opérationnel. Pour le cloud, la confiance dans la base de données fait partie du risque de plateforme. Un préfixe désordonné de la région AFRINIC peut ne pas être rejeté par préjugé; il peut être retardé parce que la plateforme ne peut pas résoudre les contradictions à faible coût à grande échelle.

L'effet économique sur le détenteur est le même.

Un courtier demande si le bloc d'adresses peut être vendu, loué ou présenté sans surprises. Il se soucie de la confiance, du prix et du calendrier de clôture. Les données IRR fragmentées sont un défaut à divulguer, nettoyer ou décoter. Pour le courtier, la confiance dans la base de données est la commercialisabilité. Les doublons obsolètes et les origines conflictuelles réduisent la promesse que l'acheteur peut utiliser le bloc rapidement. Le courtier peut ne contrôler aucune base de données, mais il doit vendre autour des défauts des bases de données.

Un acheteur demande s'il recevra un actif qui fonctionne opérationnellement après la clôture. Le transfert de registre seul ne suffit pas si de vieux objets route, des références AS‑SET ou des conflits de source bloqueront le déploiement. L'acheteur peut exiger une remédiation avant le paiement ou retenir des fonds jusqu'à ce que les opérateurs acceptent la nouvelle origine. Pour l'acheteur, la confiance dans la base de données est l'utilisabilité après clôture. L'ambiguïté devient un terme de prix.

Un prêteur demande si les revenus dépendant des adresses sont résilients. Il peut ne pas comprendre chaque objet RPSL, mais son conseiller technique traduira le conflit de base de données en risque opérationnel. Si les préfixes d'un emprunteur dépendent d'exceptions manuelles des opérateurs ou de litiges de registre non résolus, le prêteur voit de la fragilité. Pour le prêteur, la confiance dans la base de données est un soutien aux flux de trésorerie. Cela affecte le crédit même lorsque le prêt n'est pas directement garanti par les adresses.

Un client pose la question la plus simple: le service fonctionnera‑t‑il? Il peut ne pas savoir quelle base de données un route‑server a utilisée. Il voit seulement qu'une migration stagne, qu'un préfixe est rejeté ou qu'un fournisseur ne peut pas expliquer pourquoi l'acceptation diffère selon les réseaux. Pour le client, la confiance dans la base de données est la crédibilité du service. Lorsque les fournisseurs se cachent derrière des « problèmes IRR » sans explication claire, les clients apprennent que la plomberie invisible du marché n'est pas fiable.

Ces différences comptent pour AFRINIC car une réponse centrée sur le registre seule ne satisfera pas tous les besoins de confiance. Le registre peut rendre sa source plus propre, fournir des chemins de correction, publier des métadonnées de conflit et améliorer la continuité sous stress. Chaque contrepartie choisira encore comment utiliser les données. L'objectif n'est pas une confiance uniforme mais des faits cohérents: ce que la source prouve, ce qu'elle ne prouve pas, comment les conflits sont étiquetés, comment les données obsolètes sont corrigées et comment les tiers peuvent élaborer des politiques sans deviner.

La confiance ne se commande pas. Elle se rend moins chère.

Une norme étroite pour la confiance dans la région AFRINIC

Une norme pratique pour la confiance dans l'IRR de la région AFRINIC devrait commencer par l'humilité sur ce que prouve un artefact unique. Un objet route prouve qu'une déclaration préfixe‑origine existe dans une source selon les règles de cette source. Un objet route6 fait de même pour IPv6. Un mntner prouve qui peut authentifier certains changements de base de données, pas qui détient chaque mandat sous‑jacent. Un AS‑SET décrit les relations de routage prévues mais peut des données obsolètes ou inter‑sources.

Un ROA fournit une preuve cryptographique plus solide de l'origine, mais pas une carte complète des cônes clients, de l'autorité commerciale ou du nettoyage de base de données. Le BGP observé montre ce qui se passe, pas nécessairement ce qui est autorisé.

De cette humilité découle une hiérarchie. Pour les ressources administrées par AFRINIC, la source liée à AFRINIC et la politique de routage devraient avoir un poids probant élevé lorsqu'elles sont à jour, procéduralement propres et transparentes. Les entrées IRR non AFRINIC devraient rester utilisables, mais les opérateurs ne devraient pas prétendre que chaque objet RPSL repose sur la même fondation d'autorité. RPKI devrait renforcer l'assurance d'origine. L'expansion des AS‑SET devrait être traitée comme une chaîne dont les sources, les âges et les références inter‑sources comptent.

Les exceptions manuelles devraient être temporaires et journalisées. Les doublons obsolètes devraient être visibles et corrigibles.

L'alternative tentante est la centralisation: rendre une source décisive et exiger que tous les acteurs du marché s'y conforment. Cela répondrait à la fragmentation en transformant un grand livre en un gardien. AFRINIC devrait éviter cette voie. Sa valeur n'est pas d'approuver chaque transfert, location, intégration cloud ou changement de fournisseur. Sa valeur est de protéger un grand livre de continuité étroit afin que d'autres puissent prendre leurs propres décisions de routage et commerciales à moindre coût. Le langage de mandat ne devrait pas blanchir un rôle de coordination technique en contrôle discrétionnaire du marché.

L'étroitesse ne signifie pas la faiblesse. Une source fiable peut encore avoir une authentification forte, des contrôles d'autorisation proportionnels, des chemins de correction clairs, des étiquettes de conflit, des métriques publiques et des procédures de continuité. Les mises à jour de routine par des mainteneurs stables devraient être faciles. Les changements qui modifient l'AS d'origine, suppriment un ancien fournisseur, ajoutent de larges cônes clients, affectent des blocs IPv4 rares ou surviennent pendant des litiges d'entreprise ou de gouvernance devraient nécessiter plus de preuves et de préavis.

Le test est la proportionnalité: trop peu de preuves invite à l'abus; trop de preuves fige les opérations ordinaires.

Le préavis devrait faire partie de cette proportionnalité. Si un changement devait déplacer une origine existante ou supprimer un objet utilisé par des filtres, les contacts affectés devraient être notifiés lorsque c'est faisable: détenteur de la ressource, mainteneur existant, origine proposée, origine actuelle et contacts opérationnels pertinents. Le préavis ne devrait pas devenir un veto. C'est un moyen de faire surface aux erreurs avant qu'elles ne deviennent des pannes. Lorsque l'urgence nécessite une action d'urgence, l'action devrait être temporaire, journalisée et révisée.

Les métriques rendraient la norme crédible. AFRINIC et les principaux opérateurs devraient pouvoir mesurer la fréquence à laquelle les préfixes administrés par AFRINIC ont des objets route ou route6 contradictoires entre sources, la fréquence à laquelle les expansions d'AS‑SET diffèrent selon l'ordre des sources, l'âge des doublons obsolètes, la fraîcheur des miroirs, le temps de correction et le nombre de clients nécessitant des exceptions manuelles. Ces chiffres n'ont pas besoin d'exposer les fichiers clients privés. Ils diraient au marché si la fragmentation est une anecdote, un impôt chronique ou une condition en amélioration.

La même discipline devrait s'appliquer aux outils. Les systèmes de filtrage devraient exposer le chemin de source: quelle source, objet, chaîne AS‑SET et règle de récursion a produit l'acceptation ou le rejet. Les détenteurs devraient pouvoir découvrir où leurs préfixes et ASN apparaissent dans les principales sources IRR et route‑sets. Les route‑servers devraient rapporter des catégories de rejet compréhensibles pour les membres. Les enregistrements historiques devraient être conservés pour l'audit, mais les orientations sur l'état actuel devraient être suffisamment claires pour que les opérateurs les utilisent.

L'objectif n'est pas une base de données parfaite. C'est un environnement de base de données dans lequel l'incertitude est étiquetée, délimitée et peu coûteuse à réduire.

Cette norme faciliterait la vie de l'ingénieur du route‑server confronté au travail de filtrage de l'aube. Si plusieurs sources donnaient des réponses contradictoires, l'outillage montrerait la fraîcheur, la posture d'autorité, le chemin de source et l'âge du conflit. Un ROA valide serait pesé pour l'assurance d'origine mais pas utilisé pour ignorer les AS‑SET obsolètes. La source liée à AFRINIC serait digne de confiance parce que ses procédures étaient visibles, pas parce que l'institution exigeait de la déférence. Les sources externes seraient considérées avec leurs limites.

Le client recevrait un chemin de nettoyage clair plutôt qu'un rejet mystérieux. Le jugement serait toujours nécessaire, mais il serait moins cher.

Le coût de ne pas réparer la fragmentation

Si la fragmentation de l'IRR reste non gérée, le marché trouvera encore des moyens de router. L'Internet est bon pour router autour des faiblesses institutionnelles. Cette résilience ne doit pas être confondue avec la santé.

La voie de contournement est prévisible: les grands opérateurs construisent des systèmes de confiance privés, les plateformes imposent une intégration plus stricte, les petits réseaux dépendent des opérateurs historiques, les courtiers tarifient le risque de nettoyage, les route‑servers resserrent leurs politiques et les clients apprennent que les services dépendant des adresses dans certaines régions nécessitent plus d'explications. Les paquets peuvent encore circuler, mais la participation devient plus chère et moins égale.

Pour AFRINIC, ce résultat serait dommageable car la région a besoin de coûts de coordination plus faibles, pas plus élevés. L'interconnexion locale, la localisation du cloud, les services numériques du secteur public, les réseaux universitaires, la livraison de contenu régionale et la concurrence des petits fournisseurs dépendent tous d'une acceptation prévisible du routage. Si chaque migration ou intégration peut être ralentie par des sources de bases de données contradictoires, la région paie un impôt silencieux.

L'impôt se manifeste par des projets retardés, une dépendance plus élevée au transit, des positions de négociation plus faibles, des valeurs d'actifs plus basses et une plus grande dépendance aux intermédiaires extérieurs à la région.

La sécurité ne s'améliorerait pas nécessairement. Des politiques trop strictes peuvent réduire certaines mauvaises routes, mais elles poussent également les opérateurs légitimes vers des exceptions manuelles. Des politiques trop souples maintiennent une autorité obsolète en vie. Les contournements privés rendent le système moins transparent. Le meilleur résultat de sécurité vient de preuves cohérentes: données actuelles liées au détenteur, AS‑SET propres, RPKI là où c'est approprié, conflit de source visible et correction rapide. La fragmentation sans gestion ne produit ni ouverture ni sécurité. Elle produit une opacité sélective.

Le coût institutionnel serait tout aussi grave. Un registre en convalescence après des turbulences de gouvernance doit montrer que ses fonctions d'utilité de base sont fiables. La cohérence de l'IRR est l'une de ces fonctions car elle se situe près des opérations quotidiennes. Si AFRINIC peut rendre les données de politique de routage plus propres, plus transparentes et plus faciles à corriger, il renforcera la confiance dans le grand livre sans demander au marché une confiance aveugle. S'il ne le peut pas, les contreparties créeront leurs propres systèmes de confiance.

Une fois ces systèmes durcis, la fonction publique du registre régional devient moins centrale et les gardiens privés deviennent plus puissants.

Le coût de marché augmentera à mesure que la rareté de l'IPv4 persiste. La rareté augmente la valeur de chaque ambiguïté qui peut affecter l'utilisation: un objet route obsolète, une entrée AS‑SET manquante, un décalage de miroir, une préférence de source ou un litige de gouvernance. Les données IRR fragmentées transforment de petits défauts techniques en options économiques détenues par quiconque peut les exploiter ou les résoudre.

La réponse n'est pas une nouvelle revendication dramatique de souveraineté sur le routage. C'est une réduction disciplinée de l'ambiguïté. AFRINIC devrait être une utility de continuité étroite pour les ressources qu'il administre, avec un support de politique de routage suffisamment fiable pour que les tiers l'utilisent et suffisamment limité pour ne pas devenir un commandement de marché. Les opérateurs devraient publier comment ils consomment les sources et gèrent les conflits. Les principales sources IRR devraient améliorer la découverte des objets obsolètes et le contexte d'autorité.

Les IXP et les opérateurs devraient rendre les filtres des route‑servers et les décisions de filtrage client explicables. Les acheteurs, courtiers et prêteurs devraient traiter la posture IRR comme une diligence, pas comme un folklore.

Le travail du route‑server à l'aube ne devrait pas avoir à décider de l'avenir institutionnel de la numérotation Internet africaine. Il devrait avoir à décider si une route peut être acceptée en toute sécurité selon une politique claire. C'est déjà assez difficile. Les données IRR fragmentées le rendent plus difficile en présentant plusieurs passés plausibles comme s'ils étaient des présents égaux. Dans un marché construit sur des nombres rares et une interconnexion volontaire, cette confusion a un prix.

L'opportunité d'AFRINIC est de réduire ce prix. Pas en devenant un gardien sur chaque usage commercial de l'IPv4. Pas en demandant aux opérateurs d'ignorer les sources non régionales. Pas en prétendant que RPKI élimine les bases de données de politique de routage. L'opportunité est plus étroite et plus précieuse: rendre le grand livre lié à AFRINIC et sa source de politique de routage fiables, exposer les conflits, préserver l'histoire, accélérer la correction, séparer l'authentification de l'autorisation, et aider les opérateurs à voir quelle affirmation de base de données repose sur quelle fondation institutionnelle.

Si cela se produit, les données IRR reviennent à leur rôle économique approprié. Elles deviennent un moyen de rendre la confiance moins chère, plutôt qu'une raison pour chaque réseau d'acheter sa propre carte privée du doute.