Résumé

  • Le dossier de recherche recense 18 sources publiques capables de tester séparément l’identité de registre, les déclarations IRR, l’autorisation RPKI, la visibilité BGP et certains indices d’interconnexion autour de l’AS210860. Les réponses dynamiques n’ont toutefois pas été récupérées en direct pour cette enquête.
  • Aucun élément disponible ne permet donc d’affirmer que DFINFRA possède, exploite ou contrôle l’AS210860. La prochaine preuve décisive serait un changement de routage ou d’autorisation documenté, relié par des éléments indépendants à un acteur capable de l’avoir déclenché, maintenu ou inversé.

Le vrai test n’est pas la présence d’un nom

Un identifiant de registre est utile parce qu’il indique où poursuivre l’enquête. Il devient trompeur lorsqu’il est traité comme un équivalent de propriété, d’exploitation ou de pouvoir de décision. Pour DFINFRA et l’AS210860, la question nouvelle n’est donc pas de répéter que le nom apparaît dans un contexte de ressources Internet. Elle consiste à déterminer si plusieurs couches de preuve convergent vers une capacité opérationnelle identifiable.

La distinction est importante pour les opérateurs comme pour les lecteurs qui évaluent une dépendance réseau. Une organisation peut apparaître dans un objet administratif sans annoncer actuellement de préfixe. Un ASN peut être visible dans le BGP sans que les observateurs publics puissent identifier la personne ou l’entreprise qui contrôle les routeurs. Une autorisation cryptographique peut être valide sans qu’une annonce soit active. Ces signaux sont complémentaires, mais ils ne répondent pas à la même question.

Le dossier de recherche a retenu 18 sources publiques, notamment les API RIPEstat consacrées aux préfixes annoncés, à l’état du routage, à l’historique, aux mises à jour BGP, aux chemins observés et aux voisins d’ASN : préfixes annoncés, état du routage, historique du routage, mises à jour BGP, looking glass, voisins d’ASN et cohérence du routage. Le dossier inclut également l’historique Whois de RIPE. Mais ces endpoints n’ont pas été interrogés en direct dans le cadre de cette recherche. Les nombres de préfixes, les dates de changement et les chemins actuels restent donc non vérifiés.

Cinq liens distincts vers le contrôle

Le premier lien est celui de l’identité administrative. L’objet aut-num de l’AS210860 dans la base RIPE, le registre RDAP et l’historique Whois peuvent indiquer un nom, une organisation référencée, des contacts, des dates et des mainteneurs. Ce sont des faits de registre. Ils ne démontrent pas, à eux seuls, qui peut commander une modification de configuration ou interrompre une annonce.

Le deuxième lien concerne les déclarations de routage. La recherche inversée des objets route et route6 dont l’origine déclarée est AS210860 peut montrer quelles ressources sont enregistrées dans l’IRR, quels mainteneurs sont associés et quelles dates de création ou de modification apparaissent. Un objet route est une déclaration administrative d’intention ou d’autorisation dans un registre. Il ne prouve ni l’annonce actuelle ni la validité cryptographique de son origine.

Le troisième lien est le RPKI. Le flux de données RPKI de Cloudflare peut être filtré pour rechercher des ROA autorisant l’AS210860 sur un préfixe et une longueur maximale donnés. Une ROA valide établirait une autorisation d’origine pour la combinaison observée et pour la période concernée. Elle ne permettrait pas d’identifier l’opérateur physique du routeur, et ne prouverait pas qu’une annonce est actuellement visible.

Le quatrième lien est l’observation BGP. Les données RIPEstat, ainsi que les vues indépendantes de bgp.tools et du BGP Toolkit de Hurricane Electric, peuvent corroborer une origine de route, une présence dans les chemins AS et des changements de visibilité. Une observation BGP est plus proche du comportement réel du réseau qu’une simple inscription administrative. Elle reste cependant dépendante des collecteurs, de leur emplacement et du moment de mesure. Une adjacence observée ne suffit pas à établir un contrat de transit, de peering ou de fourniture.

Le cinquième lien concerne l’environnement opérationnel. PeeringDB peut contenir des informations déclarées par l’opérateur sur le type de réseau, les points d’échange, les installations et les contacts. CAIDA AS Rank peut fournir des relations inférées. Les mesures RIPE Atlas IPv4 et IPv6 peuvent aider à examiner la visibilité de mesures associées à l’ASN. Ces sources sont utiles pour tester une empreinte, mais leurs valeurs actuelles n’ont pas été vérifiées ici. Une fiche PeeringDB, même détaillée, reste une déclaration opérateur ; une relation inférée n’est pas une preuve de contrat.

Pourquoi l’absence de chiffres ne permet pas de conclure

Le dossier ne fournit pas de nombre vérifié de préfixes, de voisins, de points d’échange ou de ROA. Cette limite est substantielle. Elle interdit de transformer une liste d’endpoints en résultat factuel. Elle n’autorise pas non plus une conclusion inverse : l’absence de valeur consultée dans cette enquête ne prouve pas l’absence d’activité, de ressource ou d’opérateur.

La bonne méthode consiste à établir une base datée, puis à comparer les couches. Une réponse RIPEstat horodatée pourrait montrer qu’un préfixe était observé comme originaire de l’AS210860. Une réponse RPKI correspondante pourrait indiquer si cette origine était valide, invalide ou non couverte. Un objet IRR pourrait montrer qu’une intention de routage était déclarée. L’objet aut-num et ses mainteneurs pourraient documenter la couche administrative. Mais le lien le plus difficile resterait celui de l’acteur : qui a demandé le changement, qui l’a approuvé, qui pouvait le maintenir et qui pouvait le retirer ?

Sans cette dernière connexion, le dossier décrit un système de signaux, pas une attribution opérationnelle. C’est précisément là que les résumés de registre échouent. Ils confondent la visibilité d’une identité avec la possession d’un levier. Or la continuité d’un service dépend du levier : la capacité de faire apparaître une route, de la conserver, de la modifier ou de la retirer, avec des effets observables pour les réseaux dépendants.

Ce que l’enquête peut déjà dire

L’enquête peut établir une architecture de vérification. Le registre et RDAP répondent à la question « quelle identité ou quel objet est publié ? ». L’IRR répond à la question « quelle origine ou quelle intention de routage est déclarée ? ». Le RPKI répond à la question « quelle origine est cryptographiquement autorisée pour un préfixe et une longueur donnés ? ». Le BGP répond à la question « quel comportement de routage a été observé par certains collecteurs, à un moment donné ? ». PeeringDB, CAIDA et RIPE Atlas peuvent ajouter des éléments déclarés, inférés ou mesurés sur l’environnement réseau.

Aucune de ces réponses ne suffit seule à dire « DFINFRA contrôle l’AS210860 ». La formulation correcte reste plus étroite : les sources publiques identifiées permettent de tester si une identité enregistrée peut être reliée à une activité de routage, à une autorisation et à une capacité d’action. Dans les éléments disponibles pour cette publication, cette démonstration n’est pas achevée.

Cette frontière est aussi la limite de ce que l’on peut déduire pour la continuité. On ne peut pas chiffrer une dépendance client, une capacité, une relation commerciale ou un risque de retrait sans préfixes actuels, observations répétées, preuves d’interconnexion et élément attribuable sur le contrôle. On ne peut pas choisir un autre contrôleur par défaut parce que des champs sont incomplets ou que des sources ne concordent pas.

Le prochain signal qui changerait l’analyse

Le résultat le plus utile serait un changement documenté après une base de référence. Par exemple, une modification d’autorisation ou une variation observable du jeu de préfixes devrait être datée, confirmée par plusieurs sources et mise en regard des objets IRR, des ROA, de l’aut-num et des observations BGP. Il faudrait ensuite un élément indépendant reliant DFINFRA à la décision : une trace d’organisation, une information d’opérateur, une déclaration contrôlée ou une autre preuve montrant que cette entité a initié, approuvé ou pouvait inverser le changement.

Même cette convergence ne prouverait pas automatiquement la propriété juridique. Elle rendrait toutefois beaucoup plus solide l’hypothèse d’une capacité opérationnelle. À l’inverse, des annonces visibles sans preuve d’acteur établiraient une activité de routage, pas l’identité de son décideur. Une ROA valide sans annonce établirait une autorisation, pas une exploitation. Un objet IRR sans visibilité BGP établirait une déclaration, pas un service actif.

La conclusion actuelle est donc bornée mais exploitable : DFINFRA demeure une identité publique à examiner dans le contexte de l’AS210860 ; le paquet de sources définit les tests nécessaires ; il ne démontre pas encore que DFINFRA possède, exploite ou contrôle ce système autonome. Pour les opérateurs, la leçon pratique est de séparer systématiquement le registre, l’autorisation, l’observation et l’acteur capable d’agir. C’est seulement lorsque ces quatre dimensions convergent que le signal administratif commence à devenir une information sur la continuité réelle.