Résumé

  • Les données RIPE et les bases de routage établissent une association administrative et plusieurs signaux d’autorité technique autour d’AS210860, mais elles ne prouvent pas à elles seules que DFINFRA exploite l’infrastructure ou en contrôle la continuité.
  • La démonstration d’un contrôle opérationnel exigerait une chronologie reliant visibilité des routes, accessibilité indépendante, changements de chemins ou de préfixes et action identifiable d’un opérateur.

L’enquête sur DFINFRA et l’AS210860 commence par une distinction souvent perdue dans les tableaux de registre : être associé à une ressource Internet, disposer d’une autorisation technique, annoncer un préfixe et contrôler le service rendu par cette ressource sont quatre propositions différentes.

Les sources publiques consultées dessinent un ensemble cohérent, mais à plusieurs niveaux. Les objets du registre identifient l’AS210860 et ses relations administratives. Les objets de route et de route6 déclarent comment certains préfixes peuvent être originés. Les données RPKI indiquent si une annonce correspond à une autorisation cryptographique publiée. Les systèmes de mesure du routage montrent ensuite ce qui a été visible depuis des collecteurs ou des points d’observation. Les données de voisinage, de peering et de sondes ajoutent des indications sur la topologie apparente.

Ce que cet ensemble ne fournit pas automatiquement, c’est une preuve de contrôle au sens opérationnel. Il ne dit pas nécessairement qui possède les équipements, qui paie le transit, qui répond aux incidents, qui décide d’un retrait de route ou qui supporte une perte de service. Il ne permet pas non plus d’inférer l’existence de clients, un volume de trafic, un niveau de disponibilité ou une valeur commerciale.

Ce que les registres établissent

Les données RDAP et les objets de la base RIPE fournissent le premier niveau de preuve : une identité administrative et des relations documentées autour de l’AS210860. Les enregistrements publics peuvent associer le label DFINFRA à l’autonomous system et faire apparaître les mainteneurs, contacts ou objets connexes selon le type d’enregistrement consulté (RIPE RDAP; objet aut-num RIPE; recherche RIPE DFINFRA).

Cette association est importante parce qu’elle rend l’objet traçable. Elle permet de rechercher des préfixes, des routes, des voisins et des changements historiques. Mais une relation de registre reste une relation de registre. Elle ne constitue pas, sans éléments supplémentaires, une preuve de propriété économique, de gestion quotidienne ou de responsabilité contractuelle.

La différence est particulièrement importante pour les ressources Internet administrées par plusieurs parties. Un titulaire, un mainteneur, un opérateur de transit, un hébergeur et un client peuvent apparaître dans des systèmes différents. Un objet peut aussi rester publié après un changement d’exploitation, ou être administré par une partie qui n’est pas celle qui prend les décisions de production. La bonne question n’est donc pas seulement « quel nom apparaît ? », mais « quelle capacité concrète ce nom permet-il d’exercer, et quelle autre preuve confirme cette capacité ? »

Autorisation technique ne signifie pas exploitation observée

Les objets route et route6 constituent un second niveau. Ils décrivent les préfixes qu’un système autonome est censé pouvoir annoncer et les relations de routage déclarées dans l’Internet Routing Registry (routes IPv4 de l’AS210860; routes IPv6 de l’AS210860). Ces déclarations sont utiles pour analyser la cohérence entre une identité administrative et une intention de routage.

La RPKI fournit une autre vérification, plus forte sur un point précis : l’autorisation d’un origin AS pour un préfixe. Le fichier public de Cloudflare permet d’examiner les autorisations publiées et leur état au moment de la collecte (données RPKI Cloudflare). Une ROA valide signifie qu’une annonce donnée correspond à une autorisation cryptographique selon les règles de longueur de préfixe et d’origin. Elle ne signifie pas que l’entité nommée dans un registre exploite le routeur, possède le lien de transit ou fournit un service aux utilisateurs finaux.

La RPKI répond à une question d’authenticité de l’origine annoncée. Elle ne répond pas directement aux questions de gouvernance opérationnelle : qui a créé ou modifié la ROA, qui a configuré le routeur, qui peut interrompre l’annonce, qui décide du rétablissement et quelle conséquence une défaillance aurait eue pour un service.

Visibilité BGP : un fait temporel, pas un contrat d’exploitation

Les systèmes RIPEstat et les autres observatoires de routage ajoutent une dimension temporelle. Ils peuvent montrer des préfixes annoncés, leur première ou dernière visibilité, leur évolution historique et les chemins AS observés (statut de routage RIPEstat; historique des routes; première et dernière observation RIS; préfixes annoncés). Les données de BGP.Tools et de Hurricane Electric fournissent des vues complémentaires des annonces et de la connectivité apparente (BGP.Tools; Hurricane Electric BGP Toolkit).

Ces observations établissent qu’un préfixe ou un chemin a été visible depuis une ou plusieurs sources à un moment donné. Elles peuvent révéler une présence persistante, une modification de chemin, une disparition d’annonce ou une relation de voisinage apparente. Elles ne prouvent pas, seules, que l’annonce était liée à un service actif, qu’elle transportait du trafic significatif ou qu’une personne associée à DFINFRA a pris la décision opérationnelle.

La visibilité dépend aussi de la couverture des collecteurs, des délais de convergence, des filtres, des politiques de transit et de la perspective de mesure. Une absence dans une source n’est pas nécessairement une panne. Une présence dans plusieurs sources n’est pas nécessairement la preuve d’un réseau exploité commercialement. Pour transformer un signal BGP en preuve de continuité ou de contrôle, il faut le croiser avec une mesure indépendante et une chronologie suffisamment précise.

Topologie apparente et dépendances

Les bases de voisinage et de peering contribuent à cette analyse sans la conclure. Les données de RIPEstat sur les voisins d’AS, PeeringDB et les services d’exploration IRR peuvent montrer des relations déclarées ou observées entre AS210860 et d’autres réseaux (voisins AS210860; PeeringDB; NLNOG IRR Explorer). Le fichier de statistiques déléguées du RIPE NCC fournit également un contexte sur les ressources de numérotation publiées dans la région (statistiques déléguées RIPE NCC).

Une relation de voisinage peut indiquer une dépendance de transit, de peering ou d’accès à une ressource. Elle ne précise pas toujours la nature économique de cette relation, sa durée, son exclusivité ou la partie qui peut la modifier. La topologie visible est une carte de possibilités et d’observations ; ce n’est pas un organigramme des responsabilités.

Les sondes RIPE Atlas peuvent être utilisées pour rechercher des mesures d’accessibilité associées à un ASN ou à des préfixes (sondes RIPE Atlas IPv4; sondes RIPE Atlas IPv6). Elles sont précieuses pour tester si une destination répond depuis certains points. Elles ne prouvent toutefois pas automatiquement qu’une sonde mesure un service DFINFRA, qu’une absence de réponse est causée par AS210860 ou qu’un changement d’accessibilité a produit un effet commercial.

Ce que l’enquête ne peut pas encore affirmer

Dans le paquet de recherche disponible, aucune séquence confirmée ne relie un retrait de route, une perte d’accessibilité indépendante, une réannonce ou une modification de chemin à une action attribuable à un opérateur identifié. Il n’y a pas non plus de preuve publique établie d’un incident précis, d’un basculement réussi, d’un temps de rétablissement, d’un impact sur un service client ou d’une perte commerciale causée par l’AS210860.

Cette limite n’est pas un détail de rédaction. Elle définit la frontière entre une enquête documentée et une inférence excessive. Dire que les sources montrent une association administrative, une autorisation ou une visibilité de routage est défendable lorsque la source correspondante est citée. Dire que DFINFRA exploite l’AS210860, fournit un service, contrôle la résilience ou dispose d’une clientèle exige une preuve supplémentaire.

La prochaine étape probante serait une chronologie multi-source : un événement de retrait ou de changement de route horodaté, observé par plusieurs collecteurs ; une mesure indépendante de l’accessibilité depuis des emplacements distincts ; une trace de réannonce, de basculement ou de modification de chemin ; et un élément permettant d’identifier l’action ou la responsabilité de l’opérateur. Des journaux d’incident, des annonces publiques, des configurations authentifiées, des contrats de transit ou des déclarations directes pourraient compléter cette chaîne.

Le test de contrôle

Pour analyser DFINFRA sans confondre les couches, il faut poser quatre questions successives.

Premièrement, l’identité administrative : quel objet public relie DFINFRA à AS210860 et quelles relations sont explicitement enregistrées ? Deuxièmement, l’autorité technique : quels objets de routage, ROA ou mécanismes d’authentification permettent ou autorisent une annonce ? Troisièmement, l’opération observable : quelles annonces, quels chemins, quelles réponses et quelles variations sont réellement mesurés dans le temps ? Quatrièmement, le contrôle conséquentiel : qui peut décider, rétablir, rediriger ou interrompre, et quel service ou quelle dépendance cette capacité affecte-t-elle ?

Les trois premières questions peuvent être partiellement documentées par les sources publiques réunies ici. La quatrième reste ouverte. C’est précisément là que se situe l’écart entre la présence d’une ressource dans les bases Internet et la démonstration d’un contrôle opérationnel ayant des conséquences pour des utilisateurs ou des clients.

Sources

Pour consulter la fiche de l’entité étudiée : DFINFRA dans le répertoire BTW.