Résumé

  • L’association publique entre DFINFRA et AS210860 ouvre une enquête vérifiable, mais ne démontre ni la propriété, ni l’exploitation, ni la capacité actuelle à modifier les routes.
  • La conclusion opérationnelle dépend d’une chaîne datée reliant identité de registre, autorisations, annonces BGP, validation RPKI et preuve indépendante d’un service ou d’une conséquence commerciale.

Le changement d’état qui compte

Le point important n’est pas qu’un nom apparaisse à côté d’un numéro de système autonome. Ce fait était déjà visible dans la couverture précédente de DFINFRA. Le changement d’état recherché est plus exigeant : peut-on maintenant montrer qu’un acteur identifiable possède la capacité de modifier l’état du réseau, de maintenir cette capacité dans le temps et d’en tirer — ou d’en faire porter — une conséquence opérationnelle ou économique ?

La réponse disponible dans ce dossier est négative, mais de manière circonscrite. La recherche a identifié les bons points d’observation — registre RIPE, objets de routage, mesures BGP, RPKI, données d’interconnexion et documents de l’opérateur — sans récupérer les valeurs vivantes qui permettraient de fermer la chaîne. Il serait donc excessif de transformer une piste administrative en affirmation de contrôle. Il serait tout aussi excessif de conclure que l’absence de valeur récupérée équivaut à l’absence de réseau.

La différence entre ces deux erreurs est centrale pour les infrastructures numériques. Un registre peut dire sous quel nom une ressource est enregistrée. Une table de routage peut montrer qu’un ASN a été observé comme origine d’un préfixe à un instant donné. Un objet IRR peut déclarer une relation d’origine ou de maintenance. Une ROA peut autoriser cryptographiquement un ASN à annoncer un préfixe dans une limite de longueur donnée. Aucun de ces éléments, isolément, ne répond à la question : qui peut effectivement faire fonctionner le réseau, changer son état, répondre de sa continuité et convertir cette capacité en service ou en revenu ?

Ce que l’identité de registre permet d’établir

Le premier niveau de vérification est l’identité administrative. L’objet aut-num de l’AS210860 dans la base RIPE est la source directe à consulter pour le nom de l’ASN, les références d’organisation, les contacts, les mainteneurs, le statut, les attributs de politique de routage et les dates de création ou de modification https://rest.db.ripe.net/ripe/aut-num/AS210860.json. Les données WHOIS de RIPEstat offrent une représentation indépendante des attributs de l’objet et des enregistrements associés https://stat.ripe.net/data/whois/data.json?resource=AS210860. Le service RDAP peut, de son côté, corroborer le statut de l’ASN, les entités liées et les événements de registre https://rdap.db.ripe.net/autnum/210860.

Ces sources répondent à une question étroite : quelle identité est actuellement attachée à la ressource dans les bases consultées ? Elles ne prouvent pas que cette identité est le bénéficiaire effectif, l’exploitant physique des routeurs ou le détenteur d’un contrat de transit. Une organisation mentionnée dans un registre peut être un opérateur, un intermédiaire administratif, un prestataire technique ou une entité dont la relation commerciale avec le réseau n’est pas documentée publiquement.

Même les données d’adresse et de contact doivent être traitées comme des éléments d’identification à vérifier, pas comme une preuve de contrôle économique.

La première contradiction à résoudre est donc celle qui pourrait apparaître entre l’objet RIPE direct, les données RIPEstat et RDAP : nom différent, identifiant d’organisation différent, statut divergent ou dates d’événement non concordantes. Ces différences peuvent venir du modèle de données, de la mise en cache ou d’un changement récent. Elles ne doivent être aplaties en une seule identité avant d’être comparées et datées.

Les mainteneurs et objets de routage décrivent une autorisation, pas nécessairement une exploitation

Le deuxième niveau porte sur les droits administratifs liés au routage. La recherche inverse RIPE des objets route et route6 dont l’attribut origin est AS210860 peut révéler les préfixes déclarés, les sources, les mainteneurs, les dates de création et les dernières modifications https://rest.db.ripe.net/search.json?query-string=AS210860&inverse-attribute=origin&type-filter=route&type-filter=route6. Une recherche des ensembles d’AS qui contiennent directement AS210860 peut également montrer comment le numéro est intégré à une politique de routage déclarée https://rest.db.ripe.net/search.json?query-string=AS210860&inverse-attribute=members&type-filter=as-set.

Les règles de la base RIPE sont pertinentes pour comprendre ce que signifient ces informations : les attributs de maintenance indiquent quels mainteneurs sont autorisés à modifier des objets protégés, tandis que les objets IRR expriment une déclaration de politique ou d’autorisation https://docs.db.ripe.net/. Un objet de route maintenu par une entité différente de celle qui apparaît dans l’objet aut-num pourrait documenter une chaîne technique distincte. Il ne prouverait toutefois ni la propriété de l’espace d’adresses, ni la maîtrise des équipements, ni l’existence d’un contrat client.

Cette distinction est particulièrement importante dans un dossier où l’on cherche un mécanisme économique. Un droit de modifier une fiche de registre peut faciliter une annonce autorisée ; il ne montre pas qui paie le transit, qui fournit le service, qui supporte les obligations de continuité ou qui encaisse la valeur associée à la connectivité. L’autorisation administrative est une condition possible de l’action réseau, pas l’action elle-même.

L’observation BGP montre un état visible à un moment donné

Le troisième niveau est comportemental. Les données RIPEstat sur les préfixes annoncés, le statut de routage, l’historique et les voisins peuvent établir si AS210860 a été observé comme origine ou comme participant à des chemins BGP durant une période donnée https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS210860 https://stat.ripe.net/data/routing-status/data.json?resource=AS210860 https://stat.ripe.net/data/routing-history/data.json?resource=AS210860 https://stat.ripe.net/data/asn-neighbours/data.json?resource=AS210860. Les vues de BGP.Tools et de Hurricane Electric peuvent servir de points de comparaison indépendants pour les préfixes, les chemins et la visibilité https://bgp.tools/as/210860 https://bgp.he.net/AS210860.

Une observation BGP est plus proche de l’exploitation réelle qu’une simple fiche administrative, mais elle reste limitée. Elle montre qu’une annonce a été visible depuis certains collecteurs et à un moment donné. Elle ne révèle pas nécessairement l’identité juridique de l’opérateur, la propriété du préfixe, le détenteur de la relation de transit ou la dépendance d’un client. Un retrait observé peut signifier une interruption, un changement de politique, une migration ou une limite de couverture du collecteur. Une annonce persistante peut correspondre à une activité de réseau réelle sans dire quelle entité en assume le contrôle.

Il faut donc comparer trois dates plutôt que produire une phrase intemporelle : la date de création ou de modification du registre, la fenêtre d’observation de l’annonce et le moment où l’objet d’autorisation était valide. La différence entre ces dates peut être le fait le plus instructif. Une route enregistrée mais non observée, ou une route observée sans objet IRR correspondant, n’est pas un détail secondaire : c’est un point où la chaîne d’attribution doit être examinée.

RPKI renforce l’autorisation d’origine, sans créer une preuve de propriété

La quatrième couche est cryptographique. Une exportation de données RPKI peut être filtrée pour rechercher les ROA qui autorisent AS210860 à annoncer certains préfixes et longueurs maximales https://rpki.cloudflare.com/rpki.json. Le principe des ROA est défini dans la documentation technique pertinente, notamment le RFC 6482 https://www.rfc-editor.org/rfc/rfc6482.html.

Une validation RPKI concordante serait un élément plus fort qu’une simple déclaration IRR pour évaluer l’autorisation d’origine. Elle signifierait qu’un détenteur de certificat de ressource a autorisé AS210860 à annoncer le préfixe couvert dans une limite précise. Elle ne démontrerait toujours pas que DFINFRA exploite les routeurs, possède l’espace d’adresses, contrôle le contrat de transit ou tire un revenu du trafic. Une ROA peut rester publiée alors qu’une annonce n’est plus visible ; une annonce peut également être invalide parce qu’elle dépasse la longueur maximale, même lorsqu’une ROA couvrante existe.

Le test utile est donc une comparaison par préfixe et par longueur : l’annonce observée, l’objet IRR, la ROA, sa période de validité et l’identité qui peut être reliée à chacune de ces couches. Une concordance technique renforcerait l’hypothèse d’une capacité d’origination autorisée. Une divergence ne prouverait pas à elle seule une fraude ou une perte de contrôle, mais elle affaiblirait une conclusion simple reliant automatiquement le nom DFINFRA à l’état du réseau.

La connectivité ne suffit pas à prouver une relation commerciale

La cinquième couche concerne l’interconnexion. Une réponse PeeringDB pourrait fournir un nom de réseau déclaré, une organisation, un site web, une politique de routage, des installations, des points d’échange et une portée géographique https://www.peeringdb.com/api/net?asn=210860. Ces éléments peuvent aider à relier une identité technique à un opérateur qui se décrit lui-même. Ils ne constituent pas pour autant un registre légal ni une preuve qu’un port ou une session est actif à la date de consultation.

De même, les voisins visibles dans les chemins BGP peuvent suggérer une connectivité, mais ils ne permettent pas de qualifier automatiquement une relation comme transit payant, client, pair ou fournisseur. Les étiquettes de topologie et les ensembles d’AS peuvent être incomplets, indirects ou obsolètes. Une inférence de voisinage n’est pas un contrat. Pour atteindre la question économique posée par cette enquête — dépendance client, pouvoir de négociation, continuité ou flux de trésorerie — il faudrait une source indépendante : site de l’opérateur, conditions de service, annonce client, contrat, dépôt officiel ou autre document attribuable.

C’est ici que l’enquête rencontre sa limite la plus importante. Aucun registre officiel d’entreprise ne relie dans ce dossier DFINFRA à une dénomination juridique, une juridiction et un identifiant vérifiés. Aucun site officiel, catalogue de services, liste de clients, étude de cas, contrat ou annonce client n’a été récupéré. En conséquence, l’impact économique ne peut pas être décrit comme un fait établi. On peut définir le mécanisme à rechercher, pas affirmer qu’il existe.

Ce qui est établi, ce qui ne l’est pas

Le dossier établit que DFINFRA est la cible d’un article associée à une entité mondiale existante du répertoire, sous le slug dfinfra https://btw.media/fr/directory/dfinfra. Il établit également que la recherche pertinente doit couvrir les bases RIPE, les objets de routage, les observations BGP, la validation RPKI, les données d’interconnexion et les documents de l’opérateur. Il n’établit pas les valeurs actuelles de ces réponses : les corps des réponses vivantes n’ont pas été récupérés dans cette exécution.

La formulation correcte est donc la suivante : l’association DFINFRA–AS210860 est une piste administrative suffisamment précise pour justifier une enquête technique ; elle n’est pas encore une preuve attribuable de contrôle opérationnel ou économique. Les mainteneurs peuvent indiquer une capacité de modification des objets. Les objets IRR peuvent indiquer une autorisation déclarée. BGP peut montrer une origination observée. RPKI peut confirmer une autorisation cryptographique. PeeringDB peut fournir des métadonnées opérationnelles auto-déclarées.

Mais la chaîne demeure ouverte tant qu’un même acteur identifiable n’est pas relié à ces couches et à une conséquence de service ou de marché.

Cette retenue n’est pas une faiblesse rédactionnelle. Elle protège contre deux conclusions symétriques et également infondées. La première serait de présenter une association de registre comme une preuve de propriété ou de maîtrise des routes. La seconde serait d’utiliser l’absence de réponse live dans ce run comme preuve que le réseau est inactif ou que l’identité est fictive. La bonne conclusion est une frontière de vérification, accompagnée d’un protocole pour la franchir.

La prochaine condition observable

La prochaine condition décisive est un ensemble de preuves horodatées et cohérentes. Il devrait relier une entité identifiable à l’objet aut-num et à ses mainteneurs, aux objets route ou route6 correspondants, à une annonce BGP observée, à une autorisation RPKI valide lorsque celle-ci s’applique, puis à une preuve indépendante d’exploitation ou de relation commerciale. Les mêmes noms, identifiants ou contrôles ne doivent pas seulement apparaître dans des bases distinctes ; ils doivent converger dans une période définie.

Un tel ensemble renforcerait l’hypothèse que DFINFRA — ou une entité juridiquement reliée à ce nom — peut modifier ou maintenir un état de réseau et que cette capacité a une conséquence opérationnelle identifiable. Une divergence entre l’identité du registre et celle du mainteneur, entre les objets d’autorisation et les annonces, ou entre l’ASN et le prétendu fournisseur affaiblirait cette hypothèse. Dans les deux cas, la question avance : elle passe d’un nom visible dans un registre à une attribution testable.

Pour l’instant, la limite est nette. DFINFRA et AS210860 peuvent être placés sur le même chemin documentaire. La preuve que le même acteur contrôle les équipements, les annonces, les contrats ou la valeur économique du réseau reste à produire.