Résumé

  • Les registres RIPE et RDAP peuvent documenter une association administrative avec AS210860, mais ils ne démontrent ni la propriété juridique d’une infrastructure, ni l’exploitation quotidienne d’équipements ou de services.
  • Les données BGP, les voisins observés et les déclarations PeeringDB peuvent préciser le type de présence technique à rechercher, mais les éléments disponibles ici n’ont pas été récupérés en direct et ne permettent donc pas d’attribuer une activité actuelle à DFINFRA.

La question utile n’est pas simplement de savoir si AS210860 existe ou si le nom DFINFRA apparaît dans un registre. Elle consiste à déterminer quelle chaîne de preuves relierait une identité administrative à une autorité technique, à une présence réseau observable, à des dépendances d’interconnexion et à une conséquence opérationnelle attribuable.

Le registre fournit une identité, pas un opérateur complet

Le point de départ le plus formel est l’objet aut-num de la RIPE Database pour AS210860. La réponse peut documenter le nom d’AS, les références organisationnelles, les mainteneurs, les contacts et la chronologie de modification du dossier (objet aut-num de la RIPE Database). Le service RDAP fournit une représentation normalisée de l’enregistrement et peut corroborer son existence et son statut (fiche RDAP d’AS210860).

Ces éléments répondent à une question précise : quelle relation administrative est inscrite dans le registre ? Ils ne répondent pas automatiquement à d’autres questions. Ils ne disent pas nécessairement qui administre les routeurs, qui possède les adresses, qui signe les contrats de transit, qui maintient les équipements ou qui assume les conséquences d’une interruption. Les attributs de registre sont importants parce qu’ils rendent l’identité vérifiable ; ils sont insuffisants lorsqu’ils sont utilisés comme raccourci vers le contrôle opérationnel.

Cette distinction est particulièrement importante pour une organisation dont le nom peut apparaître dans plusieurs couches techniques. Un nom de registre peut être repris par des annuaires ASN, des plateformes de visualisation et des outils de routage. Cette répétition rend l’étiquette plus visible, mais ne constitue pas plusieurs preuves indépendantes de la même responsabilité.

Une annonce BGP montre une visibilité située dans le temps

La seconde couche concerne les préfixes observés avec AS210860 comme origine. RIPEstat propose un point d’accès aux préfixes annoncés et à leur historique (préfixes annoncés par AS210860). Son aperçu général rassemble également des indicateurs de visibilité et de routage (aperçu RIPEstat d’AS210860). Des agrégateurs comme bgp.tools proposent une vue complémentaire des préfixes et des relations visibles (profil de routage de bgp.tools).

Une observation BGP peut donc établir qu’un collecteur a vu un préfixe associé à un ASN à un moment donné. Elle peut servir à dater une présence, à comparer des périodes ou à formuler une hypothèse sur l’évolution d’un périmètre routé. Elle ne prouve pas, à elle seule, que l’organisation nommée dans le registre possède les adresses, héberge chaque machine située dans le préfixe ou fournit un service à chaque domaine qui y résout.

La couverture des collecteurs est partielle. Les résultats peuvent varier selon la date, les points d’observation, les filtres et la façon dont chaque service traite les routes plus spécifiques, les retraits ou les annonces intermittentes. La première date visible dans une base n’est pas nécessairement la première annonce sur Internet. Une conclusion sérieuse doit donc conserver la date de l’observation, l’origine de la mesure et sa portée exacte.

Les voisins décrivent une topologie observée, pas un contrat commercial

Les relations entre AS constituent une troisième couche. RIPEstat peut retourner les ASN observés à proximité d’AS210860 dans les chemins BGP (voisins d’AS210860 dans RIPEstat). Cette proximité peut aider à rechercher des fournisseurs, des clients, des pairs ou des intermédiaires de route-server. Mais un voisin dans un chemin n’est pas automatiquement un fournisseur de transit, et une classification d’« upstream » ou de « peer » n’est pas un contrat.

Les chemins BGP peuvent refléter du transit partiel, du prepend, un route-server, un AS frère, une relation de client ou une politique de visibilité limitée. Les classifications produites par des services tiers doivent donc être traitées comme des inférences. Elles deviennent plus utiles lorsqu’elles sont comparées à des observations temporelles, à des annonces réelles et à des déclarations séparées de l’opérateur.

PeeringDB ajoute justement une autre forme de signal. Sa fiche réseau peut contenir le nom déclaré, un site web, une politique de peering, une catégorie de réseau ou une portée géographique (fiche réseau PeeringDB pour l’ASN 210860). Les enregistrements d’IXP peuvent associer l’ASN à des points d’échange ou à des adresses de peering (présences exchange-LAN dans PeeringDB). Les enregistrements de sites peuvent déclarer une présence dans une installation (présences en facility dans PeeringDB).

Ces données sont potentiellement précieuses parce qu’elles décrivent une déclaration d’opérateur différente d’un objet de registre. Elles restent toutefois déclaratives. Une présence dans PeeringDB ne prouve pas qu’un port est actif au moment de l’observation, qu’une session BGP est établie, que l’organisation possède l’installation ou qu’un service commercial dépend de cette interconnexion. Pour parler d’exploitation, il faudrait rapprocher la déclaration d’éléments observés, datés et attribuables.

Ce que l’on peut et ne peut pas dire sur un déploiement

L’enquête initiale a identifié plusieurs sources complémentaires pour rechercher des services et des déploiements visibles sur l’espace associé à AS210860. Des services d’analyse peuvent corréler un ASN avec des hôtes, des certificats, des noms de domaine ou des pages web. Ces corrélations peuvent constituer des pistes. Elles ne prouvent pas que DFINFRA exploite chaque site observé, car un même espace peut accueillir des clients, des revendeurs, des proxies ou des services sans lien organisationnel direct.

Cette limite n’est pas secondaire. Un résultat d’analyse d’hôte décrit ce qu’un instrument a vu sur une adresse ou un certificat. Il ne décrit pas nécessairement la relation contractuelle entre cette adresse et l’entité dont le nom apparaît dans un registre. De même, un domaine résolu vers un préfixe annoncé par AS210860 peut signaler une dépendance d’hébergement à un instant donné, sans démontrer qui a choisi l’hébergeur, qui exploite le serveur ou qui répondrait à une panne.

La bonne méthode consiste à séparer plusieurs questions :

  1. Quelle identité administrative est inscrite pour AS210860 ?
  2. Quels droits techniques ou objets d’autorisation sont associés à cette identité ?
  3. Quels préfixes et voisins ont été observés, à quelle date et par quels collecteurs ?
  4. Quelles interconnexions ou installations sont déclarées par l’opérateur lui-même ?
  5. Quels systèmes ou services peuvent être corrélés à l’espace routé ?
  6. Quelle preuve indépendante relie ces éléments à une personne morale, à un service et à une responsabilité opérationnelle ?

Les premières questions peuvent être abordées par des registres, des bases BGP et des annuaires techniques. La dernière exige généralement des documents ou des observations supplémentaires : site contrôlé par l’organisation, déclaration cohérente et datée, contrat ou dossier d’installation, annonce persistante, réponse à un incident, ou témoignage attribuable. Sans ce dernier raccord, la conclusion doit rester limitée à une relation administrative et à des signaux techniques.

Pourquoi la continuité reste la question décisive

La continuité transforme une présence technique en question de responsabilité. Il ne suffit pas de montrer qu’un ASN a été visible. Il faut pouvoir établir qui détecte une disparition de route, qui décide d’un changement de chemin, qui possède l’autorité de modifier les annonces et qui rétablit le service. Une analyse historique des routes peut rechercher des ajouts, retraits, changements d’origine ou variations de visibilité (historique de routage RIPEstat). Mais un changement observé ne révèle pas automatiquement la décision ni l’acteur qui l’a provoqué.

La même prudence vaut pour RPKI. Une autorisation de route peut relier un préfixe à un ASN dans un système de validation. Elle ne suffit pas à démontrer qui exploite les routeurs ou qui fournit le service. L’autorisation porte sur une relation technique de route-origin ; elle ne remplace ni un contrat de transit, ni une preuve de maintenance, ni une preuve d’impact commercial.

Pour fermer réellement la boucle de continuité, il faudrait aligner, dans une même fenêtre temporelle, une perte ou une modification de visibilité, une mesure indépendante d’accessibilité, une action de réannonce ou de bascule, et une intervention attribuable. Il faudrait ensuite montrer que l’événement concernait un service identifiable. Les données rassemblées dans ce dossier permettent de définir ce test ; elles ne fournissent pas ses valeurs actuelles vérifiées.

Conclusion : le signal est réel, la responsabilité reste ouverte

Le nom DFINFRA et l’ASN 210860 forment une piste d’enquête légitime. Les registres peuvent établir une association administrative. Les bases de routage peuvent documenter une visibilité située dans le temps. PeeringDB peut exposer des déclarations de connectivité ou de présence. Les outils d’observation de déploiement peuvent fournir des pistes sur des hôtes ou des domaines.

Aucune de ces couches, prise isolément, ne suffit à conclure que DFINFRA exploite une infrastructure complète, contrôle toutes les annonces d’AS210860, fournit un service commercial ou assume les conséquences d’une panne. La conclusion la plus solide est donc également la plus étroite : l’objet est suffisamment documenté pour une enquête technique, mais la chaîne reliant identité, autorité, déploiement, dépendance et responsabilité opérationnelle n’est pas fermée par les éléments vérifiés ici.

La prochaine avancée ne consisterait pas à répéter le nom dans davantage d’annuaires. Elle consisterait à obtenir des observations datées et indépendantes sur les préfixes, les relations de transit, les installations, les services et la continuité, puis à les relier à un acteur identifiable. C’est cette jonction — plutôt que l’existence d’un ASN dans un registre — qui permettrait de parler d’une exploitation démontrée.