AFRINIC et l'économie du risque de révocation de ROA

Le matin où un préfixe cesse de paraître routinier

La première alarme ne dit pas qu’un registre a révoqué quoi que ce soit. Elle dit qu’un préfixe client se comporte différemment selon l’endroit d’où la route est observée. Un centre d’opérations réseau à Nairobi voit une session de transit accepter un /22 géré par AFRINIC depuis l’AS d’origine de longue date du client. Une équipe d’intégration cloud à Johannesbourg voit le même client demander à déplacer le bloc vers un programme « apportez votre propre IP ». Un collecteur de routes en Europe voit toujours la route. Un serveur de routes d’un IXP signale maintenant une annonce plus spécifique comme étant hors de l’autorisation attendue. Un fournisseur de sécurité gérée constate une augmentation soudaine des avertissements d’origine de route. Le ticket du client n’est pas rédigé dans le vocabulaire du droit institutionnel. Il dit que certains chemins fonctionnent, d’autres non, et personne ne peut dire si le changement est une erreur, une migration planifiée, un problème de publication du registre ou le premier signe d’un litige.

En une heure, le vocabulaire s’élargit. Le fournisseur de transit demande une autorisation d’origine de route à jour. La plateforme cloud demande pourquoi le ROA couvre l’agrégat mais pas le plus spécifique qu’elle prévoit d’annoncer. L’ancien fournisseur du client dit qu’il dispose encore d’une route valide pour le service de secours. Un rapport de validateur d’une région montre la route comme Invalid car l’AS d’origine ne correspond plus au ROA actuel. Un autre système de surveillance signale NotFound parce que son cache n’a pas encore récupéré le ROA de remplacement. Un troisième système voit encore l’ancienne vue parce que le cache de sa partie fiable n’a pas expiré. L’équipe commerciale du client demande s’il s’agit d’un problème de routage ou d’actif. La réponse est les deux, et c’est précisément pourquoi le risque de révocation de ROA est important.

Rien dans ce scénario ne requiert un détournement malveillant. La séquence pourrait commencer par un membre retirant un ROA trop tôt durant une migration cloud. Elle pourrait commencer par une édition de maxLength autorisant un /24 mais laissant accidentellement un /25 utilisé pour l’ingénierie de trafic hors de la plage autorisée. Elle pourrait commencer par une défaillance de publication du certificat ou du référentiel faisant disparaître des ROA auparavant valides de la vue utilisable de certains validateurs. Elle pourrait commencer par un blocage administratif du compte d’un membre durant un litige. Elle pourrait commencer par une correction juridique d’une fausse autorité. Elle pourrait commencer par une simple expiration après que personne n’a remarqué qu’un processus de signature avait échoué. Avant que la cause ne soit connue, le résultat économique peut sembler similaire: les contreparties commencent à traiter le bloc d’adresses comme moins fiable.

AFRINIC rend le scénario plus aigu car le registre n’est pas une ancre de confiance abstraite dans un environnement institutionnel paisible. Des rapports publics ont décrit une longue crise impliquant des inquiétudes sur l’intégrité des enregistrements d’adresses, le litige Cloud Innovation, le gel de comptes bancaires, la mise sous administration judiciaire, la discontinuité du conseil d’administration, l’annulation d’élections, la restauration ultérieure du conseil et des litiges en cours. Le propos n’est pas que chaque ressource d’AFRINIC soit suspecte. Le propos est que l’épreuve contrôlée par le registre devient économiquement chargée quand la légitimité du registre a été visiblement mise à rude épreuve. Un ROA est techniquement limité, mais il est lu par les fournisseurs de transit, les plateformes cloud, les IXP, les acheteurs, les auditeurs et les clients comme faisant partie d’un dossier de dépendance plus large.

Dans le marché épuisé d’IPv4, la perte réelle d’un mauvais événement ROA n’est pas seulement la perte de paquets. C’est la perte d’acceptation prévisible. Un préfixe qui ne peut être validé proprement peut rester accessible via des réseaux permissifs, mais il devient plus difficile à vendre, à louer, à migrer, à financer, à assurer, à acquérir ou à défendre lors d’une revue de continuité client. Un état de validation contesté devient un signal de prix. Il indique aux contreparties qu’une diligence supplémentaire est nécessaire avant que l’actif puisse être traité comme une infrastructure ordinaire.

C’est là le problème de l’économie institutionnelle. RPKI a été conçu pour réduire l’incertitude sur l’origine de route. Les ROA aident les réseaux à éviter d’accepter des routes qui ne correspondent pas aux autorisations actuelles. La validation d’origine de route fournit aux opérateurs un langage simple pour le risque. Mais tout système de sécurité qui devient une condition d’accès au marché doit aussi être jugé sur son processus de correction. Quand la publication change, qui reçoit une notification? Quand le changement est incorrect, qui peut le corriger? Quand une action d’urgence est requise, comment est-elle limitée? Quand une décision du registre affecte les routes en direct, comment rendre l’appel significatif sans transformer chaque ticket en litige? Ces questions font partie du coût d’utiliser des ressources d’adresses rares.

L’économie est plus précise qu’un slogan sur le pouvoir du registre. Le risque de révocation de ROA est la possibilité qu’un changement dans l’autorisation d’origine de route, la validité du certificat, la publication du référentiel ou la propagation du validateur amène les réseaux et les contreparties à dégrader, rejeter ou retarder la confiance dans un préfixe avant que le titulaire affecté n’ait eu une chance équitable de comprendre et de résoudre le problème. Ce risque n’est pas une raison d’affaiblir RPKI. C’est une raison de rendre l’autorité derrière RPKI limitée, documentée, réversible quand c’est possible et résiliente en cas de stress institutionnel.

Ce que signifie réellement le risque de révocation de ROA

L’expression « révocation de ROA » est pratique, mais elle peut être trompeuse si elle suggère un acte juridique unique avec un déclencheur et une conséquence. Une autorisation d’origine de route est une autorisation de routage signée dans le système RPKI qui autorise un système autonome spécifié à annoncer un préfixe IP spécifié, généralement avec une longueur maximale de préfixe optionnelle. La validation d’origine de route compare ensuite une annonce BGP reçue avec l’ensemble des ROA actuellement utilisables. Le résultat de la validation est communément décrit comme Valid, Invalid ou NotFound. Valid signifie qu’une autorisation correspondante existe. Invalid signifie qu’un ROA existe pour la ressource pertinente mais que l’annonce entre en conflit avec son AS d’origine ou les limites de longueur de préfixe. NotFound signifie que le validateur ne dispose d’aucun ROA pertinent pour le préfixe.

Le risque de révocation de ROA, au sens opérationnel utilisé ici, couvre plusieurs mécanismes différents. Le premier est le retrait explicite: un titulaire ou un système hébergé par le registre supprime le ROA de la publication. Le deuxième est le remplacement: un changement d’AS d’origine ou une modification de maxLength crée un nouvel état valide pour certaines routes tout en rendant d’autres invalides. Le troisième est l’invalidation via la chaîne de certificats: un certificat de ressource peut expirer, être révoqué, échouer la validation ou cesser de couvrir l’ensemble de ressources de la manière requise par le ROA. Le quatrième est l’expiration du ROA ou la publication obsolète, lorsqu’un ROA ou un enregistrement de référentiel connexe n’est plus valide parce que le temps a avancé et que le processus de signature ou de publication ne l’a pas fait. Le cinquième est la non-publication: le ROA qui devrait exister n’est pas publié au point de référentiel attendu, ou un manifeste et l’état du référentiel le rendent inutilisable pour les validateurs. Le sixième est la propagation en cache: les caches des parties fiables récupèrent, conservent et font vieillir les données selon des horaires différents, de sorte que la même route peut apparaître dans différents états à travers l’écosystème de routage pendant un certain temps.

Ces mécanismes ne sont pas égaux. Un titulaire retirant intentionnellement un ROA avant un changement de fournisseur planifié n’est pas la même chose qu’un registre révoquant un certificat après une fausse autorité avérée. Une erreur de maxLength n’est pas la même chose qu’un blocage administratif lié à un tribunal. Une panne de référentiel n’est pas la même chose qu’une sanction politique. Un validateur avec des données obsolètes n’est pas la même chose qu’une décision actuelle du registre. Les regrouper sous une catégorie appelée « révocation » occulte les faits dont les opérateurs ont besoin. L’économie dépend de la classification parce que chaque cause a un chemin de correction différent et un standard de légitimité différent.

Le risque inclut aussi la distinction entre l’invalidité technique et le manque de fiabilité commerciale. Une route peut être techniquement Invalid parce qu’un ROA autorise AS64500 alors que le client annonce via AS64501. Si le décalage est causé par une migration cloud planifiée et peut être corrigé en minutes, le risque commercial est faible. Si le décalage est causé par une perte contestée de l’autorité du compte, une action de certificat ou une décision du registre que le titulaire ne peut contester, le risque commercial est plus élevé. Le paquet ne connaît pas la différence, mais le marché la connaît.

L’état NotFound mérite une égale précision. NotFound n’est pas la même chose qu’invalide. De nombreux réseaux ne rejettent pas les routes NotFound parce que l’absence d’un ROA peut simplement signifier que le titulaire n’a pas adopté RPKI. Cependant, dans des contextes de grande valeur ou sensibles à la sécurité, NotFound peut encore être un signal négatif. Un fournisseur cloud peut demander pourquoi un titulaire prétendument mature ne peut publier un ROA. Un client public peut traiter NotFound comme une posture de sécurité incomplète. Un acheteur peut exiger des ROA comme condition de clôture. Un prêteur peut voir NotFound comme une lacune dans la garantie opérationnelle. Ainsi, un retrait de ROA qui fait passer un préfixe de Valid à NotFound peut ne pas couper les routes aussi abruptement qu’un état Invalid, mais il peut encore ralentir les transactions et affaiblir la confiance.

Le terme « autorité de révocation » doit donc être compris de manière large mais pas négligente. C’est le pouvoir pratique de modifier la preuve d’origine de route que les autres parties utilisent. Le titulaire peut l’exercer en changeant ses propres ROA. Le registre peut l’influencer via les services RPKI hébergés, l’état du certificat, l’accès au compte, l’infrastructure de publication et le contrôle des enregistrements de ressources. Les validateurs et les opérateurs réseau influencent l’effet sur le marché par leurs intervalles de rafraîchissement et leurs politiques de routage. Un tribunal ou un administrateur judiciaire peut l’affecter indirectement en limitant qui peut agir au nom du registre ou du titulaire de la ressource. Le choc survient lorsque cette autorité distribuée n’est pas accompagnée d’une procédure claire.

La pertinence d’AFRINIC n’est pas qu’il a une technologie RPKI particulièrement déficiente. La question la plus vive est de savoir si un registre ayant connu de graves turbulences institutionnelles peut garantir de manière crédible que les changements d’origine de route resteront limités, documentés et préserveront le service même lorsque les litiges sont intenses. Un ROA est destiné à réduire l’incertitude sur l’origine de route. Si le processus entourant la suppression ou la modification crée une nouvelle incertitude sur la discrétion institutionnelle, l’artefact de sécurité commence à porter une prime de gouvernance.

La définition économique est donc celle-ci: le risque de révocation de ROA est l’exposition d’un titulaire de ressource, d’un opérateur, d’un client ou d’une contrepartie à la perte de confiance dans l’origine de route causée par un retrait, un remplacement, une invalidation de certificat, une expiration, une non-publication, une défaillance du référentiel ou une propagation inégale des données RPKI, en particulier lorsque la partie affectée manque de notification en temps utile, d’un chemin de correction réaliste, d’un mécanisme de correction réversible ou d’un appel crédible contre des actions à fort impact. Cette définition est suffisamment technique pour être utile et suffisamment large pour saisir pourquoi une petite autorisation signée peut dans les bilans.

Le cycle de vie est une chaîne, pas un interrupteur

Le cycle de vie d’un ROA commence avant que l’autorisation ne soit signée. Il commence avec la reconnaissance par le registre d’un titulaire de ressource et avec l’autorité du titulaire pour gérer la ressource. Les propres documents publics d’AFRINIC le décrivent comme une organisation à but non lucratif fondée sur l’adhésion, enregistrée à Maurice, qui distribue et gère l’espace d’adresses IP et les numéros de systèmes autonomes pour l’Afrique et certaines parties de l’océan Indien. Ses services incluent WHOIS, RDAP, le DNS inverse, un registre de routage Internet et un programme de certification de ressources pour RPKI. Ce catalogue importe parce qu’un ROA n’est pas une opinion cryptographique isolée. Il repose sur les enregistrements de ressources, les contrôles de compte, l’émission de certificats et les systèmes de publication du registre.

En fonctionnement ordinaire, la chaîne est ennuyeuse. Un titulaire a un compte AFRINIC ou une autre voie reconnue pour gérer la certification. Les ressources pertinentes sont couvertes par un certificat de ressource. Le titulaire crée un ROA qui autorise un AS d’origine pour un préfixe et une longueur maximale. Le ROA signé est publié dans le référentiel RPKI. Un manifeste liste les enregistrements publiés pour que les validateurs puissent détecter si le contenu du référentiel est complet et à jour. Une liste de révocation de certificats soutient le modèle d’état du certificat. Le logiciel de partie fiable récupère le référentiel, valide la chaîne et produit des données utilisées par les routeurs ou les systèmes de politiques de routage. Le titulaire surveille si les annonces restent Valid.

Chaque étape peut échouer différemment. L’autorité du titulaire peut ne pas être claire après une fusion, une mise sous administration judiciaire, une insolvabilité, une réorganisation du secteur public ou un changement de sous-traitant. L’accès au compte peut être compromis ou gelé. Un certificat peut expirer ou être révoqué. Un ROA peut contenir un ASID, un préfixe ou un maxLength incorrect. Un processus de signature peut échouer. Un référentiel peut publier un ensemble incomplet d’enregistrements. Un manifeste peut amener les validateurs à se méfier de la vue qu’ils ont obtenue. Un validateur peut continuer à utiliser d’anciennes données pendant une période au lieu de passer immédiatement à un état vide ou d’échec. Un réseau peut appliquer la politique ROV différemment de son voisin. Le cycle de vie n’est donc pas un interrupteur entre sécurisé et non sécurisé; c’est une chaîne de dépendances dont les modes de défaillance sont économiquement distincts.

Le cycle de vie interagit aussi avec les schémas opérationnels réels. Un titulaire peut autoriser son propre AS pour le service normal, l’AS d’un fournisseur de transit pour le secours, un AS cloud pour un déploiement BYOIP spécifique à une région et un fournisseur de mitigation DDoS durant les attaques. Il peut annoncer un agrégat depuis un réseau et des plus spécifiques depuis un autre. Il peut diviser un préfixe après une migration de centre de données. Il peut utiliser délibérément des conceptions multi-origines. Chacun de ces schémas dépend de choix corrects d’origine et de maxLength. Un ROA restrictif peut protéger contre les détournements accidentels de plus spécifiques, mais bloquer l’ingénierie de trafic légitime. Un maxLength large peut préserver la flexibilité mais augmenter le rayon d’explosion si un plus spécifique est mal utilisé. Ce sont des décisions d’ingénierie avec des conséquences commerciales.

Dans la région d’AFRINIC, le cycle de vie peut être plus difficile car la qualité de la documentation varie. Certaines ressources sont liées à d’anciens enregistrements, d’anciens noms d’entreprises, des organismes publics, des universités ou des opérateurs dont les ingénieurs d’origine sont partis. Le récit de KrebsOnSecurity sur les accusations de vol d’adresses en 2019 et l’analyse de l’Internet Governance Project sur la crise plus large ont clairement montré que des enregistrements dormants ou faiblement contrôlés peuvent devenir des cibles précieuses une fois qu’IPv4 a une valeur de marché. Un registre qui tente de nettoyer de mauvais enregistrements fait face à un vrai problème. Un titulaire qui tente de préserver le service pendant le nettoyage fait aussi face à un vrai problème. RPKI hérite des deux.

Le cycle de vie a donc besoin d’un vocabulaire d’état plus riche que « le ROA existe » ou « le ROA a disparu ». Un changement peut être demandé par le titulaire, lié à une migration routinière, à la récupération de compte, à une réponse à un compromis d’urgence, à la maintenance du certificat, à un incident de référentiel, à la préservation d’un litige, à l’exécution d’une ordonnance judiciaire ou à la correction de l’état d’une ressource. Chaque catégorie devrait impliquer un standard de notification, un chemin de correction, une horloge de révision et une continuité par défaut. Le marché peut tolérer une action dure s’il sait pourquoi elle est arrivée et comment une erreur peut être inversée. Il peine face à une disparition inexpliquée.

Le bon principe du cycle de vie est la continuité avec une correction contrôlée. La fausse autorité doit être supprimée. Les comptes compromis doivent être contenus. Les ROA incorrects doivent être corrigés. Les ordonnances judiciaires doivent être respectées. Mais la correction doit être conçue de façon à ce que les clients innocents en aval ne deviennent pas le moyen le moins cher de créer de la pression. Dans une économie en réseau, le coût d’un changement brusque d’origine de route est rarement supporté seulement par la partie nommée dans le registre. Il est supporté par les clients, les services publics, les contreparties et les fournisseurs qui ont construit autour de la route.

Invalid et NotFound sont des événements économiques différents

Invalid et NotFound sont souvent compressés en une même crainte commerciale: la route n’est plus propre. Techniquement, ils sont différents, et la différence importe. Une annonce BGP est Invalid quand un validateur trouve des données ROA couvrant le préfixe mais que l’annonce entre en conflit avec elles. Les raisons habituelles sont un décalage d’AS d’origine ou une longueur de préfixe plus longue que ce que le maxLength du ROA permet. Une annonce BGP est NotFound quand il n’existe aucun ROA validé la couvrant. Dans de nombreux réseaux, Invalid est un candidat direct au rejet, tandis que NotFound est accepté mais surveillé. En diligence commerciale, les deux peuvent soulever des questions, mais ils soulèvent des questions différentes.

Invalid est plus aigu parce qu’il dit que l’autorisation publiée du titulaire et la route observée ne correspondent pas. Cela le rend utile contre les détournements et les fuites. Cela rend aussi les erreurs innocentes dangereuses. Un changement de fournisseur qui met à jour BGP avant de changer le ROA peut créer des routes Invalid. Une intégration cloud qui annonce un /24 alors que le ROA n’autorise que l’agrégat sans un maxLength adéquat peut créer des routes Invalid. Un événement de mitigation DDoS qui fait annoncer le trafic depuis un AS d’urgence peut créer des routes Invalid si le ROA d’urgence manque. Un client délégué qui change d’origine sans informer le titulaire peut créer des routes Invalid. L’état n’explique pas le motif. Il signale seulement un conflit.

Le marché traite Invalid comme une défaillance qui nécessite une explication. Un opérateur peut rejeter la route automatiquement là où sa politique applique la validation d’origine de route. Un serveur de routes d’IXP peut la supprimer pour protéger les membres. Un fournisseur cloud peut bloquer l’intégration jusqu’à ce que le client répare le décalage. Un acheteur peut retarder la clôture parce que l’actif ne peut être déployé via l’AS prévu. Un client du secteur public peut interpréter Invalid comme une défaillance des contrôles de sécurité. Un assureur peut demander si la surveillance d’origine de route est adéquate. Le coût apparaît sous forme de tickets, d’interruptions, de retards, de frictions contractuelles et de dommages réputationnels.

NotFound est plus doux mais reste important. Une route auparavant Valid qui devient NotFound après un retrait de ROA peut continuer à passer à travers de nombreux réseaux. Cependant, un changement de Valid à NotFound supprime la preuve positive. Si le titulaire a intentionnellement désactivé RPKI parce qu’il y a un litige en cours, les contreparties peuvent l’interpréter comme un risque. Si le changement provient d’une défaillance du référentiel, elles peuvent l’interpréter comme une fragilité du service. S’il vient d’une expiration, elles peuvent l’interpréter comme un mauvais contrôle opérationnel. S’il vient d’un problème de compte du registre, elles peuvent l’interpréter comme une dépendance institutionnelle. Dans un monde où davantage de contreparties attendent RPKI, NotFound est de plus en plus un état commercial plus faible, même quand ce n’est pas une défaillance de routage.

Le contraste affecte aussi la correction. Invalid a généralement une solution concrète: ajuster l’AS d’origine, ajuster maxLength, changer la route, publier un ROA additionnel, corriger le certificat ou revenir sur l’édition erronée. NotFound peut exiger de restaurer toute la chaîne de publication ou de décider si un ROA devrait exister tout court. Un NotFound causé par un retrait délibéré pendant un litige non résolu ne peut être corrigé par un seul ingénieur de transit. Un NotFound causé par la non-publication du référentiel peut exiger une réparation de l’infrastructure du registre. Un NotFound causé par l’expiration du certificat peut exiger un renouvellement ou une réémission. Le ticket doit trouver le bon propriétaire.

Pour AFRINIC, la distinction devrait façonner la gouvernance. Un litige sur l’état d’une ressource ne devrait pas automatiquement pousser les routes en direct vers Invalid si l’origine existante est le dernier état sûr vérifié et qu’il n’y a pas de risque immédiat de détournement. Un ROA soupçonné d’être faux peut requérir une contention immédiate, mais l’état devrait être limité dans le temps et révisé. Un incident de publication devrait être communiqué comme un incident d’infrastructure, et non laissé aux contreparties pour être interprété comme une faute du titulaire. Une migration planifiée devrait autoriser des autorisations qui se chevauchent quand c’est sûr, pour que les changements d’origine ne créent pas de fenêtres Invalid évitables.

Invalid est une contradiction directe entre l’annonce et l’autorisation. NotFound est l’absence d’autorisation utilisable. Le premier crée souvent un risque de filtrage immédiat dans les réseaux qui appliquent ROV; le second crée une perte de garantie et peut plus tard devenir un obstacle commercial. Un cadre de révocation mature les distingue avant d’agir, les explique en agissant et soutient une correction rapide après avoir agi. Sans cette discipline, la validation d’origine de route peut protéger contre une classe de mauvaises routes tout en créant un choc institutionnel dans une autre.

La propagation en cache transforme le temps du registre en temps du marché

RPKI ne se déplace pas à travers l’Internet en un seul instant. Les validateurs récupèrent les référentiels selon des horaires. Les opérateurs définissent des politiques locales. Les caches conservent les données validées jusqu’au rafraîchissement. Les points de publication peuvent être accessibles depuis un réseau et lents depuis un autre. Un problème de manifeste ou de certificat peut être interprété différemment selon la version du logiciel et la configuration locale. Certains routeurs consomment les données de validation d’un cache local, d’autres d’une paire redondante, et d’autres encore de services externalisés ou hébergés. Cela signifie que l’événement économique créé par un changement de ROA n’a pas une seule estampille temporelle. Il a une courbe de propagation.

Cette courbe importe durant la révocation ou le retrait. Si un titulaire supprime un ROA à 10h00 UTC et publie un remplacement à 10h05, certains validateurs peuvent voir une transition propre. D’autres peuvent voir l’ancien ROA, puis le nouveau. D’autres peuvent brièvement n’en voir aucun. Si la route change avant que le nouveau ROA ne soit récupéré, la route peut être Invalid sur un réseau et NotFound ou Valid sur un autre. Si un référentiel a un problème de fraîcheur, un validateur peut continuer à utiliser les données en cache pendant une période avant de déclarer les données inutilisables. L’opérateur qui subit un rejet peut ne pas savoir si le problème est l’état actuel, l’état obsolète ou la politique locale.

C’est pourquoi les changements planifiés de ROA exigent une chorégraphie. Le titulaire doit savoir quelle route sera annoncée, depuis quel AS d’origine, avec quelle longueur de préfixe et via quels fournisseurs. Le ROA doit être publié avant que la route ne change, et non après, quand la sécurité le permet. Les anciennes et nouvelles origines peuvent devoir se chevaucher durant la migration. maxLength doit être choisi pour autoriser les plus spécifiques prévus sans en autoriser d’inutiles. La surveillance doit confirmer la visibilité globale avant que les clients ne soient déplacés. Un plan de retour en arrière doit être prêt. Ce sont des pratiques ordinaires de gestion des changements, mais les processus du registre peuvent les soutenir ou les perturber.

Les changements non planifiés sont plus difficiles. Un compte compromis, un faux ROA, un détournement soupçonné ou une ordonnance judiciaire d’urgence peuvent exiger une action immédiate. Cependant, même l’action d’urgence a des effets de propagation. Si le registre ou le titulaire supprime un ROA pour arrêter une fausse origine, des routes de secours ou de mitigation légitimes peuvent devenir Invalid si le ROA couvrait plusieurs usages opérationnels. Si un certificat est révoqué, tous les ROA dépendants peuvent disparaître de la validation même si une seule route était problématique. Si un référentiel est mis hors ligne durant un incident, les validateurs peuvent passer par différents états selon leurs propres règles. La conception d’urgence doit supposer que l’action sera lue par les machines avant que les humains ne la comprennent.

L’histoire institutionnelle d’AFRINIC ajoute une autre couche de propagation: la propagation narrative. Quand un registre paisible modifie la publication RPKI, les opérateurs sont plus enclins à supposer un problème de maintenance routinière. Quand un registre sous tension modifie la publication durant un litige, une mise sous administration judiciaire, une controverse électorale ou des accusations publiques, les contreparties peuvent inférer des problèmes plus larges. Le même état technique peut donc avoir une signification de marché différente. Ce n’est pas toujours juste, mais c’est ainsi que le risque est évalué. Le silence durant un événement ROA invite les contreparties à combler le vide avec la pire explication plausible.

L’antidote est la transparence opérationnelle sans divulgation imprudente. Un registre ne doit pas publier de dossiers de litige privés, de détails de sécurité ou de contrats clients. Il peut publier des faits d’état du service: si les référentiels RPKI fonctionnent, si un incident de publication fait l’objet d’une enquête, si les actions du portail des membres sont retardées, si les restrictions d’urgence sont temporaires et si les titulaires affectés ont été notifiés. Les titulaires peuvent dire aux contreparties si un changement est planifié, si l’on s’attend à ce qu’un Invalid s’éclaircisse après la mise à jour du cache et quelle route doit être considérée comme autorisée. Une bonne communication n’élimine pas le délai de propagation; elle rend le délai moins alarmant.

Dans un marché IPv4 rare, le temps n’est pas neutre. Un préfixe qui passe une journée en validation inconsistante peut créer plus de dommages qu’une erreur ordinaire de base de données parce que l’inconsistance affecte plusieurs contreparties à la fois. Le temps du registre, le temps du validateur, le temps du fournisseur et le temps du client deviennent une seule horloge commerciale. Le défi d’AFRINIC est de garantir que tout changement de ROA à fort impact soit classifié, communiqué et corrigible à l’intérieur de cette horloge, et pas seulement au rythme plus lent du processus institutionnel.

MaxLength et les éditions d’origine sont de petits champs aux grandes conséquences

Le champ maxLength d’un ROA semble un détail technique jusqu’à ce qu’il bloque un modèle d’affaires. Si un titulaire autorise un /20 sans permettre des préfixes plus longs, le ROA peut ne valider que l’origine /20. Si le titulaire annonce ensuite un /24 pour l’ingénierie de trafic, la mitigation DDoS, l’intégration cloud ou le basculement régional, l’annonce peut être Invalid parce que la route est plus longue que le maximum autorisé. Si le titulaire fixe un maxLength trop large, des annonces plus spécifiques peuvent être validées même quand le titulaire ne voulait pas une telle flexibilité. Le champ est un dispositif d’allocation de risque déguisé en nombre.

Les éditions de l’AS d’origine ont un poids similaire. Un client peut passer de son propre AS à un AS cloud, d’un fournisseur de transit à un autre, d’un centre de données à un service de mitigation DDoS ou d’un accord de revendeur à l’annonce directe. Le ROA doit suivre l’origine prévue. Si l’ancienne origine reste autorisée trop longtemps, le titulaire peut préserver la surface d’attaque ou la dépendance envers l’ancien fournisseur. Si l’ancienne origine est supprimée trop tôt, le service de secours peut se rompre. Si la nouvelle origine est autorisée sans notification suffisante aux fournisseurs affectés, le changement peut sembler un transfert d’autorité suspect. Dans un environnement propre, ce sont des compromis opérationnels. Dans un environnement contesté, ils deviennent des preuves.

L’économie est plus claire dans le BYOIP. Une plateforme cloud ne peut pas simplement accepter la déclaration d’un client selon laquelle il peut annoncer un préfixe. Elle a besoin d’une preuve d’origine de route. Certaines plateformes utilisent des jetons de défi, des lettres d’autorisation, des contacts de registre, des vérifications RPKI et une surveillance de route. Si un client manque d’un ROA pour l’origine cloud, l’intégration peut stagner. Si un ROA autorise l’AS cloud mais que maxLength ne couvre pas le plus spécifique requis, le service peut être techniquement proche mais commercialement indisponible. Le bloc d’adresses existe, mais sa valeur n’est pas pleinement déployable.

Les cas de transit et d’IXP sont moins glamour mais non moins importants. Un fournisseur d’accès africain peut avoir besoin d’annoncer un préfixe client via un nouveau fournisseur amont pour réduire les coûts ou améliorer la latence. Un point d’échange peut avoir besoin d’accepter une route sur un serveur de routes. Un centre de données peut avoir besoin de déplacer le trafic client durant une coupure de fibre. Une université ou un organisme public peut avoir besoin de continuité en changeant de sous-traitant. Dans chaque cas, la différence entre un ROA correct et un ROA incorrect peut être la différence entre un changement d’ingénierie routinier et une semaine d’escalade.

C’est ici que les procédures d’AFRINIC doivent être proportionnelles. Une correction routinière de maxLength demandée par un titulaire vérifié ne devrait pas nécessiter une enquête étendue sur le modèle d’affaires du titulaire. Un changement d’origine durant une migration documentée devrait avoir un chemin clair, avec notification aux contacts pertinents et surveillance des états Invalid inattendus. Un changement à haut risque qui supprime une origine de longue date ou ajoute une capacité large de plus spécifiques devrait recevoir des vérifications plus strictes. Un changement contesté devrait préserver le dernier état opérationnel vérifié quand c’est sûr, pendant que l’on examine la question limitée de l’origine de route. Le processus devrait distinguer une faute de frappe d’une tentative d’appropriation d’actif.

Le problème de maxLength montre aussi pourquoi le risque de révocation ne concerne pas seulement la suppression. Un ROA peut rester présent et néanmoins créer un choc. Ajuster maxLength peut invalider des plus spécifiques. Changer l’AS d’origine peut invalider d’anciennes annonces. Diviser un préfixe en plusieurs ROA peut rendre certaines routes valides et d’autres invalides. Réémettre un certificat peut affecter l’ensemble des enregistrements du référentiel que les validateurs acceptent. Le marché peut les percevoir comme similaires à une révocation même si personne n’a utilisé le mot « révoquer ». Un bon cadre traite donc les éditions conséquentes comme faisant partie de la même famille de risques.

Les petits paramètres RPKI ont une grande signification économique parce qu’ils sont consommés par des systèmes automatisés et auxquels font confiance les contreparties. Les traiter comme de simples configurations sous-estime les dommages de la surprise. Les traiter comme des adjudications complètes de propriété exagère ce qu’ils peuvent prouver. Ils exigent une discipline intermédiaire: étroitesse technique, sérieux procédural et réversibilité quand un petit champ erroné crée un grand choc sur le marché.

La crise d’AFRINIC a rendu visible le pouvoir discrétionnaire des certificats

La crise publique d’AFRINIC n’est pas le sujet de cet article pour le sensationnalisme. Elle importe parce qu’elle montre comment le pouvoir discrétionnaire du registre devient économiquement visible lorsque la rareté d’IPv4, la faiblesse institutionnelle et la sécurité d’origine de route se rencontrent. L’analyse de 2021 de l’Internet Governance Project a décrit le litige Cloud Innovation comme une collision entre la tentative d’AFRINIC de nettoyer les abus perçus et un membre dont l’activité dépendait de grandes possessions d’IPv4. Elle a décrit des ordonnances judiciaires, le gel de comptes bancaires et le risque que les opérations ordinaires du registre puissent être affectées. La déclaration de 2023 du NRO a décrit la nomination d’un administrateur judiciaire pour maintenir le statu quo, superviser les élections et restaurer une gouvernance fonctionnelle. The Register a ensuite relaté des retards électoraux, une annulation, une restauration du conseil, des litiges continus et des interventions de l’ICANN. Aucune de ces sources ne doit être traitée comme un jugement définitif sur chaque revendication légale. Ensemble, elles montrent que la couche du registre est devenue une surface de risque vivante.

Le pouvoir discrétionnaire des certificats importe dans cet environnement parce qu’il est moins visible qu’une ordonnance judiciaire ou un refus public de transfert. Un registre peut influencer la confiance dans l’origine de route via les contrôles RPKI hébergés, l’accès aux comptes des membres, l’état des certificats de ressources, la publication du référentiel, la réponse du support, la classification des litiges et les restrictions d’urgence. Beaucoup de ces décisions sont opérationnelles, non politiques. Cependant, si les standards sont opaques, le titulaire affecté peut les percevoir comme un pouvoir sans recours clair. La contrepartie voit seulement un changement de validation ou un retard dans l’obtention d’une preuve propre.

Cela ne signifie pas qu’AFRINIC ne doit jamais agir avec décision. Les accusations de vol d’adresses de 2019 rapportées par KrebsOnSecurity et d’autres ont rappelé que les registres de ressources numériques peuvent être abusés à grande échelle. Un registre incapable de corriger une fausse autorité ne protège pas ses membres. Un compte compromis ne peut pas être autorisé à publier des ROA indéfiniment. Une autorisation d’origine de route frauduleuse ne doit pas être préservée simplement parce que la route affectée a des clients. Une ordonnance judiciaire légale peut exiger une action. La question n’est pas de savoir si le pouvoir de correction existe. C’est de savoir si le pouvoir est limité par la notification, la preuve, la continuité et la révision.

Les documents de politiques d’AFRINIC montrent aussi une tension de longue date entre le langage de gestion et la réalité du marché. Le manuel officiel décrit l’allocation basée sur les besoins, les exigences de documentation et l’idée que les ressources numériques sont des ressources publiques plutôt qu’une propriété ordinaire. La page sur l’épuisement enregistre la pression créée par la rareté et le processus d’atterrissage en douceur. L’analyse de 2021 de l’IGP a souligné que l’environnement de tarifs historiquement bas d’AFRINIC s’est heurté aux prix mondiaux d’IPv4. Le reportage de 2026 de The Register a saisi la lutte continue pour savoir si les adresses doivent être traitées comme des actifs économiques ou des ressources non propriétaires gérées par des politiques. RPKI se trouve précisément là où cet argument devient opérationnel.

Si la certification est utilisée uniquement pour répondre à une question limitée – quel AS d’origine est autorisé pour quel préfixe sous l’autorité reconnue actuelle – elle peut réduire le conflit. Si elle est utilisée pour exprimer une désapprobation plus large d’un modèle d’affaires, d’une géographie de client, d’une pratique de location ou d’une faction politique, elle transforme la sécurité en levier. La différence peut ne pas être évidente pour un validateur, mais elle le sera pour le marché. Les acheteurs et les clients demanderont si la validité de l’origine de route dépend de la correction technique ou de la faveur institutionnelle.

C’est pourquoi le mécanisme d’appel importe avant que le litige ne survienne. Un titulaire ne devrait pas avoir à découvrir, en pleine urgence, qu’il n’y a aucun moyen pratique de contester une action RPKI à fort impact. Un registre ne devrait pas avoir à improviser sous la pression d’un litige. Les tribunaux ne devraient pas être forcés d’apprendre la validation d’origine de route au milieu d’une crise de service. Les catégories devraient exister à l’avance: édition routinière, compromission suspecte, fausse autorité, litige sur l’état de la ressource, incident de publication, action sur ordonnance judiciaire, suspension d’urgence et révocation finale. Chacune devrait avoir une autorité définie, une attente de notification, un chemin de révision et une continuité par défaut.

Le redressement d’AFRINIC devrait être mesuré à l’aune de ces contraintes opérationnelles autant qu’à celle des réunions du conseil et des budgets. Une institution reconstruite peut encore être risquée si le pouvoir discrétionnaire des certificats reste opaque. À l’inverse, une institution sous tension peut préserver la confiance si elle montre que les services RPKI sont isolés des conflits non liés. Le marché n’exige pas la perfection. Il exige suffisamment de prévisibilité pour savoir que la garantie d’origine de route ne deviendra pas un dommage collatéral dans une lutte de gouvernance, de tarifs, d’élections, d’idéologie commerciale ou de survie institutionnelle.

La conclusion institutionnelle est limitée. AFRINIC n’est ni un simple mauvais exemple, ni une simple victime de litiges. C’est un test de résistance pour la supposition du système RIR selon laquelle les ancres de confiance du registre peuvent être traitées comme une infrastructure neutre sans constitution de continuité détaillée. Le risque de révocation de ROA est là où cette supposition rencontre le bilan.

Notification, correction et appel ne sont pas des ornements juridiques

La notification est la sauvegarde la moins coûteuse dans un système d’origine de route à fort impact. Elle ne décide pas qui a raison. Elle informe les parties affectées qu’un changement est imminent, de quelle catégorie de changement il s’agit et comment répondre avant que le changement ne devienne une interruption ou un signal de marché. Pour le retrait ou le remplacement de ROA, les parties affectées peuvent inclure le titulaire de la ressource, l’AS d’origine actuel, l’AS d’origine proposé, l’opérateur délégué, les contacts de maintenance pertinents, les grands clients en aval et, parfois, un représentant désigné par le tribunal ou la procédure d’insolvabilité. La liste n’a pas besoin d’être publique. Elle doit être opérationnellement réelle.

La notification doit être calibrée selon le risque. Un ajout routinier demandé par le titulaire d’une nouvelle origine pour une migration cloud planifiée peut nécessiter une courte notification et une confirmation claire. Un ajustement de maxLength qui pourrait invalider des plus spécifiques existants devrait avertir le titulaire et l’origine actuelle avant le changement. Un ROA soupçonné d’être faux et soutenant un détournement actif peut justifier une action temporaire immédiate suivie d’une notification rapide. Une révocation de certificat affectant de nombreux ROA devrait exiger une revue interne renforcée car elle peut perturber plusieurs routes à la fois. Un incident de référentiel devrait être annoncé comme un incident de service plutôt que d’être dissimulé comme une faute individuelle du titulaire.

La correction est la deuxième sauvegarde. Le but de la correction n’est pas de maintenir de mauvaises autorisations. C’est d’empêcher que des défauts corrigibles ne deviennent des gels d’actifs. Un contact obsolète peut être mis à jour. Un AS d’origine incorrect peut être corrigé. Un maxLength manquant peut être modifié. Une erreur de séquence de transfert peut être résolue. Une route d’intégration cloud peut être préautorisée. Une expiration de certificat peut être renouvelée. Un titulaire avec des enregistrements historiques faibles peut devoir produire des documents de continuité d’entreprise. Le chemin de correction doit être proportionnel au défaut et assez rapide pour aux réseaux en direct.

La charge de documentation de la correction ne doit pas être ignorée. AFRINIC dessert une région avec de grandes différences de capacité institutionnelle. Un opérateur multinational peut rapidement rassembler des enregistrements de registre, des approbations d’entreprise, des lettres d’avocats et des preuves de routage. Un petit FAI africain peut ne pas le pouvoir. Une université peut avoir d’anciens enregistrements d’allocation mais aucun ingénieur actuel de la période d’origine. Un organisme public peut se mouvoir lentement parce que l’autorité réside dans des canaux d’approvisionnement, des ministères ou des entreprises d’État. Un opérateur rural peut dépendre d’un fournisseur géré qui détient la connaissance technique. Si les règles de correction supposent la capacité documentaire d’un grand opérateur, le système devient régressif.

L’appel est la troisième sauvegarde, et il doit être plus limité qu’un jugement complet de propriété mais plus fort qu’une boîte à suggestions. La question en appel devrait être de savoir si l’action affectant RPKI correspondait à la catégorie publiée, au standard de preuve, à la règle de notification, à la continuité par défaut et à l’horloge de révision. L’action d’urgence était-elle justifiée? Le changement a-t-il été limité à la ressource affectée? Le registre a-t-il préservé la dernière route sûre vérifiée quand c’était possible? Le titulaire s’est-il vu offrir un moyen réaliste de corriger? De nouvelles preuves ont-elles exigé une annulation? Ces questions suffisent à discipliner le processus d’origine de route sans demander au registre de trancher tous les droits commerciaux.

Le chemin d’appel devrait aussi distinguer la contention temporaire de l’action finale. Un blocage temporaire après une compromission suspecte peut être justifié avant que tous les faits ne soient connus. Une révocation finale ou une action de certificat affectant des ressources en direct devrait exiger des preuves plus solides et une révision indépendante. Si le même standard est utilisé pour les deux, soit les urgences deviennent trop lentes, soit les actions finales trop faciles. L’échelle des recours doit être explicite avant la crise.

La continuité durant l’appel est la partie difficile. Si le ROA contesté semble frauduleux et soutient un routage incorrect actif, le préserver nuirait à l’Internet. Si le ROA contesté soutient une route client de longue date et que le litige porte sur un contrat, le supprimer immédiatement peut punir des utilisateurs innocents. La valeur par défaut devrait être la préservation du dernier état opérationnel sûr vérifié, à moins que cet état lui-même ne soit la source d’un préjudice immédiat. Ce principe ne décide pas de la propriété. Il empêche le système de validation de devenir l’instrument par lequel une partie gagne avant la révision.

L’histoire d’AFRINIC rend ces sauvegardes plus que théoriques. Le conflit Cloud Innovation a impliqué des tentatives de retrait de ressources, des injonctions, des gels bancaires et des revendications existentielles des deux côtés. Les litiges électoraux ont impliqué des accusations autour des procurations et des titres de membre. La mise sous administration judiciaire visait à préserver le statu quo tout en restaurant la gouvernance. Dans un tel environnement, les changements d’origine de route doivent être visiblement isolés des luttes plus larges. La notification, la correction et l’appel sont l’isolation.

Le contraire est également vrai. Un registre qui traite la notification comme une courtoisie, la correction comme un pouvoir discrétionnaire et l’appel comme un retard invite le marché à se protéger de manière privée. Les opérateurs créeront des politiques plus strictes. Les clouds exigeront davantage de documents. Les acheteurs réclameront des décotes. Les clients chercheront des alternatives. Les grands acteurs géreront par les relations et les avocats; les petits opérateurs absorberont le retard. Ainsi, une procédure faible ne nuit pas seulement à la partie sous revue. Elle élève le coût de la confiance pour toute la région.

La suspension d’urgence doit être limitée et réversible

Le pouvoir d’urgence est nécessaire en sécurité d’origine de route. Un faux ROA peut donner une légitimité apparente à un détournement. Un compte compromis peut publier de nouvelles origines. Une identité volée peut modifier maxLength pour autoriser des plus spécifiques. Un compromis du référentiel peut empoisonner les données. Une ordonnance judiciaire peut exiger une préservation immédiate. Un registre incapable d’agir rapidement contre un préjudice réel faillirait à ses membres. Mais le pouvoir d’urgence est aussi l’endroit le plus facile pour que le contrôle discrétionnaire se cache, car l’urgence affaiblit l’examen ordinaire.

La première règle de la suspension d’urgence est la limitation de l’objet. L’urgence doit être liée à un préjudice à l’origine de route, une fausse autorité, une compromission de compte, l’intégrité du certificat, l’intégrité du référentiel ou une restriction légale immédiate affectant le service de certification. Elle ne doit pas être utilisée pour sanctionner un défaut de paiement, faire respecter une politique commerciale large, discipliner un modèle d’affaires impopulaire ou faire pression sur un plaideur, à moins que des règles publiées ne relient clairement ce problème à la certification et que des sauvegardes de continuité ne s’appliquent. Si tout peut être une urgence, la catégorie n’a pas de discipline.

La deuxième règle est le rayon d’explosion minimal. Si un ROA est faux, suspendez ce ROA plutôt que de révoquer un certificat qui invalide de nombreuses routes non liées, à moins qu’une action au niveau du certificat ne soit nécessaire. Si une origine est contestée, évitez de désactiver des origines non liées. Si le contrôle du compte est compromis, bloquez les changements à haut risque tout en préservant les autorisations valides existantes quand c’est sûr. Si la publication du référentiel est incertaine, communiquez l’incident et préservez l’état validé là où les standards et le comportement logiciel le permettent. L’action d’urgence doit être un scalpel avant d’être un marteau.

La troisième règle est la limite de temps. La suspension d’urgence doit déclencher une horloge. Dans un délai défini, le registre ou le titulaire doit classifier l’événement, notifier les parties affectées, rassembler les preuves, décider de restaurer, remplacer, limiter ou escalader, et enregistrer le résultat. Un blocage temporaire qui se transforme silencieusement en une révocation indéfinie est une défaillance de gouvernance. Dans un marché IPv4 rare, l’incertitude indéfinie peut détruire de la valeur même si la route revient plus tard.

La quatrième règle est la correction réversible. Les erreurs surviennent. Un titulaire peut ne pas reconnaître un opérateur délégué légitime. Un registre peut mal lire un document. Un système de surveillance peut signaler un faux positif. Une ordonnance judiciaire peut être clarifiée. Un changement de maxLength peut avoir des conséquences imprévues. Le système doit rendre la réversion opérationnellement faisable sans forcer le titulaire à recommencer depuis le début. La réversion doit inclure non seulement la publication, mais aussi l’explication aux contreparties affectées quand c’est approprié. Le marché a besoin de savoir que l’état restauré est délibéré, pas accidentel.

La cinquième règle est la révision indépendante pour les cas graves. Une équipe du personnel du registre peut prendre une décision de contention immédiate, mais une suspension de longue durée ou à fort impact doit être révisée par une autorité séparée, à l’intérieur ou à l’extérieur du registre. Cette révision n’a pas besoin d’être lente. Elle peut être accélérée et technique. La clé est la séparation de l’équipe ou de l’acteur institutionnel qui a initié l’action. Un registre sous la pression d’un litige a besoin de cette protection autant pour lui-même que pour ses membres. La révision indépendante réduit l’affirmation selon laquelle la sécurité d’urgence n’est que de l’auto-assistance institutionnelle.

La suspension d’urgence nécessite aussi une conscience de l’aval. Un préfixe peut soutenir des hôpitaux, des banques, des universités, des portails gouvernementaux, des systèmes de paiement, des charges de travail cloud ou des VPN clients. Le registre peut ne pas connaître toutes les dépendances en aval, mais il peut supposer qu’elles existent. Le titulaire devrait maintenir des cartes de dépendance pour les préfixes à haute valeur. Les fournisseurs de transit et les clouds devraient maintenir des chemins de contact. L’action d’urgence devrait considérer si le dommage collatéral peut être réduit en préservant une dernière origine sûre connue, en limitant la suspension à un nouveau ROA suspect ou en utilisant une courte fenêtre de notification avant une action plus large.

Le but du pouvoir d’urgence est de préserver la confiance. L’usage excessif détruit la confiance parce que les titulaires commencent à craindre l’outil conçu pour les protéger. L’usage insuffisant détruit la confiance parce que la fausse autorité reste vivante. L’équilibre n’est pas rhétorique. Il est procédural: motifs limités, rayon d’explosion minimal, horloges courtes, correction réversible, révision indépendante et communication. L’opportunité d’AFRINIC est de démontrer que, même sous stress institutionnel, l’action RPKI d’urgence reste un instrument de sécurité plutôt qu’un levier discrétionnaire.

Les petits opérateurs africains portent le fardeau caché de la documentation

Le risque de révocation de ROA est souvent discuté comme si le titulaire affecté était une grande société de portefeuille d’adresses avec des avocats et des ingénieurs de routage à disposition. De nombreux réseaux affectés ne sont pas ainsi. Ce sont des fournisseurs d’accès, des universités, des organismes publics, des centres de données locaux, des réseaux de recherche, des hébergeurs de contenu, des entreprises régionales et des sociétés de services gérés qui dépendent d’un petit nombre de préfixes rares. Pour eux, le fardeau de prouver l’autorité après un événement de validation peut être plus dommageable que l’événement lui-même.

Le fardeau commence par les enregistrements. Un petit opérateur peut avoir rejoint AFRINIC il y a des années sous un nom d’entreprise différent. Son contact technique d’origine peut être parti. Son contact administratif peut être un dirigeant qui ne gère plus les réseaux. Ses factures peuvent être payées par une filiale. Son routage peut être externalisé. Les attributions à ses clients peuvent avoir crû par une pratique opérationnelle informelle plutôt que par une documentation rigoureuse. Rien de tout cela ne signifie que l’opérateur est illégitime. Cela signifie que le dossier de preuves de l’opérateur peut être plus faible que sa dépendance opérationnelle.

Quand un problème de ROA survient, cette faiblesse devient visible. Le registre peut demander des documents d’entreprise, une autorisation du conseil, une preuve d’identité, des contacts à jour, des plans de réseau, des données d’utilisation, des délégations clients, des confirmations d’AS d’origine ou des enregistrements historiques. Un fournisseur de transit peut demander une lettre d’autorisation. Une plateforme cloud peut demander un ROA à jour et une validation des contacts du registre. Un IXP peut demander pourquoi la route diffère des données attendues. Un client peut demander si le service va continuer. La même petite équipe doit répondre à tous tout en réparant la route.

Le fardeau de la documentation n’est pas seulement un coût. C’est un pouvoir de négociation. Un fournisseur avec un dossier faible peut accepter des conditions défavorables d’un fournisseur amont parce que celui-ci peut router plus vite. Un acheteur peut exiger une retenue de garantie. Un projet cloud peut être retardé. Un client peut choisir un concurrent plus grand. Un prêteur peut classer les revenus dépendant des adresses comme fragiles. L’incapacité de prouver rapidement l’autorité devient un désavantage commercial indépendamment du droit sous-jacent.

La région d’AFRINIC a un intérêt de développement à réduire ce fardeau sans abaisser la sécurité. Cela exige des niveaux de preuve prévisibles. Les changements routiniers de ROA par un titulaire établi avec des contacts à jour devraient être faciles. Les changements impliquant d’anciens contacts, une autorité d’entreprise contestée ou de nouvelles origines devraient exiger davantage de preuves, mais néanmoins avoir des listes de vérification claires. Les cas du secteur public et des universités devraient reconnaître des chaînes d’autorité plus lentes. Les délégations de services gérés devraient permettre au titulaire d’autoriser des délégués techniques sans renoncer au contrôle final. L’assainissement historique devrait être soutenu par une vérification par étapes plutôt que par une interruption soudaine de l’origine de route.

Le fardeau de la documentation interagit aussi avec la langue, la juridiction et la forme légale. La région de service d’AFRINIC couvre de nombreux systèmes juridiques et langues. Les preuves d’entreprise d’un pays peuvent ne pas ressembler à celles d’un autre. Les organismes publics peuvent avoir des mandats qui ne s’expriment pas en résolutions de conseil d’administration d’entreprises privées. Les universités peuvent avoir des structures de gouvernance statutaires. Les petites entreprises peuvent utiliser des documents locaux que les fournisseurs cloud mondiaux ne reconnaissent pas facilement. Un modèle de preuve rigide peut involontairement privilégier des formes d’entreprise familières au détriment de réalités régionales légitimes.

Le remède n’est pas d’accepter des revendications faibles. C’est de traduire l’autorité légitime en preuves utilisables. AFRINIC peut publier des catégories de preuves, et non seulement des noms de documents. Il peut dire ce qu’il faut établir: continuité du titulaire reconnu, autorité du contact actuel, délégation technique, consentement de l’AS d’origine, dépendance client, nécessité d’urgence et état du litige. Différents documents peuvent satisfaire la même catégorie dans différentes juridictions. Cela réduit le fardeau tout en préservant la rigueur.

Si AFRINIC ne résout pas cela, les acteurs privés le feront. Les grands opérateurs, les clouds, les courtiers et les fournisseurs de sécurité construiront leurs propres exigences de preuve. Ces exigences peuvent être plus strictes, moins sensibles à la région et plus difficiles à satisfaire pour les petits opérateurs africains. Le résultat serait un marché à deux vitesses où les grands réseaux peuvent se prouver eux-mêmes et les plus petits restent dépendants d’intermédiaires. RPKI devrait réduire le besoin de gardiens privés. Un mauvais processus de révocation ferait le contraire.

La rareté d’IPv4 transforme la continuité en protection du capital

La rareté d’IPv4 est la raison pour laquelle le risque de révocation de ROA est devenu un problème économique plutôt qu’un problème limité de sécurité réseau. Les documents officiels sur l’épuisement d’AFRINIC décrivent la rareté d’IPv4, les phases d’atterrissage en douceur et la disponibilité réduite des larges allocations. L’analyse de 2021 de l’IGP a décrit le marché mondial des transferts et la valeur croissante par adresse IPv4. Les rapports publics et la pratique du marché ont clairement montré que les blocs d’adresses peuvent supporter une valeur commerciale significative, même si les registres et les politiques résistent au langage de la propriété ordinaire. La catégorie juridique peut être contestée; la dépendance économique ne l’est pas.

Un préfixe a de la valeur parce que d’autres parties en dépendent. Les clients l’inscrivent dans les règles de pare-feu. Les banques le reconnaissent comme une source connue. Les fournisseurs le mettent sur liste blanche. Les API s’y lient. Les équipes de sécurité le surveillent. Le DNS et le DNS inverse pointent vers lui. Les bases de données de géolocalisation l’associent à des régions de service. Les plateformes cloud le routent. Les fournisseurs de transit l’acceptent. Les acheteurs l’examinent. Les prêteurs et les assureurs le traduisent en risque de continuité. Une adresse qui peut être remplacée demain est une capacité. Une adresse inscrite dans ces relations est une infrastructure assimilable à du capital.

La validité du ROA fait de plus en plus partie de cette inscription. Un préfixe constamment Valid sous les origines prévues est plus facile à traiter comme un actif opérationnel stable. Un préfixe qui devient fréquemment Invalid à cause de mauvaises pratiques de maxLength, de changements erratiques d’origine ou de lacunes de publication inexpliquées semble fragile. Un préfixe qui est NotFound malgré un usage sensible à la sécurité peut nécessiter une explication supplémentaire. Un préfixe dont l’état de certification peut être modifié sans notification durant des litiges institutionnels attire une prime de risque. La couche d’origine de route devient une composante de la qualité de l’actif.

Cela est particulièrement important pour la location et l’usage délégué. Un titulaire peut permettre à un autre réseau d’annoncer un préfixe pour de l’hébergement, un service géré, le cloud, l’accès client ou la mitigation de sécurité. Qu’on l’appelle location, délégation, attribution client ou accord de service, le fait opérationnel est que le titulaire et l’origine peuvent différer. Le ROA est le pont. Si le titulaire peut autoriser l’origine de manière fiable, l’accord a une valeur de marché. Si le titulaire ne peut garantir des changements opportuns de ROA ou craint le pouvoir discrétionnaire du registre, l’accord devient moins finançable. Les clauses contractuelles commencent à tourner autour de la maintenance, de la notification et de l’indemnisation du ROA.

Les transferts créent un problème similaire. Un transfert n’est pas économiquement complet lorsqu’un enregistrement de registre change. Il est complet lorsque l’acheteur peut utiliser le préfixe via les origines prévues, publier les ROA appropriés, aligner les enregistrements IRR et le DNS inverse, terminer l’intégration cloud ou transit et satisfaire la diligence client. Un événement de révocation ou de non-publication de ROA durant le règlement peut créer des blocages, des retards ou des réductions de prix. Plus le processus de certification du registre est incertain, plus le marché exigera un langage de garantie et de séquestre.

La crise d’AFRINIC illustre le danger de traiter la continuité et le contrôle institutionnel comme la même chose. Certains récits officiels et communautaires mettent l’accent sur la protection d’AFRINIC en tant que registre régional. Les critiques répondent que la fonction de grand livre doit être protégée sans préserver un contrôle d’accès sans vérification. La distinction utile est fonctionnelle. L’unicité des numéros, l’exactitude du registre, RDAP, WHOIS, le DNS inverse, les référentiels RPKI et les registres de litiges doivent continuer. Cela ne signifie pas que chaque revendication discrétionnaire du registre doive être à l’abri de toute révision. La continuité protège les réseaux qui utilisent les numéros. Elle ne doit pas être détournée en protection de l’institution aux dépens de ces réseaux.

Pour les titulaires, cela signifie maintenir des ROA, des contacts, des délégations et une surveillance précis. Pour les registres, cela signifie une publication fiable, une autorité de révocation limitée et des chemins de correction. Pour les opérateurs, cela signifie des politiques ROV claires et une communication. Pour les acheteurs et les clients, cela signifie interroger le contrôle de l’origine de route avant de signer. Pour les tribunaux et les administrateurs judiciaires, cela signifie préserver la continuité technique pendant que les procédures légales avancent. La valeur d’IPv4 rend l’échec de chaque partie plus coûteux.

AFRINIC est un cas d’essai parce que le besoin de connectivité, de peering local, d’adoption du cloud et de services publics numériques de la région se heurte à la rareté et au redressement institutionnel. Un système ROA fiable peut rendre les ressources africaines plus utilisables et plus précieuses. Un système discrétionnaire ou opaque peut leur attacher une décote de gouvernance. Dans un marché où chaque adresse est coûteuse à remplacer, la continuité n’est pas une courtoisie. C’est une protection du capital.

Le contraste limité avec l’IRR montre pourquoi RPKI a besoin de sauvegardes plus strictes

Les enregistrements de route IRR et les ROA RPKI sont souvent discutés ensemble parce que les deux concernent des revendications d’origine de préfixe. Le contraste n’est utile que s’il reste limité. Un enregistrement de route IRR est une entrée de base de données de politique de routage. Il peut alimenter les filtres chez les opérateurs et les points d’échange, mais son autorité dépend de la source, des règles du mainteneur, des miroirs, des enregistrements dupliqués et de la politique de l’opérateur. Un ROA est un enregistrement RPKI signé, validé via une chaîne de certificats de ressources. Il est plus limité dans ce qu’il affirme et plus fort dans le nombre de systèmes qui peuvent le traiter automatiquement. Les deux peuvent affecter l’atteignabilité. Ils le font via des modèles de confiance différents.

Le problème de l’IRR est un pluralisme désordonné: des enregistrements de route obsolètes, la récursion des AS-SET, la sélection de la source, le retard des miroirs, l’autorité du mainteneur et les standards de suppression peuvent tous produire des signaux opérationnels conflictuels. Le propos de cet article est différent. Le risque de révocation de ROA ne porte pas principalement sur des bases de données textuelles fragmentées. Il porte sur un signal de sécurité de routage de plus haute autorité dont la défaillance peut directement créer des états Invalid ou NotFound dans les réseaux qui font confiance aux validateurs. Le problème de l’IRR est l’autorité fragmentée. Le problème du ROA est la dépendance concentrée sur une chaîne de publication adossée à des certificats.

Cette dépendance concentrée est la force de RPKI. Elle réduit l’ambiguïté sur l’autorisation d’origine. Elle aide les opérateurs à rejeter les routes qui entrent en conflit avec l’autorité publiée. Elle donne aux clouds, aux opérateurs et aux clients une piste de preuve plus forte. Elle peut réduire la dépendance aux lettres privées et aux entrées IRR obsolètes. Mais plus la piste de preuve devient forte, plus il est dommageable quand l’autorité derrière elle change sans processus. Un enregistrement IRR incorrect peut être une mauvaise source parmi plusieurs. Un ROA incorrect ou manquant peut rendre une route Invalid dans les réseaux stricts.

AFRINIC devrait donc éviter deux erreurs. La première erreur est de traiter RPKI comme un simple autre service de registre pouvant être regroupé avec l’application ordinaire des comptes. Parce que les ROA peuvent affecter l’acceptation des routes en direct, ils nécessitent des règles de continuité spécifiques au service. La seconde erreur est de traiter RPKI comme une solution complète aux litiges d’autorité de routage. Un ROA ne prouve pas la pleine propriété, ne résout pas les contrats de location, ne décide pas de la géographie du client et ne tranche pas les litiges d’entreprise. Il prouve une autorisation d’origine de route actuelle sous le système RPKI. Sa force vient de ce qu’il reste à l’intérieur de cette limite.

Les sauvegardes RPKI devraient donc être plus strictes que les sauvegardes IRR sur trois aspects. Premièrement, la continuité du service doit être protégée parce que le rejet automatisé peut être sévère là où ROV est appliqué. Deuxièmement, les actions sévères doivent avoir une révision indépendante parce que la preuve adossée à des certificats a une haute autorité. Troisièmement, les incidents de référentiel et de publication doivent être signalés avec plus d’urgence parce que les validateurs dépendent de la fraîcheur et de l’intégrité. Ces standards n’affaiblissent pas RPKI. Ils rendent l’adoption plus sûre.

La conclusion politique est modeste mais exigeante. L’IRR restera une partie des opérations de routage pour les filtres clients et l’expression des politiques de routage. RPKI devrait de plus en plus porter le fardeau de l’autorisation d’origine. Les deux systèmes doivent être superposés, et non fusionnés. La tâche d’AFRINIC est de rendre sa couche RPKI suffisamment fiable pour que les opérateurs puissent s’y fier sans craindre que la validité de l’origine de route ne devienne un autre champ de bataille discrétionnaire. Cela signifie une bonne cryptographie, mais aussi une bonne procédure.

Le standard qu’AFRINIC devrait respecter

Le standard pour AFRINIC n’est pas qu’aucun ROA ne doive jamais être supprimé, modifié ou invalidé. Cela serait dangereux. Les autorisations fausses, obsolètes et compromises doivent pouvoir être corrigées. Le standard est qu’un changement d’origine de route ayant des conséquences sur le marché doit être limité dans son objet, visible dans sa catégorie, proportionnel dans ses preuves, protecteur de la continuité, réversible quand il est incorrect et révisable quand il est grave. Toute chose moindre transforme RPKI d’un service de sécurité en une source de choc institutionnel.

La première exigence est un modèle de classification public. AFRINIC devrait distinguer les changements routiniers demandés par le titulaire, les migrations planifiées, les corrections de maxLength, les remplacements d’AS d’origine, la maintenance des certificats, les incidents de référentiel, les compromissions suspectes, les fausses autorités, les actions sur ordonnance judiciaire, la préservation des ressources en litige et la révocation finale. L’étiquette n’a pas besoin de révéler des détails privés. Elle informe les parties affectées du type d’événement auquel elles font face et de la procédure qui s’applique. La classification réduit la panique.

La deuxième exigence est une échelle de notification et de correction. Les changements routiniers peuvent avancer rapidement. Les changements qui peuvent invalider des routes en direct doivent notifier les contacts affectés lorsque c’est faisable. Les actions d’urgence peuvent précéder la notification mais doivent déclencher une explication et une révision rapides. Les demandes de documentation doivent être proportionnelles au risque et réalistes à travers les juridictions africaines et les tailles d’opérateurs. Les fenêtres de correction doivent être assez longues pour une réponse véritable et assez courtes pour ne pas préserver indéfiniment une mauvaise autorité. L’échelle doit être connue avant une crise, et non inventée pendant.

La troisième exigence est la continuité par défaut. Les ROA valides existants pour des routes en direct de longue date doivent être préservés durant les litiges, à moins que la route elle-même ne soit la source d’un préjudice immédiat ou qu’une ordonnance judiciaire claire n’exige un traitement différent. Les nouveaux changements peuvent être restreints pendant la révision de l’autorité. Les ajouts suspects peuvent être suspendus. Mais le dernier état opérationnel sûr vérifié ne doit pas être détruit à la légère parce que le registre, le titulaire, le plaideur ou un tiers veut un levier. L’isolation des litiges est une forme de stabilité de routage.

En pratique, c’est le pare-feu de continuité: séparer la question d’autorité contestée de la route en direct, à moins que la route en direct ne soit elle-même le danger.

La quatrième exigence est la résilience du référentiel et la transparence des incidents. Les référentiels, les manifestes, les CRL, les certificats et les systèmes de publication RPKI doivent être traités comme une infrastructure critique. AFRINIC doit pouvoir dire si le référentiel fonctionne, si la publication est retardée, s’il y a un incident de manifeste ou de certificat et si les membres doivent agir. Des métriques agrégées sur la disponibilité, les actions d’urgence, les révocations, les réversions et le temps de correction aideraient le marché à évaluer la fiabilité sans exposer des cas privés.

La cinquième exigence est la révision indépendante pour les préjudices graves à l’origine de route. Une escalade interne peut suffire pour les erreurs ordinaires. La suspension de longue durée, la révocation de certificat affectant des routes en direct ou la suppression finale contestée doivent pouvoir être révisées par un processus qui n’est pas identique au décideur dans le litige sous-jacent. La révision doit se concentrer sur l’action RPKI, et non trancher toutes les revendications commerciales. Cela maintient le processus rapide tout en lui donnant de la légitimité.

La sixième exigence est une limite nette entre la sécurité et l’application des politiques. Si AFRINIC croit qu’un membre a violé la politique des ressources, il doit utiliser le processus politique et contractuel correspondant. Si une action RPKI est nécessaire pour prévenir une fausse autorité ou un préjudice immédiat, il doit le dire. Il ne doit pas dissimuler l’application large des politiques dans l’ambiguïté du certificat. La légitimité de la sécurité dépend de la retenue. Plus RPKI est perçu comme une garantie neutre d’origine de route, plus les opérateurs l’adopteront et l’appliqueront.

La septième exigence est l’alphabétisation du marché. AFRINIC n’a pas besoin d’avaliser chaque revendication du marché sur la propriété d’IPv4 pour comprendre que ses actions affectent le capital, les revenus et la continuité des clients. Un /24 peut soutenir une entreprise. Un /16 peut soutenir un portefeuille. Une seule erreur de ROA peut retarder une migration cloud. Un état NotFound peut ralentir la diligence. Un Invalid prolongé peut manquer aux attentes des clients. Reconnaître la conséquence économique n’est pas la même chose que renoncer à la politique du registre. C’est la base d’une gouvernance proportionnée.

La scène initiale devrait alors se terminer différemment. Un préfixe change d’origine pour une migration cloud. Le nouveau ROA est publié avant que la route ne bouge. L’ancienne origine reste autorisée durant un chevauchement défini. Les validateurs convergent. Le serveur de routes accepte la nouvelle route. Le ticket d’intégration cloud est fermé. Les clients ne voient aucune interruption. Si quelque chose tourne mal, le titulaire reçoit un avertissement spécifique, utilise un chemin de correction connu et peut revenir sur le champ erroné avant que le marché ne traite le bloc comme contaminé. Si une urgence exige une suspension, elle est limitée, enregistrée, bornée dans le temps et révisée.

C’est cela, l’économie du risque de révocation de ROA. L’enregistrement est petit. La dépendance qu’il représente ne l’est pas. Le test d’AFRINIC est de savoir s’il peut rendre l’autorité d’origine de route assez forte pour protéger contre les mauvaises routes, et assez restreinte pour ne pas devenir un amortisseur de chocs pour les défaillances institutionnelles. Dans un marché où la rareté d’IPv4 transforme la continuité en capital, la notification, la correction, l’appel et la correction réversible ne sont pas des luxes procéduraux. Ils font partie de l’infrastructure qui permet aux numéros rares de rester utilisables.