Résumé

  • Les données de registre peuvent établir une association administrative entre DFINFRA et AS210860, mais pas à elles seules la propriété effective, l’exploitation d’équipements ou la continuité d’un service.
  • Une conclusion solide sur l’empreinte opérationnelle devrait relier, dans une période définie, l’identité administrative, l’autorité technique, des annonces observées, une présence physique ou d’échange, un mécanisme de service et une conséquence attribuable.

Le registre donne un point de départ, pas une carte de contrôle

Le premier élément de la chaîne est administratif. L’allocation des numéros autonomes par l’IANA situe l’autorité de registre au niveau des blocs de numérotation, mais ne désigne pas l’opérateur actuel d’un réseau ni son bénéficiaire économique (IANA, registre des numéros AS). Le dossier RDAP de l’AS210860 et l’objet aut-num de la RIPE Database sont plus directement pertinents pour l’identité publiée, les contacts, les mainteneurs et les déclarations de politique (dossier RDAP de l’AS210860; objet aut-num).

Ces éléments permettent de formuler une proposition limitée : des données publiques associent le label DFINFRA à l’AS210860. Elles ne permettent pas, sans autres preuves, d’affirmer que DFINFRA possède le réseau, exploite ses routeurs, contrôle toutes ses ressources d’adressage, vend une connectivité ou perçoit des revenus. Un nom administratif peut être exact tout en restant insuffisant pour répondre à la question opérationnelle.

Autoriser une route n’est pas exploiter un service

La deuxième étape concerne l’autorité technique. Une recherche d’objets route ou route6 peut montrer qu’un registre IRR déclare l’AS210860 comme origine autorisée pour certains préfixes (recherche RIPE des objets de route). Une autorisation RPKI, lorsqu’elle est observée dans une source adaptée, répond à une autre question : quels préfixes un certificat autorise-t-il à être originés par quel ASN (données RPKI Cloudflare) ?

Ni l’un ni l’autre ne constitue une preuve complète d’exploitation. Un objet IRR peut subsister après l’arrêt d’une annonce. Une autorisation peut être maintenue sans démontrer l’existence d’un service commercial. À l’inverse, une annonce visible peut ne pas avoir d’objet correspondant dans une base IRR donnée. L’autorisation, l’observation et l’usage sont des catégories différentes.

Ce que les mesures de routage peuvent réellement montrer

Les API RIPEstat peuvent servir à séparer ces catégories. La vue d’ensemble de l’AS fournit un résumé dépendant de l’heure d’interrogation (RIPEstat AS Overview). La liste des préfixes annoncés vise les origines observées dans les données de routage (préfixes annoncés), tandis que l’état de routage et la visibilité dépendent des collecteurs et de la période mesurée (état de routage). Les données RIS et leurs échantillons de chemins offrent une autre fenêtre sur la propagation (RIPEstat Looking Glass; RIPE RIS Live).

Ces sources peuvent établir qu’un ASN a été visible comme origine ou qu’il apparaît dans certains chemins observés à un moment donné. Elles ne disent pas automatiquement qui gère les routeurs, qui paie le transit, qui détient une adresse, qui sert un client ou qui répond à une panne. Une visibilité faible peut résulter de la sélectivité des annonces ou de la couverture des collecteurs; l’absence dans une source ne prouve pas l’absence dans l’Internet public.

L’adjacence n’est pas encore une dépendance commerciale

Les voisins ASN sont utiles pour rechercher une structure de dépendance. RIPEstat peut recenser des adjacences observées (ASN Neighbours); BGP.Tools, Cloudflare Radar, CAIDA AS Rank, Hurricane Electric et BGPView peuvent fournir des points de comparaison (BGP.Tools; Cloudflare Radar; CAIDA AS Rank; Hurricane Electric; BGPView).

Mais un ASN adjacent dans un chemin n’est pas nécessairement un fournisseur de transit payé. Il peut s’agir d’un pair, d’un client, d’un réseau frère, d’un routeur de route server ou d’une relation déduite par un algorithme. Pour qualifier une dépendance, il faudrait conserver la direction des chemins, leur répétition, les dates d’observation et, de préférence, une documentation de l’opérateur ou du fournisseur. La prudence est particulièrement importante lorsqu’une seule vue laisse penser qu’un voisin serait le point de sortie principal.

La présence en échange doit être corroborée

PeeringDB peut documenter le nom choisi par l’opérateur, une politique de peering, des points de contact, des installations ou des échanges associés à l’AS210860 (profil réseau PeeringDB; page AS210860). Les données d’échange peuvent également signaler une adresse de peering, un port ou une participation à un route server (données netixlan). La documentation du service est nécessaire pour interpréter correctement ces champs (documentation PeeringDB).

Ce sont des informations opérationnelles potentiellement utiles, mais elles restent déclaratives. Une installation listée ne prouve pas qu’un équipement y est encore présent. Une absence de fiche ne prouve pas qu’aucune interconnexion n’existe. Une présence sur un échange ne démontre pas une relation bilatérale active avec chaque membre, ni l’existence d’un service vendu à des clients.

Le test qui manque

L’empreinte opérationnelle ne devrait être retenue que si plusieurs chaînes se recoupent dans le temps. Il faudrait d’abord une identité administrative suffisamment précise. Il faudrait ensuite montrer l’autorité technique sur des ressources ou des annonces, puis observer une activité de routage avec ses dates et ses points de mesure. Une présence physique ou d’échange devrait être confirmée par des sources adaptées, sans confondre déclaration et vérification. Enfin, il faudrait identifier le mécanisme de service : client, application, capacité, hébergement, transit ou autre fonction documentée.

Le dernier maillon est l’effet attribuable. Une modification d’annonce, une dépendance répétée à un voisin, une interruption observée puis une restauration ne suffisent pas nécessairement à identifier le responsable. Pour relier l’événement à DFINFRA, il faudrait une preuve indépendante de l’action, de la capacité de correction et de la conséquence pour un service ou un utilisateur. Les outils IPinfo et les agrégateurs ASN peuvent aider à contextualiser l’objet, mais leurs libellés ne remplacent pas cette chaîne (IPinfo AS210860).

Ce que cette enquête peut conclure maintenant

Le matériau réuni définit une méthode de vérification plus stricte que la simple lecture d’un registre. Il permet de distinguer l’identité, l’autorisation, la visibilité, l’adjacence, la présence déclarée et le service. En revanche, les contenus actuels des sources n’ont pas été récupérés dans cette enquête. Aucun nombre courant de préfixes, aucun fournisseur nommé, aucun pair, aucune installation, aucun ROA précis et aucun mécanisme de service DFINFRA documenté indépendamment ne peut donc être présenté comme une valeur actuelle établie.

La conclusion est limitée mais utile : les données publiques indiquent une piste d’enquête autour de DFINFRA et de l’AS210860; elles ne ferment pas encore la chaîne qui relierait cette piste à une exploitation durable, à une dépendance commerciale ou à une conséquence de continuité. La prochaine preuve décisive ne sera pas un nouveau label dans un agrégateur. Ce sera un ensemble daté et corroboré reliant identité, pouvoir technique, routage observé, infrastructure, service et effet attribuable.

Sources et périmètre de vérification

Les définitions de l’API RIPEstat sont disponibles dans sa documentation (documentation RIPEstat). Les résultats provenant de sources de routage différentes doivent être comparés avec leurs heures d’observation et leur couverture. Les données d’autorisation, les mesures de contrôle et les déclarations d’opérateur doivent rester séparées dans toute mise à jour ultérieure.