Résumé

  • Les données publiques peuvent relier une identité enregistrée à un numéro de système autonome, à des objets de routage et à des observations de réseau, mais aucune de ces couches ne prouve seule la propriété, l’exploitation physique ou le contrôle commercial.
  • Le résultat décisif serait une série horodatée reliant le même opérateur identifiable à l’objet AS210860, à des annonces BGP, à des autorisations IRR ou RPKI persistantes et à un service, un contrat ou une entité juridique contrôlable.

Le changement d’état qui compte

La question la plus importante n’est pas de savoir si le nom DFINFRA apparaît dans des données liées à AS210860. Les articles précédents ont déjà établi cette association et ont expliqué pourquoi elle ne vaut pas preuve de propriété ou de contrôle opérationnel. La question nouvelle est plus exigeante : peut-on relier, dans une même fenêtre temporelle, cette identité à un acteur capable d’initier, de maintenir, de modifier ou de retirer une route — puis à une conséquence identifiable pour des clients, la continuité du service, le pouvoir de négociation ou les flux de trésorerie ?

Cette distinction sépare un signal administratif d’une capacité économique. Un nom dans une base de données indique qu’une relation existe dans un système de référence. Une annonce BGP indique qu’un chemin est observé par certains collecteurs. Une autorisation IRR indique qu’un objet de route a été enregistré selon les règles du registre. Une ROA RPKI autorise un ASN à être utilisé comme origine pour un préfixe. Aucune de ces observations, prise isolément, ne répond à la question : qui peut effectivement changer l’état du réseau et en supporter les conséquences ?

La source publique primaire pour commencer ce contrôle est l’objet aut-num de l’AS210860 dans la base RIPE. Une recherche RIPE sur DFINFRA peut compléter cette vérification en recensant les objets et attributs associés (recherche RIPE de DFINFRA). Il peut contenir le nom enregistré, l’organisation associée, des contacts, des mainteneurs, une politique de routage ainsi que des dates de création ou de modification (objet aut-num AS210860 dans la base RIPE). Ces champs permettent de vérifier l’état administratif du numéro et de rechercher une continuité dans le temps. Ils ne prouvent pas que la personne ou l’organisation mentionnée possède les routeurs, détient les contrats de transit ou contrôle les identifiants cryptographiques utilisés pour les autorisations.

Un mainteneur peut disposer du droit de modifier un objet dans la base sans avoir accès aux équipements qui annoncent effectivement une route. Il peut s’agir d’un opérateur, d’un fournisseur de services, d’un registre local, d’un consultant ou d’une autre entité agissant pour le compte d’un titulaire. Cette possibilité n’est pas une objection marginale : elle définit la frontière entre la gouvernance de la donnée et le contrôle de l’infrastructure.

Ce que les objets de routage permettent de tester

Une recherche RIPE inversée sur l’origine peut faire apparaître des objets route ou route6 qui désignent AS210860 comme origine prévue. Elle peut également montrer quels mainteneurs peuvent modifier ces objets (recherche RIPE des objets dont AS210860 est l’origine). La documentation de la RIPE NCC explique les mécanismes d’autorisation qui protègent l’espace des objets de route et la manière dont les droits de maintenance sont associés aux préfixes et aux origines (documentation RIPE sur la protection des objets de route).

Cela permet de poser un test précis : les préfixes enregistrés, les mainteneurs, l’organisation et l’ASN désignent-ils le même ensemble d’acteurs, au même moment ? Si oui, le dossier administratif devient plus cohérent. Mais la cohérence n’est pas encore une preuve d’exploitation. Un objet IRR peut être ancien, ne correspondre à aucune annonce actuelle ou avoir été créé pour faciliter un filtrage sans établir qui possède juridiquement l’espace d’adresses. La présence d’un objet ne démontre donc ni la réalité d’une annonce ni la capacité de contrôler un routeur.

La différence entre autorisation et action est essentielle. Une route enregistrée indique une intention ou une autorisation déclarée dans un registre. Une annonce BGP observée indique qu’un système a présenté un chemin à au moins certains collecteurs. La comparaison des deux peut renforcer l’analyse, mais elle ne ferme pas automatiquement la chaîne d’attribution. Un opérateur amont peut annoncer une route pour un client ; un fournisseur peut appliquer une configuration ; une annonce peut être temporaire, erronée ou résulter d’une fuite de route.

Ce que l’observation BGP ajoute — et ne peut pas ajouter

RIPEstat peut fournir des observations sur les préfixes annoncés, l’état du routage, l’historique et les réseaux voisins. Des agrégateurs indépendants tels que bgp.tools et le BGP Toolkit de Hurricane Electric peuvent servir de points de comparaison (vue d’ensemble RIPEstat de l’AS210860; préfixes annoncés selon RIPEstat; état du routage selon RIPEstat; voisins AS selon RIPEstat; historique du routage RIPEstat; profil bgp.tools; profil Hurricane Electric).

La persistance serait plus informative qu’un instant isolé. Des annonces observées sur une période, des préfixes récurrents et des voisins stables pourraient établir qu’AS210860 possède une présence technique réelle plutôt qu’une existence purement administrative. Mais même cette conclusion resterait limitée. La visibilité d’un collecteur n’est pas la portée mondiale du routage. Une relation de chemin ne distingue pas nécessairement le transit payant, le peering sans règlement, un client, un serveur de routes ou une fuite temporaire.

L’observation BGP répond donc surtout à la question : « un comportement de routage associé à cet ASN est-il visible ? » Elle ne répond pas automatiquement à : « quelle entité a configuré les équipements ? », « qui paie le transit ? » ou « qui est responsable du service vendu à un client ? » Pour attribuer une capacité opérationnelle, il faut rapprocher le comportement observé d’identifiants administratifs, de droits d’autorisation, de preuves d’exploitation et d’une action attribuable à un acteur précis.

RPKI : une autorisation forte, mais circonscrite

Une ROA RPKI peut autoriser un ASN à être l’origine d’un préfixe. Le cadre technique de ces autorisations est défini par le RFC 6482 (RFC 6482). Le dépôt de données validées de Cloudflare permettrait de rechercher les VRP associés à AS210860 et de comparer ces autorisations aux annonces observées (données RPKI validées de Cloudflare). Cette comparaison pourrait classer une annonce comme valide, invalide ou non trouvée.

La force de RPKI est cryptographique, mais son objet est étroit. Une ROA indique qu’un détenteur de ressources a autorisé un ASN à être utilisé comme origine dans certaines limites. Elle ne dit pas qui exploite les routeurs, qui détient les contrats avec les fournisseurs de transit, qui facture les clients ou qui contrôle la société bénéficiaire. Une absence de VRP produit normalement un état « NotFound », et non une preuve d’annonce illégitime.

Le meilleur usage de RPKI serait donc de vérifier la convergence de plusieurs faits : une annonce observée, un préfixe identifié, une ROA correspondante, un objet IRR compatible et une identité administrative qui ne change pas de manière contradictoire. Même cette convergence établirait principalement une autorisation de routage et une activité technique. Elle ne suffirait pas à prouver la propriété des actifs ou l’existence d’un pouvoir commercial durable.

Les voisins ne sont pas encore des contrats

Les données de voisinage et les profils de fournisseurs peuvent suggérer qu’AS210860 est connecté à d’autres réseaux. BGPView peut proposer des fournisseurs déduits, tandis que CAIDA peut fournir des relations inférées et une cartographie de l’ASN (fournisseurs déduits par BGPView; profil CAIDA AS Rank). Ces informations sont utiles pour formuler des hypothèses sur la connectivité.

Elles ne constituent pas des contrats. Un voisin dans un chemin AS peut correspondre à un transit, à un peering, à un client, à un chemin de serveur de routes ou à une configuration transitoire. Une relation inférée ne permet pas de savoir qui paie qui, qui possède la capacité, quelles obligations de disponibilité existent ou quelle partie peut résilier et rétablir le service. Pour transformer la connectivité en impact commercial, il faudrait une documentation de transit, une présence de fournisseur contrôlée par l’opérateur, un accord d’interconnexion ou un service public reliant explicitement DFINFRA à AS210860.

PeeringDB serait particulièrement utile si une fiche auto-déclarée associait explicitement le nom DFINFRA à l’ASN, à un site web contrôlé, à des installations, à une politique de peering ou à des points d’échange (recherche PeeringDB pour l’ASN 210860). Mais cette source resterait déclarative et potentiellement obsolète. Une fiche absente ne démontrerait pas que l’ASN n’a ni transit ni infrastructure physique ; une fiche présente ne démontrerait pas la propriété des équipements ou des contrats.

Le test commercial commence après le test technique

Le lien entre une ressource réseau et un marché ne peut pas être déduit d’un ASN seul. Il faudrait identifier au moins un mécanisme économique : des clients qui dépendent d’une connectivité fournie par l’opérateur, une capacité de tarification, une obligation contractuelle de continuité, un service hébergé, une infrastructure louée ou un actif dont l’interruption produit un coût mesurable.

Les sources ouvertes peuvent aider à chercher ce mécanisme. IPinfo peut fournir des indications sur les préfixes, les domaines ou l’organisation associée (profil IPinfo de l’AS210860). Censys peut offrir des indices sur des hôtes, des certificats, des services et des noms d’hôte visibles dans l’espace attribué (recherche Censys sur l’AS210860). Cloudflare Radar peut parfois révéler des observations de trafic ou d’incidents (profil Cloudflare Radar de l’AS210860).

Ces pistes doivent être traitées comme des pistes. Un domaine hébergé dans un préfixe peut appartenir à un client, à un revendeur ou à un locataire. Un certificat ne prouve pas la propriété du réseau. Une observation de trafic peut être attribuée à un service tiers. Pour établir un effet commercial, il faudrait relier ces observations à une identité contrôlée par DFINFRA, à une offre publique, à des conditions de service ou à un document juridique.

La recherche d’une personne morale nommée DFINFRA est soumise à la même discipline. OpenCorporates peut identifier des entités candidates, leur juridiction, leur statut ou leurs dirigeants, mais un nom commun ou une abréviation ne suffit pas (recherche OpenCorporates pour DFINFRA). L’adresse, le numéro d’enregistrement, les dirigeants, le domaine de messagerie ou les coordonnées devraient correspondre aux données RIPE et être confirmés dans un registre national primaire. Même une correspondance juridique ne prouverait pas, à elle seule, que cette société exploite AS210860.

Une limite de recherche qui change la conclusion

Cette enquête n’a pas récupéré en direct le contenu actuel des points de terminaison listés. Le paquet de recherche conserve les sources candidates et décrit ce qu’elles permettraient de vérifier, mais il ne contient pas de résultat courant vérifié pour les annonces, les préfixes, les voisins, les objets IRR, les VRP RPKI, PeeringDB, les services exposés ou l’entité juridique.

Cette limite interdit certaines formulations. Il serait incorrect d’écrire qu’AS210860 annonce actuellement tel préfixe, qu’il possède tel voisin, qu’une ROA existe, qu’un service DFINFRA est actif ou qu’une société déterminée contrôle l’ASN. Il serait également incorrect de transformer l’absence de résultat récupéré dans cette exécution en preuve d’inactivité. La conclusion doit rester proportionnée à ce qui a réellement été observé : les sources indiquent où trouver les éléments décisifs, mais elles ne les ont pas fournis ici sous une forme actuelle et vérifiée.

Cette retenue ne rend pas l’enquête inutile. Elle déplace sa valeur. Au lieu de répéter que l’identité DFINFRA apparaît dans un contexte lié à AS210860, l’article définit la chaîne falsifiable qui permettrait de passer d’une association à une attribution : identité enregistrée, droits de maintenance, préfixes et autorisations, activité BGP persistante, connectivité, identité opératrice et mécanisme commercial. Chaque transition doit être documentée séparément.

La condition qui confirmerait ou affaiblirait la thèse

La preuve la plus convaincante serait un ensemble horodaté dans lequel le même opérateur identifiable apparaît dans l’objet aut-num et les objets associés, correspond aux annonces BGP observées, dispose d’autorisations IRR ou RPKI compatibles, maintient une connectivité persistante et contrôle un site, un service, un document d’entreprise, une installation ou un contrat lié à AS210860.

Un résultat contradictoire serait tout aussi important. Des annonces actives avec un titulaire enregistré différent, une maintenance assurée par un prestataire sans lien démontré avec DFINFRA, une RPKI contrôlée par une autre entité ou des services exploités par un opérateur distinct affaibliraient l’attribution. Une telle contradiction ne prouverait pas nécessairement que DFINFRA n’a aucun rôle ; elle empêcherait simplement de présenter son rôle comme un contrôle opérationnel établi.

Le point économique est identique. Tant qu’aucun client, contrat, service ou obligation de continuité n’est relié à l’acteur qui peut modifier les routes, le passage d’une présence réseau à une dépendance commerciale reste hypothétique. L’ASN peut être actif sans que DFINFRA soit l’opérateur économique ; DFINFRA peut être associé à la ressource sans être en mesure d’en modifier l’état technique. Le mécanisme causal doit être démontré, pas supposé.

La conclusion actuelle est donc étroite mais vérifiable : les registres publics permettent de construire un test sérieux du rôle de DFINFRA, mais les éléments disponibles dans cette enquête ne ferment pas la chaîne entre identité, action réseau et effet commercial. La prochaine observation utile n’est pas une nouvelle répétition du nom dans un registre. C’est une série temporelle indépendante qui relie un acteur identifiable à une capacité de routage réelle, à une autorisation cohérente et à une conséquence opérationnelle ou économique démontrable.