Résumé

  • Les objets RIPE Database et RDAP sont les voies de preuve principales pour vérifier l’identité enregistrée d’AS210764 et son lien déclaré avec ISC-AGP1, mais ils ne prouvent ni une annonce BGP actuelle ni un contrôle opérationnel présent.
  • Les observations RIPEstat, les objets IRR, les autorisations RPKI et la page réseau de l’ISC répondent à des questions différentes. Les snapshots disponibles ici ne contiennent pas les valeurs live nécessaires pour établir un nombre de préfixes, une visibilité ou une autorisation précise.

L’Internet Systems Consortium est connu du public comme l’organisation qui développe et maintient notamment BIND et Kea. Cette couverture antérieure permettait d’examiner la chaîne de responsabilité entre un logiciel publié, sa distribution, son déploiement et sa récupération après incident. Le dossier AS210764 pose une question plus étroite : que peut-on démontrer publiquement sur l’infrastructure réseau attachée au nom ISC-AGP1, et où la preuve s’arrête-t-elle ?

La distinction est importante. Un nom dans un registre n’est pas une mesure de disponibilité. Une route visible n’est pas une preuve de propriété juridique. Un objet IRR décrit une intention de routage déclarée, non une annonce effectivement observable. Une autorisation RPKI établit qu’un détenteur de ressources a autorisé un ASN pour un préfixe et une longueur maximale déterminés, mais elle ne prouve pas que la route est annoncée ni que l’organisation nommée exploite les routeurs.

Le premier maillon : l’identité de registre

Les objets officiels de la RIPE Database et le service RDAP constituent les sources primaires pour examiner AS210764 : son nom court, son organisation de référence, son statut, ses mainteneurs, ses contacts et ses dates de création ou de modification (RIPE Database, objet aut-num ; RIPE NCC RDAP). Le résumé WHOIS de RIPEstat fournit une représentation complémentaire de ces données (RIPEstat WHOIS).

Cette chaîne peut établir qu’un ASN est enregistré avec une identité et une organisation de référence. Elle ne permet pas, à elle seule, d’en déduire qui administre actuellement les routeurs, qui décide d’une politique d’annonce ou qui répond à un incident. Les bases de registre sont des systèmes d’identité et de coordination. Elles ne sont pas des sondes de disponibilité.

Cette limite n’est pas un détail juridique périphérique. Elle empêche de transformer automatiquement un attribut administratif en affirmation opérationnelle. Une organisation peut conserver un objet attribué alors que l’ASN n’est pas visible dans les collecteurs BGP. À l’inverse, une observation de routage peut démontrer une activité technique sans identifier la personne ou l’équipe qui exploite effectivement l’équipement.

La visibilité BGP doit être mesurée, pas supposée

Les points d’accès RIPEstat consacrés à l’aperçu d’un ASN, à l’état de routage, aux préfixes annoncés et à l’état BGP sont adaptés pour mesurer ce que les collecteurs de la RIPE NCC voient à un instant donné (AS Overview ; Routing Status ; Announced Prefixes ; BGP State).

Ces mesures répondent à une question différente de celle du registre : AS210764 est-il actuellement visible dans un ensemble donné de collecteurs, et quels préfixes apparaissent avec cet ASN comme origine effective ? La réponse doit être accompagnée de son heure d’observation. Les routes peuvent être retirées, réannoncées ou visibles depuis certains points et absentes d’autres. Une absence dans RIPEstat ne prouve donc pas l’abandon de l’ASN ; une présence ne prouve pas la propriété juridique ni la criticité d’un service.

Dans le dossier disponible pour cette enquête, les sources ont été sélectionnées et conservées comme pistes de preuve runtime, mais les snapshots accessibles ne reproduisent pas les réponses live détaillées. Il n’est donc pas possible de publier honnêtement un nombre exact de préfixes, une valeur de visibilité, un dernier instant observé ou une liste de voisins. Toute conclusion plus précise inventerait une mesure que le dossier ne contient pas.

L’IRR décrit une politique déclarée

La recherche inverse des objets route et route6 dans la RIPE Database peut montrer quels préfixes sont déclarés avec AS210764 comme origine, ainsi que les sources, mainteneurs, dates de création et dates de modification associés (recherche inverse RIPE des routes).

Ces objets sont utiles pour reconstituer une intention administrative ou une politique de routage. Ils peuvent aider à comparer ce qu’une organisation déclare avec ce que les collecteurs BGP observent. Mais l’IRR n’est pas une preuve cryptographique et un objet peut être ancien, incomplet ou maintenu sans annonce correspondante. Une route visible peut aussi ne pas disposer d’un objet IRR correspondant.

Le bon raisonnement est donc comparatif : une concordance entre un objet IRR récent et une annonce observée renforce la description d’une configuration publique cohérente ; une discordance est un signal à examiner, non une preuve automatique d’erreur, de détournement ou de compromission.

Le RPKI autorise une origine précise, sans prouver l’exploitation

L’historique RPKI de RIPEstat et les charges utiles validées par les validateurs peuvent indiquer si une autorisation de route couvre un préfixe, un ASN d’origine et une longueur maximale donnés (historique RPKI RIPEstat). Cette information est plus forte qu’une simple déclaration textuelle, car elle repose sur une chaîne d’autorisation cryptographique liée aux ressources Internet.

Elle reste toutefois circonscrite. Une ROA valide autorise une origine ; elle ne démontre pas que le préfixe est annoncé maintenant, que l’annonce est mondialement visible ou que l’organisation citée dans un registre exploite les routeurs. Le statut dépend aussi de la longueur exacte du préfixe et de l’état du validateur au moment de l’observation. « NotFound » ne signifie pas « Invalid », et une ROA peut rester publiée après le retrait d’une route.

Pour établir une conclusion solide, il faudrait rapprocher, pour chaque préfixe, l’observation BGP, l’objet IRR, la ROA et l’identité de la ressource. Une affirmation générale sur « le RPKI d’AS210764 » serait trop imprécise si elle ne précisait pas les préfixes et les heures concernés.

Le contexte officiel de l’ISC complète, mais ne remplace pas, les registres

La page réseau officielle de l’ISC peut fournir un contexte de première partie sur son réseau, ses interconnexions, ses services ou son architecture (page réseau de l’ISC). Une mention explicite d’AS210764 ou d’ISC-AGP1 serait une attribution opérationnelle plus forte qu’une présentation générale. L’absence d’une telle mention ne démontrerait cependant pas que l’ISC n’exploite pas l’ASN : les pages publiques ne sont pas nécessairement des inventaires exhaustifs.

Cette asymétrie est centrale. Les sources institutionnelles peuvent expliquer une fonction ou une responsabilité annoncée, mais elles ne doivent pas être utilisées pour combler une mesure de routage manquante. De même, les registres peuvent confirmer une relation déclarée sans prouver la continuité opérationnelle de cette relation.

La chaîne de contrôle à vérifier

Pour passer d’une identité de registre à une conclusion sur la gestion durable d’une infrastructure, il faut relier plusieurs maillons :

  1. l’objet aut-num et le RDAP identifient-ils explicitement l’organisation et ses mainteneurs ?
  2. les contacts et dates sont-ils cohérents avec les informations officielles de l’ISC ?
  3. RIPEstat observe-t-il AS210764 comme origine de préfixes à une heure documentée ?
  4. ces préfixes correspondent-ils à des objets IRR identifiables et suffisamment récents ?
  5. une ROA autorise-t-elle précisément chaque couple préfixe-origine-longueur ?
  6. une source officielle de l’ISC relie-t-elle l’ASN à un service, un réseau ou une fonction déterminée ?
  7. existe-t-il des éléments publics montrant la détection, la réponse et la vérification après un incident de routage ?

Le dernier maillon est souvent le plus difficile. Les données publiques peuvent montrer qu’un route a existé ou qu’une autorisation a été publiée. Elles montrent rarement qui surveille continuellement le système, qui décide d’un retrait, qui coordonne la récupération et comment la restauration est vérifiée. Une organisation peut contrôler le logiciel sans contrôler chaque distribution, chaque configuration ou chaque réseau qui l’utilise ; de même, un titulaire enregistré peut ne pas être l’opérateur quotidien de chaque annonce associée à son ASN.

Conclusion : une identité solide, une opérationnalité non établie

La conclusion publiable est donc bornée. Les registres RIPE et RDAP constituent les sources appropriées pour examiner l’identité enregistrée d’AS210764 et son lien déclaré avec ISC-AGP1. RIPEstat, l’IRR, le RPKI et la page réseau de l’ISC fournissent les cadres adaptés pour tester séparément la visibilité, l’intention, l’autorisation et le contexte opérationnel. Mais les snapshots disponibles ne livrent pas les mesures live nécessaires pour conclure sur les préfixes actuellement annoncés, la visibilité, l’état RPKI ou le contrôle opérationnel durable.

L’écart de preuve n’est pas un échec de l’enquête. C’est son résultat principal. La bonne pratique consiste à publier la date et la portée de chaque observation, à distinguer identité, déclaration, autorisation et activité, puis à conserver les réponses brutes afin qu’une autre équipe puisse reproduire la vérification. Tant que cette chaîne n’est pas complète, ISC-AGP1 doit être décrit comme une identité de registre à examiner, non comme une preuve suffisante de la maîtrise actuelle de toute l’infrastructure associée.