AFRINIC et l'économie de la visibilité des sous-allocations

Le ticket d’abus semblait ordinaire jusqu’à ce que tout le monde essaie de nommer la partie responsable. Un FAI régional avait reçu des plaintes concernant un trafic de credential stuffing provenant d’un petit /27 utilisé par l’un de ses clients professionnels. Le titulaire enregistré du bloc IPv4 parent était visible dans le registre AFRINIC. L’AS d’origine était visible dans BGP. Un revendeur se trouvait quelque part dans la chaîne commerciale. Un fournisseur de pare-feu géré gérait l’appareil de périphérie. Le client dont les serveurs généraient le trafic souhaitait la confidentialité, en partie parce que les machines pouvaient avoir été compromises et en partie parce qu’il ne voulait pas que ses modalités d’hébergement soient exposées à ses concurrents. L’opérateur amont voulait la responsabilité. La banque qui avait déposé la plainte voulait une personne capable d’arrêter l’attaque. Le registre public nommait le titulaire, pas le petit utilisateur opérationnel.

Cet écart est l’objet de la visibilité des sous-allocations. Le mot « sous-allocation » a un sens formel dans la politique d’AFRINIC: un LIR peut distribuer de l’espace aux FAI en aval pour une distribution ultérieure, sous réserve de règles de taille, de documentation et d’enregistrement. Le problème économique dépasse l’étiquette formelle. Les adresses IPv4, devenues rares, sont désormais utilisées par des titulaires, des LIR, des FAI en aval, des revendeurs, des fournisseurs d’hébergement, des prestataires de services gérés, des plateformes cloud, des courtiers, des accords de location, des entreprises clientes et parfois des utilisateurs encore plus délégués. Une partie de cet usage est légitime et ordinaire. Une partie est sensible du point de vue de la confidentialité. Une partie est confidentielle sur le plan commercial. Une partie est à l’origine d’abus, de fraudes, de filtrages de sanctions, de demandes des forces de l’ordre, d’erreurs de géolocalisation, d’erreurs de routage et de dommages à la réputation.

Le registre public ne voit souvent que la première couche. Internet fonctionne à travers de nombreuses autres couches. Un préfixe peut être enregistré par une partie, émané par une autre, délégué en DNS inverse à une troisième, répertorié dans un objet IRR maintenu par le contact d’un courtier, couvert par une ROA créée par le titulaire officiel, et utilisé par des clients dont les noms n’apparaissent jamais dans RDAP ou WHOIS. Rien de tout cela n’est automatiquement suspect. La division du travail est normale dans l’exploitation des réseaux. Le problème commence lorsque chaque acteur extérieur doit supporter le coût de la découverte de l’opérateur responsable après que quelque chose a déjà mal tourné.

AFRINIC est un cas d’étude utile car la couche aval est déjà intégrée dans les règles opérationnelles que les réseaux doivent respecter, tandis que son histoire institutionnelle récente montre pourquoi la visibilité en dessous du titulaire est importante. Le African Network Information Centre dessert l’Afrique et une partie de l’océan Indien en tant que registre Internet régional. Il gère les services qui transforment l’utilisation des ressources en preuves publiques: WHOIS, RDAP, DNS inverse, un registre de routage Internet et RPKI. Les règles opérationnelles pertinentes exigent que les allocations, les affectations et les sous-allocations soient enregistrées dans la base de données AFRINIC, et stipulent que les données d’enregistrement telles que les noms, les blocs, les contacts et le statut doivent rester exactes. Elles lient également la délégation inverse aux affectations ou sous-allocations enregistrées. Ces règles ne sont pas ornementales. Ce sont les points précis où la réalité opérationnelle en aval est censée devenir lisible.

La pression sur ces points a augmenté. AFRINIC est entré dans la phase 2 de l’IPv4 Soft Landing le 13 janvier 2020, les nouvelles allocations et affectations IPv4 ordinaires étant limitées à de petits blocs, avec un minimum de /24 et un maximum de /22. Des rapports publics ont fait état d’allégations de manipulation d’enregistrements d’adresses impliquant de l’espace IPv4 africain dormant, du litige à forte valeur entre AFRINIC et Cloud Innovation concernant l’utilisation et la commercialisation des ressources, d’un gel judiciaire des fonds d’AFRINIC en 2021, d’une mise sous séquestre à partir de 2023, de discontinuités au sein du conseil d’administration et des élections, d’une tentative d’élection annulée en 2025, du rétablissement ultérieur du conseil et des questions persistantes de reprise en 2026. Ces événements ne doivent pas être transformés en une fable générique de gouvernance. Pour la visibilité des sous-allocations, leur importance est plus étroite: lorsque le registre lui-même est sous pression, les marchés s’appuient encore plus sur des preuves claires de qui utilise les adresses rares, qui peut être contacté et quelle incertitude est réelle plutôt que rumeur.

Le client invisible est désormais un fait coûteux

À l’époque de l’abondance, un client aval caché était souvent une nuisance plutôt qu’un problème de tarification. Si les abus provenaient du sous-réseau d’un client, le fournisseur pouvait les tracer dans ses propres systèmes. Si un contact était périmé, une autre allocation pouvait être disponible. Si une petite plage était mal configurée, le renumérotage était pénible mais pas un événement capital. La rareté des adresses IPv4 a changé cette arithmétique. Un petit bloc peut soutenir des revenus d’hébergement, une infrastructure de paiement, des portails gouvernementaux, des clients SaaS, un accès VPN, des systèmes anti-fraude, la réputation des messageries et la continuité du réseau. Le client derrière l’adresse n’est plus seulement un détail opérationnel. Il est une source de risque, de valeur et de responsabilité.

L’opacité a un chemin économique mesurable. Elle augmente le coût de la recherche, car un plaignant, un amont, un acheteur, une banque, un assureur ou un enquêteur doit passer du temps à déterminer si le titulaire indiqué, l’AS d’origine, le revendeur, le prestataire de services gérés ou le client final peut résoudre le problème. Elle augmente le coût des erreurs, car si le /27 responsable ne peut pas être identifié rapidement, les contreparties surbloquent un /24, un /22 ou toute la réputation du titulaire. Elle augmente le coût des contrats, car les clients et les contreparties exigent des garanties, des indemnisations, des séquestres, des contacts d’urgence, des avoirs de service et une diligence supplémentaire lorsque le registre public ne leur en dit pas assez. Elle augmente le coût du capital, car un prêteur ou un acheteur décote les revenus liés à des adresses dont la responsabilité opérationnelle ne peut pas être reconstituée de manière indépendante.

Le client invisible modifie également les incitations à l’intérieur de la chaîne. Un titulaire qui peut percevoir des revenus tout en laissant l’utilisateur aval non enregistré peut sous-investir dans la réponse aux abus et la vérification des clients. Un revendeur qui peut refiler la responsabilité vers l’amont peut vendre à des clients plus risqués. Un prestataire géré qui n’apparaît pas dans le registre peut éviter des dommages à sa réputation lorsque sa configuration échoue. Un client qui ne peut pas être nommé publiquement pour des raisons légitimes de confidentialité peut encore avoir besoin de fournir une responsabilité authentifiée au titulaire, au registre ou à un demandeur légal dans des conditions définies. Si personne ne sait quelle couche supporte quelle obligation, chacun a intérêt à rendre visible la partie rentable et à garder privée la partie risquée.

Le langage de la politique d’AFRINIC indique la distinction correcte. Les sous-allocations et les affectations sont censées être enregistrées car l’unicité, le dépannage et la continuité exigent plus que le nom du titulaire. En même temps, le manuel n’exige pas un dossier public sur chaque utilisateur aval. Le juste milieu utile est la visibilité des responsabilités: suffisamment d’informations publiques et authentifiées pour identifier la couche opérationnelle responsable, sans exposer l’identité de chaque client à l’ensemble d’Internet.

Le coût de se tromper est le plus élevé pour les petits réseaux. Les grandes plateformes peuvent établir des canaux de confiance privés avec les grandes banques, les fournisseurs de transit, les vendeurs de sécurité et les autorités publiques. Les petits FAI et les entreprises d’hébergement régionales ne le peuvent pas. Ils dépendent des registres publics et semi-publics pour être crus par des inconnus. Si les preuves publiques sont minces, ils paient par des retards, un filtrage plus strict, des clients perdus et un pouvoir de négociation plus faible. L’opacité des sous-allocations devient ainsi une taxe régressive sur les réseaux les moins capables de l’absorber.

La couche aval fait déjà partie de l’économie des allocations

Le manuel de politiques d’AFRINIC ne décrit pas la distribution d’adresses comme une transaction en une étape entre le registre et l’utilisateur final. Il définit une hiérarchie. Un LIR reçoit des allocations d’un registre régional et attribue principalement de l’espace d’adressage aux utilisateurs finaux. Une sous-allocation est une distribution par un LIR à un FAI pour une distribution ultérieure. Une affectation est un bloc donné par un LIR à un FAI ou à un utilisateur final pour un usage spécifique dans l’infrastructure que cette partie exploite. L’espace agrégable par le fournisseur peut être affecté ou sous-alloué aux réseaux aval comme espace non portable, tandis que les affectations indépendantes du fournisseur ne sont pas destinées à de nouvelles sous-allocations. Il s’agit déjà d’un système en couches.

Le manuel attache ensuite des responsabilités à cette stratification. Il indique que chaque allocation, affectation PI, affectation PA, sous-allocation et autre affectation de ressources doit être enregistrée dans la base de données AFRINIC, et que les ressources non enregistrées seront considérées comme invalides. Il exige que les données d’enregistrement soient exactes à tout moment. Il fixe la sous-allocation IPv4 formelle minimale à /24. Il exige que les LIR effectuent des sous-allocations dans leurs fenêtres de sous-allocation ou demandent l’approbation d’AFRINIC au-delà de ces fenêtres. Il rend les LIR responsables de s’assurer que l’espace qui leur est alloué et ensuite sous-alloué est utilisé conformément aux politiques et directives de la communauté. Il conseille un démarrage lent pour les FAI aval. Il traite l’espace des FAI aval comme non portable au sein du bloc agrégable du LIR.

Ces règles révèlent la logique institutionnelle. AFRINIC n’a pas besoin de connaître l’utilisateur de chaque paquet, mais il ne peut pas rester indifférent à la structure aval. Si un FAI aval reçoit un /24, la base de données du registre ne doit pas rester aveugle. Si l’espace d’adresses public d’un utilisateur final n’est pas simplement une infrastructure point à point, le manuel indique qu’il doit être enregistré avec les contacts de l’utilisateur final, avec un aménagement pour la confidentialité des particuliers. Si le DNS inverse est demandé pour un /24, le manuel indique qu’au moins une affectation ou sous-allocation doit être enregistrée pour ce /24 spécifique. Les services de registre eux-mêmes supposent des faits opérationnels enregistrés.

La difficulté moderne est que la réalité commerciale crée des couches qui ne correspondent pas toujours aux anciennes catégories. Une société d’hébergement peut attribuer des /29, /28 ou /27 à l’intérieur d’un /24 enregistré. Un fournisseur de pare-feu peut exploiter des appliances de sécurité pour de nombreux clients au sein de l’agrégat d’un fournisseur. Un revendeur peut vendre des serveurs privés virtuels sans recevoir une sous-allocation formelle en /24. Un courtier peut aider à organiser l’utilisation sans apparaître comme un opérateur technique. Une plateforme de location peut coordonner l’accès des clients tandis que le titulaire enregistré reste inchangé. Un prestataire de services gérés peut contrôler la remédiation des abus mais pas l’origine des routes. La couche aval est plus granulaire que l’unité de politique.

Ce décalage ne devrait pas conduire à deux mauvaises réponses. La première consiste à prétendre que le registre public peut ignorer tout ce qui se trouve en dessous du titulaire enregistré. Cela rend le dépannage, la réponse aux abus, la diligence et le routage des forces de l’ordre trop coûteux. La seconde consiste à exiger que chaque petite plage client et chaque nom de client soient publics. Cela crée des préjudices à la confidentialité et à la sécurité et peut pousser les opérateurs légitimes vers des arrangements privés qui révèlent moins, pas plus.

Une meilleure réponse part de la visibilité fonctionnelle. Le registre devrait distinguer l’espace exploité par le titulaire de l’affectation client, de la sous-allocation d’un FAI aval, de l’espace géré par un revendeur, de l’exploitation en mode service géré, de l’exploitation en location, de l’utilisation d’un utilisateur final protégée par la confidentialité et du statut contesté ou périmé. Il n’est pas toujours nécessaire de publier le nom légal du client. Il devrait publier suffisamment pour montrer quelle couche est responsable de la réponse opérationnelle et le poids à accorder à cette déclaration. Le titulaire reste responsable de la relation avec le registre. L’opérateur aval devient trouvable pour les questions opérationnelles. Le client peut rester protégé lorsque la loi, la sécurité ou la confidentialité commerciale le justifient.

Cette logique d’enregistrement soutient déjà une carte des responsabilités. L’enregistrement existe pour garantir l’unicité et fournir des informations pour le dépannage. Sur un marché de rareté IPv4, le dépannage inclut désormais l’accessibilité des contacts pour les abus, l’explication de l’origine des routes, la cohérence du DNS inverse, les preuves de sous-délégation, la diligence des transferts, les achats du secteur public et la capacité des étrangers à distinguer un client caché d’un enregistrement abandonné.

Un registre public n’est pas une liste de clients privée

La frontière institutionnelle est simple à énoncer et difficile à mettre en œuvre. Un registre public ne doit pas devenir une liste de clients. Il doit devenir une carte des responsabilités. La distinction est importante. Une liste de clients divulgue qui achète des services à qui. Une carte des responsabilités divulgue quel rôle est responsable d’un segment de ressource, quel canal de contact est actif, quelles preuves soutiennent le rôle et combien de confiance les étrangers doivent lui accorder.

Pour les utilisateurs publics, l’enregistrement minimum utile n’est pas l’identité complète du client. C’est le rôle et l’accessibilité. Un enregistrement public peut indiquer qu’un /24 est exploité par le titulaire, affecté à une organisation, sous-alloué à un FAI aval, utilisé via un service géré, délégué à un utilisateur final protégé par la confidentialité, loué ou délégué commercialement sous la responsabilité du titulaire, ou sujet à contestation ou à une confirmation périmée. Il peut publier les contacts des rôles: contact du titulaire, contact technique, contact des abus, contact de routage et contact DNS inverse. Il peut exposer des horodatages: première inscription, dernière validation, dernière mise à jour matérielle et expiration de la validation. Il peut indiquer si le rôle aval a été auto-attesté par le titulaire, validé par AFRINIC, déduit des preuves de routage, confirmé par une délégation DNS inverse ou expurgé pour des raisons de confidentialité.

Pour les contreparties authentifiées, plus de détails peuvent être appropriés. Un fournisseur de transit évaluant une route, un acheteur effectuant une diligence de transfert, un registre traitant une révision ou un organisme public avec une demande légale peut avoir besoin de l’identité légale de l’opérateur aval, d’une lettre d’autorisation, de preuves contractuelles, de contacts d’urgence, de la géographie opérationnelle, de la catégorie de client, des fenêtres d’escalade et de la preuve que le titulaire peut imposer la coopération. Ces détails n’ont pas besoin d’être lisibles par tous. Ils peuvent être détenus par le titulaire, déposés auprès du registre sous une forme limitée, partagés sous accord de confidentialité ou divulgués par ordonnance judiciaire ou demande légale.

Pour les tribunaux et les forces de l’ordre, le seuil devrait être plus élevé mais les informations plus approfondies. Lorsqu’une demande légale cherche l’identité derrière une affectation protégée par la confidentialité, le système ne devrait pas obliger les enquêteurs à deviner à travers cinq intermédiaires. Le titulaire devrait être en mesure de retracer la chaîne. Le registre devrait savoir si le titulaire revendique une telle traçabilité. Le registre public devrait indiquer qu’il existe un utilisateur aval protégé par la confidentialité et que l’escalade judiciaire dispose d’un chemin défini, et non que le client est invisible pour tout le monde.

Les étiquettes de preuve sont essentielles, mais elles doivent être utilisées avec parcimonie et clairement. Le même fait visible a une valeur différente selon la façon dont il a été obtenu. Un FAI aval attesté par le titulaire n’est pas la même chose qu’un FAI validé par le registre. Une origine observée par routage n’est pas la même chose qu’un utilisateur opérationnel enregistré. Une délégation de DNS inverse n’est pas une preuve de responsabilité en matière d’abus. Un utilisateur expurgé pour des raisons de confidentialité n’est pas la même chose qu’un utilisateur inconnu. Un enregistrement actualisé le mois dernier n’est pas la même chose qu’un enregistrement touché pour la dernière fois en 2014. Un registre qui expose ces différences réduit le coût d’interprétation sans prétendre savoir plus qu’il ne sait.

La même structure protège le registre contre les excès de pouvoir. En publiant le rôle, la contactabilité, le statut des preuves et l’incertitude, AFRINIC peut améliorer la confiance du public sans revendiquer le droit d’inspecter chaque client pour la conformité aux politiques. Il peut dire: voici le titulaire reconnu; ce bloc est exploité en aval; le canal opérationnel responsable est ici; l’identité légale n’est pas divulguée publiquement mais traçable dans des conditions définies; la dernière date de validation est actuelle ou périmée. Un tel registre est plus mince qu’une base de données clients et plus épais qu’un simple enregistrement de titulaire. C’est le juste milieu économiquement utile.

La rareté des IPv4 transforme l’opacité en une décote de marché

L’opacité des sous-allocations n’est pas seulement un problème de sécurité. C’est une décote de marché. Lorsqu’une ressource rare ne peut pas être retracée du titulaire à la responsabilité opérationnelle réelle, chaque contrepartie tarifie l’écart. L’acheteur d’un bloc veut savoir si les utilisateurs aval non divulgués résisteront à la migration. Le locataire veut savoir si le bailleur peut prendre en charge les changements de route, de DNS inverse et d’abus à travers chaque revendeur intermédiaire. La banque veut savoir si les revenus liés aux adresses dépendent de clients dont les contrats ne peuvent pas être vérifiés. L’acheteur public veut savoir si un service critique repose sur des adresses dont la chaîne d’autorité est ambiguë. L’amont veut savoir s’il peut accepter la route sans devenir la première partie joignable pour chaque plainte.

Les faits de rareté d’AFRINIC rendent la décote concrète. Son avis d’épuisement indiquait que la phase 2 a commencé lorsqu’il ne restait pas plus d’un /11 d’espace non réservé dans le dernier /8. En phase 2, la plage d’allocation ou d’affectation ordinaire est petite, avec un minimum de /24 et un maximum de /22. De telles limites n’éliminent pas la demande; elles déplacent la demande vers la réutilisation, les transferts, la location, l’offre d’hébergement, la réaffectation des clients et la délégation opérationnelle. Plus la demande se déplace à travers les titulaires existants, plus il devient important de savoir ce qui se passe en dessous de ces titulaires.

L’opacité rend également les anciens enregistrements plus dangereux. KrebsOnSecurity a rapporté en 2019 des allégations selon lesquelles un espace IPv4 africain précieux associé à des organisations dormantes ou disparues aurait été détourné ou vendu par l’intermédiaire de sociétés liées à un ancien haut responsable d’AFRINIC; le chercheur Ron Guilmette a estimé que l’espace affecté représentait plus de 50 millions de dollars de valeur de marché. L’importance pour la visibilité des sous-allocations n’est pas seulement la corruption présumée. C’est que les enregistrements dormants et les faibles pistes d’autorité deviennent précieux lorsque l’IPv4 a un prix. Un enregistrement qui ne révèle pas clairement qui peut parler pour l’utilisation en aval invite à la fois la fraude et la décote défensive.

Le différend concernant Cloud Innovation montre le bord opposé du même problème. Des analyses publiques ont décrit un conflit portant sur des millions d’adresses IPv4, la location commerciale, l’utilisation réelle par rapport à l’utilisation enregistrée ou attendue, et la capacité revendiquée par AFRINIC de réviser ou de mettre fin à la reconnaissance des ressources. Cloud Innovation a contesté la théorie d’AFRINIC et le litige s’est intensifié. Pour la visibilité des sous-allocations, la leçon n’est pas que chaque location est mauvaise ou que chaque enquête du registre est légitime. La leçon est que lorsque l’utilisation réelle en aval est opaque, le registre peut être tenté de demander des informations générales sur les clients, tandis que le titulaire peut résister en invoquant la confidentialité commerciale. Les deux parties peuvent avoir partiellement raison et produire néanmoins un mauvais équilibre.

Dans un bon équilibre, les titulaires révèlent une responsabilité structurée sans livrer les listes brutes de clients. Dans un mauvais équilibre, ils révèlent peu, le registre exige trop, le litige commence et le marché décote l’ensemble du portefeuille. La rareté des IPv4 rend cette décote suffisamment importante pour modifier le comportement. Un titulaire avec une faible visibilité aval est confronté à une moindre confiance des acheteurs, des coûts juridiques plus élevés, une moins bonne réputation après un abus et une plus faible acceptation par le secteur public. Un registre avec une mauvaise visibilité est sous pression pour utiliser des examens larges parce que des preuves plus étroites ne sont pas disponibles. L’absence de visibilité crée ainsi l’argument de la discrétion.

L’objectif économique devrait être de rendre l’utilisation responsable moins chère que l’utilisation cachée. Un titulaire qui tient à jour des enregistrements de rôles aval validés, des contacts actifs, des clients protégés par la confidentialité mais traçables et des étiquettes claires d’incertitude devrait rencontrer moins de frictions dans les transactions et les incidents. Un titulaire qui ne peut pas expliquer qui utilise son espace devrait payer par des décotes, des approbations plus lentes et un examen plus strict. Ce n’est pas une punition. C’est la tarification de la qualité de l’information.

La pile de preuves est plurielle, et chaque surface a ses limites

Aucune source de données unique ne peut répondre à la question de la responsabilité aval. RDAP et WHOIS fournissent les données du titulaire enregistré et les contacts. BGP montre quel système autonome émet une route. Les objets IRR expriment la politique de routage et les conventions d’autorisation de route. RPKI et les ROA peuvent valider l’autorité d’origine. Le DNS inverse peut révéler des modèles de nommage, des délégations de clients et un historique opérationnel. Les bases de données de géolocalisation, traceroute, la latence, les certificats TLS, les historiques d’abus, les zones DNS, la réputation des messageries, les bannières d’hébergement, les registres d’entreprise et les contrats clients peuvent chacun ajouter des indices. Aucun n’est concluant en soi.

Cette pile de preuves plurielle est à la fois utile et dangereuse. Elle est utile car la responsabilité aval n’apparaît souvent que lorsque les signaux sont combinés. Un /24 enregistré par un titulaire, émané par un ASN d’hébergement, couvert par une ROA pour cet ASN, nommé avec un modèle de DNS inverse de revendeur, répertorié dans un objet IRR maintenu par un tiers et portant un historique d’abus lié à des clients VPS n’est probablement pas exploité par le titulaire au sens simple. Mais elle est dangereuse car l’inférence peut dépasser la preuve. Une étiquette de DNS inverse peut être périmée. Un objet IRR peut ne pas être autorisé. Une base de données de géolocalisation peut être erronée. Une ROA peut prouver l’autorité d’origine de la route, pas l’identité du client. Un AS d’origine peut être un opérateur de transit ou de service géré, pas l’utilisateur final.

Les services publics d’AFRINIC couvrent une grande partie de cette pile. Le registre fournit des services WHOIS, RDAP, DNS inverse, IRR et liés à RPKI. Son manuel de politiques relie la délégation inverse aux affectations ou sous-allocations enregistrées. Sa politique de contact des abus crée un emplacement pour les informations sur les abus tout en reconnaissant que l’objet, comme d’autres objets, est confronté au problème de l’exactitude des données. La franchise compte. Un champ peut créer un canal sans prouver que le canal est correct. Une ROA peut autoriser une origine sans prouver le client aval. Une affectation peut identifier une plage d’utilisateur final sans prouver chaque détail opérationnel ultérieur.

Le registre public devrait donc exposer le type de preuve. Un rôle aval peut être enregistré, attesté par le titulaire, validé par le registre, observé par le routage, cohérent avec le DNS inverse, déposé contractuellement, traçable par escalade judiciaire, périmé, contesté ou expurgé pour des raisons de confidentialité. Ces étiquettes peuvent sembler bureaucratiques si elles sont trop utilisées. Bien utilisées, elles ont une valeur économique. Elles empêchent qu’un signal faible soit traité comme un signal fort et empêchent que l’absence d’identité publique soit traitée comme une absence de responsabilité.

Les étiquettes de preuve réduisent également l’incitation à la mythologie privée. Sur les marchés opaques, les courtiers et les contreparties comblent les lacunes avec des allégations: bloc propre, adossé à des décisions de justice, de première partie, conforme à l’Afrique, sans abus, entièrement autorisé, sûr pour un usage dans le secteur public. Certaines allégations peuvent être vraies. Certaines peuvent être du marketing. Un enregistrement de registre qui expose des preuves structurées donne aux acheteurs et aux opérateurs un moyen de tester les allégations sans transformer AFRINIC en arbitre commercial. Le registre peut dire ce qu’il a validé et ce qu’il n’a pas validé. Le marché peut tarifer le reste.

Cela est particulièrement important en période de stress institutionnel. Pendant une mise sous séquestre, des litiges électoraux ou des contentieux, les rumeurs deviennent des substituts aux enregistrements. Si la base de données publique ne peut pas distinguer une exploitation aval ordinaire d’une délégation contestée, ou une protection de la confidentialité d’une utilisation inconnue, les contreparties déduiront à partir des gros titres. Une étiquette de preuve légère peut empêcher une réaction excessive coûteuse. Le registre n’a pas besoin de garantir chaque fait opérationnel. Il a besoin de divulguer le statut des faits qu’il détient.

La pile de preuves doit être lue comme une carte de probabilité. Plus la combinaison est forte entre sous-allocation enregistrée, contact validé, origine de route correspondante, ROA actuelle, DNS inverse cohérent et confirmation récente, plus la taxe d’ambiguïté est faible. Plus la combinaison est faible, plus la prudence est justifiée. C’est ainsi que les marchés se comportent déjà de manière informelle. AFRINIC peut améliorer le marché en rendant la carte de probabilité informelle plus explicite.

L’accessibilité en cas d’abus est une conséquence, pas toute l’histoire

Les plaintes pour abus sont souvent le moment où l’opacité des sous-allocations devient visible. Une banque voit des attaques. Un vendeur de sécurité voit des rappels de logiciels malveillants. Un opérateur de messagerie voit du spam. Un titulaire de droits d’auteur voit de l’hébergement. Un organisme public voit un balayage contre un service gouvernemental. Le plaignant interroge le registre et envoie un courrier au contact indiqué. Si le titulaire indiqué n’est pas l’opérateur réel, le ticket commence à se déplacer latéralement: du titulaire au revendeur, du revendeur au fournisseur d’hébergement, du fournisseur d’hébergement au fournisseur de pare-feu géré, du fournisseur au client. Chaque saut ajoute des retards et des erreurs.

Il est tentant de faire du contact des abus le seul sujet. Ce serait trop étroit. L’accessibilité en cas d’abus est un résultat de la visibilité aval, pas l’ensemble de l’économie. La même visibilité affecte l’acceptation des routes, la diligence des transactions, la continuité des clients, les achats publics, le filtrage des sanctions, la réponse des forces de l’ordre, la géolocalisation, le DNS inverse, la maintenance RPKI et la gestion de la réputation. Un ticket d’abus est simplement le moment où la structure cachée devient suffisamment coûteuse pour être remarquée.

La politique de contact des abus d’AFRINIC est une preuve utile de ce rôle limité. Elle spécifie un objet dédié comme l’emplacement préféré pour publier les informations publiques de contact des abus, référencé dans les objets inetnum, inet6num et aut-num. Elle vise à aider les signalements d’abus à atteindre le bon contact réseau. Elle reconnaît également un inconvénient: l’objet est confronté au même problème d’exactitude des données que les autres objets et n’améliore pas en soi l’exactitude de la base de données. C’est exactement le problème. Une boîte aux lettres ne résout pas l’opacité aval si la boîte aux lettres appartient à la mauvaise couche ou si le titulaire ne peut pas obliger l’opérateur aval à agir.

Une meilleure structure lie l’accessibilité en cas d’abus à la visibilité des rôles. Si un bloc est exploité par le titulaire, le bureau des abus du titulaire devrait être le principal canal public. S’il est sous-alloué à un FAI aval, le canal des abus validé du FAI aval devrait être visible, l’escalade vers le titulaire étant préservée. S’il est affecté à un client professionnel dont l’identité est protégée pour des raisons de confidentialité, le registre public devrait publier un bureau opérationnel responsable ou un proxy ainsi qu’un chemin d’escalade judiciaire. S’il est géré par un fournisseur de pare-feu ou d’hébergement, le registre public devrait montrer quelle couche opérationnelle reçoit les abus en premier. Si la responsabilité est contestée ou périmée, le registre devrait le dire.

Cela évite deux échecs courants. Le premier est le problème du mauvais bureau, où les plaintes atteignent le titulaire légal mais pas l’opérateur capable de remédier. Le second est le problème du client non imputable, où le titulaire invoque la confidentialité ou la distance du revendeur et aucune partie joignable n’agit. Dans les deux cas, le coût est transféré aux tiers. Les banques surbloquent. Les amonts menacent de suspension. Les services de réputation marquent l’espace voisin. Les forces de l’ordre escaladent par des canaux plus lents. Les utilisateurs innocents partagent la pénalité.

La visibilité des abus protège également les titulaires. Un titulaire qui peut montrer une responsabilité aval validée peut réduire sa propre exposition. Il peut dire à un plaignant: cette plage est exploitée par ce rôle aval; voici le canal des abus; le titulaire reste disponible pour l’escalade si le bureau aval échoue. Cela est mieux que de recevoir chaque ticket, d’en manquer certains et d’être traité comme négligent. C’est aussi mieux que de publier les identités brutes des clients d’une manière qui crée des risques pour la confidentialité ou la sécurité.

L’économie ne consiste donc pas à faire en sorte que chaque titulaire gère un grand service des abus. Il s’agit de rendre le chemin vers la responsabilité suffisamment court pour que les coûts fixes des incidents ne retombent pas sur des tiers aléatoires. La visibilité des sous-allocations est l’infrastructure plus large qui permet à la politique de contact des abus de fonctionner.

La rédaction responsable est le compromis de confidentialité

L’objection la plus forte à la visibilité aval est la confidentialité. Elle mérite d’être prise au sérieux. Un registre public qui nomme chaque client aval pourrait exposer des organisations vulnérables, des opérations de sécurité, des infrastructures de lanceurs d’alerte, des groupes politiques, des sous-traitants du secteur public, des institutions financières, des prestataires de santé et des entreprises ordinaires. Il pourrait également transformer le registre en un outil de reconnaissance. Les attaquants pourraient cartographier les clients, déduire les relations d’approvisionnement, identifier les fournisseurs de sécurité gérée, cibler les fenêtres de migration ou faire pression sur les fournisseurs de services. Les concurrents commerciaux pourraient savoir qui héberge qui. Une politique de visibilité qui ignore ces préjudices se saborderait elle-même.

Mais la confidentialité ne justifie pas une opacité totale. Internet impose déjà des externalités aux étrangers. Des paquets provenant d’une plage peuvent attaquer une banque, scanner un hôpital, héberger des pages d’hameçonnage, polluer la réputation des messageries, déclencher une révision des sanctions ou affecter un service public. Si la partie responsable est cachée derrière un langage de confidentialité et qu’aucun canal traçable n’existe, la confidentialité devient un moyen d’exporter les coûts. Le problème de conception est de préserver la confidentialité tout en préservant la responsabilité.

La réponse pratique est une divulgation à plusieurs niveaux. Les enregistrements publics devraient contenir le rôle, la contactabilité, le statut, la date de validation et la force des preuves. Ils ne devraient pas nécessairement publier chaque nom légal de client. Les contreparties authentifiées peuvent recevoir plus de détails en vertu d’un contrat ou d’un besoin opérationnel. Le registre peut détenir ou vérifier des preuves limitées sans les divulguer publiquement. Les forces de l’ordre et les tribunaux peuvent obtenir des informations d’identité plus approfondies par le biais d’une demande légale. Des canaux d’urgence peuvent exister pour un préjudice imminent sans rendre la divulgation d’urgence routinière. Les particuliers peuvent bénéficier d’une rédaction plus forte que les FAI aval en entreprise. Les agences publiques peuvent utiliser des contacts de sécurité désignés plutôt que d’exposer chaque sous-traitant.

La rédaction doit être étiquetée, pas silencieuse. « Identité du client retenue pour des raisons de confidentialité; le titulaire maintient un contact traçable; proxy des abus validé » est économiquement différent de « aucune information aval ». Cela indique aux étrangers qu’il existe une structure responsable même si le nom n’est pas public. Cela crée également une responsabilité pour le titulaire: si le titulaire revendique une traçabilité protégée par la confidentialité, il doit être en mesure de tracer. L’incapacité à tracer dans des conditions définies devrait avoir des conséquences, car sinon la confidentialité devient un faux statut.

L’étiquette doit également séparer la confidentialité du secret commercial. L’infrastructure sensible d’une banque, un groupe de défense des droits de l’homme et la liste de clients d’un revendeur peuvent tous mériter une protection, mais pour des raisons différentes et contre des niveaux de divulgation différents. Un FAI aval recevant une sous-allocation formelle /24 n’est pas dans la même situation qu’un client individuel recevant une petite affectation. L’intérêt public à identifier un réseau opérationnel est plus élevé que l’intérêt public à nommer chaque utilisateur final. Le manuel de politiques d’AFRINIC contient déjà un aménagement limité de la confidentialité lorsque l’utilisateur final est un particulier: l’espace peut être enregistré avec les coordonnées du fournisseur tout en référençant l’utilisateur final dans l’objet de la base de données. Cette logique peut être étendue avec prudence.

Le test institutionnel est de savoir si le système peut répondre à une question étroite: en cas de préjudice, de litige ou de demande légale, qui peut agir? Il n’a pas besoin de répondre à toutes les curiosités. Il n’a pas besoin de publier chaque client. Il ne doit pas laisser la confidentialité effacer la responsabilité. Sur un marché IPv4 rare, la conception de la confidentialité qui fonctionne n’est pas le secret. C’est la rédaction responsable.

Le routage, IRR et RPKI prouvent l’autorité, pas l’utilisation

Les preuves de routage sont puissantes car elles sont observables. Si un préfixe est émané par un AS particulier, l’Internet opérationnel peut le voir. Si un objet de route IRR existe, les réseaux peuvent déduire une politique de routage affirmée. Si une ROA autorise un AS d’origine, les parties utilisatrices peuvent valider l’autorité d’origine de la route. Ces signaux sont importants pour la visibilité aval, mais ils ne doivent pas être confondus avec un compte rendu complet de l’utilisation.

L’origine BGP identifie le réseau qui annonce la route, pas nécessairement le client qui utilise les adresses. Un fournisseur d’hébergement peut émettre de l’espace pour de nombreux clients. Un prestataire de services gérés peut annoncer un préfixe pour le compte d’une entreprise. Un bailleur peut autoriser l’AS d’un locataire tandis que le locataire dessert des milliers de petits utilisateurs. Un fournisseur de transit peut apparaître dans les preuves en raison du traitement des routes plutôt que de la responsabilité du client. L’AS d’origine est un indice sur le contrôle opérationnel, pas une identité légale pour chaque utilisateur aval.

Les objets IRR ont des limites similaires. Ils peuvent aider les amonts et les pairs à construire des filtres. Ils peuvent montrer que quelqu’un a créé un objet de route ou de jeu de routes cohérent avec une origine revendiquée. Mais les données IRR peuvent être périmées, dupliquées, créées dans différentes bases de données avec différentes normes d’authentification, ou maintenues par une partie qui n’est plus opérationnellement responsable. Un objet IRR maintenu par le contact technique d’un courtier peut aider à expliquer comment la route a été acceptée, mais il ne prouve pas qui gère les abus ou les contrats clients.

RPKI et les ROA sont plus forts pour l’autorité d’origine, mais plus étroits pour la responsabilité. Une ROA valide peut dire qu’un AS spécifié est autorisé à émettre un préfixe. Elle ne peut pas dire pourquoi l’AS utilise l’espace, qui est le client aval, si l’utilisation est régionale, si un revendeur est impliqué, si les signalements d’abus atteignent le bon bureau, ou si une affectation client existe sous le préfixe couvert. RPKI est un outil de sécurité de l’origine des routes, pas un système d’identité des clients.

Cette distinction est importante pour AFRINIC car les services RPKI et IRR sont proches de la reconnaissance du registre. Un titulaire peut être en mesure de créer une ROA pour l’AS d’un locataire. Cela donne à la route une apparence légitime du point de vue de la sécurité. Cela ne rend pas la chaîne aval visible. Inversement, l’absence d’une ROA peut refléter un retard opérationnel ou une faible adoption plutôt qu’une utilisation non autorisée. Si le registre public traite RPKI comme la seule preuve, il manquera le véritable problème de responsabilité.

L’utilisation correcte des preuves de routage est la triangulation. Un enregistrement de rôle aval peut dire que le titulaire enregistré a autorisé l’AS X à émettre le préfixe Y; qu’une ROA existe ou n’existe pas; qu’un objet IRR existe et est actuel ou périmé; que le contact des abus pour le rôle opérationnel est joignable; et que l’identité du client est publique, uniquement authentifiée ou expurgée pour des raisons de confidentialité. Cela combine l’autorité de routage avec la visibilité des responsabilités. Cela ne surcharge pas un artefact cryptographique ou de politique de routage avec des faits qu’il ne peut pas prouver.

Le rétablissement institutionnel d’AFRINIC bénéficierait de cette précision. Le registre n’a pas besoin de devenir un juge omniscient de l’utilisation aval. Il doit cesser de permettre à une surface de preuve de se faire passer pour une autre. Le routage indique l’accessibilité. RPKI indique l’autorité d’origine. IRR indique l’affirmation de politique. RDAP et WHOIS indiquent la reconnaissance et les contacts enregistrés. Le DNS inverse indique la délégation de nommage. La visibilité aval indique qui est responsable sous le titulaire, et avec quel degré de certitude.

Le DNS inverse est un indice, pas une preuve

Le DNS inverse est souvent traité comme un service technique secondaire, mais dans la visibilité aval, il a un poids pratique disproportionné. Un enregistrement PTR peut révéler une marque d’hébergement, un modèle de revendeur, une étiquette de client, un indice de pays, une identité de service de messagerie ou un ancien usage qui aurait dû être supprimé il y a des années. Les systèmes de messagerie, les outils de sécurité, les équipes de support client et les enquêteurs consultent régulièrement le DNS inverse car il offre un indice lisible par l’homme lorsque l’enregistrement du registre est trop abstrait.

Le manuel de politiques d’AFRINIC donne au DNS inverse un lien formel avec l’enregistrement aval. Il indique qu’AFRINIC accepte les demandes de délégation inverse des LIR actifs et qu’aucune délégation inverse de l’espace d’adresses IP administré ou alloué n’est autorisée à moins qu’une affectation ou sous-allocation de l’allocation spécifique ne soit enregistrée de manière appropriée dans la base de données AFRINIC. Pour une délégation inverse /24, au moins une affectation ou sous-allocation doit être enregistrée pour ce /24 spécifique. Cette règle est une reconnaissance discrète que le DNS inverse ne devrait pas flotter librement par rapport aux faits opérationnels enregistrés.

L’indice peut encore être trompeur. Le DNS inverse est souvent périmé après le départ d’un client. Les conventions de nommage peuvent utiliser des étiquettes génériques qui cachent l’opérateur réel. Un titulaire peut déléguer le DNS inverse à un revendeur dont le client contrôle le service. Un fournisseur de sécurité peut utiliser des noms neutres pour éviter d’exposer les clients. Un opérateur de messagerie peut définir des noms pour la délivrabilité plutôt que pour l’identité. Un utilisateur malveillant peut créer des noms trompeurs. Le DNS inverse ne peut donc pas être traité comme une preuve de l’identité aval.

Pourtant, un DNS inverse périmé ou opaque a des conséquences économiques. Les systèmes de réputation des messageries peuvent se méfier d’une plage. Les clients peuvent demander pourquoi les noms pointent vers un ancien fournisseur. Les équipes de sécurité peuvent envoyer des plaintes à la mauvaise organisation. Les fournisseurs de géolocalisation et de renseignement sur l’hébergement peuvent absorber d’anciennes étiquettes dans les systèmes de risque. Un client du secteur public peut échouer à un examen d’achat ou de sécurité parce que le nommage des adresses ne correspond pas au service déclaré. Un acheteur peut exiger des concessions de prix si le contrôle du DNS inverse semble incertain. Un locataire peut découvrir que le bailleur ne peut pas mettre à jour les noms rapidement parce que la piste d’affectation enregistrée est incomplète.

La réponse n’est pas de forcer des noms significatifs dans chaque enregistrement PTR. Le nommage opérationnel a des compromis de sécurité et de confidentialité. La réponse est de traiter le DNS inverse comme une surface de preuve. Une carte de responsabilité publique peut indiquer si le DNS inverse est contrôlé par le titulaire, délégué en aval, géré par le client, périmé, neutre du point de vue de la confidentialité ou incohérent avec le rôle enregistré. C’est plus utile que d’essayer de tout déduire des noms eux-mêmes.

Le DNS inverse illustre également pourquoi la visibilité des sous-allocations ne peut pas être résolue uniquement dans RDAP ou WHOIS. La base de données du registre peut montrer un titulaire et une sous-allocation. L’arbre inverse peut montrer une autre histoire opérationnelle. La route peut en montrer une troisième. Le contact des abus peut en montrer une quatrième. Un régime de visibilité sérieux réconcilie ces surfaces. Il signale les incohérences sans supposer que chaque incohérence est une faute. Il demande si l’incohérence est importante pour l’accessibilité, la réputation, l’escalade judiciaire ou la confiance du marché.

Pour AFRINIC, une amélioration modeste serait précieuse: lorsqu’une délégation inverse est liée à une affectation ou sous-allocation enregistrée, le registre public devrait rendre le lien lisible. Si un /24 a un DNS inverse délégué parce qu’une affectation de FAI aval existe, les étrangers devraient pouvoir voir que la délégation inverse n’est pas aléatoire. Si le DNS inverse reste sous le contrôle du titulaire alors que l’utilisation opérationnelle est en aval, le registre devrait indiquer qui gère les changements de nom et l’escalade des abus. Cela n’expose pas les clients. Cela expose la responsabilité d’un service qui les affecte déjà.

Les revendications d’utilisation régionale exigent de l’humilité

La région d’AFRINIC donne à la visibilité des sous-allocations une charge politique particulière. Le registre dessert l’Afrique et une partie de l’océan Indien. Ses documents sur l’épuisement et son manuel de politiques encadrent les ressources autour de la région de service d’AFRINIC. Sa politique de Soft Landing inclut un langage d’utilisation régionale pour les ressources pendant la période d’épuisement. Les analyses publiques du différend Cloud Innovation ont décrit les préoccupations d’AFRINIC concernant les écarts entre les descriptions d’utilisation enregistrées et les pays d’utilisation réels, et concernant les services émanant de la région. Cloud Innovation et les critiques alignés ont contesté cette interprétation et ont fait valoir que l’exploitation d’un réseau mondial ne peut pas être réduite à une simple règle géographique.

Pour la visibilité aval, le point clé est que l’utilisation régionale n’est pas toujours directement visible. La géographie du routage n’est pas la géographie des clients. Un préfixe émanant d’un AS en Europe peut desservir des utilisateurs africains via une plateforme de contenu ou de sécurité. Un serveur à Johannesburg peut soutenir des clients dans le monde entier. Un titulaire enregistré aux Seychelles peut louer des adresses à un réseau ayant des clients en Chine, au Nigéria et en Afrique du Sud. Une base de données de géolocalisation peut placer un bloc dans un pays en raison des données du registre, dans un autre en raison du routage et dans un troisième en raison des signalements des utilisateurs. Le DNS inverse peut utiliser des codes de pays pour des raisons de commodité opérationnelle. La latence peut indiquer où le trafic entre dans le réseau, pas où le service économique est fourni.

Cela ne signifie pas que les preuves d’utilisation régionale sont inutiles. Cela signifie qu’elles devraient être exprimées comme une confiance, pas une certitude. Un enregistrement de responsabilité peut distinguer la région de service déclarée, l’origine de route observée, le consensus de géolocalisation, la catégorie de client, la dépendance africaine, l’exploitation hors région et le statut inconnu. Il peut indiquer si un titulaire a auto-attesté que l’utilisation soutient la connectivité vers la région AFRINIC, si le registre a validé une revendication spécifique d’utilisation régionale, si les preuves sont uniquement observées par le routage ou si la question est contestée. C’est plus honnête que de prétendre qu’un seul champ de pays règle la question.

L’humilité est également économiquement efficace. Si le registre traite une inférence faible comme une preuve, les titulaires résisteront à la divulgation et plaideront. Si les titulaires traitent la géographie comme inconnaissable, le registre et les parties prenantes publiques supposeront une évasion. Un enregistrement basé sur la confiance donne aux deux parties un vocabulaire moins explosif. Il permet à AFRINIC de voir des modèles sans exiger des listes brutes de clients pour chaque bloc. Il permet aux titulaires de divulguer la pertinence régionale sans exposer chaque client. Il permet aux marchés de tarifer l’incertitude plutôt que d’inventer un binaire conforme/non conforme.

L’inférence d’utilisation régionale importe également pour les revendications de développement. Certains soutiennent que les IPv4 émises par l’Afrique devraient soutenir la connectivité africaine. D’autres soutiennent que les marchés mondiaux et la demande interrégionale importeront plus que la protection du stock régional résiduel. Le registre public ne devrait pas trancher ce débat par des champs obscurs. Il devrait fournir des preuves: où se trouve la responsabilité aval, quelle utilisation est déclarée, ce qui est observé, ce qui est validé et ce qui reste incertain. De bonnes preuves peuvent éclairer la politique. Une mauvaise inférence devient un contrôle du capital par conjecture.

La norme devrait être froide et pratique. Publier le rôle et la région déclarés au bon niveau de détail. Étiqueter les signaux observés. Préserver la confidentialité lorsque cela est justifié. Escalader uniquement lorsque les preuves entrent en conflit matériel avec la politique ou la confiance du public. Dans une région où le registre a déjà fait face à des litiges sur l’utilisation et le contrôle, cette humilité n’est pas une faiblesse. C’est une gestion des risques.

Les intermédiaires ont besoin d’étiquettes de responsabilité

La chaîne aval moderne est rarement une ligne droite. Un titulaire peut travailler avec un courtier. Le courtier peut présenter un revendeur. Le revendeur peut conditionner les adresses en produits VPS, de messagerie, VPN ou de pare-feu géré. Un fournisseur d’hébergement peut exploiter l’AS d’origine. Un client peut contrôler le serveur. Un fournisseur tiers de lutte contre les abus peut trier les plaintes. Un fournisseur de DNS géré peut contrôler les zones inverses. Le registre public peut ne montrer que le titulaire et peut-être l’AS d’origine. Lorsque des problèmes surviennent, chaque couche peut dire qu’une autre couche détient les faits opérationnels.

Les courtiers et les revendeurs ne sont pas intrinsèquement mauvais. Ils réduisent les coûts de recherche, font correspondre les capacités inutilisées à la demande, fournissent une intégration technique, rassemblent la documentation et aident les petits réseaux à obtenir des adresses qu’ils ne pourraient pas trouver autrement. Les prestataires de services gérés résolvent également de vrais problèmes. De nombreux clients ne veulent pas gérer le routage, le DNS inverse, les bureaux des abus ou RPKI. L’externalisation peut améliorer la qualité. Le problème de visibilité n’est pas l’intermédiation. C’est l’intermédiation non étiquetée.

Une étiquette de responsabilité est une divulgation étroite du rôle. Elle ne dit pas que le courtier possède le bloc ou que le revendeur est le client final. Elle peut dire qu’un intermédiaire commercial est impliqué mais n’est pas le contact opérationnel. Elle peut dire qu’un revendeur est responsable de la vérification des clients. Elle peut dire qu’un opérateur de services gérés reçoit d’abord les abus. Elle peut dire que le titulaire reste responsable des modifications du registre. Elle peut dire qu’un FAI aval contrôle les affectations des clients. Elle peut dire que l’identité du client est expurgée pour des raisons de confidentialité mais traçable via l’opérateur. Les étiquettes indiquent aux étrangers où ne pas envoyer la mauvaise demande.

De telles étiquettes réduiraient les échecs courants. Un amont évaluant une route saurait si l’AS d’origine agit en tant que locataire, opérateur géré ou réseau titulaire. Un plaignant saurait si la boîte aux lettres publique des abus atteint l’opérateur le plus proche du client. Un acheteur saurait si des revendeurs non divulgués peuvent avoir des revendications de continuité des clients. Un acheteur public saurait si l’approvisionnement en adresses d’un sous-traitant dépend d’une chaîne intermédiée. Le registre saurait si un titulaire revendiquant la confidentialité a au moins cartographié sa chaîne de responsabilité.

Les étiquettes de responsabilité aident également à distinguer les locations de la visibilité des sous-allocations sans faire des locations le cadre principal. La location est un canal par lequel l’opacité apparaît. La question pertinente ici n’est pas les recours privés ou le prix commercial du bail. C’est si la location ou une autre délégation commerciale change qui utilise l’espace et qui peut être contacté. Une location avec des étiquettes de responsabilité claires peut être moins risquée qu’une affectation d’hébergement ordinaire sans traçabilité. Une vente avec des clients aval cachés peut être plus problématique qu’une délégation transparente à durée limitée.

La même logique s’applique à la confidentialité des clients. Une étiquette peut dire « utilisateur final protégé par la confidentialité, traçable par le titulaire » sans nommer l’utilisateur final. Elle peut dire « contact des forces de l’ordre disponible via l’escalade du titulaire » sans publier de canaux sensibles. Elle peut dire « liste de clients contrôlée par le revendeur » pour que les contreparties sachent que le titulaire peut ne pas avoir de journaux immédiats. Ce n’est pas une liste de clients. C’est une carte de qui a quel devoir opérationnel.

Les intermédiaires deviennent économiquement plus sûrs lorsque leurs rôles sont lisibles. S’ils résistent à toute divulgation de rôle, les marchés supposeront le pire. Si le registre exige une divulgation complète des clients, les intermédiaires légitimes résisteront. Les étiquettes offrent une alternative moins coûteuse: responsabilité visible, identité protégée et incertitude tarifée.

La dépendance du secteur public transforme l’opacité en risque pour la capacité de l’État

L’opacité des sous-allocations devient plus grave lorsque les systèmes du secteur public dépendent de la chaîne d’adressage. Un ministère peut héberger des services aux citoyens chez un fournisseur local qui utilise des adresses d’un titulaire régional. Un hôpital public peut acheter une sécurité gérée auprès d’un fournisseur dont les nœuds de pare-feu se trouvent dans un bloc loué ou sous-alloué. Une unité de cybercriminalité de la police peut avoir besoin d’informations sur les abonnés ou les clients après un incident. Un réseau national d’éducation peut s’appuyer sur des fournisseurs aval pour les campus. Un tribunal peut avoir besoin de préserver les preuves pendant qu’un service reste en ligne. Dans chaque cas, l’organisme public peut ne pas savoir que sa continuité dépend d’une chaîne d’adresses profonde de plusieurs couches.

Pour les clients commerciaux ordinaires, l’opacité est un problème d’allocation des risques. Pour les clients du secteur public, cela peut devenir un problème de capacité de l’État. Un portail fiscal qui perd la délivrabilité des courriels parce que le DNS inverse est périmé, une plateforme d’achats publics qui est bloquée parce que les adresses voisines sont abusives, ou un fournisseur de services d’urgence qui ne peut pas prouver l’autorité de la route ne fait pas face à un simple inconvénient informatique. Le coût est supporté par les citoyens et les institutions publiques qui n’ont pas choisi la structure d’adressage cachée.

Les besoins des forces de l’ordre sont également spécifiques. Les enquêteurs commencent souvent avec une adresse IP, un horodatage et un port. Si le registre public ne nomme que le titulaire, l’enquêteur doit parcourir la chaîne: titulaire, revendeur, fournisseur géré, client, utilisateur final. La NAT, la CGNAT, la location de VPS et l’hébergement à court terme rendent le temps critique. Si le titulaire ne maintient pas la traçabilité ou si le revendeur n’est pas enregistré, les demandes légales peuvent arriver trop tard ou à la mauvaise partie. Une divulgation publique trop large n’est pas la réponse, mais un chemin d’escalade structuré l’est.

L’historique de crise d’AFRINIC élève les enjeux car les autorités publiques peuvent déjà considérer le registre comme une institution. Les reportages sur la mise sous séquestre mauricienne ont décrit un mandat de préservation des opérations et de rétablissement de la gouvernance, tandis que les couvertures ultérieures ont décrit la pression continue des tribunaux, les mécanismes électoraux défaillants, les questions de rétablissement du conseil, les poursuites et les litiges concernant le traitement des ressources de numérotation. Dans un tel environnement, les utilisateurs du secteur public ont besoin de preuves que la continuité des adresses ne dépend pas d’arrangements privés non enregistrés qui s’effondrent sous le coup d’un litige ou d’un changement de gouvernance.

Une norme d’achat du secteur public pourrait être simple. Les fournisseurs utilisant des IPv4 administrées par AFRINIC pour des services publics devraient être en mesure de montrer le titulaire enregistré, le réseau d’exploitation, l’autorité d’origine de la route, le contrôle du DNS inverse, les contacts des abus et de la sécurité, les étiquettes de responsabilité aval, les arrangements de confidentialité, l’escalade des demandes légales et tout litige affectant l’espace. La version publique n’a pas besoin de révéler chaque client. Le dossier destiné à l’acheteur devrait être suffisamment complet pour soutenir la continuité et la responsabilité.

La dépendance du secteur public modifie donc l’équilibre de la confidentialité. Le public n’a pas besoin de chaque nom de client. Il a besoin de l’assurance que les services critiques ont une responsabilité d’adressage traçable. Un registre qui aide à créer cette assurance ne devient pas un organisme de surveillance. Il réduit le risque des achats publics sur un marché où la rareté des adresses et l’instabilité institutionnelle ont rendu la couche d’adressage visible.

Le rétablissement sera jugé en dessous de la ligne du titulaire

AFRINIC n’a pas besoin d’un régime de transparence maximale. Il a besoin d’un pacte de visibilité qui énonce à quoi sert la visibilité aval: l’unicité, le dépannage, l’accessibilité en cas d’abus, la diligence sur l’autorité des routes, la cohérence du DNS inverse, l’escalade judiciaire, la confiance dans les transactions et la continuité pour les clients qui dépendent des IPv4 rares. Il devrait également énoncer à quoi la visibilité ne sert pas: publier des listes brutes de clients, juger chaque arrangement commercial, exposer des utilisateurs sensibles ou utiliser les champs d’enregistrement comme levier dans des litiges non liés.

Le pacte pourrait commencer par quelques types d’enregistrement. Les sous-allocations formelles au seuil minimum de la politique ou au-dessus devraient être visibles publiquement avec l’identité du FAI aval, les contacts, le statut, la date de validation et l’escalade vers le titulaire. Les affectations aux utilisateurs finaux qui nécessitent une responsabilité opérationnelle publique devraient identifier l’utilisateur final ou un proxy protégé pour la confidentialité avec des étiquettes de rôle claires. Les plages de clients plus petites en dessous des seuils de sous-allocation publique n’ont pas besoin d’être nommées publiquement, mais les titulaires devraient maintenir la traçabilité et publier des étiquettes de responsabilité lorsque les abus, le routage, le DNS inverse ou les demandes légales rendent le rôle important.

Chaque enregistrement devrait porter un statut de preuve: validé par le registre, attesté par le titulaire, confirmé par la contrepartie, observé par le routage, expurgé pour des raisons de confidentialité mais traçable, périmé, contesté ou contraint par une décision de justice. Ces étiquettes empêcheraient un champ public de prétendre être plus certain qu’il ne l’est. Elles permettraient également aux marchés de récompenser de meilleures preuves. Un bloc avec une responsabilité aval actuelle devrait être moins cher à router, transférer, louer, financer et acquérir qu’un bloc avec des données périmées ne contenant que le titulaire.

Le pacte devrait inclure des cycles de validation. Les contacts et les étiquettes de rôle devraient expirer à moins d’être actualisés. Les changements matériels, tels qu’un nouveau FAI aval, un nouvel AS d’origine, une prise de contrôle par un service géré, un changement de délégation DNS inverse ou une migration importante de clients, devraient déclencher des obligations de mise à jour. Le défaut de mise à jour devrait d’abord produire une incertitude visible et des procédures de correction, pas une atteinte immédiate aux ressources. Les recours graves devraient être réservés aux fausses déclarations, aux utilisations à haut risque non traçables, à la fraude, aux ordonnances judiciaires ou au refus répété de maintenir une responsabilité minimale.

Il devrait également y avoir une couche de preuves privée. Les titulaires devraient conserver des enregistrements des affectations de clients, des autorisations, des contrats de revendeur, de l’escalade des abus, des autorisations de routage et des justifications de confidentialité. AFRINIC ne devrait pas avoir besoin de chaque document par défaut. Il devrait pouvoir demander des preuves proportionnées lorsqu’une sous-allocation formelle, une dépendance du secteur public, un transfert, un litige, un modèle d’abus majeur ou un conflit DNS inverse/RPKI rend le rôle aval important. La demande devrait être spécifique, limitée dans le temps et plus étroite qu’un audit de tous les clients, à moins que les preuves ne justifient plus.

Le pacte devrait récompenser la correction. Si un titulaire met volontairement à jour une responsabilité aval périmée, la réponse par défaut devrait être la correction de l’enregistrement, pas une application large. Sinon, les titulaires rationnels se cacheront. La fraude et les fausses déclarations intentionnelles nécessitent un traitement différent, mais la correction ordinaire devrait être encouragée. Un registre qui se remet d’un historique de corruption d’enregistrements doit être ferme contre la fausseté et sûr pour la vérité.

Le rétablissement public d’AFRINIC est souvent discuté à travers les conseils d’administration, les budgets, la mise sous séquestre, les ordonnances judiciaires, l’intervention de l’ICANN et la légitimité institutionnelle. Ces questions sont réelles. Mais pour de nombreux opérateurs, le test pratique se situera en dessous de la ligne du titulaire. Un client, un amont, un acheteur, un organisme public, un bureau des forces de l’ordre ou un rapporteur d’abus peut-il comprendre qui est responsable d’une utilisation spécifique d’IPv4 rares lorsque cette utilisation n’est pas le fait du titulaire enregistré? Si ce n’est pas le cas, le rétablissement de la gouvernance reste trop abstrait.

Le registre peut être juridiquement préservé et laisser néanmoins la responsabilité aval opaque. Il peut élire un conseil d’administration et n’exposer que les enregistrements au niveau du titulaire. Il peut exploiter RDAP, WHOIS, le DNS inverse, IRR et RPKI sans relier ces surfaces en une carte de responsabilité. Il peut annoncer des politiques et laisser néanmoins les marchés deviner si un préfixe routé est exploité par le titulaire, par un revendeur, loué, sous-alloué, affecté, protégé par la confidentialité ou contesté. Sur un marché de rareté, cette supposition est coûteuse.

L’histoire récente d’AFRINIC lui donne à la fois une raison et une obligation de faire mieux. Les signalements de vols d’adresses montrent le danger d’une faible autorité des enregistrements. Le différend Cloud Innovation montre le danger d’une délégation commerciale opaque et d’un large pouvoir discrétionnaire du registre qui entrent en collision. La mise sous séquestre montre le besoin de continuité lorsque la gouvernance d’entreprise échoue. La discontinuité électorale montre que l’autorité des membres et la légitimité institutionnelle peuvent elles-mêmes devenir des faits de marché. Les litiges continus montrent que les allégations publiques concernant la location, la commercialisation et la reconnaissance judiciaire peuvent ébranler la confiance. La visibilité des sous-allocations ne résoudra pas tout cela. Elle réduira une incertitude importante qui, autrement, alimente le reste.

La posture institutionnelle correcte est modeste. AFRINIC ne devrait pas prétendre connaître chaque client. Il ne devrait pas devenir le régulateur économique de chaque service aval. Il ne devrait pas exiger des listes de clients comme substitut à une politique claire. Il ne devrait pas utiliser la visibilité pour punir des arrangements commerciaux impopulaires sans garanties appropriées. Mais il devrait insister pour que les titulaires enregistrés puissent expliquer et prouver la responsabilité aval au niveau où les tiers s’appuient sur l’enregistrement d’adresse. C’est la différence entre un registre et un brouillard privé.

Le gain est pratique: des signalements d’abus plus ciblés, un filtrage moins grossier, des changements de DNS inverse et de RPKI plus propres, une diligence moins dépendante des courtiers, des achats publics plus solides et des clients protégés avec une traçabilité responsable. Les marchés tariféraient la responsabilité vérifiée plutôt que les rumeurs.

Le pacte disciplinerait également les titulaires. Un titulaire qui loue, affecte, sous-alloue ou délègue de la capacité IPv4 rare ne devrait pas pouvoir dire seulement: le registre public me nomme, donc tout le monde doit me faire confiance. Le titulaire est l’ancre, pas toute l’histoire. S’il profite de l’utilisation aval, protège des clients ou utilise des intermédiaires, il doit savoir qui peut agir. S’il ne le peut pas, le marché a raison de décoter le bloc.

AFRINIC est un cas d’étude parce que le registre africain a vécu la collision complète de la rareté, de l’intégrité des enregistrements, de la délégation commerciale, des litiges et du rétablissement institutionnel. La leçon n’est pas que chaque utilisateur aval devrait être public. C’est que la responsabilité ne peut pas rester privée lorsque les coûts de son absence sont publics. Un registre utile n’expose pas la liste des clients. Il expose suffisamment de la chaîne de responsabilité pour que les étrangers puissent agir sans se joindre à la lutte.