Résumé

  • Les données publiques associent AS210833, le nom Florian Bauer, l’étiquette FSRV et un ensemble de sources consacrées au routage IPv6, mais cette association ne prouve pas à elle seule une gestion quotidienne des équipements ou une capacité de restauration.
  • Dans cette exécution, les points d’accès publics destinés à vérifier l’état actuel du réseau n’ont pas pu être récupérés. Aucune valeur actuelle de préfixe, de validation RPKI, d’amont, de pair ou de présence dans PeeringDB ne doit donc être présentée comme observée.
  • La contribution nouvelle est opérationnelle : transformer cette absence de visibilité en protocole de vérification, en séparant l’identité administrative, la politique déclarée, l’observation BGP, l’autorisation RPKI et les preuves de continuité.

Le registre donne un point d’ancrage, pas une preuve complète de contrôle

Le dossier public d’AS210833 est suffisamment précis pour identifier un objet de recherche. La base RIPE contient un objet aut-num pour l’AS ; les sources de routage et de registre l’associent au nom Florian Bauer, à l’as-name Florian-Bauer et à l’étiquette FSRV. Cette association est la partie vérifiable du problème : un nom et un numéro de système autonome apparaissent ensemble dans des données publiques. La fiche correspondante du répertoire BTW conserve cette identité et signale que l’analyse porte sur un réseau à dominante IPv6. Voir l’entrée de répertoire.

Mais un objet aut-num est un document de registre. Ses attributs peuvent inclure un nom, une organisation, des mainteneurs et une politique import/export déclarée. Ils indiquent comment le détenteur décrit le système autonome dans la base. Ils ne montrent pas, à eux seuls, qui possède les identifiants des routeurs, qui signe un contrat de transit, qui exploite une machine dans un point de présence ou qui dispose d’un accès d’urgence.

Cette distinction est importante parce que plusieurs formes de responsabilité se superposent souvent : titulaire administratif d’une ressource, auteur d’une politique de routage, opérateur d’une session BGP, fournisseur d’hébergement, prestataire de transit et personne capable de restaurer un service. Un même acteur peut occuper ces rôles, mais les sources publiques ne permettent pas de les confondre sans preuve supplémentaire.

Cinq couches de preuve, cinq questions différentes

Une analyse robuste doit traiter séparément au moins cinq couches.

Première couche : l’identité enregistrée. L’objet aut-num de RIPE est le point de départ pour vérifier le nom, l’organisation associée, le statut et les attributs déclarés d’AS210833. Il répond à la question : « Quel acteur ou quelle organisation est publiquement rattaché à ce numéro ? » Il ne répond pas à la question : « Qui administre actuellement les équipements ? » Objet aut-num RIPE.

Deuxième couche : les routes enregistrées. La recherche inverse des objets route6 peut montrer quels préfixes sont déclarés avec AS210833 comme origine dans la base RIPE. Cette donnée est utile pour comparer l’intention administrative avec le plan de contrôle observé. Elle ne prouve pas qu’un préfixe est annoncé maintenant, ni qu’il est valide selon RPKI. Un objet de route peut subsister après un retrait, tandis qu’une route active peut être décrite dans une autre base IRR ou ne pas disposer d’un objet RIPE correspondant. Recherche route6 RIPE.

Troisième couche : la visibilité BGP. RIPEstat peut montrer des préfixes annoncés, l’état de routage et les chemins vus par différents collecteurs. Ces réponses sont temporelles. Elles permettent de dire qu’un collecteur a observé une annonce à un moment donné ; elles ne suffisent pas à prouver la disponibilité d’un service applicatif ou une redondance physique. Les points d’accès pertinents sont l’API des préfixes annoncés, l’état de routage, l’état BGP et le looking glass. Préfixes annoncés État de routage État BGP Looking glass.

Quatrième couche : l’autorisation RPKI. Une ROA peut autoriser AS210833 à annoncer un préfixe donné, avec une longueur maximale donnée. Si une annonce visible correspond à cette autorisation, cela renforce la conclusion sur l’autorisation de l’origine. Cela ne montre toutefois pas que la route est actuellement annoncée, que le détenteur contrôle les équipements, ni que l’annonce est utilement accessible depuis tous les réseaux. Une ROA peut rester valide après le retrait d’une route ; une route légitime peut être « not found » sans être nécessairement frauduleuse. Le fichier de validation Cloudflare est donc une source à comparer aux observations BGP, et non un substitut à celles-ci. Export RPKI Cloudflare.

Cinquième couche : les relations d’interconnexion. PeeringDB contient des informations déclarées par les opérateurs sur le nom du réseau, la politique de peering, les préfixes, les sites et les échanges. BGPView, BGP.Tools, Hurricane Electric et CAIDA proposent des vues indépendantes ou inférées des voisins et des chemins. Ces sources peuvent se corroborer, mais leurs catégories ne sont pas interchangeables. Un voisin immédiat dans un chemin AS peut être un fournisseur, un pair, un route-server ou un effet de visibilité partielle. Une relation « upstream » affichée par un agrégateur n’est pas nécessairement une description contractuelle. PeeringDB BGP.Tools Hurricane Electric Préfixes BGPView Amonts BGPView Pairs BGPView CAIDA AS Rank.

Ce que cette exécution a réellement établi

La recherche a identifié les endpoints nécessaires pour tester l’empreinte actuelle d’AS210833 : préfixes visibles, état de routage, chemins BGP, objet aut-num, objets route6, fiche PeeringDB, données d’agrégateurs de routage, export RPKI et relations CAIDA. Les snapshots de ces sources ont été conservés avec leurs URL et leurs empreintes pour permettre une reprise reproductible.

Mais la récupération en direct n’a pas été disponible dans cette exécution. Les snapshots ne contiennent pas une nouvelle lecture exploitable des valeurs actuelles ; le résultat de recherche indique explicitement qu’aucun nombre courant de préfixes, aucun statut RPKI actuel, aucun amont, aucun pair et aucune valeur PeeringDB n’a été vérifié. Il serait donc incorrect d’écrire qu’AS210833 annonce actuellement deux préfixes, dispose d’un fournisseur précis, participe à un échange donné ou présente une validation RPKI particulière sur la seule base de cette exécution.

Cette limite n’est pas un détail rédactionnel. Une photographie BGP est liée à une heure, à des collecteurs et à une définition de la visibilité. Un compte déclaré dans PeeringDB peut être ancien ou incomplet. Une ROA peut avoir une durée de vie différente de celle d’une annonce. Un objet RIPE peut être maintenu alors que l’exploitation a changé. La bonne formulation est donc : « cette source est le point de contrôle requis », et non : « cette valeur est actuelle » lorsque la réponse n’a pas été récupérée.

Comment transformer l’absence de données en test de continuité

La prochaine vérification devrait suivre une séquence ordonnée.

D’abord, relever la date et l’heure de chaque réponse. Ensuite, comparer les préfixes annoncés par RIPEstat avec les objets route6 de RIPE, les listes BGPView, BGP.Tools et Hurricane Electric. Il faut conserver les différences plutôt que les lisser : un désaccord peut venir de la couverture des collecteurs, du délai de rafraîchissement ou d’une définition différente de « présent ».

Puis, pour chaque préfixe effectivement observé, rechercher une autorisation RPKI correspondante et noter l’état exact : valide, invalide ou non trouvé. La comparaison doit porter sur le préfixe, l’origine et la longueur maximale autorisée. Une conclusion de continuité ne devrait être tirée que si l’observation BGP et l’autorisation RPKI sont datées et reliées au même objet.

Enfin, reconstruire les chemins depuis plusieurs collecteurs et distinguer les adjacences répétées des événements isolés. Plusieurs prédécesseurs AS peuvent suggérer une diversité de chemins, mais ne prouvent pas une diversité de câbles, de sites, de contrats ou d’alimentation électrique. Pour répondre à la question « qui contrôle la continuité ? », il faut compléter les données de routage par des preuves d’exploitation : changements cohérents dans les registres, mise à jour de PeeringDB, annonces depuis plusieurs points, réponse aux incidents et capacité documentée à modifier ou restaurer la politique.

Le résultat attendu n’est pas une note binaire sur Florian Bauer. C’est une matrice de confiance : identité administrative confirmée ou non ; préfixes enregistrés ; préfixes observés ; autorisations RPKI ; relations déclarées ; relations inférées ; indices de maintenance récente ; dépendances non résolues. Cette matrice montre où une conclusion est solide et où elle repose encore sur une hypothèse.

Le risque de continuité se situe dans les dépendances invisibles

Même une annonce BGP stable ne démontre pas la continuité complète d’un service. Le plan de contrôle peut rester visible alors que le réseau d’accès, l’hébergement, le transit ou les procédures de restauration sont fragiles. Inversement, une absence temporaire dans un collecteur ne prouve pas un abandon : elle peut refléter une couverture incomplète, un retrait bref ou un changement de chemin.

Pour les opérateurs et les investisseurs, la question pratique est donc celle du point de défaillance. Si un seul acteur détient les accès, la relation de transit et les informations de restauration, la dépendance opérationnelle est plus forte que ne le laisse voir le simple nombre de routes. Si plusieurs chemins sont visibles mais convergent vers la même installation ou le même fournisseur, la diversité apparente peut masquer une concentration réelle.

Dans le cas d’AS210833, les sources publiques permettent de concevoir ce test mais, dans cette exécution, elles ne permettent pas de conclure sur la situation actuelle de ces dépendances. La prudence n’affaiblit pas l’enquête : elle empêche de transformer une carte de données en preuve de contrôle.

Conclusion : une association publique, pas encore une chaîne de responsabilité

Ce que l’on peut soutenir est précis. Des sources publiques rattachent AS210833 au nom Florian Bauer et à l’étiquette FSRV. Les registres, les objets de routage, les données BGP, les informations RPKI et les fiches d’interconnexion offrent des angles complémentaires pour examiner cette association.

Ce que l’on ne peut pas soutenir à partir de cette exécution est tout aussi précis : aucun état actuel des préfixes, de la validation RPKI, des amonts, des pairs ou de PeeringDB n’a été confirmé. L’association administrative ne prouve ni le contrôle quotidien des routeurs, ni la capacité à restaurer le service, ni l’existence d’une redondance indépendante.

La prochaine étape est une mesure datée et corrélée, pas une extrapolation. Tant que cette mesure n’est pas disponible, la formulation responsable reste celle-ci : AS210833 constitue une identité réseau publiquement attribuée et un objet de recherche identifiable ; la chaîne complète reliant cette identité à une stewardship opérationnelle continue demeure à établir.

Sources de vérification