Résumé

  • Les données publiques séparent au moins sept questions : attribution du numéro autonome, maintenance de l’objet de registre, autorisation d’origine, visibilité du routage, contrôle opérationnel, responsabilité contractuelle et droit au recours.
  • Les éléments disponibles ne démontrent pas quelle personne ou entité peut effectivement modifier le comportement de routage ou répondre d’un service, ni un lien établi avec Comcast ou Xfinity WiFi.

Le nom INFINITYWIFI ne suffit pas à établir une identité juridique. Pour analyser AS210057, la première étape consiste à vérifier le service RDAP compétent à partir du registre d’amorçage de l’IANA, puis à examiner l’objet actuel de l’ASN auprès du RIPE NCC. Ces instruments peuvent montrer le service de registre, le libellé de l’ASN, les entités liées, les contacts, les mainteneurs et les dates de modification. Ils ne prouvent pas, à eux seuls, qui exploite quotidiennement les routeurs ou qui doit répondre à un client. Registre d’amorçage RDAP de l’IANA ; objet RDAP du RIPE NCC pour AS210057 ; objet aut-num natif.

Cette distinction est essentielle parce que plusieurs formes d’autorité sont souvent confondues. Un enregistrement administratif décrit ce que le registre associe à une ressource. Un champ de mainteneur indique qui est autorisé à modifier un objet dans la base, non pas nécessairement qui possède l’infrastructure, vend l’accès ou exploite le réseau. L’historique des versions peut établir qu’un objet a changé, mais un changement de base ne prouve pas qu’un contrôle physique ou commercial a changé le même jour. Interface de recherche RIPE ; historique des versions de l’objet ; documentation de la base RIPE.

La deuxième couche concerne les ressources et les routes. Un objet IRR peut formuler une assertion de politique indiquant qu’AS210057 est une origine prévue pour un préfixe. Une ROA RPKI peut fournir une autorisation cryptographique pour une paire préfixe-origine, selon le préfixe, l’origine et la date examinés. Ni l’une ni l’autre ne démontre seule qui configure les routeurs, qui transporte le trafic ou qui a conclu un contrat de service. Les statistiques d’allocation peuvent corroborer un attribut administratif, mais elles n’identifient pas nécessairement le détenteur juridique ou l’opérateur. Statistiques déléguées du RIPE NCC ; recherche inverse des objets de route RIPE ; guide RIPE sur le RPKI ; RFC 6482 sur les ROA.

La troisième couche est l’observation. RIPEstat, RIPE RIS et Route Views peuvent indiquer ce qu’un collecteur a vu, depuis certains points de mesure et pendant une période donnée. Une origine BGP observée est donc une preuve d’apparition dans le routage, pas une preuve complète d’autorisation, de propriété ou de responsabilité envers les utilisateurs. L’observation doit être horodatée, comparée entre collecteurs et séparée de toute conclusion sur la continuité du service. Vue d’ensemble RIPEstat ; données WHOIS dérivées ; préfixes annoncés ; état du routage ; état BGP ; historique du routage ; historique RPKI ; données RIPE RIS ; archives Route Views.

La quatrième couche est l’identité opérationnelle. Les profils publics de réseau et les bases de peering peuvent fournir des indices sur une présence déclarée ou des relations techniques. Ils ne désignent pas nécessairement l’acteur qui peut initier, modifier ou inverser une annonce. De même, un contact d’abus peut constituer une voie de signalement pour un trafic malveillant ou une suspicion d’abus de route, sans être un service client, un décideur de rétablissement ou une partie au contrat. Profil réseau PeeringDB ; profil public BGP.tools ; résolution de contact d’abus RIPEstat ; coordonnées du RIPE NCC ; procédure d’abus du RIPE NCC.

Le recours doit suivre la proposition qui a réellement échoué. Si l’erreur porte sur un nom, une organisation ou un contact dans la base, le premier chemin est une correction auprès du mainteneur autorisé ou du support de la base RIPE. Si le problème porte sur une origine de route, il faut comparer l’objet IRR, la validation RPKI, les observations des collecteurs et les données du détenteur du préfixe. Une alerte envoyée à un contact d’abus peut accélérer l’escalade technique, mais elle ne crée pas à elle seule une obligation de restaurer une connexion.

Si la question est celle d’une interruption de service, le recours dépend d’un élément qui n’est pas fourni ici : un contrat, une facture, un compte client, une plainte documentée ou une règle applicable à la relation concernée. Les procédures d’Ofcom et les règles britanniques sur les communications électroniques peuvent être pertinentes dans certaines situations, mais elles ne prouvent ni la juridiction applicable ni l’existence d’une relation entre INFINITYWIFI, AS210057 et un utilisateur donné. Recherche du registre britannique des sociétés ; plainte auprès d’Ofcom ; conditions générales des communications électroniques d’Ofcom ; cadre législatif britannique ; indemnisation automatique selon Ofcom.

Rien dans les éléments réunis n’établit un pont d’identité vérifié entre INFINITYWIFI, AS210057 et Comcast ou Xfinity WiFi. La similarité des noms ne permet donc pas d’attribuer une clientèle, une infrastructure, un revenu ou une obligation de service. Le registre britannique recherché ne remplace pas une preuve de constitution, de contrôle ou de contrat ; l’absence d’un résultat exploitable dans le paquet ne permet pas non plus de conclure qu’aucune entité pertinente n’existe.

La conclusion est procédurale. Pour attribuer un incident, il faut relier une date, un préfixe ou un service à un acteur identifié, puis sélectionner l’instrument qui correspond à la défaillance : correction de registre, escalade technique, contestation d’autorisation, plainte contractuelle ou recours réglementaire. Tant que la personne ou l’entité capable de modifier le routage ou d’assumer le service n’est pas nommée par une preuve indépendante, AS210057 reste une trace technique et administrative, non une chaîne complète de responsabilité.

Sources et limites

Les sources publiques pertinentes comprennent également le registre des autorisations d’origine annoncées, les données de statut BGP, les documents RIPE-679, les documents RIPE-679, les documents RIPE-682 et la documentation de contact RIPE. Le paquet de recherche indique que sa synthèse n’a pas procédé à une nouvelle vérification en direct des points terminaux ; les affirmations sur l’état actuel des champs, contacts, préfixes et mainteneurs doivent donc rester limitées à ce que montrent exactement les instantanés immuables correspondants.