AFRINIC et l'économie de la fragilité des bases de données IRR

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

Le travail du serveur de routes s'exécute avant l'aube parce que le point d'échange veut ses filtres prêts avant le début de la journée ouvrable. Il interroge plusieurs sources du Registre de Routage Internet (IRR), actualise les données miroir, développe les AS-SET des membres, construit des listes de préfixes et des vérifications d'origine, et émet une configuration qui décidera quelles annonces le point d'échange accepte. La plupart des matins sont sans incident. Ce matin-là, le travail s'arrête sur un préfixe IPv4 administré par l'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 amont. Une autre a un objet plus récent pour un réseau client qui indique qu'il a déménagé vers un centre de données régional. Une troisième source fait miroiter une entrée plus ancienne qui semble encore plausible parce que le nom du mainteneur ressemble à celui du détenteur des ressources. 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 parce qu'un jeu de routes fait référence à un AS-SET qui existe dans un dépôt différent. Une vérification RPKI publique aide pour une partie de la question mais n'explique pas pourquoi les vues IRR divergent ou quelle relation opérationnelle est actuelle. L'ingénieur du point d'échange peut rejeter la route, l'accepter, faire une exception manuelle, demander des lettres, ou retarder 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 seul objet route puisse être erroné, obsolète ou difficile à corriger. Le problème plus large est que les données de politique de routage sont réparties entre plusieurs dépôts ayant des historiques, des règles de mise à jour, des pratiques d'authentification, des calendriers de 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 choisi, via des outils qui font des hypothèses sur les doublons, la récursivité, l'appartenance aux jeux de routes et la préférence de source. Lorsque ces hypothèses se heurtent à des enregistrements contradictoires, la conception de la base de données devient un événement économique.

Les parties prenantes sont plus larges que les ingénieurs réseau. Un fournisseur de transit a besoin de savoir à quelle source se fier avant le provisionnement. Un fournisseur de cloud a besoin de confiance avant d'annoncer l'espace client. Un serveur de routes 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 déprimeront pas le prix ou ne retarderont pas le transfert. Un acheteur, un prêteur ou un assureur doit savoir si l'acceptation opérationnelle survivra à la due diligence. Un client achetant de la connectivité ne se soucie pas de la syntaxe RPSL, mais il en ressentira le coût si les routes ne sont pas acceptées rapidement.

L'AFRINIC est le test de résistance utile parce que son environnement institutionnel rend le coût caché visible. La région a fait face à une longue crise de gouvernance, des litiges, des questions de redressement judiciaire, des turbulences électorales et des préoccupations publiques concernant l'intégrité des enregistrements d'adresses historiques. La rareté d'IPv4 a rendu chaque bloc routable plus conséquent économiquement. Dans ce contexte, les données de routage adjacentes au registre ne sont pas un appendice administratif. Elles deviennent une partie de l'infrastructure de confiance du marché. Si les données sont cohérentes, des tiers peuvent dire oui à moindre coût. Si elles sont fragmentées, chaque entité doit décider du niveau de risque juridique, opérationnel et réputationnel à absorber.

Le bon cadre n'est pas la loyauté institutionnelle. Ce n'est pas que l'AFRINIC, ou tout autre RIR, devrait se voir accorder la confiance parce qu'il revendique un mandat communautaire. Ce n'est pas non plus que les IRR privés devraient être fiables 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 de numérotation rare, à quelle réponse un fournisseur amont, un point d'échange, une plateforme cloud, un courtier, un acheteur, un prêteur ou un client devrait-il se fier, et qui paie lorsque la réponse est erronée?

RPSL a rendu la politique de routage lisible, pas auto-validée

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, en 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 les configurations privées des routeurs et les fils de courriels. RPSL, défini dans la RFC 2622, a donné aux opérateurs un langage structuré pour exprimer cette politique. Il inclut 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 dans une forme que le logiciel peut 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 changements 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 larges car la sortie devient une politique de 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 au lieu d'être construits manuellement. Les changements pourraient être examinés par rapport à un modèle de politique visible. Les erreurs seraient plus faciles à détecter. La coordination à l'échelle d'Internet aurait une grammaire commune. La RFC 2725, rédigée alors que les préoccupations de sécurité autour de l'IRR augmentaient, a saisi 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 strictes. Une base de données de coordination maintenue de manière lâche est une chose. Une base de données qui alimente les filtres en est une autre.

RPSL n'a pas rendu les données auto-validées. 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 actuel, que le mainteneur représente toujours la partie concernée, qu'un doublon ailleurs est faux, ou qu'une expansion de route-set à travers les sources reflète les relations commerciales actuelles. Le format rend une revendication lisible par machine. Il ne rend pas la revendication vraie.

Cette limitation importait moins autrefois parce que les enjeux étaient plus faibles et la culture opérationnelle était davantage axée sur les relations. Le marché moderne est moins indulgent. IPv4 est rare; l'automatisation est plus profonde; l'intégration cloud, les serveurs de routes, 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 à se coordonner influence maintenant la capacité du capital, de la connectivité et des relations clients à se déplacer.

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 devrait 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 registre. Elle devrait enregistrer, authentifier et exposer les déclarations opérationnelles de manière à réduire l'incertitude. Elle ne devrait 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 de nombreux dépôts, chacun avec un modèle d'autorité différent, alors le marché reçoit des déclarations qui semblent comparables mais reposent sur des fondations différentes. L'objet route dans une source peut être étroitement lié à un enregistrement de détenteur 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 en miroir peut être en retard sur 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 un péage pour le marché

La fragmentation est parfois décrite comme une nuisance pour les outils de filtrage. C'est trop faible. Dans un marché d'adresses rares, les données IRR fragmentées sont un système de péage. Elle taxe chaque partie qui doit enquêter, expliquer, concilier, passer outre, documenter ou assurer autour d'enregistrements contradictoires. Le péage n'est pas versé à un seul collecteur. Il est payé en main-d'œuvre, en retards, en décotes de risque, en intégrations échouées, en peering bloqué, en exceptions manuelles, en examens juridiques et en 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 font autorité pour la région de ressources, si les copies en 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 devrait pouvoir supplanter une entrée manquante ou obsolète dans une source liée à un RIR. Un petit réseau ne voit qu'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 rapidement le service.

Le deuxième coût est l'explication. Lorsqu'un client dit « l'objet route est là », le fournisseur amont doit demander où. Si l'objet est dans RADB mais pas dans l'IRR RIR pertinent, 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 l'emporte? Si le client a un AS-SET qui s'étend sur plusieurs dépôts, le fournisseur amont 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 font ressembler la connectivité à des litiges sous un autre nom.

Le troisième coût est l'asymétrie des compétences. Les grands opérateurs peuvent maintenir des équipes de registre, élaborer des politiques spécifiques à la source, effectuer des vérifications régulières des objets obsolètes, surveiller les différences de filtres et savoir qui contacter. Les petits FAI, universités, agences publiques et entreprises africains peuvent ne pas avoir cette capacité. Ils peuvent hériter d'anciens enregistrements de sous-traitants. Ils peuvent compter sur les fournisseurs amont pour créer des objets. Ils peuvent ne pas savoir qu'un doublon dans un IRR éloigné affectera un serveur de routes dans un marché différent. La fragmentation favorise donc les acteurs ayant suffisamment d'échelle 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 une retenue de garantie. Si un prêteur voit que le service dépendant des 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 de 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. Il suffit qu'ils rendent 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 réseaux en aval qui n'appartiennent plus. Le retard de miroir peut donner l'impression qu'un enregistrement corrigé n'est pas 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 confiance à toutes les sources sans discernement, ils élargissent la surface d'attaque. S'ils réagissent en ne faisant confiance qu'à une liste étroite de sources, des réseaux légitimes avec des enregistrements incomplets peuvent être exclus. La fragmentation oblige la politique de sécurité à choisir parmi des maux 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 parce qu'ils savent comment fonctionne la correction. Sous stress, chaque ambiguïté est interprétée de manière plus sombre: objet obsolète, faible contrôle des enregistrements, lacune administrative, verrouillage du détenteur, ou contournement du registre régional? L'histoire récente de l'AFRINIC rend ces questions plus difficiles à écarter. Le problème des 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 ne les maintiennent pas.

La fragmentation change donc la signification é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 transférer le coût vers l'extérieur. Le serveur de routes, le fournisseur amont, 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 laisse pas d'é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. Il aborde le filtrage des préfixes, les filtres clients dérivés des registres de routage, la récursivité AS-SET, la nécessité d'actualiser les filtres et la difficulté de choisir quelles 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 revendications de base de données sont assez bon marché pour s'y fier et lesquelles nécessitent une escalade manuelle ou un rejet.

Considérons un opérateur qui accepte les objets d'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 se trouvent 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écursivité 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 nuire aux clients légitimes dont les enregistrements étaient historiquement maintenus ailleurs ou dont les objets créés par le fournisseur se trouvent en dehors de la source régionale. Un troisième opérateur peut utiliser un ordre de préférence des sources, en 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 la main-d'œuvre au client et peut exclure les petits réseaux. Une politique laxiste fait accepter les routes 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 goulets 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 l'AFRINIC, la sélection de source est particulièrement sensible parce que les enregistrements de la région peuvent porter plusieurs historiques à la fois. Un préfixe peut avoir un ancien objet route dans un IRR commercial parce qu'un fournisseur amont l'a créé bien avant que le détenteur n'utilise les propres outils IRR de l'AFRINIC. Il peut avoir un objet lié à l'AFRINIC créé lors d'un nettoyage ultérieur. Il peut avoir des références de route-set qui supposent un outillage de type RIPE parce qu'un fournisseur de transit européen maintenait la politique du client. Il peut avoir des entrées IRR privées utilisées par un fournisseur de cloud ou de 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.

La préférence de source conflictuelle affecte également la concurrence entre les fournisseurs. Si la politique d'un fournisseur amont dominant accepte un ensemble plus large de sources, il peut intégrer des clients plus rapidement qu'un petit fournisseur avec des filtres plus stricts. Si une plateforme cloud exige un type de nettoyage et un fournisseur de transit en exige un autre, le client peut choisir la voie de moindre friction administrative plutôt que le meilleur service technique. Si un serveur de routes 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 aussi devenir une forme cachée de choix juridictionnel. Un objet route pour un préfixe administré par l'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 de l'AFRINIC. Un opérateur qui accepte cet objet ne transfère pas formellement l'autorité loin de l'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, pas celle qui reflète le mieux le registre 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 opérateurs de serveurs de routes devraient publier comment ils utilisent les sources, comment ils traitent les doublons, à quelle fréquence ils actualisent les miroirs, comment ils traitent les conflits entre les 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 savoir à 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 de l'AFRINIC, la priorité institutionnelle devrait être de rendre la source liée à l'AFRINIC suffisamment prévisible pour que les opérateurs aient moins de raisons de chercher dans toutes les bases de données la réponse qu'ils préfèrent. Cela ne signifie pas faire de l'AFRINIC un régulateur du marché. Cela signifie renforcer la fonction de registre pour que la source régionale devienne un point de référence à faible coût. Protégez le registre, 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 retard de miroir et les doublons obsolètes créent une fausse continuité

Les données IRR transitent souvent par des miroirs. La mise en miroir est utile parce que 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 être en retard par rapport à la source faisant autorité. Il peut préserver une vue après une correction. Il peut échouer en silence. Il peut mettre à jour une source tandis qu'une autre reste obsolète. Il peut donner à l'automatisation l'impression qu'un enregistrement existe encore ou a encore une certaine origine alors que le dépôt sous-jacent a évolué.

Le retard de miroir est facile à sous-estimer parce que la plupart des retards sont inoffensifs. Si une actualisation de filtre a quelques heures de retard sur une mise à jour de routine d'un route-set, rien de dramatique ne se produit. Le problème n'est pas le retard moyen. C'est le retard lors de changements contestés ou à signification économique. 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 serveur de routes IXP s'actualise à partir d'une copie en retard et continue d'accepter une route que le détenteur pense avoir été 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é, donc le ticket est bloqué. La différence entre une vue actuelle et obsolète devient une interruption des activités.

Les doublons obsolètes sont plus durables que le retard de miroir. Un objet en double peut rester dans une autre source longtemps après la fin de la relation commerciale initiale. L'ancien fournisseur amont peut l'avoir créé pour un client et ne l'a 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 parce que l'objet n'est pas lié au registre des ressources de cette source. Des années plus tard, les filtres automatisés voient toujours une revendication plausible préfixe-origine. Si le détenteur actuel veut changer de fournisseur, il peut devoir expliquer pourquoi l'ancien objet ne devrait pas gouverner l'acceptation. Si un acteur malveillant cherche 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 donne à une relation passée l'apparence du présent. Un objet en miroir donne à une vue corrigée l'apparence non résolue. Un AS-SET récursif qui inclut un ancien réseau en aval fait paraî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é ». Il suffit qu'elle soit consommée par suffisamment d'outils pour créer une dépendance. Dans un marché où la vitesse compte, la continuité apparente a de la valeur. Elle permet à une partie de dire « les données ont toujours ressemblé à cela », même lorsque la survie des données est un échec de maintenance.

Le contexte de l'AFRINIC augmente le prix de la fausse continuité. Les préoccupations historiques concernant l'intégrité des enregistrements font que les données dormantes ou obsolètes ne sont pas simplement du désordre. Elles peuvent devenir une ombre probatoire autour d'un 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 de cloud peut demander si une origine précédente apparaît encore là où il consomme. Un courtier peut avoir besoin de nettoyer les anciennes références de route-set avant la clôture. Un fournisseur amont peut refuser d'accepter une nouvelle origine tant que l'ancienne n'a pas été supprimée. Chaque étape est rationnelle, mais ensemble, elles transforment le nettoyage fragmenté de la base de données en une condition préalable du 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 donner la priorité au nettoyage pour un client perdu. Un revendeur peut préférer des AS-SET larges parce qu'ils facilitent l'intégration. Une source faible peut préférer le volume et la commodité aux vérifications rigoureuses de l'autorité. 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 du cycle de vie. Les enregistrements utilisés pour les filtres de routage ont besoin d'horodatages, de la provenance de la source, de la visibilité de la suppression, du statut de 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 grands opérateurs IRR devraient faciliter le nettoyage pour les détenteurs qui peuvent prouver l'autorité actuelle, tout en préservant suffisamment d'historique d'audit pour empêcher la réécriture furtive. Le logiciel de serveur de routes devrait 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 un 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 les blocs IPv4 rares, l'intégration cloud et la diligence financière dépendent d'enregistrements que les étrangers ne peuvent pas facilement interpréter. Dans cet environnement, un doublon obsolète n'est pas seulement un vieil objet. C'est une revendication sur le coût de la 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 les informations d'identification du mainteneur? Le mot de passe, la clé PGP, le compte du portail ou une autre méthode étaient-ils valides? La mise à jour a-t-elle été soumise par 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 pour l'économie de l'IRR fragmenté.

L'authentification prouve le contrôle d'une information d'identification. L'autorisation demande si le détenteur de l'information d'identification avait le droit de faire cette déclaration de politique de routage particulière 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 réseau 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é corporative sous-jacente est contestée. Des contrôles de connexion forts réduisent l'usurpation d'identité; ils ne répondent pas au mandat.

La fragmentation multiplie le problème parce que chaque source peut tracer la ligne authentification-autorisation différemment. Un dépôt peut lier étroitement la création d'un objet route à un détenteur de ressources 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 les anciens objets selon des pratiques héritées. Un quatrième peut permettre aux mainteneurs fournisseurs de créer des objets clients pour des raisons de commodité opérationnelle. Lorsque les filtres les consomment tous 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 la 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, liquidation ou conflit de conseil d'administration? 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 devrait-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 parce que les marchés aiment les informations d'identification. Les informations d'identification sont rapides. Elles s'intègrent dans les logiciels. Elles permettent de fermer les tickets. L'autorisation est plus lente. Elle implique des contrats, des lettres, l'autorité corporative, les enregistrements du registre, le contexte historique et parfois la loi. Un marché sous pression sera tenté d'accepter l'authentification comme substitut de l'autorisation parce que le retard coûte cher. Cette tentation crée une surface d'attaque pour quiconque peut conserver ou obtenir des informations d'identification sans autorité actuelle. Elle crée également une barrière pour les détenteurs légitimes qui manquent d'anciennes informations d'identification mais peuvent prouver leur droit actuel.

L'erreur inverse est également coûteuse. Si chaque mise à jour de l'IRR nécessite une preuve complète de l'autorité sur les ressources, les changements de routage de routine deviennent trop coûteux. Les petits opérateurs éviteront de mettre à jour les enregistrements. Les fournisseurs conserveront des AS-SET larges pour réduire les frictions. Les clients se fieront à des lettres privées et à des exceptions manuelles. Les filtres deviendront moins précis parce que le coût d'une publication précise est trop élevé. L'objectif n'est pas une documentation maximale. C'est une autorisation proportionnelle: plus de preuves pour les changements qui modifient le risque ou la signification économique, moins de friction pour la maintenance courante stable, une correction rapide lorsque l'autorité obsolète est évidente, et une notification claire 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 ressources devrait pouvoir être distingué de celui créé par un mainteneur fournisseur. Un enregistrement lié à la confirmation de l'AS d'origine devrait pouvoir être distingué d'un objet hérité historique. Un objet contesté ou récemment corrigé devrait porter un statut suffisamment visible pour que les opérateurs le traitent avec précaution. 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é à partir de la syntaxe de l'objet et des noms des mainteneurs.

C'est là que le principe de la continuité étroite importe. Les registres devraient agir comme des utilitaires de continuité, pas comme des gouverneurs discrétionnaires de chaque utilisation du marché. Ils devraient maintenir le registre suffisamment fiable pour que des tiers puissent interpréter les déclarations opérationnelles. Ils devraient résister au blanchiment de mandat, où une large invocation de la communauté ou de la gestion transforme la coordination technique en contrôle institutionnel sur les résultats commerciaux. Mais ils devraient aussi résister à l'échec inverse, où une faible hygiène d'authentification permet aux anciennes informations d'identification et aux sources fragmentées de gouverner l'accessibilité actuelle. Un utilitaire étroit a encore besoin de procédures solides. Il utilise simplement les procédures pour protéger la confiance, pas pour accumuler un pouvoir discrétionnaire.

La récursivité des AS-SET fait voyager loin les petites erreurs

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 devraient être traités comme faisant partie de son cône client ou de sa politique de routage. Un fournisseur de transit peut demander à un client un AS-SET, le développer récursivement, trouver les ASN à l'intérieur, puis construire des filtres pour les préfixes associés à ces ASN. Sans cette machinerie, la maintenance des filtres clients serait bien plus manuelle. Avec elle, un seul serveur de routes ou opérateur peut traiter automatiquement de nombreuses relations de routage.

Le danger est la récursivité. Un AS-SET peut inclure d'autres AS-SET. Ces AS-SET peuvent se trouver dans différentes sources. Ils peuvent inclure des ASN clients obsolètes, des revendeurs en aval, des route-sets, ou des objets maintenus selon des normes d'autorité différentes. L'expansion peut dépendre de la source. Un outil qui recherche dans toutes les sources peut produire un ensemble plus grand qu'un outil qui se restreint aux sources préférées. Un outil qui s'arrête à la première correspondance peut considérer 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 à travers une chaîne que personne n'a récemment auditée. La mise en garde de la RFC 7454 concernant la récursivité 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 où 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écursivité peut être masqué par des couches commerciales ordinaires. Un petit FAI achète du transit à 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 de l'AFRINIC, d'autres d'autres régions, certains loués ou délégués, d'autres déplacés vers des fournisseurs de cloud ou de DDoS. Les objets ont été créés sur de nombreuses années par différents mainteneurs. Lorsqu'un serveur de routes IXP développe l'AS-SET de premier niveau, il peut tout un historique 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 réseaux en aval légitimes peuvent disparaître.

L'effet économique est d'échelle. Un seul objet route obsolète affecte une seule revendication préfixe-origine. Un membre d'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 augmente avec chaque couche d'indirection. Cela fait de l'hygiène des AS-SET un problème de marché. Le coût d'un ensemble inexact n'est pas supporté seulement par le mainteneur, mais par chaque fournisseur amont, serveur de routes, client et pair qui dépend de son expansion.

La récursivité crée également de l'opacité. Un client peut ne pas savoir pourquoi le filtre d'un fournisseur amont 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 « discordance IRR » alors que le vrai problème est que l'AS du client est absent d'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 discutent du préfixe visible tandis que la cause se trouve dans une chaîne cachée d'objets RPSL.

Pour les fournisseurs de cloud et les grands réseaux de contenu, le problème des AS-SET recoupe l'échelle de l'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 pour les clients. Une gestion laxiste 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 due diligence. Un bloc peut sembler propre dans les enregistrements du 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 significatives sur le plan opérationnel, 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'ensemble en double, les références inter-sources, l'âge de l'expansion, la croissance inhabituelle et les conflits avec les données connues du détenteur ou de l'origine. Les opérateurs devraient éviter d'accepter une récursivité arbitraire à travers toutes les sources sans tenir compte de 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 grands IXP et opérateurs devraient publier comment ils traitent la récursivité inter-sources. Plus un marché dépend de l'automatisation, plus l'automatisation doit expliquer ses hypothèses.

Pour l'AFRINIC, la récursivité 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 points d'échange et les fournisseurs amont, 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 serveurs de routes peuvent resserrer les règles d'une manière qui exclut ces mêmes petits réseaux. Une bonne gouvernance des AS-SET n'est donc pas seulement une commodité de sécurité. Cela fait partie de la réduction du coût de participation à l'économie du routage.

L'AFRINIC transforme l'ambiguïté de la base de données en risque institutionnel

Chaque RIR fait face à des données IRR fragmentées. L'AFRINIC n'est pas unique parce qu'il a des objets route, des enregistrements obsolètes ou des opérateurs en désaccord sur la politique de source. Il est distinctif parce que l'ambiguïté de la base 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 de la maintenance. Dans une institution stressée, le même doublon peut être interprété comme la preuve que le registre ne peut pas surveiller ses bordures.

L'histoire récente de l'AFRINIC comprend des litiges, une gouvernance contestée, une incertitude liée à une mise sous séquestre, des turbulences électorales, une élection de 2025 annulée après des préoccupations d'irrégularités signalées, et des efforts ultérieurs pour restaurer la fonction du conseil. Elle comprend également des préoccupations publiques concernant l'intégrité des enregistrements IPv4 historiques et le détournement d'adresses. Ces faits ne devraient 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 examinant un préfixe administré par l'AFRINIC peut poser plus de questions parce que l'institution autour du registre 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 à l'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é devrait régler la revendication opérationnelle. Dans une région où les adresses sont rares et où 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 d'anciens enregistrements peut être traitée comme suspecte lorsqu'elle change de fournisseur. Un petit FAI peut perdre une opportunité de transit parce que son AS-SET s'étend 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 de l'AFRINIC ou d'un quelconque opérateur IRR. Ce sont des échecs d'un système de confiance fragmenté à rendre la légitimité ordinaire bon marché.

Le stress institutionnel encourage également l'expansion du mandat. Un registre sous le feu des critiques 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 donner à cette expansion une apparence naturelle: parce que le registre dessert une région, il devrait décider de 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 replie dans une tenue de registres passive tandis que les données fragmentées gouvernent l'accessibilité, il échoue autrement. La voie étroite est une fiabilité accrue du registre sans un contrôle d'accès plus large.

Cette voie exige de reconnaître les couches séparées. Le registre des ressources en numérotation de l'AFRINIC est le registre durable. Les données IRR sont une publication de politique de routage adjacente à ce registre. RPKI et les ROA fournissent des preuves cryptographiques d'origine de route par 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 doivent être traduits en signaux opérationnels. Confondre ces couches produit un excès de pouvoir 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 conflictuelles, le registre ne devrait pas avoir à décider de chaque litige commercial avant qu'un enregistrement opérationnel puisse changer. Mais il devrait fournir des procédures claires pour l'autorité des sources, des notifications, des é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 l'AFRINIC ne reflète plus sa délégation, le chemin de correction devrait être rapide et auditable. 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 transposer cette ordonnance dans le registre 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. On ne devrait pas non plus permettre à la turbulence de gouvernance de transformer des enregistrements IRR ambigus en levier privé. Un registre qui est é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é d'IPv4 transforme l'ambiguïté en prime

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

Un bloc d'adresses n'a pas de valeur simplement parce qu'il apparaît dans un registre. Il a de la valeur parce que les contreparties croient qu'il peut être utilisé. L'utilisabilité dépend d'un empilement de preuves: enregistrements du détenteur dans le 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 des opérateurs. Les données IRR fragmentées se trouvent 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 origine précédente apparaîtra-t-elle encore dans les filtres? Le vendeur pourra-t-il supprimer les doublons obsolètes des sources qu'il ne contrôle pas? Les fournisseurs de cloud accepteront-ils rapidement la nouvelle origine? Un prêteur finançant la transaction verra-t-il la posture de routage comme stable? Chaque réponse incertaine peut modifier 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 y voit un risque d'exécution. Les courtiers vendent de la confiance autant qu'ils vendent des présentations. 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 grands fournisseurs de transit et les 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 reposait sur des preuves fragiles. Les données IRR fragmentées transforment le courtage en une forme de due diligence de routage.

Un prêteur y voit une incertitude sur la garantie. Les entreprises dépendantes des adresses ne donnent pas nécessairement les blocs IPv4 en gage de manière simple et directe, mais les prêteurs se soucient néanmoins de la stabilité des actifs réseau soutenant les flux de trésorerie. Si la capacité d'une entreprise à servir ses clients dépend de préfixes nécessitant des exceptions de route manuelles, l'actif est plus faible. Si des enregistrements IRR conflictuels pourraient permettre à un ancien fournisseur ou à un 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 y voit une fiabilité de service. Les entreprises, les agences publiques et les utilisateurs de cloud ne veulent pas apprendre la différence entre RADB, AFRINIC, la récursivité des AS-SET et RPKI. Ils veulent que le réseau de leur fournisseur fonctionne. Lorsqu'une migration échoue parce qu'un serveur de routes rejette un préfixe, le client subit des retards et de la méfiance. Le fournisseur peut blâmer le registre, l'ancien fournisseur, le nouveau fournisseur amont 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 le problème de répartition. Les réseaux plus riches peuvent acheter de l'expertise. Les petits réseaux peuvent payer par des retards. Les opérateurs africains essayant de construire une interconnexion locale peuvent faire face au scepticisme des plateformes mondiales habituées à une documentation plus stricte. Les réseaux du secteur public avec d'anciennes allocations peuvent avoir du mal à se moderniser parce que les anciens 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é sur la complexité historique.

La conclusion politique devrait être modeste. L'AFRINIC ne devrait pas s'ériger en arbitre de chaque prix de transfert, location, mise en gage ou décision d'intégration cloud. Cela transformerait un registre en superviseur du marché. Mais elle 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 la source est visible, et si les opérateurs peuvent s'appuyer sur des procédures claires, la prime de rareté attachée à l'ambiguïté diminue. Une bonne gouvernance de l'IRR rend les marchés IPv4 moins féodaux. Une mauvaise gouvernance de l'IRR permet à ceux qui ont des connaissances privées d'extraire de la valeur de l'incertitude des autres.

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

RPKI et les autorisations d'origine de route (ROA) sont souvent présentés comme l'alternative plus propre à l'IRR. Ils sont plus propres pour une question spécifique. Un ROA permet à un détenteur de ressources, dans le cadre du système de certificats de ressources, d'indiquer 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. Cela réduit une classe d'incertitude autour de l'autorité d'origine.

Mais RPKI ne dissout pas le problème de l'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 amont origine encore le bloc. Il ne dit pas à un courtier si d'anciennes références IRR retarderont l'intégration d'un acheteur 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 une alternative partielle, pas le centre du problème de fragmentation des sources. Il peut fournir des preuves plus solides pour les revendications d'origine de préfixe. Il peut aider les opérateurs à rejeter les annonces incompatibles avec les ROA. Il peut réduire la dépendance aux données IRR faibles pour un sous-ensemble de décisions. Pourtant, l'économie du routage reste plurielle. Certains réseaux appliquent strictement la validation d'origine de route (ROV). Certains surveillent. Certains utilisent plus les filtres IRR que RPKI. Certains exigent les deux. Certains acceptent RPKI pour l'origine mais exigent toujours les AS-SET pour le filtrage du cône client. Le marché n'est pas gouverné par un seul interrupteur de validation.

Dans le cas de l'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 attractives. Un ROA peut rassurer un fournisseur amont qu'un détenteur a publié une autorisation d'origine actuelle. Il peut aider un fournisseur de 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 d'anciens AS-SET. Un serveur de routes peut utiliser des filtres dérivés de l'IRR qui rejettent la route avant même que RPKI n'entre en jeu. Un fournisseur amont peut exiger l'enregistrement IRR pour le provisionnement même si RPKI est valide. Les cultures opérationnelles évoluent lentement.

Il y a aussi une économie politique de substitution. Si un registre ou une communauté de normalisation dit « utilisez RPKI et ignorez l'IRR », elle 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 la superposition. 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 quel signal 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 solides d'origine actuelle. Chaque signal a un travail.

Cette approche superposée é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é d'origine de route, mais les contrats, les enregistrements du registre, l'autorité corporative, 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 serveurs de routes et du transit, l'amélioration pratique est une politique sensible aux conflits. Un système devrait pouvoir dire: le ROA valide cette origine, la source IRR liée à l'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. Cela 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. Le but n'est pas plus de données pour elles-mêmes. Le but est un jugement moins cher et plus cohérent.

L'essor de RPKI devrait donc rendre la gouvernance de l'IRR plus disciplinée, pas hors de propos. À 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 de l'AFRINIC est de soutenir cette transition sans l'utiliser pour étendre son pouvoir discrétionnaire. Une sécurité de routage plus forte devrait protéger la fiabilité du registre. Elle ne devrait pas donner à l'opérateur du registre un mandat plus large pour gouverner implicitement les relations de marché.

La question de confiance est différente pour chaque contrepartie

L'expression « à quelle base de données peut-on se fier? » semble singulière. En pratique, la confiance dépend de la contrepartie et de la décision. Un fournisseur amont, un IXP, un fournisseur de 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 de décision.

Un fournisseur amont demande s'il peut accepter en toute sécurité l'annonce d'un client. Il se soucie d'empêcher les détournements, d'éviter les fuites de route, de satisfaire la politique interne, de limiter la charge de support et de générer des revenus d'approvisionnement. Il peut accepter un mélange de preuves IRR et RPKI si la relation client est solide. Il peut être plus strict pour les clients nouveaux ou petits. Pour le fournisseur amont, 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 les enregistrements. Le coût retombe sur le client.

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

Un fournisseur de 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 de RPKI, mais il rencontre encore des enregistrements IRR pendant la due diligence et le 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 à moindre 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 ne contrôle peut-être 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 d'anciens objets route, des références AS-SET ou des conflits de source bloquent 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 une condition de prix.

Un prêteur demande si les revenus dépendant des adresses sont résilients. Il ne comprend peut-être pas 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 chez les 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 garanti directement par des adresses.

Un client pose la question la plus simple: le service fonctionnera-t-il? Il ne sait peut-être pas quelle base de données un serveur de routes a utilisée. Il voit seulement qu'une migration bloque, qu'un préfixe est rejeté, ou qu'un fournisseur ne peut pas expliquer pourquoi l'acceptation diffère d'un réseau à l'autre. 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 importent pour l'AFRINIC parce qu'une réponse centrée sur le registre seul 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 toujours 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 une politique 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é quant à ce que chaque artefact prouve. 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 d'origine cryptographique plus forte, 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 l'AFRINIC, la source de registre et de politique de routage liée à l'AFRINIC devrait avoir un poids probatoire élevé lorsqu'elle est actuelle, procéduralement propre et transparente. 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 enregistré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 registre en gardien. L'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 registre 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é.

Étroitesse ne signifie pas faiblesse. Une source fiable peut toujours avoir une authentification forte, des vérifications d'autorisation proportionnelles, 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 lors de litiges corporatifs ou de gouvernance devraient nécessiter plus de preuves et de notifications. Le critère est la proportionnalité: trop peu de preuves invite les abus; trop de preuves gèle les opérations ordinaires.

La notification devrait faire partie de cette proportionnalité. Si un changement devait déplacer une origine existante ou supprimer un objet utilisé par les filtres, les contacts concernés devraient être notifiés dans la mesure du possible: détenteur de la ressource, mainteneur existant, origine proposée, origine actuelle et contacts opérationnels pertinents. La notification ne devrait pas devenir un veto. C'est un moyen de faire remonter les erreurs avant qu'elles ne deviennent des pannes. Lorsque l'urgence exige une action d'urgence, l'action devrait être temporaire, enregistrée et examinée.

Des métriques rendraient la norme crédible. L'AFRINIC et les grands opérateurs devraient pouvoir mesurer à quelle fréquence les préfixes administrés par l'AFRINIC ont des objets route ou route6 conflictuels entre les sources, à quelle fréquence les expansions d'AS-SET diffèrent selon l'ordre des sources, quel âge ont les doublons obsolètes, quelle est la fraîcheur des miroirs, combien de temps prennent les corrections et combien de clients nécessitent des exceptions manuelles. Ces chiffres n'ont pas besoin d'exposer les dossiers clients privés. Ils diraient au marché si la fragmentation est une anecdote, une taxe chronique ou une condition en amélioration.

La même discipline devrait s'appliquer aux outils. Les systèmes de filtrage devraient exposer les chemins de source: quelle source, quel objet, quelle chaîne AS-SET et quelle règle de récursivité ont 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 serveurs de routes devraient rapporter des catégories de rejet compréhensibles pour les membres. Les enregistrements historiques devraient être préservés pour l'audit, mais les indications sur l'état actuel devraient être suffisamment claires pour que les opérateurs puissent les utiliser. 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 de serveur de routes confronté au travail de filtrage à 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 à l'AFRINIC serait digne de confiance parce que ses procédures étaient visibles, pas parce que l'institution exigeait 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 coûteux.

Le coût de ne pas corriger la fragmentation

Si la fragmentation de l'IRR reste non gérée, le marché trouvera toujours des moyens de router. L'Internet est bon pour contourner les faiblesses institutionnelles. Cette résilience ne doit pas être confondue avec la santé. Le chemin 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 en place, les courtiers tarifient le risque de nettoyage, les serveurs de routes resserrent les 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 coûteuse et moins égale.

Pour l'AFRINIC, ce résultat serait dommageable parce que la région a besoin de coûts de coordination plus bas, pas plus élevés. L'interconnexion locale, la localisation cloud, les services numériques du secteur public, les réseaux universitaires, la distribution de contenu régionale et la concurrence des petits fournisseurs dépendent tous d'une acceptation de routage prévisible. Si chaque migration ou intégration peut être ralentie par des sources de base de données contradictoires, la région paie une taxe silencieuse. La taxe apparaît sous forme de projets retardés, de dépendance accrue au transit, de positions de négociation plus faibles, de valeurs d'actifs plus basses et d'une plus grande dépendance aux intermédiaires extérieurs à la région.

La sécurité ne s'améliorerait pas nécessairement. Les politiques trop strictes peuvent réduire certaines mauvaises routes, mais elles poussent également les opérateurs légitimes vers des exceptions manuelles. Les politiques trop laxistes maintiennent en vie les autorités obsolètes. Les solutions de contournement privées rendent le système moins transparent. Le meilleur résultat de sécurité provient de preuves cohérentes: des données liées au détenteur actuel, des AS-SET propres, RPKI le cas échéant, des conflits de source visibles et une 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 se remettant d'une tourmente de gouvernance doit montrer que ses fonctions utilitaires de base sont fiables. La cohérence de l'IRR est l'une de ces fonctions parce qu'elle est proche des opérations quotidiennes. Si l'AFRINIC peut rendre les données de politique de routage plus propres, plus transparentes et plus faciles à corriger, elle renforcera la confiance dans le registre sans demander au marché une confiance aveugle. Si elle 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é d'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 retard 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 de souveraineté dramatique sur le routage. C'est une réduction disciplinée de l'ambiguïté. L'AFRINIC devrait être un utilitaire de continuité étroit pour les ressources qu'elle administre, avec un soutien à la politique de routage suffisamment fiable pour que des tiers l'utilisent et suffisamment limité pour ne pas devenir un commandement du 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 décisions de serveur de routes et de filtres clients explicables. Les acheteurs, courtiers et prêteurs devraient traiter la posture IRR comme une diligence, pas comme du folklore.

Le travail du serveur de routes à l'aube ne devrait pas avoir à décider de l'avenir institutionnel de la numérotation Internet en Afrique. 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 rendent cela plus difficile en présentant plusieurs passés plausibles comme s'ils étaient des présents égaux. Dans un marché construit sur des numéros rares et une interconnexion volontaire, cette confusion a un prix.

L'opportunité de l'AFRINIC est de réduire ce prix. Pas en devenant un gardien de chaque utilisation commerciale d'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 registre et la source de politique de routage liés à l'AFRINIC fiables, exposer les conflits, préserver l'historique, accélérer la correction, séparer l'authentification de l'autorisation, et aider les opérateurs à voir sur quelle fondation institutionnelle repose chaque revendication de base de données. Si cela se produit, les données IRR retrouvent 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.