Pourquoi un réseau en état de marche peut-il disparaître lorsque les données du registre changent ?

Imaginez que votre service fonctionne toujours depuis une connexion mobile, mais que les clients d’un autre réseau ne puissent plus y accéder. Les serveurs sont en bon état. Les câbles sont branchés. Une explication possible est qu’un autre réseau a cessé d’accepter la route vers vos adresses à la suite de la modification d’un enregistrement.

Le chaînon manquant est la décision qui intervient entre l’enregistrement et le routeur. Une modification de base de données peut affecter la connectivité lorsqu’un système s’en sert pour construire un filtre ou évaluer une annonce. Pour comprendre la panne, suivez cette chaîne. « Le registre est erroné » n’est que le début du diagnostic.

Les connexions physiques peuvent rester intactes lorsqu’une modification d’enregistrement affecte l’acceptation des routes. Examinez les preuves et la politique du réseau qui reçoit l’annonce.

Commencez par identifier l’enregistrement modifié

Un préfixe IP est un bloc d’adresses. Un numéro de système autonome, ou ASN, identifie un réseau qui échange des routes avec d’autres réseaux. BGP est le protocole utilisé par ces réseaux pour annoncer les destinations qu’ils peuvent atteindre.

Plusieurs types d’enregistrements accompagnent ces échanges. Ils répondent à des questions différentes :

• Données d’enregistrement : quelle organisation est associée à un bloc d’adresses, et qui contacter. La documentation de la base de données RIPE distingue l’enregistrement des ressources, les informations de routage et les fiches de contact, même s’ils partagent une même base de données.
• Enregistrements des registres de routage Internet (IRR) : des informations que les opérateurs peuvent utiliser pour établir des listes de routes qu’ils accepteront. Un enregistrement décrit le routage prévu ; il n’annonce pas lui-même une route.
• Enregistrements de l’infrastructure à clés publiques des ressources (RPKI) : ils comprennent des autorisations signées d’origine de route, appelées ROA, à partir desquelles les validateurs produisent des données permettant de vérifier le réseau d’origine et la longueur de préfixe autorisée.

Une adresse électronique de contact obsolète ne retire pas directement une route BGP. Une route absente du filtre généré par un fournisseur peut empêcher celui-ci de l’accepter. Qualifier ces deux situations de « données de registre invalides » masque la différence essentielle.

Comment un enregistrement aboutit au rejet d’une route

Prenons un fournisseur qui construit les filtres de ses clients à partir des données IRR. Voici un enchaînement possible menant à une panne :

1. Un enregistrement de route est supprimé, ou l’ensemble de routage du client ne l’inclut plus.
2. Lors de la prochaine génération des filtres du fournisseur, cette route est omise.
3. Le nouveau filtre est déployé sur les routeurs du fournisseur, qui rejettent l’annonce du client.
4. S’il ne reste aucune solution de rechange utilisable, les personnes qui dépendent de ce chemin perdent l’accès.

Pour que cet enchaînement se produise, les données doivent réellement alimenter le filtre. La politique publiée par NTT DATA concernant les registres de routage fournit un exemple concret de filtres clients fondés sur les IRR et de mises à jour automatisées. Elle décrit également le rejet des routes à l’état RPKI Invalid et l’exclusion des enregistrements IRR contradictoires. Il s’agit de mécanismes opérationnels identifiables, pas d’un interrupteur universel dont disposerait le registre.

Ce que signifie réellement l’état RPKI « Invalid »

Pour valider l’origine, la route annoncée est comparée aux données d’autorisation validées. La RFC 6811 définit trois résultats :

• Valid : au moins une autorisation couvrant la route correspond à l’ASN d’origine et permet la longueur du préfixe annoncé.
• Invalid : des données d’autorisation couvrant la route existent, mais aucune ne satisfait les deux conditions.
• NotFound : aucune donnée d’autorisation ne couvre la route.

Par exemple, une route annoncée par le réseau A peut passer à l’état Invalid si l’autorisation qui lui correspond disparaît alors qu’une autorisation couvrant la route pour le réseau B subsiste. S’il ne reste aucune autorisation couvrant la route, le résultat est alors NotFound. Ici, « Invalid » est un résultat de validation du routage, pas un verdict sur la propriété ou la légitimité institutionnelle. La validation de l’origine n’authentifie pas non plus l’intégralité du chemin qu’une route déclare avoir suivi.

L’étape suivante dépend de la politique configurée par l’opérateur. La RFC 8481 distingue l’attribution d’un état de validation de l’action qui en découle : la politique doit être configurée par l’opérateur. Un réseau configuré pour rejeter les routes Invalid peut alors rejeter cette annonce. Une modification du registre et un rejet sont reliés par ces mécanismes ; ce ne sont pas le même événement.

Pourquoi certaines personnes perdent l’accès avant d’autres

Les réseaux n’utilisent pas tous les mêmes filtres, les mêmes fournisseurs ni les mêmes données au même moment. La RFC 7115 explique que les caches RPKI peuvent avoir des vues différentes et qu’aucun délai unique d’arrivée des mises à jour sur les routeurs n’est garanti.

Dans l’exemple initial, un réseau peut avoir déjà agi sur la base des données modifiées tandis qu’un autre dispose encore d’un chemin accepté. Une panne partielle est donc possible. Cela ne prouve pas que le registre soit à l’origine d’une panne particulière : les ingénieurs doivent encore examiner la route touchée, les données utilisées et la décision qui a conduit à son rejet.

Repérez le maillon défaillant avant de multiplier les modifications

La question utile pour rétablir le service est précise : quel système a cessé d’accepter quelle annonce, et pourquoi ? Un opérateur peut l’examiner avec son fournisseur :

1. Identifier l’annonce. Relever le préfixe concerné et l’ASN d’origine, puis vérifier si la route attendue est toujours annoncée.
2. Localiser le rejet. Comparer à la route le filtre installé chez le fournisseur et le résultat de validation. Demander quelle source de données et quelle mise à jour ont produit cette décision.
3. Conserver les preuves. Garder les enregistrements, observations et horodatages pertinents afin de distinguer une mise à jour erronée d’une annonce non autorisée.
4. Corriger et vérifier. Coordonner la correction précise de l’enregistrement ou de la configuration, confirmer qu’elle est parvenue aux systèmes qui l’utilisent et tester l’accès depuis les réseaux touchés.

Désactiver la validation partout supprimerait aussi la protection contre les annonces incorrectes. Le travail opérationnel consiste à rétablir des preuves exactes et le routage prévu, puis à vérifier le résultat. La réussite d’une modification dans la base de données ne suffit pas à démontrer que les clients peuvent de nouveau se connecter.

Le problème de fond : des preuves utiles peuvent concentrer le pouvoir

C’est ici que la chaîne technique rejoint l’argument de Lu Heng. Un administrateur n’a pas besoin d’acheminer les paquets de quiconque pour influer sur son accessibilité. Si d’autres systèmes dépendent des données qu’il contrôle, ses décisions peuvent imposer aux opérateurs et aux clients des coûts qui dépassent largement le cadre de son bureau.

Dans la Note 65, La primauté du code opérationnel, Lu Heng soutient que la coordination doit rester limitée par les besoins des réseaux en fonctionnement. Un rôle de tenue des données ne peut s’étendre de lui-même en un mandat politique permanent. Le fait qu’un enregistrement soit signé répond à une question technique sur l’assertion qu’il contient ; il n’établit pas un droit de gouverner toutes les personnes qu’il affecte.

Sa proposition va au-delà d’une meilleure procédure de réclamation. Les règles communes doivent protéger l’unicité, le contrôle vérifiable et l’interopérabilité, tandis que les participants valident l’état localement et décident des changements compatibles qu’ils souhaitent adopter. Un nouveau comité doté d’un droit de veto illimité reproduirait le problème sous un autre nom.

La continuité exige une voie de sortie utilisable par les autres réseaux

Une solution de remplacement utilisable doit préserver des données fiables, les assertions de sécurité et les relations opérationnelles. Les autres réseaux doivent pouvoir vérifier ces données et les utiliser. Copier simplement une base de données ne les amène pas à accepter un remplaçant, et déclarer son indépendance ne rétablit pas une route rejetée.

La Note 72 explicite le résultat recherché : des données exactes, la continuité opérationnelle et une capacité réelle à quitter un coordinateur défaillant. Le défi pratique consiste à créer cette capacité sans perdre l’unicité partagée et la compatibilité qui permettent aux réseaux indépendants de communiquer.

Le guide sur l’export de l’état d’un registre explore la préservation et le transfert des données dans ce travail. Il s’agit d’une composante de la transition, aux côtés de la vérification, de l’adoption par les opérateurs et des tests de continuité.

Préparez-vous tant que le service fonctionne encore

Demandez à votre équipe de suivre un bloc d’adresses important, depuis ses enregistrements jusqu’aux fournisseurs et aux clients qui en dépendent. Qui peut modifier chaque enregistrement ? Qui l’utilise ? Comment une erreur serait-elle corrigée si l’administrateur actuel était indisponible ou contesté ?

Établir ces réponses entre plusieurs organisations prend du temps. Les trouver avant une défaillance laisse une marge de manœuvre ; les découvrir pendant une panne en fait supporter le coût aux clients. L’urgence est de construire une indépendance concrète tant que la continuité peut encore être préservée.

Poursuivez avec la Note 65 : La primauté du code opérationnel pour suivre l’argumentation complète de Lu Heng en faveur d’une coordination fondée sur les réseaux en fonctionnement, la vérification locale et l’adoption volontaire.