Résumé

  • Les objets RIPE et RDAP peuvent établir ce qui est enregistré au sujet d’AS210833, mais pas qui détient actuellement les identifiants des routeurs ni qui assure chaque opération quotidienne.
  • Les politiques déclarées, les observations BGP, les autorisations RPKI et les relations de transit répondent à des questions différentes ; leur concordance répétée dans le temps serait nécessaire pour parler prudemment de gestion opérationnelle.

Une identité de registre n’est pas une preuve d’exploitation

Le nom Florian Bauer apparaît dans les données publiques associées à l’aut-num AS210833, dont le nom d’AS est Florian-Bauer. Le registre RIPE permet d’examiner les champs d’identité, l’organisation liée, les contacts, les mainteneurs, le statut et les événements de modification de l’objet. Le service RDAP fournit une représentation structurée complémentaire de cette inscription.

Ces documents sont importants parce qu’ils indiquent quelle identité est publiée comme responsable ou associée à la ressource. Ils ne démontrent toutefois ni l’accès aux routeurs, ni le contrôle des comptes d’administration, ni l’existence d’un contrat de transit, ni la continuité d’une activité opérationnelle. Un mainteneur indique le compte autorisé à modifier un objet de registre ; il ne prouve pas que cette personne contrôle encore les équipements ou les décisions de routage.

Le premier niveau de conclusion doit donc rester étroit : AS210833 est listé dans les bases consultées avec une association publique à Florian Bauer et à FSRV. La formulation « le registre liste » est plus exacte que « Florian Bauer contrôle le réseau ».

Objet aut-num RIPE pour AS210833 et fiche RDAP de l’AS210833 peuvent être comparés pour repérer les différences de présentation, les événements de modification et les rôles des entités. Une mise à jour administrative récente ne constituerait pas, à elle seule, la preuve d’un changement de routage récent.

La politique annoncée décrit une intention, pas une session active

Les objets route6 associés à l’origine AS210833 peuvent indiquer quels préfixes sont déclarés comme devant être originés par cet AS, ainsi que les mainteneurs et les politiques de routage enregistrés. Ils décrivent une intention de routage dans un registre. Ils ne suffisent pas à établir que les routes étaient annoncées au moment considéré, qu’elles étaient visibles partout ou qu’elles restaient valides sous RPKI.

La même distinction vaut pour PeeringDB. Une fiche réseau peut présenter le nom FSRV, le site web, le type de réseau, la politique de routage ou une politique générale de peering ouverte. Une politique ouverte signifie que l’opérateur se déclare disposé à échanger du trafic selon ses conditions techniques ; elle ne prouve pas qu’une session BGP particulière est établie, qu’un port d’échange transmet actuellement des paquets ou qu’un fournisseur de transit est redondant.

Les données PeeringDB sont donc utiles pour documenter une déclaration de l’opérateur et pour identifier des canaux publics de contact. Elles doivent être confrontées à des observations de routage et aux données des opérateurs d’échange lorsqu’une affirmation sur la connectivité active est nécessaire.

L’inverse search RIPE des objets route6, la fiche réseau PeeringDB et les enregistrements PeeringDB des exchange LAN fournissent les points de comparaison appropriés. Un accord entre ces sources montrerait une cohérence documentaire, non une preuve complète de maîtrise opérationnelle.

Voir une route n’est pas mesurer toute la joignabilité

Les services RIPEstat, bgp.tools, BGPView et Hurricane Electric peuvent fournir des observations bornées dans le temps et dépendantes de leurs collecteurs. Ils peuvent montrer si AS210833 a été observé comme origine, quels chemins ont été vus, quels changements ou retraits ont été enregistrés, et quelle visibilité les collecteurs ont mesurée.

Cette couche répond à une question différente : que le plan de contrôle a-t-il exposé à certains observateurs ? Elle ne répond pas automatiquement à la question de savoir si chaque hôte situé dans un préfixe était joignable, si une session privée existait, si le trafic passait réellement ou si les chemins observés étaient physiquement indépendants.

L’aperçu RIPEstat de l’AS et la liste des préfixes annoncés dans RIPEstat peuvent servir à vérifier les annonces observées au moment d’une nouvelle collecte. L’état BGP RIPEstat permet d’examiner les chemins vus par les collecteurs. Les mises à jour BGP, l’historique de routage et la visibilité RIPEstat permettent de rechercher des retraits, des changements de chemin ou des variations simultanées entre plusieurs préfixes.

Les résultats devraient toujours être datés. Une disparition observée par un seul collecteur peut correspondre à une réinitialisation de session du collecteur plutôt qu’à une panne d’origine. Un retour d’annonce montre une récupération du plan de contrôle telle qu’elle a été vue, mais ne prouve pas une récupération du service applicatif.

L’interface bgp.tools pour AS210833, les upstreams indiqués par BGPView et la vue Hurricane Electric de l’AS peuvent fournir des recoupements. Ils ne doivent pas être traités comme trois mesures indépendantes lorsque l’un de ces services réutilise des données de registre ou de PeeringDB.

RPKI : une autorisation cryptographique, pas une garantie de service

La validation RPKI porte sur une relation précise entre un préfixe et un AS d’origine. Une ROA valide peut autoriser AS210833 à annoncer un préfixe jusqu’à une longueur maximale donnée. Une annonce qui correspond à cette autorisation peut être classée Valid ; une absence de couverture peut produire NotFound ; une origine différente ou une longueur excessive peut produire Invalid, selon le jeu de données et le validateur consultés.

Cette autorisation ne démontre pas que le préfixe est actuellement annoncé, qu’il est visible par tous les réseaux, que les paquets atteignent les hôtes ou que la personne nommée dans le registre possède la ressource d’adresses. L’émetteur de la ROA peut être le détenteur certifié des ressources, un fournisseur ou un LIR qui n’est pas identique à l’opérateur du système autonome.

La vue de validation RPKI pour AS210833 et la documentation RIPE sur la gestion RPKI donnent le cadre pour effectuer cette vérification. Chaque préfixe pertinent devrait être contrôlé à une date précise, puis comparé aux annonces BGP observées à la même période.

La dépendance se déduit d’une répétition, pas d’un seul chemin

Si plusieurs préfixes présentent régulièrement le même dernier AS en amont dans les chemins observés, cela peut signaler une concentration de dépendance dans le plan de contrôle. Plusieurs derniers AS distincts peuvent suggérer une diversité de chemins. Ni l’un ni l’autre ne prouve toutefois une diversité physique, géographique ou contractuelle.

Un échange Internet peut aussi apparaître dans un enregistrement PeeringDB sans qu’une session bilatérale active ou un flux de trafic soit démontré. À l’inverse, une interconnexion privée peut ne pas apparaître dans les données publiques. La bonne conclusion est donc conditionnelle : les sources publiques peuvent indiquer une dépendance déclarée ou observée, mais elles ne permettent pas nécessairement d’identifier la totalité des fournisseurs, des liens de secours ou des responsabilités contractuelles.

Pour déterminer qui peut détecter et corriger une panne, il faut rapprocher plusieurs éléments : les contacts publiés, les changements de registre, les retraits BGP, l’évolution de la visibilité, la validation RPKI et les explications données lors d’un incident. Une adresse de contact prouve l’existence d’un canal de signalement ; elle ne prouve pas un délai de réponse ni une capacité de rétablissement.

Ce que la recherche permet et ne permet pas aujourd’hui

Les sources réunies pour cette analyse constituent une architecture de vérification reproductible : registre, RDAP, objets route6, observations RIPEstat, validateurs RPKI, PeeringDB et agrégateurs BGP. La récupération directe en temps réel n’a pas été disponible pour cette analyse. Il est donc impossible d’affirmer ici l’état actuel des préfixes, des chemins, des upstreams, des présences dans les échanges ou des validations RPKI.

Cette limite est importante mais bornée. Elle ne prouve ni l’absence de routage, ni l’invalidité d’une ROA, ni l’inactivité d’AS210833, ni l’absence de stewardship. Elle empêche seulement de transformer des points d’accès documentaires en constat présent au moment de la publication.

La prochaine collecte utile devrait enregistrer la date et l’heure de chaque réponse, comparer l’aut-num RIPE au RDAP, confronter les objets route6 aux origines BGP, vérifier chaque préfixe dans plusieurs collecteurs, examiner les retraits et récupérations, puis comparer les déclarations PeeringDB avec les données des échanges et des route-servers. La question pertinente n’est pas seulement « qui est nommé ? », mais « quelles traces répétées relient cette identité à une capacité observable de maintenir, expliquer et rétablir le service ? »

Sources et méthode

Pour le contexte du sujet, voir aussi la fiche Florian Bauer dans le répertoire BTW.