Résumé

  • Les objets de registre, leurs mainteneurs et les observations de routage décrivent des relations documentaires ou une activité visible ; ils ne suffisent pas, à eux seuls, à prouver qu’une personne contrôlait des routeurs, des sessions BGP ou les identifiants sous-jacents.
  • Une attribution plus solide exigerait des éléments datés et concordants : évolution d’un objet RIPE, transition de mainteneur ou de contact, historique de routes, observations BGP qui se recouvrent et preuve opératoire indépendante.

Le vrai sujet est le mécanisme, pas le nom

Les dossiers publics relatifs à l’AS211867 et à l’identifiant ALL-INC-AS peuvent être étudiés dans plusieurs classes de sources : l’objet aut-num de la RIPE Database, son historique de versions, les objets de routes associés, les données RDAP, les observations RIPE RIS, les bases de topologie BGP, PeeringDB et les présentations de bgp.tools, de Hurricane Electric et de CAIDA (objet aut-num RIPE; historique des versions; RDAP).

Ces sources ne répondent toutefois pas à la même question. L’objet aut-num peut documenter une organisation déclarée, des contacts administratifs ou techniques et des mainteneurs associés. L’historique peut montrer qu’un champ a changé à une date donnée. Une recherche inverse peut identifier des objets de route qui déclarent l’AS211867 comme origine (recherche inverse RIPE). Cela établit une chaîne de registres : qui ou quoi est déclaré dans la base, et quels comptes sont autorisés à modifier certains objets.

Ce n’est pas encore une chaîne de contrôle personnel. Un mainteneur est une relation d’autorisation au niveau d’un objet de base de données. Elle ne prouve pas qui détenait les identifiants, qui exploitait les routeurs, qui configurait les sessions BGP, ni qui bénéficiait juridiquement ou économiquement de l’infrastructure. Confondre ces niveaux transforme une déclaration administrative en preuve de contrôle opérationnel.

Trois catégories de preuve à ne pas mélanger

La première catégorie est celle des déclarations de registre. Elle comprend l’aut-num, les contacts, les mainteneurs, les objets de route et leurs modifications. La deuxième est celle de l’activité observée. RIPE RIS peut montrer des préfixes annoncés, des périodes de visibilité, des voisins et des écarts entre objets de registre et annonces observées (historique du routage; préfixes annoncés; cohérence du routage; voisins ASN; première et dernière observation). La troisième est celle de l’identité et de l’autorité : contrats, déclarations d’opérateur, journaux de changement, dossiers de transaction, témoignages nommés ou documents techniques contemporains reliant explicitement une personne à une décision.

Les deux premières catégories peuvent se renforcer mutuellement sans devenir la troisième. Une annonce BGP observée démontre une activité de routage visible par certains collecteurs. Elle ne démontre pas l’identité de la personne qui l’a autorisée. Un voisin récurrent peut suggérer un mécanisme de connectivité, mais il ne prouve ni une relation commerciale, ni la propriété d’un routeur, ni la responsabilité d’un individu. Une fiche PeeringDB peut fournir une piste opérationnelle utile, tout en restant une déclaration soumise par un participant (PeeringDB).

Pourquoi la chronologie compte

La chronologie est le moyen le plus prometteur de dépasser une simple association de noms, mais elle doit être construite avec prudence. Un changement dans l’historique de l’aut-num peut indiquer qu’un contact, un mainteneur ou une politique déclarée a été ajouté, supprimé ou remplacé. Un changement d’objet de route peut montrer une modification de la politique publiée. Une période de routage observée peut établir que l’AS a été visible dans certaines données de collecte à un moment donné.

Aucune de ces dates ne doit être surinterprétée. La date de modification d’un objet n’est pas nécessairement la date du premier routage. La première observation par RIPE RIS est une date de visibilité pour un collecteur, pas la date de création du réseau. La dernière observation ne prouve pas une cessation d’activité globale. Les agrégateurs peuvent présenter des données différentes selon leurs collecteurs, leurs caches et leurs méthodes (bgp.tools; Hurricane Electric; CAIDA AS Rank).

Pour transformer une chronologie en mécanisme d’attribution, il faudrait donc aligner plusieurs événements datés : une modification de registre, une transition identifiable de contact ou de mainteneur, une continuité ou une rupture dans les annonces, puis un document indépendant reliant cette transition à une personne ou à une organisation. Sans ce chevauchement, la chronologie reste une succession de signaux institutionnels, non une preuve de commandement personnel.

Ce que cette recherche établit réellement

Le dossier de recherche a identifié les sources publiques pertinentes, mais les valeurs exactes des champs en direct, des versions, des routes, des préfixes, des voisins et des fiches opérateur ne doivent pas être présentées comme des valeurs vérifiées dans cette enquête. Cette limite est importante : ne pas avoir confirmé un transfert, une succession, une délégation ou une continuité de personnel ne permet pas d’affirmer qu’un tel élément n’existe pas.

La conclusion défendable est plus étroite. Les sources disponibles indiquent quelles traces permettraient de tester l’hypothèse d’une continuité ou d’un transfert d’autorité, mais elles ne fournissent pas ici un mécanisme personnel vérifié reliant Osipenko Alexander Nikolaevich à l’exploitation opérationnelle de l’AS211867. Le résultat est une limite de preuve, et non une preuve de non-existence.

Les documents qui changeraient l’analyse

Un futur dossier gagnerait en force s’il réunissait plusieurs éléments indépendants :

  1. un historique RIPE montrant une transition datée d’organisation, de contact ou de mainteneur ;
  2. des objets de route et des observations BGP correspondant à la même période ;
  3. une déclaration d’opérateur, un contrat, un dossier de transaction ou un document réglementaire identifiant la responsabilité ;
  4. des traces techniques contemporaines reliant cette responsabilité à une décision concrète ;
  5. un successeur, collaborateur ou contrepartie nommé confirmant le transfert ou la continuité.

Même cette combinaison devrait être formulée avec précision. Elle pourrait établir une autorité déclarée, une responsabilité administrative ou un rôle opérationnel documenté. Elle ne prouverait pas automatiquement la propriété économique, l’intention ou le contrôle permanent de tous les équipements.

Une méthode pour éviter l’attribution excessive

La bonne question n’est donc pas : « quel nom apparaît dans la base ? » Elle est : « quel mécanisme relie ce nom à une décision, à un identifiant, à une transition et à un résultat observable ? » Cette méthode protège à la fois l’exactitude factuelle et la responsabilité individuelle.

Pour Osipenko, les registres et les systèmes de routage peuvent fournir un cadre d’enquête. Ils peuvent documenter des objets, des changements et une activité visible. Ils ne doivent pas être utilisés pour combler automatiquement les étapes absentes entre une association publique et une autorité personnelle. Tant que ces étapes ne sont pas documentées par des sources datées et concordantes, l’attribution doit rester bornée.