Résumé

  • Les données d’enregistrement, les objets d’autorisation et la visibilité BGP décrivent des plans de responsabilité différents ; aucune de ces couches ne prouve seule qui possède les accès aux routeurs ou qui répond devant les abonnés.
  • Une route peut disparaître à la suite d’un retrait complet, d’une perte de sessions externes, d’un filtrage amont ou d’une origine invalide dans le RPKI. À l’inverse, un routage stable peut coexister avec une panne de transport, de DNS, d’authentification ou d’accès client.

Le premier problème est une chaîne d’identité incomplète

Les recherches antérieures sur INFINITYWIFI et AS210057 ont déjà établi une limite importante : le nom de l’entité du répertoire ne constitue pas, à lui seul, un pont documentaire vers le service Xfinitywifi de Comcast. Cette enquête ajoute une distinction opérationnelle. Même lorsqu’un ASN, une organisation enregistrée ou un objet de routage sont correctement associés, cela ne répond pas automatiquement à la question de savoir qui contrôle les équipements de production, les sessions BGP ou la relation avec les utilisateurs.

Le registre RDAP de RIPE NCC est la source primaire à consulter pour l’identité enregistrée, les entités liées, les avis et les dates d’événements associés à AS210057 (registre RDAP d’AS210057). L’objet aut-num et son historique peuvent exposer un nom de réseau, une organisation, des contacts, des mainteneurs et une politique déclarée (objet aut-num RIPE). Ces éléments peuvent soutenir une chronologie de responsabilité enregistrée. Ils ne démontrent toutefois pas que le mainteneur d’un objet dispose des identifiants nécessaires pour modifier un routeur de production.

Un attribut de maintenance montre une autorité de modification dans le registre. Il ne prouve ni la possession d’un équipement, ni l’existence d’une obligation contractuelle envers un client. Une société inscrite dans un registre peut également être différente d’une marque commerciale. C’est pourquoi un identifiant d’organisation, un numéro d’entreprise ou une adresse enregistrée devraient être recoupés avec une source corporative indépendante, et non déduits d’une ressemblance de nom (recherche corporative INFINITYWIFI).

Le deuxième problème est la différence entre autorisation et contrôle observé

Les objets route et route6 dont AS210057 est déclaré comme origine peuvent indiquer qui est autorisé à maintenir une politique de routage pour certains préfixes (recherche inverse des objets RIPE). Les données de préfixes annoncés (préfixes annoncés RIPEstat) et les observations publiques de bgp.tools complètent cette vérification. Ils ne prouvent pas qu’un préfixe est actuellement annoncé ou joignable. De même, une autorisation RPKI valide indique que le détenteur de la ressource a autorisé un ASN à l’originer ; elle constitue un contrôle préventif contre certaines annonces non autorisées, pas une garantie de disponibilité (données de couverture RPKI).

La différence devient concrète dans les scénarios de défaillance. Le retrait de tous les préfixes visibles d’AS210057, la perte de toutes les sessions BGP externes, un filtrage appliqué par un fournisseur amont ou une annonce rendue invalide par le RPKI peuvent provoquer une perte large ou sélective de connectivité. L’historique de routage peut montrer les périodes où les préfixes étaient visibles par les collecteurs RIPE RIS, ainsi que des changements d’origine ou de chemin (historique de routage RIPEstat). L’état BGP peut montrer les préfixes et chemins observés à un moment donné (état BGP RIPEstat).

Mais une disparition dans un collecteur n’est pas automatiquement une panne de l’opérateur : la maintenance d’un collecteur, une couverture limitée ou un événement très court peuvent produire un signal incomplet. Les voisins ASN observés peuvent aider à repérer une dépendance apparente ou une migration (voisins ASN RIPEstat). Ils ne suffisent pas à déterminer la nature commerciale d’une relation, ni à révéler un lien de secours inactif.

Le troisième problème est l’écart entre routage et service

Le BGP mesure une visibilité de routage, pas l’expérience de l’abonné. Une route peut rester stable alors que l’alimentation, le transport, le DNS, l’authentification, l’application ou le réseau d’accès sont défaillants. Les outils d’observation de l’Internet, notamment IODA et RIPE Atlas, peuvent fournir des signaux externes de reachability ou de récupération (IODA pour AS210057; sondes RIPE Atlas). Ils ne révèlent pas, à eux seuls, l’alerte interne, l’escalade, la cause racine ou la procédure de réparation.

Les archives RIPE RIS et RouteViews peuvent compléter l’analyse historique et comparer plusieurs points de vue (données RIPE RIS; archives RouteViews). Une route restaurée est un résultat externe. Elle ne prouve pas que l’incident a été compris, que le changement est documenté ou que le même mode de défaillance ne se reproduira pas. Aucun rapport d’incident propre à l’opérateur ni aucun postmortem n’a été vérifié dans le dossier de recherche utilisé ici.

Plusieurs fournisseurs ne prouvent pas plusieurs infrastructures

La présence de plusieurs ASN voisins peut soutenir l’hypothèse d’un multihoming logique. Elle ne prouve pas que les circuits utilisent des bâtiments, des routeurs, des fibres, des sources d’énergie ou des transporteurs de gros réellement indépendants. Les données de voisinage, les profils PeeringDB et les agrégateurs publics doivent donc être traités comme des indices complémentaires, pas comme une preuve de diversité physique (voisins ASN; profil PeeringDB; profil CAIDA AS Rank).

Une preuve de diversité physique demanderait des éléments de facility, de contrat ou d’ingénierie. Une modification du profil PeeringDB ou du registre après un incident prouverait une modification documentaire ; elle ne suffirait pas à établir que la faiblesse technique sous-jacente a été corrigée (profil de routage Cloudflare).

Ce que les données permettent actuellement de conclure

Le dossier public permet de définir un standard d’enquête, pas d’attribuer une identité définitive à INFINITYWIFI ou à l’opérateur actuel d’AS210057. Il permet aussi d’énumérer des mécanismes plausibles de perte de routage et des signaux à surveiller. Il ne contient pas de fenêtre d’incident datée, de mesure directe du service aux abonnés, de valeur actuelle des préfixes, de preuve d’une configuration RPKI courante ou de démonstration de redondance physique.

La conclusion la plus solide est donc bornée : la responsabilité enregistrée, le contrôle opérationnel visible dans le routage et la continuité de bout en bout sont trois propositions liées mais non équivalentes. Une observation dans le premier plan ne peut pas être créditée comme preuve dans le suivant. Les registres de membres et les programmes de bonnes pratiques peuvent fournir un contexte institutionnel, mais leur présence ou leur absence ne remplace pas les preuves propres à AS210057 (liste des membres RIPE NCC; participants MANRS).

La réparation doit être observable dans le temps

Une continuité durable demanderait la persistance de plusieurs signaux : visibilité après incident par des chemins indépendants, autorisations RPKI valides, objets IRR exacts, tests de basculement réussis et mesures séparées au niveau DNS, authentification, application et accès client. Aucun de ces éléments ne suffit seul. La valeur probante vient de leur cohérence dans le temps, avec des dates, des préfixes, des chemins et des résultats comparables.

Cette exigence protège aussi contre une erreur de gouvernance. Si un opérateur est récompensé pour un ASN visible, un registre à jour ou un nombre de fournisseurs déclaré, il peut satisfaire l’indicateur sans démontrer la continuité ressentie par l’utilisateur. Le contrôle pertinent est donc la chaîne complète : identité attribuable, autorisation correcte, routage observable, service mesuré, réponse documentée et récupération durable.