Ce que les sous-allocations d'AFRINIC laissent sous le registre public

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 du 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 périphérique.

Le client dont les serveurs généraient le trafic souhaitait rester privé, en partie parce que les machines avaient peut-être été compromises et en partie parce qu'il ne voulait pas exposer ses arrangements d'hébergement à ses concurrents. Le fournisseur amont voulait de la responsabilité. La banque qui avait déposé la plainte voulait une personne capable d'arrêter l'attaque. Le registre nommait le titulaire, pas le petit utilisateur opérationnel.

Cet écart est le sujet de la visibilité des sous-allocations. Le mot « sous-allocation » a une signification formelle dans la politique d'AFRINIC: un LIR peut distribuer de l'espace à des FAI aval pour une distribution ultérieure, sous réserve de règles de taille, de documentation et d'enregistrement. Le problème économique est plus large que l'étiquette formelle. L'IPv4 rare est désormais utilisé via des titulaires, LIR, FAI aval, revendeurs, fournisseurs d'hébergement, fournisseurs de services gérés, plateformes cloud, courtiers, arrangements de location, clients entreprises et parfois des utilisateurs délégués supplémentaires.

Une partie de cette utilisation est légitime et ordinaire. Une partie est sensible à la vie privée. Une partie est confidentielle sur le plan commercial. Une partie est là où les abus, la fraude, le filtrage des sanctions, les demandes des forces de l'ordre, les erreurs de géolocalisation, les erreurs de routage et les dommages de réputation surviennent réellement.

Le registre public ne voit souvent que la première couche. Internet fonctionne à travers de nombreuses autres couches. Un préfixe peut être enregistré pour une partie, originaire d'une autre, délégué dans le DNS inversé à une troisième, listé dans un objet IRR maintenu par le contact d'un courtier, couvert par un ROA créé par le titulaire formel, 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 les opérations réseau.

Le problème commence lorsque chaque partie extérieure 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 de test utile car la couche aval est déjà intégrée dans les règles opérationnelles avec lesquelles les réseaux doivent vivre, alors que son histoire institutionnelle récente montre pourquoi la visibilité en dessous du titulaire est importante. L'African Network Information Centre dessert l'Afrique et une partie de l'océan Indien en tant que registre régional. Il se trouve au cœur des services qui transforment l'utilisation des ressources en preuves publiques: WHOIS, RDAP, DNS inversé, un registre de routage Internet et RPKI.

Les règles opérationnelles pertinentes exigent que les allocations, attributions et sous-allocations soient enregistrées dans la base de données AFRINIC, et que les données d'enregistrement telles que les noms, blocs, contacts et statuts restent correctes. Elles lient également la délégation inversée aux attributions ou sous-allocations enregistrées. Ces règles ne sont pas décoratives. Ce sont les points étroits 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 d'atterrissage en douceur IPv4 le 13 janvier 2020, avec des tailles d'allocation et d'attribution ordinaires nouvelles contraintes à de petits blocs, dont un minimum /24 et un maximum /22.

Des reportages publics ont décrit des allégations de manipulation d'enregistrements d'adresses impliquant de l'espace IPv4 africain dormant, le litige de grande valeur entre AFRINIC et Cloud Innovation concernant l'utilisation et la commercialisation des ressources, un gel judiciaire des fonds d'AFRINIC en 2021, la mise sous séquestre à partir de 2023, une discontinuité du conseil d'administration et des élections, une tentative d'élection annulée en 2025, une restauration ultérieure du conseil, et des questions de rétablissement continu en 2026. Ces événements ne doivent pas être transformés en un conte moral générique sur la gouvernance.

Pour la visibilité des sous-allocations, leur importance est plus étroite: lorsque le registre lui-même est sous tension, les marchés comptent 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 de la rumeur.

La bonne question n'est pas de savoir si chaque client doit être nommé publiquement. Ce serait dangereux et économiquement insensé. La bonne question est de savoir combien de détails aval doivent être visibles, pour qui, à quel niveau de certitude, et avec quel effet sur le coût du routage, de la réponse aux abus, des transferts, de la location, des marchés publics et de la responsabilité du registre. Un registre public n'est pas une liste de clients privée. Mais s'il expose seulement le titulaire formel tandis que l'utilisateur pratique se trouve à trois contrats de distance, il laisse le marché fixer le prix de l'opacité.

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

À l'ère de l'abondance, un client aval caché était souvent une nuisance plutôt qu'un problème de prix. Si un abus provenait d'un sous-réseau client, le fournisseur pouvait le tracer dans ses propres systèmes. Si un contact était obsolète, une autre allocation était peut-être disponible. Si une petite plage était mal configurée, le renumérotage était douloureux mais pas un événement financier. La rareté de l'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 du courrier et la continuité du réseau. Le client derrière l'adresse n'est plus seulement un détail opérationnel. C'est une source de risque, de valeur et de responsabilité.

L'opacité a un chemin économique mesurable. Elle augmente les coûts de 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 listé, l'AS d'origine, le revendeur, le fournisseur de services gérés ou le client final peut résoudre le problème. Elle augmente les coûts d'erreur, car si le /27 responsable ne peut pas être identifié rapidement, les contreparties sur-bloquent un /24, un /22 ou une réputation entière du titulaire.

Elle augmente les coûts de contractualisation, car les clients et les contreparties exigent des garanties, des indemnités, des séquestres, des contacts d'urgence, des crédits de service et des diligences supplémentaires lorsque le registre public ne leur en dit pas assez. Elle augmente le coût du capital, car un prêteur ou un acheteur escompte les revenus liés aux adresses dont la responsabilité opérationnelle ne peut être reconstituée indépendamment.

Le client invisible modifie également les incitations au sein 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 transmettre la responsabilité vers le haut peut vendre à des clients plus risqués. Un fournisseur géré qui n'apparaît pas dans le registre peut éviter les dommages de 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 a quel devoir, tout le monde a intérêt à garder la partie rentable visible et la partie risquée privée.

Le langage politique d'AFRINIC pointe vers la distinction correcte. Les sous-allocations et attributions 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é de la responsabilité: suffisamment d'informations publiques et authentifiées pour identifier la couche opérationnelle responsable, sans exposer chaque identité de client à l'ensemble d'Internet.

Le coût de se tromper est le plus élevé pour les petits réseaux. Les grandes plateformes peuvent construire des canaux de confiance privés avec les grandes banques, les fournisseurs de transit, les fournisseurs de sécurité et les autorités publiques. Les petits FAI et les sociétés d'hébergement régionales ne le peuvent pas. Ils dépendent des enregistrements publics et semi-publics pour être crus par des étrangers. Si les preuves publiques sont maigres, 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 donc un impôt régressif sur les réseaux les moins capables de l'absorber.

La couche aval fait déjà partie de l'économie d'attribution

Le manuel politique 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 adresse aux utilisateurs finaux. Une sous-allocation est une distribution par un LIR à un FAI pour une distribution ultérieure. Une attribution est un bloc donné par un LIR à un FAI ou à un utilisateur final pour une utilisation spécifique dans l'infrastructure que cette partie exploite.

L'espace agrégéable par fournisseur peut être attribué ou sous-alloué à des réseaux aval en tant qu'espace non portable, tandis que les attributions indépendantes du fournisseur ne sont pas destinées à une sous-allocation ultérieure. C'est déjà un système en couches.

Le manuel attache ensuite des responsabilités à cette stratification. Il dit que chaque allocation, attribution PI, attribution PA, sous-allocation et autre attribution de ressource 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 correctes à 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-dessus 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 dans le bloc agrégéable du LIR.

Ces règles révèlent la logique institutionnelle. AFRINIC n'a pas besoin de connaître chaque paquet de l'utilisateur, 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'adresse public d'un utilisateur final n'est pas simplement une infrastructure point à point, le manuel dit qu'il doit être enregistré avec les contacts de l'utilisateur final, avec un aménagement de confidentialité pour les individus.

Si le DNS inversé est demandé pour un /24, le manuel dit qu'au moins une attribution ou sous-allocation doit être enregistrée pour ce /24 spécifique. Les services de registre eux-mêmes supposent des faits aval 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 à l'intérieur d'un agrégat de fournisseur. Un revendeur peut vendre des serveurs privés virtuels sans recevoir de sous-allocation formelle /24. Un courtier peut aider à organiser l'utilisation sans apparaître comme opérateur technique.

Une plateforme de location peut coordonner l'accès client tandis que le titulaire enregistré reste inchangé. Un fournisseur de services gérés peut contrôler la remédiation des abus mais pas l'origine du routage. La couche aval est plus granulaire que l'unité politique.

Ce décalage ne devrait pas conduire à deux mauvaises réponses. La première est de faire semblant 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 demandes d'application de la loi trop coûteux. La seconde est d'exiger que chaque petite plage client et chaque nom client soit public. Cela crée des préjudices à la vie privée 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'attribution client, de la sous-allocation FAI aval, de l'espace géré par un revendeur, de l'opération de service géré, de l'opération soutenue par location, de l'utilisation client protégée par la vie privée et du statut contesté ou obsolète. Il n'a pas besoin de publier toujours le nom légal du client. Il devrait publier assez pour montrer quelle couche est responsable de la réponse opérationnelle et combien de poids s'attache à 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é là où la loi, la sécurité ou la confidentialité commerciale le justifient.

Cette logique d'enregistrement soutient déjà une carte de responsabilité. L'enregistrement existe pour assurer l'unicité et fournir des informations pour le dépannage. Dans un marché de rareté IPv4, le dépannage inclut désormais la joignabilité des abus, l'explication de l'origine de la route, la cohérence du DNS inversé, les preuves de sous-délégation, la diligence de transfert, les marchés publics 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 limite institutionnelle est simple à énoncer et difficile à mettre en œuvre. Un registre public ne devrait pas devenir une liste de clients. Il devrait devenir une carte de responsabilité. La distinction est importante. Une liste de clients divulgue qui achète des services auprès de qui. Une carte de responsabilité 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 devraient lui accorder.

Pour les utilisateurs publics, l'enregistrement minimal utile n'est pas l'identité complète du client. C'est le rôle et la joignabilité. Un enregistrement public peut montrer qu'un /24 est exploité par le titulaire, attribué à une organisation, sous-alloué à un FAI aval, utilisé via un service géré, délégué à un utilisateur final protégé par la vie privée, loué ou délégué commercialement sous la responsabilité du titulaire, ou sujet à un litige ou à une confirmation obsolète. Il peut publier les contacts par rôle: contact titulaire, contact technique, contact abus, contact routage et contact DNS inversé.

Il peut exposer les horodatages: première inscription, dernière validation, dernière mise à jour matérielle et expiration de la validation. Il peut montrer si le rôle aval a été auto-attesté par le titulaire, validé par AFRINIC, déduit des preuves de routage, confirmé par la délégation DNS inversée, ou expurgé pour 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 client, des fenêtres de temps d'escalade et de la preuve que le titulaire peut contraindre la coopération. Ces détails n'ont pas besoin d'être lisibles dans le monde entier.

Ils peuvent être détenus par le titulaire, déposés auprès du registre sous forme limitée, partagés sous non-divulgation, 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 l'information plus profonde. Lorsqu'une demande légale cherche l'identité derrière une attribution protégée par la vie privée, le système ne devrait pas exiger que les enquêteurs devinent à travers cinq intermédiaires. Le titulaire devrait pouvoir retracer la chaîne. Le registre devrait savoir si le titulaire revendique une telle traçabilité. L'enregistrement public devrait montrer qu'un utilisateur aval protégé par la vie privée existe et que l'escalade légale a un chemin défini, pas que le client est invisible pour tout le monde.

Les étiquettes de preuve sont essentielles, mais elles doivent être utilisées avec parcimonie et clarté. 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 le même qu'un FAI validé par le registre. Une origine observée par le routage n'est pas la même qu'un utilisateur opérationnel enregistré. Une délégation DNS inversée n'est pas une preuve de responsabilité des abus. Un utilisateur expurgé pour confidentialité n'est pas la même chose qu'un utilisateur inconnu.

Un enregistrement rafraîchi le mois dernier n'est pas le même 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 en savoir plus qu'il n'en sait.

La même structure protège le registre des excès. En publiant le rôle, la joignabilité, le statut des preuves et l'incertitude, AFRINIC peut améliorer la confiance publique sans affirmer un droit d'inspecter chaque client pour la conformité politique. Il peut dire: voici le titulaire reconnu; ce bloc est exploité en aval; le canal opérationnel responsable est ici; l'identité légale est retirée de la vue publique mais traçable dans des conditions définies; la date de dernière validation est actuelle ou obsolète. Un tel registre est plus fin qu'une base de données clients et plus épais qu'un enregistrement de titulaire nu.

C'est le juste milieu économiquement utile.

La rareté de l'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 tracée du titulaire à la responsabilité opérationnelle réelle, chaque contrepartie fixe le prix de l'écart. L'acheteur d'un bloc veut savoir si les utilisateurs aval non divulgués résisteront à la migration. Le preneur veut savoir si le bailleur peut soutenir les changements de route, de DNS inversé et d'abus à travers chaque revendeur intermédiaire. La banque veut savoir si les revenus soutenus par l'adresse dépendent de clients dont les contrats ne peuvent ê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ë. Le fournisseur 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 indique que la phase 2 a commencé lorsqu'il ne restait plus qu'un /11 d'espace non réservé dans le dernier /8. En phase 2, la plage d'allocation ou d'attribution ordinaire est petite, avec un minimum /24 et un maximum /22. Ces limites ne suppriment pas la demande; elles déplacent la demande vers la réutilisation, les transferts, la location, l'offre d'hébergement, la réaffectation de clients et la délégation opérationnelle. Plus la demande passe par 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 de l'espace IPv4 africain de valeur associé à des organisations dormantes ou disparues aurait été détourné ou vendu via des sociétés liées à une ancienne figure senior d'AFRINIC; le chercheur Ron Guilmette a estimé l'espace affecté à plus de 50 millions de dollars de valeur marchande. L'importance pour la visibilité des sous-allocations n'est pas seulement la corruption alléguée. C'est que les enregistrements dormants et les pistes d'autorité faibles deviennent précieux lorsque l'IPv4 a un prix.

Un enregistrement qui ne révèle pas clairement qui peut parler pour l'utilisation aval invite à la fois la fraude et la décote défensive.

Le litige Cloud Innovation montre le bord opposé du même problème. Des analyses publiques ont décrit un conflit 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 d'AFRINIC à examiner ou à résilier la reconnaissance des ressources. Cloud Innovation a contesté la théorie d'AFRINIC et le litige a escaladé. Pour la visibilité des sous-allocations, la leçon n'est pas que chaque location est mauvaise ou que chaque enquête de registre est légitime.

La leçon est que lorsque l'utilisation aval réelle est opaque, le registre peut être tenté de demander des informations clients larges, tandis que le titulaire peut résister en invoquant la confidentialité commerciale. Les deux côtés 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 abandonner les listes brutes de clients. Dans un mauvais équilibre, ils révèlent peu, le registre exige trop, le contentieux commence, et le marché décote l'ensemble du portefeuille. L'IPv4 rare rend cette décote suffisamment importante pour modifier le comportement. Un titulaire avec une mauvaise visibilité aval fait face à une confiance moindre des acheteurs, des coûts juridiques plus élevés, une pire réputation après un abus et une plus faible acceptation du secteur public.

Un registre avec une mauvaise visibilité fait face à une 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 en faveur 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 maintient des enregistrements de rôles aval validés, des contacts vivants, des clients protégés par la vie privée mais traçables, et des étiquettes d'incertitude claires devrait faire face à une friction moindre 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 fixer le prix 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 origiine 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 inversé peut révéler des modèles de nommage, des délégations client et un historique opérationnel.

Les bases de données de géolocalisation, traceroute, latence, certificats TLS, historiques d'abus, zones DNS, réputation de courrier, bannières d'hébergement, registres d'entreprise et 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 apparaît souvent seulement lorsque les signaux sont combinés. Un /24 enregistré pour un titulaire, originaire d'un ASN d'hébergement, couvert par un ROA pour cet ASN, nommé avec un motif DNS inversé de revendeur, listé 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 DNS inversée peut être obsolète. Un objet IRR peut être non autorisé.

Une base de données de géolocalisation peut être erronée. Un 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 services gérés, pas l'utilisateur final.

Les services publics d'AFRINIC couvrent une grande partie de cette pile. Le registre fournit des services WHOIS, RDAP, DNS inversé, IRR et liés à RPKI. Son manuel politique lie la délégation inversée aux attributions ou sous-allocations enregistrées. Sa politique de contact d'abus crée un lieu pour les informations d'abus tout en reconnaissant que l'objet, comme d'autres objets, fait face au problème de précision des données. La franchise est importante. Un champ peut créer un canal sans prouver que le canal est correct. Un ROA peut autoriser une origine sans prouver le client aval.

Une attribution 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 inversé, déposé par contrat, traçable par escalade légale, obsolète, contesté ou expurgé pour confidentialité. Ces étiquettes peuvent sembler bureaucratiques si elles sont trop utilisées. Bien utilisées, elles sont économiquement précieuses. 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. Dans les marchés opaques, les courtiers et les contreparties comblent les lacunes avec des affirmations: bloc propre, soutenu par un tribunal, première partie, conforme à l'Afrique, pas d'abus, entièrement autorisé, sûr pour une utilisation publique. Certaines affirmations 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 affirmations 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 fixer le prix du reste.

Cela est particulièrement important en période de stress institutionnel. Pendant la mise sous séquestre, les litiges électoraux ou les contentieux, les rumeurs deviennent des substituts aux enregistrements. Si la base de données publique ne peut pas distinguer une opération aval ordinaire d'une délégation contestée, ou une protection de la vie privée d'une utilisation inconnue, les contreparties déduiront 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 aval. Il doit divulguer le statut des faits qu'il porte.

La pile de preuves doit être lue comme une carte de probabilité. Plus la combinaison de sous-allocation enregistrée, de contact validé, d'origine de route correspondante, de ROA actuel, de DNS inversé cohérent et de confirmation récente est forte, 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é des abus est une conséquence, pas toute l'histoire

Les plaintes pour abus sont souvent l'endroit où l'opacité des sous-allocations devient visible. Une banque voit des attaques. Un fournisseur de sécurité voit des rappels de malware. Un opérateur de courrier voit du spam. Un demandeur de droit d'auteur voit de l'hébergement. Un organisme public voit du balayage contre un service gouvernemental. Le plaignant interroge le registre et envoie un courriel au contact listé.

Si le titulaire listé n'est pas l'opérateur réel, le ticket commence à se déplacer latéralement: titulaire vers revendeur, revendeur vers fournisseur d'hébergement, fournisseur d'hébergement vers fournisseur de pare-feu géré, fournisseur vers client. Chaque saut ajoute du délai et de l'erreur.

Il est tentant de faire du contact d'abus le sujet entier. Ce serait trop étroit. L'accessibilité des abus est un résultat de la visibilité aval, pas l'économie complète. La même visibilité affecte l'acceptation du routage, la diligence des transactions, la continuité client, les marchés publics, le filtrage des sanctions, la réponse des forces de l'ordre, la géolocalisation, le DNS inversé, 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 d'abus d'AFRINIC est une preuve utile de ce rôle limité. Elle spécifie un objet dédié comme lieu préféré pour publier les informations de contact d'abus publiques, référencé dans les objets inetnum, inet6num et aut-num. Elle vise à aider les rapports d'abus à atteindre le contact réseau correct. Elle reconnaît également un inconvénient: l'objet fait face au même problème de précision des données que d'autres objets et n'améliore pas en soi la précision de la base de données. C'est exactement le point.

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 contraindre l'opérateur aval à agir.

Une meilleure structure lie l'accessibilité des abus à la visibilité des rôles. Si un bloc est exploité par le titulaire, le bureau des abus du titulaire devrait être le canal public principal. S'il est sous-alloué à un FAI aval, le canal d'abus validé du FAI aval devrait être visible, avec escalade par le titulaire préservée. S'il est attribué à un client entreprise dont l'identité est protégée par la vie privée, l'enregistrement public devrait publier un bureau opérationnel responsable ou un proxy plus un chemin d'escalade légale.

S'il est géré par un fournisseur de pare-feu ou d'hébergement, l'enregistrement public devrait montrer quelle couche opérationnelle reçoit les abus en premier. Si la responsabilité est contestée ou obsolète, l'enregistrement 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 responsable, 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 parties extérieures. Les banques sur-bloquent. Les fournisseurs amont menacent de suspension. Les services de réputation marquent l'espace voisin. Les forces de l'ordre escaladent par des canaux plus lents. Des 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 d'abus; le titulaire reste disponible pour escalade si le bureau aval échoue. C'est mieux que de recevoir chaque ticket, en manquer certains, et être traité comme négligent. C'est aussi mieux que de publier des identités clients brutes d'une manière qui crée des risques de confidentialité ou de sécurité.

L'économie n'est donc pas de faire gérer à chaque titulaire un grand service d'abus. Elle est de rendre le chemin vers la responsabilité suffisamment court pour que les coûts fixes d'incident ne tombent pas sur des étrangers aléatoires. La visibilité des sous-allocations est l'infrastructure plus large qui fait fonctionner la politique de contact d'abus.

La rédaction responsable est le compromis de la vie privée

L'objection la plus forte à la visibilité aval est la vie privée. 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 entrepreneurs 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és, cibler les fenêtres de migration ou faire pression sur les fournisseurs de services. Les concurrents commerciaux pourraient apprendre qui héberge qui. Une politique de visibilité qui ignore ces préjudices se détruirait elle-même.

Mais la vie privée ne justifie pas une opacité complète. 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 de phishing, polluer la réputation du courrier, déclencher un examen de 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 vie privée devient un moyen d'exporter le coût. Le problème de conception est de préserver la confidentialité tout en préservant la responsabilité.

La réponse pratique est la divulgation à plusieurs niveaux. Les enregistrements publics devraient porter le rôle, la joignabilité, le statut, la date de validation et la force de la preuve. Ils ne devraient pas nécessairement publier chaque nom légal de client. Les contreparties authentifiées peuvent recevoir plus de détails sous contrat ou 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 demande légale.

Des canaux d'urgence peuvent exister pour un danger imminent sans rendre la divulgation d'urgence routinière. Les individus peuvent bénéficier d'une expurgation plus forte que les FAI aval corporatifs. Les agences publiques peuvent utiliser des contacts de sécurité désignés plutôt que d'exposer chaque entrepreneur.

L'expurgation doit être étiquetée, pas silencieuse. « Identité du client retenue pour confidentialité; le titulaire maintient un contact traçable; proxy d'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 vie privée, il doit être capable de tracer. L'incapacité de tracer dans des conditions définies devrait avoir des conséquences, car sinon la vie privée devient un faux statut.

L'étiquette doit également séparer la vie privée du secret commercial. L'infrastructure sensible d'une banque, un groupe de 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 position qu'un client individuel recevant une petite attribution. 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 politique d'AFRINIC contient déjà un aménagement limité de confidentialité lorsqu'un utilisateur final est un individu: l'espace peut être enregistré avec les informations de contact du fournisseur tout en référençant l'utilisateur final dans l'objet de base de données. Cette logique peut être étendue soigneusement.

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

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

Les preuves de routage sont puissantes car elles sont observables. Si un préfixe est originaire d'un AS particulier, Internet opérationnel peut le voir. Si un objet IRR de route existe, les réseaux peuvent inférer une politique de routage affirmée. Si un ROA autorise un AS d'origine, les parties dépendantes 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 annonçant la route, pas nécessairement le client utilisant les adresses. Un fournisseur d'hébergement peut originer de l'espace pour de nombreux clients. Un fournisseur de services gérés peut annoncer un préfixe pour le compte d'une entreprise. Un bailleur peut autoriser l'AS d'un preneur tandis que le preneur sert des milliers de petits utilisateurs. Un fournisseur de transit peut apparaître dans les preuves en raison du traitement de la route plutôt que de la responsabilité 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 fournisseurs amont et les pairs à construire des filtres. Ils peuvent montrer que quelqu'un a créé un objet route ou route-set cohérent avec une origine revendiquée. Mais les données IRR peuvent être obsolètes, 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é. Un ROA valide peut dire qu'un AS spécifié est autorisé à originer un préfixe. Il 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 rapports d'abus atteignent le bon bureau, ou si une attribution client existe en dessous du préfixe couvert. RPKI est un outil de sécurité d'origine de route, pas un système d'identité client.

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 un ROA pour l'AS d'un preneur. Cela rend la route légitime dans un sens sécuritaire. Cela ne rend pas la chaîne aval visible. Inversement, l'absence de 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 le RPKI comme la seule preuve, il manquera le problème de responsabilité réel.

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 à originer le préfixe Y; qu'un ROA existe ou n'existe pas; qu'un objet IRR existe et est actuel ou obsolète; que le contact d'abus pour le rôle opérationnel est joignable; et que l'identité du client est publique, authentifiée seulement ou expurgée pour confidentialité. Cela combine l'autorité de routage avec la visibilité de la responsabilité. 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 avale. Il doit cesser de permettre à une surface de preuve d'en usurper une autre. Le routage dit la joignabilité. RPKI dit l'autorité d'origine. IRR dit l'affirmation de politique. RDAP et WHOIS disent la reconnaissance enregistrée et les contacts. Le DNS inversé dit la délégation de nommage. La visibilité aval dit qui est responsable en dessous du titulaire, et à quel point on peut en être sûr.

Le DNS inversé est un indice, pas une preuve

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

Le manuel politique d'AFRINIC donne au DNS inversé un lien formel avec l'enregistrement aval. Il dit qu'AFRINIC accepte les demandes de délégation inversée des LIR actifs et qu'aucune délégation inversée d'espace d'adresse administré ou alloué n'est autorisée à moins qu'une attribution 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 inversée /24, au moins une attribution ou sous-allocation doit être enregistrée pour ce /24 spécifique.

Cette règle est une reconnaissance silencieuse que le DNS inversé ne doit pas flotter librement des faits aval enregistrés.

L'indice peut encore induire en erreur. Le DNS inversé est souvent obsolète 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 inversé à 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 courrier 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 inversé ne peut donc pas être traité comme une preuve d'identité avale.

Pourtant, un DNS inversé obsolète ou opaque a des conséquences économiques. Les systèmes de réputation de courrier peuvent se méfier d'une plage. Les clients peuvent demander pourquoi les noms pointent vers un fournisseur précédent. Les équipes de sécurité peuvent envoyer des plaintes à la mauvaise organisation. Les fournisseurs de géolocalisation et d'intelligence d'hébergement peuvent absorber d'anciennes étiquettes dans les systèmes de risque. Un client du secteur public peut échouer à un examen d'approvisionnement 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 inversé semble peu clair. Un preneur peut découvrir que le bailleur ne peut pas mettre à jour les noms rapidement parce que la piste d'attribution 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 inversé comme une surface de preuve. Une carte de responsabilité publique peut dire si le DNS inversé est contrôlé par le titulaire, délégué en aval, géré par le client, obsolète, neutre en 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 inversé 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 inversé peut montrer une histoire opérationnelle différente. La route peut en montrer une troisième. Le contact d'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 inconduite. Il demande si l'incohérence est importante pour la joignabilité, la réputation, l'escalade légale ou la confiance du marché.

Pour AFRINIC, une amélioration étroite serait précieuse: lorsqu'une délégation inversée est liée à une attribution ou sous-allocation enregistrée, l'enregistrement public devrait rendre le lien lisible. Si un /24 a un DNS inversé délégué parce qu'une attribution de FAI aval existe, les étrangers devraient pouvoir voir que la délégation inversée n'est pas aléatoire. Si le DNS inversé reste sous le titulaire tandis que l'utilisation opérationnelle est aval, l'enregistrement devrait dire qui gère les changements de nommage et l'escalade des abus. Cela n'expose pas les clients. Cela expose la responsabilité pour 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 d'épuisement et son manuel politique encadrent les ressources autour de la région de service d'AFRINIC. Sa politique d'atterrissage en douceur inclut un langage d'utilisation régionale pour les ressources pendant la période d'épuisement.

Les analyses publiques du litige Cloud Innovation ont décrit les préoccupations d'AFRINIC concernant les écarts entre les descriptions d'utilisation enregistrée et les pays d'utilisation réels, et concernant les services originaires de la région. Cloud Innovation et des critiques alignés ont contesté cette interprétation et ont fait valoir que l'opération réseau globale ne peut pas être réduite à une simple règle géographique.

Pour la visibilité avale, 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 client. Un préfixe originaire d'un AS en Europe peut servir 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 avec des clients en Chine, au Nigeria 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, un autre en raison du routage, et un troisième en raison de rapports d'utilisateurs. Le DNS inversé peut utiliser des codes de pays pour la commodité opérationnelle. La latence peut indiquer où le trafic entre dans le réseau, pas où le service économique est livré.

Cela ne signifie pas que les preuves d'utilisation régionale sont inutiles. Cela signifie qu'elles doivent ê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 client, la dépendance africaine, l'opération hors région et le statut inconnu.

Il peut dire si un titulaire a auto-attesté que l'utilisation soutient la connectivité à la région AFRINIC, si le registre a validé une revendication d'utilisation régionale spécifique, si les preuves ne sont qu'observées par le routage, ou si la question est contestée. C'est plus honnête que de faire semblant 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 intenteront des poursuites. 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 côtés 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 fixer le prix de l'incertitude plutôt que d'inventer un binaire de conforme et non conforme.

L'inférence d'utilisation régionale est également importante pour les revendications de développement. Certains soutiennent que l'IPv4 attribué à l'Afrique devrait soutenir la connectivité africaine. D'autres soutiennent que les marchés mondiaux et la demande interrégionale compteront plus que la protection du résidu du stock régional. Le registre public ne devrait pas décider ce débat à travers des champs obscurs. Il devrait fournir des preuves: où se situe 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.

De mauvaises inférences deviennent un contrôle des capitaux 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é là où elle est justifiée. Escalader seulement lorsque les preuves entrent en conflit matériellement avec la politique ou la confiance publique. 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 avale moderne est rarement une ligne droite. Un titulaire peut travailler avec un courtier. Le courtier peut présenter un revendeur. Le revendeur peut emballer des adresses dans des produits VPS, courrier, VPN ou pare-feu gérés. Un fournisseur d'hébergement peut exploiter l'AS d'origine. Un client peut contrôler le serveur. Un fournisseur d'abus tiers peut trier les plaintes. Un fournisseur DNS géré peut contrôler les zones inversées. Le registre public peut montrer seulement le titulaire et peut-être l'AS d'origine. Lorsque des problèmes surviennent, chaque couche peut dire qu'une autre couche a 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 la capacité inutilisée avec 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 fournisseurs de services gérés résolvent également de vrais problèmes. De nombreux clients ne veulent pas gérer le routage, le DNS inversé, les bureaux d'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 du filtrage client. Elle peut dire qu'un opérateur de services gérés reçoit les abus en premier. Elle peut dire que le titulaire reste responsable des modifications du registre. Elle peut dire qu'un FAI aval contrôle les attributions client. Elle peut dire que l'identité du client est expurgée pour confidentialité mais traçable via l'opérateur.

Les étiquettes disent aux étrangers où ne pas envoyer la mauvaise demande.

De telles étiquettes réduiraient les défaillances courantes. Un fournisseur amont évaluant une route saurait si l'AS d'origine agit en tant que preneur, opérateur géré ou réseau titulaire. Un plaignant saurait si la boîte aux lettres d'abus publique atteint l'opérateur le plus proche du client. Un acheteur saurait si des revendeurs non divulgués peuvent avoir des revendications de continuité client. Un acheteur public saurait si l'approvisionnement en adresses d'un entrepreneur dépend d'une chaîne de courtage. 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 de la location 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 de la location ou le prix commercial. C'est de savoir 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 attribution 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 limitée dans le temps.

La même logique s'applique à la confidentialité des clients. Une étiquette peut dire « utilisateur final protégé par la vie privée, traçable par le titulaire » sans nommer l'utilisateur final. Elle peut dire « contact des forces de l'ordre disponible via escalade par le titulaire » sans publier de canaux sensibles. Elle peut dire « liste de clients contrôlée par le revendeur » afin 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 la divulgation complète des clients, les intermédiaires légitimes résisteront. Les étiquettes offrent une alternative à moindre coût: responsabilité visible, identité protégée et incertitude tarifée.

La dépendance du secteur public transforme l'opacité en risque de capacité étatique

L'opacité des sous-allocations devient plus grave lorsque les systèmes du secteur public dépendent de la chaîne d'adresses. Un ministère peut héberger des services 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 à l'intérieur d'un bloc loué ou sous-alloué. Une unité de cybercriminalité de la police peut avoir besoin d'informations sur l'abonné ou le client après un incident. Un réseau national d'éducation peut dépendre de fournisseurs aval pour les campus.

Un tribunal peut avoir besoin de préserver des 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, elle peut devenir un problème de capacité étatique. Un portail fiscal qui perd la délivrabilité du courrier parce que le DNS inversé est obsolète, une plateforme d'approvisionnement 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 route n'est pas seulement confronté à un inconvénient informatique. Le coût est supporté par les citoyens et les institutions publiques qui n'ont pas choisi la structure d'adresses 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. NAT, CGNAT, location VPS et hébergement à court terme rendent le temps critique. Si le titulaire ne maintient pas de traçabilité ou si le revendeur n'est pas enregistré, les demandes légales peuvent arriver trop tard ou à la mauvaise partie. La divulgation publique excessive n'est pas la réponse, mais un chemin d'escalade structuré l'est.

L'histoire de crise d'AFRINIC augmente les enjeux car les autorités publiques peuvent déjà regarder le registre en tant qu'institution. Les reportages autour de la mise sous séquestre mauricienne ont décrit un mandat pour préserver les opérations et restaurer la gouvernance, tandis que des reportages ultérieurs ont décrit une pression judiciaire continue, des mécanismes électoraux échoués, des questions de restauration du conseil, des poursuites et des litiges sur 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 contentieux ou le changement de gouvernance.

Une norme d'approvisionnement du secteur public pourrait être simple. Les fournisseurs utilisant l'IPv4 administré par AFRINIC pour des services publics devraient pouvoir montrer le titulaire enregistré, le réseau opérationnel, l'autorité d'origine de la route, le contrôle du DNS inversé, les contacts d'abus et de sécurité, les étiquettes de responsabilité avale, 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 change donc l'équilibre de la vie privée. Le public n'a pas besoin de chaque nom de client. Il a besoin d'avoir l'assurance que les services critiques ont une responsabilité d'adresse traçable. Un registre qui aide à créer cette assurance ne devient pas un organisme de surveillance. Il réduit le risque d'approvisionnement public dans un marché où la rareté des adresses et l'instabilité institutionnelle ont rendu la couche d'adresses visible.

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

AFRINIC n'a pas besoin d'un régime de transparence maximal. Il a besoin d'un pacte de visibilité qui énonce à quoi sert la visibilité avale: unicité, dépannage, joignabilité des abus, diligence de l'autorité de route, cohérence du DNS inversé, escalade légale, confiance transactionnelle et continuité pour les clients qui dépendent de l'IPv4 rare. 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 des champs d'enregistrement comme levier dans des litiges non liés.

Le pacte pourrait commencer par quelques types d'enregistrements. Les sous-allocations formelles au niveau ou au-dessus du minimum politique devraient être publiquement visibles avec l'identité du FAI aval, les contacts, le statut, la date de validation et l'escalade par le titulaire. Les attributions d'utilisateurs finaux qui nécessitent une responsabilité opérationnelle publique devraient identifier l'utilisateur final ou un proxy protégé par la vie privée avec des étiquettes de rôle claires.

Les plages 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 une traçabilité et publier des étiquettes de responsabilité là où les abus, le routage, le DNS inversé ou les demandes légales rendent le rôle pertinent.

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 confidentialité mais traçable, obsolète, contesté ou contraint par un tribunal. 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 une meilleure preuve. Un bloc avec une responsabilité avale à jour devrait être moins cher à router, transférer, louer, financer et acquérir qu'un bloc avec des données obsolètes uniquement de titulaire.

Le pacte devrait inclure des cycles de validation. Les contacts et les étiquettes de rôle devraient expirer sauf s'ils sont rafraîchis. Les changements matériels, tels qu'un nouveau FAI aval, un nouvel AS d'origine, une reprise de service géré, un changement de délégation DNS inversée ou une migration importante de client, 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 dépréciation immédiate de la ressource.

Les recours graves devraient être réservés aux fausses déclarations, à l'utilisation à haut risque intraçable, à la fraude, aux ordonnances judiciaires ou au refus répété de maintenir une responsabilité minimale.

Il devrait également y avoir une couche de preuve privée. Les titulaires devraient conserver des enregistrements des attributions client, des autorisations, des contrats de revendeur, de l'escalade des abus, des permissions 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 inversé/RPKI rend le rôle aval pertinent.

La demande devrait être spécifique, limitée dans le temps et plus étroite qu'un audit de tous les clients, sauf si les preuves justifient plus.

Le pacte devrait récompenser la correction. Si un titulaire met à jour volontairement une responsabilité avale obsolète, 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 la fausseté intentionnelle nécessitent un traitement différent, mais la correction ordinaire devrait être encouragée. Un registre qui se remet d'un historique de corruption des 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, 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 fournisseur 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 rare lorsque cette utilisation n'est pas par le titulaire enregistré?

Si non, le rétablissement de la gouvernance reste trop abstrait.

Le registre peut être légalement préservé et laisser encore la responsabilité avale opaque. Il peut élire un conseil et n'exposer encore que les enregistrements de niveau titulaire. Il peut exploiter RDAP, WHOIS, DNS inversé, IRR et RPKI et encore échouer à connecter ces surfaces en une carte de responsabilité. Il peut annoncer des politiques et encore laisser les marchés deviner si un préfixe routé est exploité par le titulaire, par un revendeur, loué, sous-alloué, attribué, protégé par la vie privée ou contesté. Dans un marché de rareté, cette devinette est coûteuse.

L'histoire récente d'AFRINIC lui donne à la fois une raison et une obligation de faire mieux. Les reportages sur le vol d'adresses montrent le danger d'une autorité d'enregistrement faible. Le litige Cloud Innovation montre le danger d'une délégation commerciale opaque et d'une large discrétion du registre 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é.

La poursuite des litiges montre que les affirmations publiques sur la location, la commercialisation et la reconnaissance judiciaire peuvent affecter 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é avale au niveau où les étrangers se fient à l'enregistrement d'adresses. C'est la différence entre un registre et un brouillard privé.

Le gain est pratique: des rapports d'abus plus étroits, un filtrage moins brutal, des changements de DNS inversé et de RPKI plus propres, une diligence moins dépendante des courtiers, des marchés publics plus solides et des clients protégés avec une traçabilité responsable. Les marchés fixeraient le prix de la responsabilité vérifiée plutôt que des rumeurs.

Le pacte disciplinerait également les titulaires. Un titulaire qui loue, attribue, sous-alloue ou délègue une capacité IPv4 rare ne devrait pas pouvoir dire seulement: le registre public me nomme, donc tous les autres doivent me faire confiance. Le titulaire est l'ancre, pas toute l'histoire. S'il profite de l'utilisation avale, 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 de test car le registre de l'Afrique a vécu la collision complète de la rareté, de l'intégrité des enregistrements, de la délégation commerciale, du contentieux et du rétablissement institutionnel. La leçon n'est pas que chaque utilisateur aval doit ê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 de clients. Il expose suffisamment de la chaîne de responsabilité pour que des étrangers puissent agir sans rejoindre le combat.