Résumé

  • Les résultats de cette enquête ne permettent pas d’affirmer l’état actuel des préfixes, des routes, des relations de transit ou des autorisations RPKI d’AS210837 : les réponses des points d’accès en direct n’ont pas été récupérées.
  • Une conclusion défendable sur la continuité devrait relier, avec des horodatages et des corroborations indépendantes, l’identité enregistrée, les annonces observées, l’accessibilité, les dépendances, les décisions opérationnelles et des preuves répétées de rétablissement.

L’identité administrative n’est pas encore une preuve d’exploitation

La première distinction est simple, mais elle conditionne toute la suite. Une entrée de registre peut associer une organisation à un numéro de système autonome. Dans le cas étudié, les sources publiques de recherche associent ROYA Communications and Internet Services Company Ltd à l’AS210837. Cette association doit être vérifiée dans la réponse actuelle de la base RIPE et dans le service RDAP, qui sont les sources appropriées pour l’état administratif, les références liées, les mainteneurs et les dates d’événements : objet aut-num AS210837 dans la base RIPE et enregistrement RDAP de l’AS210837.

Mais une association administrative ne répond pas aux questions opérationnelles. Elle ne dit pas, à elle seule, si l’ASN annonce actuellement des préfixes, si des utilisateurs atteignent ces préfixes, si ROYA prend les décisions de routage, ou si un tiers exploite l’infrastructure pour son compte. Les dates de création ou de modification d’un objet décrivent les changements du registre, pas la disponibilité d’un réseau.

C’est pourquoi l’absence de réponse en direct dans cette enquête est une limite substantielle. Elle ne permet ni de confirmer un fonctionnement actuel, ni de conclure à un arrêt. Elle interdit également de transformer une donnée historique ou une fiche de répertoire en affirmation sur une activité commerciale présente.

Les déclarations de routage décrivent une intention

La recherche inverse de la base RIPE peut identifier des objets route et route6 dont l’origine déclarée est AS210837 : recherche RIPE des objets route et route6. Ces objets peuvent être utiles pour comprendre les préfixes qu’un opérateur déclare vouloir annoncer. Les politiques import/export relèvent notamment de l’objet aut-num, et ne sont pas établies par la seule présence d’un objet route ou route6.

Ils ne constituent toutefois pas une preuve d’une session BGP active. Une déclaration RPSL peut être ancienne, incomplète ou destinée à préparer un filtrage qui ne correspond plus à la situation observée. Elle ne prouve pas non plus qu’un voisin fournit un service de transit commercial. Pour passer de l’intention à l’observation, il faut comparer les objets déclarés avec des données de collecteurs, à des moments compatibles.

Cette différence est une mesure de prévention importante. Un opérateur peut réduire le risque d’annonces erronées en tenant ses objets de routage à jour et en utilisant des filtres cohérents. Mais la qualité du registre ne permet pas de savoir si ces filtres sont appliqués, surveillés et révisés lors d’un changement d’architecture.

Ce que les collecteurs BGP peuvent montrer

Les interfaces RIPEstat consacrées à l’aperçu d’un ASN, aux préfixes annoncés, à l’état BGP, aux voisins, aux mises à jour et à l’historique de routage sont les sources candidates pour reconstruire cette partie de la chaîne : aperçu RIPEstat de l’AS210837, préfixes annoncés, état BGP, voisins ASN, mises à jour BGP, historique du routage et visualisation BGPlay.

Ces sources peuvent établir qu’un collecteur a observé une annonce, un retrait, un chemin ou un voisin à un moment donné. Elles peuvent aider à dater une disparition puis une réapparition, ou à détecter une modification du chemin visible. Elles ne peuvent pas, seules, établir que le monde entier voyait le même état. La visibilité dépend des points de mesure, de leur couverture, de leur calendrier de mise à jour et de la manière dont chaque service agrège les observations.

Une annonce stable ne garantit pas une continuité de service. Le plan de contrôle peut continuer à porter une route alors que le plan de données est dégradé, que les équipements internes sont indisponibles ou que les utilisateurs ne peuvent plus atteindre les services. Inversement, une absence dans un collecteur ne prouve pas une disparition globale : un préfixe peut être visible depuis un autre point de mesure.

L’historique BGP est donc un outil de détection, pas un compte rendu complet d’incident. Pour attribuer une cause, il faudrait des journaux opérationnels, des communications d’incident ou d’autres éléments nommant les décisions prises et les contrôles utilisés. Rien dans les résultats de cette enquête ne permet d’attribuer un retrait de route, une panne ou une réparation à ROYA.

Les relations de transit doivent rester des inférences

Les services secondaires peuvent faciliter la comparaison. BGPView propose des vues de préfixes, d’upstreams et de peers : préfixes BGPView, upstreams BGPView et peers BGPView. Des services comme bgp.tools, AS Rank de CAIDA et IODA peuvent fournir d’autres présentations de la visibilité ou de la topologie observée. BGP.he.net constitue également une vue technique complémentaire.

Un ASN placé avant AS210837 dans un chemin observé peut constituer un indice d’adjacence BGP. Il ne suffit pas à prouver un contrat de transit. Une même apparence peut correspondre à un pair, un fournisseur, un revendeur, un route server ou une relation de secours. Les étiquettes « upstream » et « peer » sont des inférences dépendantes de la méthode, de la fenêtre temporelle et des collecteurs utilisés.

PeeringDB ajoute une autre couche, mais de nature différente. Sa fiche réseau peut contenir des informations déclarées par l’opérateur sur les politiques, les installations, les échanges et les contacts : requête PeeringDB pour l’ASN 210837. La présence d’une fiche ne prouve pas qu’une session est active. Son absence ne prouve pas que le réseau n’a ni pair ni transit, car des relations privées ou des informations non publiées peuvent exister.

La dépendance réelle d’AS210837 ne pourrait donc être décrite avec rigueur qu’en rapprochant les chemins observés, les déclarations administratives, les informations publiées par l’opérateur et plusieurs fenêtres de mesure. Même alors, la relation commerciale resterait à distinguer de l’adjacence technique.

RPKI : un contrôle précis, mais limité

La structure des ROA et la validation d’origine BGP définissent une vérification par paire préfixe-origine, et non une certification globale du réseau. Les points de référence pertinents comprennent l’historique RPKI de RIPEstat, le service RPKI de Cloudflare et les ressources de routage de Cloudflare : historique RPKI RIPEstat, explorateur RPKI Cloudflare et routage Cloudflare pour AS210837.

Un résultat « Valid » peut montrer qu’une autorité de ressources a publié une autorisation couvrant un préfixe et une origine ASN donnés. C’est un élément de prévention contre certaines annonces d’origine incorrecte. Il ne valide pas le chemin AS complet, ne prouve pas que les fournisseurs en amont rejettent les annonces invalides et ne mesure pas la disponibilité du service.

Un résultat « NotFound » ne signifie pas automatiquement qu’une annonce est illégitime : il peut simplement indiquer qu’aucun VRP couvrant n’était disponible pour le validateur. Les différences entre validateurs peuvent aussi refléter des délais de publication, de synchronisation ou de cache. Toute affirmation devrait donc indiquer le préfixe, l’origine, l’horodatage et le validateur utilisés.

RPKI peut ainsi renforcer la prévention et aider à détecter certaines erreurs d’origine. Il ne répond pas à la question de savoir qui appuie sur le bouton lors d’un incident, qui reçoit l’alerte, qui décide d’un retrait ou qui vérifie que le service utilisateur est revenu.

Ce qu’il faudrait pour établir une continuité durable

La question utile n’est pas seulement : « AS210837 apparaît-il dans une base ? » Elle est : « Quelle chaîne d’éléments indépendants permettrait de relier cette identité à une opération continue et contrôlée ? »

Un dossier plus solide devrait d’abord établir l’identité administrative dans la base RIPE et le RDAP, avec leurs dates de récupération. Il devrait ensuite comparer les objets IRR avec les préfixes effectivement observés. Pour chaque préfixe, il faudrait conserver les heures, les collecteurs, les chemins et les variations de visibilité. Les résultats RPKI devraient être associés aux mêmes couples préfixe-origine et à une fenêtre temporelle comparable.

Il faudrait encore distinguer la joignabilité du plan de contrôle de celle du plan de données. Des tests depuis plusieurs réseaux, des mesures d’accessibilité et des informations sur les services concernés seraient nécessaires avant de parler de continuité utilisateur. Les dépendances devraient être décrites comme des observations techniques, non comme des contrats supposés.

Enfin, une preuve de réparation durable devrait comporter plus qu’une réapparition de route. Elle devrait montrer une séquence répétée : détection, décision, correction, retour du contrôle et maintien de l’état corrigé. Les événements de routage peuvent fournir une chronologie externe, mais ils ne suffisent pas à identifier les contrôles internes ni à prouver que les utilisateurs ont retrouvé un service normal.

À ce stade, la conclusion doit rester bornée. La recherche a identifié une méthode et des sources techniquement pertinentes, mais elle n’a pas récupéré leurs réponses actuelles. Elle ne démontre donc ni l’exploitation actuelle d’AS210837, ni son arrêt, ni une défaillance de ROYA, ni la présence d’une réparation durable. Cette retenue n’est pas un manque d’analyse : c’est la condition pour ne pas confondre un objet administratif avec une preuve d’exploitation.