Résumé

  • L’association entre DFINFRA et AS210860 constitue un signal registral vérifiable, mais elle ne démontre ni la propriété, ni l’exploitation quotidienne, ni la capacité d’un acteur identifié à réparer une interruption.
  • Une conclusion sur la continuité devrait relier, dans une même période, les retraits et réannonces BGP, une mesure indépendante de l’accessibilité, les chemins observés vers les voisins et une preuve opérationnelle attribuable.

Le vrai sujet n’est plus le nom dans le registre

Les précédentes publications consacrées à DFINFRA et à l’AS210860 ont établi une limite importante : voir le nom DFINFRA associé à un numéro de système autonome constitue un point de départ, non une preuve de contrôle. Un registre peut indiquer une identité administrative, un mainteneur ou une politique déclarée. Il ne montre pas nécessairement qui possède les routeurs, qui autorise une annonce, qui entretient une session de transit, qui détecte une panne ou qui décide d’un rétablissement.

Cette distinction devient plus importante lorsqu’on passe de la question « qui est associé à la ressource ? » à la question « qui peut en préserver la disponibilité ? ». La continuité d’un réseau n’est pas une propriété inscrite dans un champ d’annuaire. C’est une capacité observable : maintenir une visibilité de routage, disposer d’un chemin de repli, détecter une dégradation, exécuter une correction et confirmer que le service est redevenu accessible.

Pour l’AS210860, la recherche a donc été déplacée vers la mécanique de la panne et de la reprise. Les points d’observation pertinents comprennent l’historique de routage de RIPEstat, les mises à jour BGP, les préfixes annoncés, les voisins observés, les sondes RIPE Atlas, les données PeeringDB, les objets du RIPE Database et des sources de comparaison comme bgp.tools et CAIDA (historique de routage RIPEstat; mises à jour BGP RIPEstat; préfixes annoncés).

Mais la collecte effectuée dans cette enquête n’a pas capturé les réponses dynamiques de ces services. Il n’existe donc pas, dans le dossier présent, d’intervalle vérifié de retrait, de réannonce, de perte de sonde, de basculement entre fournisseurs ou d’impact au niveau d’un service. Cette absence est une limite de résultat, pas une preuve que rien ne s’est produit.

Cinq couches qui ne répondent pas à la même question

Une enquête de continuité devient fragile lorsque des couches de preuve différentes sont traitées comme si elles décrivaient le même état du réseau.

La première couche est registrale. L’objet aut-num peut aider à identifier le nom associé à AS210860, les contacts, les mainteneurs et les politiques d’importation ou d’exportation déclarées (objet aut-num du RIPE Database). Les objets route et route6 peuvent montrer quels préfixes sont autorisés dans l’IRR et quels mainteneurs les modifient (recherche des objets route et route6). Ces éléments peuvent orienter l’attribution administrative. Ils ne prouvent pas qu’un opérateur précis a manipulé une session BGP pendant un incident.

La deuxième couche est celle de la visibilité de routage. L’historique RIPEstat peut montrer les périodes pendant lesquelles des préfixes associés à AS210860 étaient visibles depuis des collecteurs participants (historique de routage RIPEstat). Une disparition synchronisée de plusieurs préfixes, suivie d’une réapparition, serait compatible avec une séquence de retrait et de réannonce. Elle ne suffirait toutefois pas à distinguer une maintenance, une panne d’amont, une session BGP défaillante, un filtrage ou une intervention volontaire.

La troisième couche est celle du plan de contrôle détaillé. Les mises à jour BGP peuvent fournir des horodatages de retraits et d’annonces, ainsi que des différences entre voisins (mises à jour BGP RIPEstat). Cette granularité permettrait de tester si une route est revenue par le même chemin ou par un autre ASN. Elle ne permettrait pas automatiquement de conclure que l’application ou le trafic utilisateur était rétabli au moment de la première réannonce.

La quatrième couche concerne l’accessibilité. IODA pourrait fournir un signal indépendant de visibilité BGP, de sondage actif ou de réponse réseau, sous réserve qu’il dispose d’une couverture suffisante pour l’AS210860 (signaux IODA pour l’ASN 210860). Les sondes RIPE Atlas pourraient ajouter une observation située dans le plan de données, si une sonde IPv4 ou IPv6 a effectivement été associée à l’ASN pendant la période considérée (sondes IPv4 RIPE Atlas; sondes IPv6 RIPE Atlas). Une sonde indisponible ne démontrerait pas, à elle seule, une panne de l’ensemble du système autonome.

La cinquième couche est opérationnelle et commerciale. Un avis de maintenance, un post-mortem, une modification de configuration, une page d’état ou un témoignage indépendant pourrait relier un événement de routage à une action attribuable. Une preuve de clients affectés, de dépendance ou de perte de service pourrait ensuite montrer la conséquence économique. Rien, dans les réponses capturées pour cette enquête, ne ferme cette dernière chaîne.

Ce que la continuité exigerait de démontrer

Le test le plus utile ne consiste pas à chercher une seule preuve spectaculaire. Il consiste à aligner des observations indépendantes dans le temps.

Première condition : identifier les préfixes réellement observés pour AS210860. Une liste de préfixes annoncés est un point de départ pour des requêtes plus étroites, mais leur présence dans un registre d’autorisation ne prouve pas qu’ils ont été annoncés à un moment donné (préfixes annoncés par RIPEstat; objets route et route6). L’enquête devrait préciser si l’événement concernait tout l’ASN, un seul préfixe ou une famille d’adresses.

Deuxième condition : établir une chronologie par collecteur. Les heures de disparition et de retour peuvent varier selon les points d’observation. Il faut donc conserver les différences entre collecteurs au lieu de les transformer en une heure mondiale unique. Une baisse observée par un collecteur n’est pas nécessairement une interruption mondiale.

Troisième condition : examiner les chemins. Les voisins ASN observés peuvent indiquer plusieurs voies de connectivité visibles (voisins ASN RIPEstat). Deux fournisseurs apparents pourraient constituer un mécanisme potentiel de résilience. Mais un voisin observé n’est pas forcément un fournisseur contractuel, et la présence d’un voisin ne prouve pas que le basculement a fonctionné. Il faudrait voir, dans les mises à jour horodatées, si les annonces ont réellement transité par une autre relation après la disparition du premier chemin.

Quatrième condition : confronter le contrôle et le trafic. Une réannonce BGP signifie que le plan de contrôle est de nouveau visible. Elle ne prouve pas que les paquets atteignent les équipements, que les réponses reviennent, que les applications fonctionnent ou que les clients ont récupéré leur service. C’est pourquoi un signal de routage devrait être comparé à une mesure de reachability ou à une observation de sonde.

Cinquième condition : attribuer la décision. Les données de registre, l’IRR et PeeringDB peuvent guider l’identification des personnes, organisations ou relations techniques à examiner. Elles ne suffisent pas à identifier celui qui a détecté, corrigé ou validé la reprise. Une preuve opérationnelle indépendante est nécessaire pour passer de la possibilité technique à la responsabilité démontrée.

La multiconnexion est une hypothèse, pas encore un résultat

Les sources publiques peuvent permettre de tester si l’AS210860 dispose de plusieurs relations externes. Les voisins RIPEstat, le profil PeeringDB, les inférences de CAIDA et les pages de comparaison comme bgp.tools peuvent être rapprochés (voisins ASN RIPEstat; profil PeeringDB; fiche CAIDA AS Rank; fiche bgp.tools; fiche Hurricane Electric).

Cette triangulation serait utile, mais elle ne doit pas être surinterprétée. PeeringDB est une base largement auto-déclarée et peut être incomplète ou périmée. Les relations déduites par un service peuvent différer des politiques déclarées ou des chemins visibles par un autre. Deux relations nominales ne garantissent pas deux chemins réellement disponibles, deux ports actifs, deux contrats de transit ou une capacité de basculement automatique.

Même lorsqu’une multiconnexion est établie, elle ne répond qu’à la question de la prévention possible. La reprise exige encore une détection, une décision, une politique d’annonce, une capacité de configuration et une vérification. Un réseau peut avoir deux fournisseurs et rester indisponible si les deux dépendent d’un même site, d’un même équipement, d’un même opérateur ou d’une même autorité de configuration.

La bonne conclusion est donc conditionnelle : la diversité des voisins pourrait être un mécanisme de continuité, mais aucune preuve capturée ici ne montre qu’un tel mécanisme a été utilisé avec succès pour AS210860 lors d’un événement défini.

RPKI : protection de l’origine, pas garantie de disponibilité

La RPKI occupe une place importante dans l’analyse des ressources Internet, mais son rôle doit rester précis. Une autorisation cryptographique peut indiquer quel ASN est autorisé à originer un préfixe. Elle peut réduire certains risques d’origines erronées ou d’annonces non autorisées. Elle ne garantit ni la disponibilité d’une route, ni la santé d’une session BGP, ni l’existence d’un chemin de secours, ni la capacité de l’opérateur à restaurer le service.

De même, une route autorisée dans l’IRR ne démontre pas qu’elle était annoncée. Une annonce observée ne démontre pas qui contrôlait le routeur. Une réannonce ne démontre pas que le trafic utilisateur circulait correctement. Chaque couche répond à une question différente et doit être reliée à la suivante par une observation datée (recherche RIPE des objets route; statut de routage et RPKI sur bgp.tools).

Cette séparation évite une erreur fréquente : transformer une propriété de sécurité du plan de contrôle en conclusion générale sur la résilience commerciale. La protection contre certaines annonces incorrectes est utile. Elle n’est pas un plan de reprise.

Ce que l’enquête établit aujourd’hui

Le résultat le plus solide est négatif mais exploitable. Les données disponibles établissent une architecture de vérification, pas un incident historique.

Elles permettent de dire que l’association DFINFRA–AS210860 mérite une vérification multi-couches. Elles permettent de préciser les sources à comparer : registre, IRR, historique BGP, mises à jour, préfixes, voisins, mesures de reachability, sondes et indices opérationnels. Elles permettent aussi de définir les contradictions attendues : les collecteurs peuvent diverger, les bases déclaratives peuvent être périmées et la visibilité du plan de contrôle peut revenir avant la disponibilité du service.

Elles ne permettent pas de dire qu’AS210860 a subi une panne à une date déterminée. Elles ne permettent pas de dire qu’un préfixe a été retiré puis réannoncé après un incident. Elles ne permettent pas de dire qu’un fournisseur a pris le relais, qu’une sonde a perdu puis retrouvé la connectivité ou qu’un client a subi une conséquence commerciale. Elles ne permettent pas non plus d’attribuer une action de prévention ou de réparation à DFINFRA.

Cette retenue n’annule pas la question économique. Elle la rend mesurable. Si un opérateur peut être relié à une capacité durable de publier, maintenir, modifier et retirer des routes, alors la continuité devient une capacité contrôlable. Si cette capacité peut ensuite être reliée à des clients, à une dépendance, à un prix ou à un flux de revenus, la portée commerciale devient démontrable. Avant ces deux raccordements, le registre reste un signal, et non une preuve de pouvoir opérationnel.

Le prochain test observable

La prochaine étape devrait être une enquête bornée dans le temps, et non une nouvelle lecture générale des registres. Il faut d’abord sélectionner un ou plusieurs préfixes effectivement associés à AS210860, puis interroger l’historique de routage et les mises à jour BGP sur une fenêtre étroite. Il faut conserver les horodatages par collecteur, identifier les retraits et les réannonces, puis comparer les chemins avant et après l’événement.

La même fenêtre devrait être confrontée à IODA et, lorsque la couverture existe, aux données RIPE Atlas. Une concordance entre perte de visibilité, perte de reachability et rétablissement ultérieur serait plus forte qu’un seul signal BGP. Elle ne deviendrait une preuve d’action opérationnelle qu’avec un élément attribuable : avis de maintenance, post-mortem, modification de politique, changement de configuration ou documentation indépendante.

Enfin, la question de la reprise doit être posée explicitement : qui avait la capacité de déclencher le changement, qui pouvait vérifier son effet et qui pouvait revenir à l’état précédent ? Tant que ces trois capacités ne sont pas reliées à un acteur identifiable, l’analyse peut décrire un mécanisme plausible, mais pas une chaîne de contrôle démontrée.

La conclusion actuelle est donc étroite : la continuité de l’AS210860 est testable par une combinaison de visibilité de routage, reachability, diversité des chemins et preuve opérationnelle. Elle n’est pas encore établie par les éléments capturés dans cette enquête.