IBM Cloud en 2020 : l’afflux de routes erronées met en lumière les responsabilités entre opérateurs

Résumé

IBM a déclaré qu’un fournisseur de réseau extérieur avait transmis à IBM Cloud des informations de routage incorrectes, ce qui avait engorgé son réseau et perturbé des services ainsi que des centres de données.
Zello a documenté des échecs de connexion et de reconnexion, l’interruption de communications déjà établies, l’indisponibilité de consoles d’administration et quatre services touchés ; CRN a recueilli d’autres signalements de clients et de partenaires.
La responsabilité se joue dans la capacité d’IBM à filtrer, surveiller et rétablir les routes reçues, dans la qualité des routes envoyées par le fournisseur et dans l’existence de moyens d’administration et d’information qui ne dépendent pas tous du même chemin réseau.

Une panne visible bien au-delà d’un seul tableau de bord

Le 9 juin 2020, une interruption étendue du réseau d’IBM Cloud est devenue visible vers 14 h 30, heure du Pacifique. TechCrunch a alors constaté que des services hébergés étaient touchés et que la principale page d’état d’IBM renvoyait elle-même une erreur interne. Ce dernier point a une portée opérationnelle particulière : lorsqu’un client ne peut plus atteindre ni son service ni la page censée expliquer la panne, il perd à la fois un outil de travail et une source d’orientation.

Les heures publiées décrivent des observations faites depuis des positions différentes. Elles ne permettent pas de fixer une heure unique à laquelle chaque service, chaque région et chaque client aurait cessé de fonctionner ou serait revenu à la normale. Une chronologie sérieuse doit donc conserver l’auteur de chaque constat, le système observé et l’heure associée, au lieu de fondre plusieurs expériences dans un seul intervalle.

IBM a ensuite attribué l’incident à un fournisseur de réseau extérieur qui aurait envoyé à IBM Cloud un afflux d’informations de routage incorrectes. Selon la déclaration d’IBM conservée par la presse, ces informations ont provoqué une forte congestion, c’est-à-dire un engorgement du réseau qui empêche le trafic légitime de circuler normalement. IBM a indiqué que des services cloud et des centres de données avaient été affectés.

Cette attribution est la meilleure explication publique disponible, mais elle reste une déclaration d’IBM. Aucun journal privé de routeur n’est publié dans le dossier étudié. Le fournisseur n’est pas nommé, et les éléments publics ne donnent ni le réseau autonome d’origine, ni les routes précises, ni le code de politique qui aurait produit ou accepté ces informations.

Comment une information de route peut rendre un service inaccessible

Sur Internet, le Border Gateway Protocol (BGP) est le protocole par lequel de grands réseaux administrés séparément s’indiquent les chemins qu’ils proposent pour joindre des destinations. Deux routeurs qui échangent ces informations entretiennent une session BGP, autrement dit une relation configurée entre voisins. Chaque message utile contient notamment une annonce de route, soit l’indication qu’un réseau sait acheminer le trafic vers une destination donnée.

Cette destination est souvent exprimée sous la forme d’un préfixe réseau, un bloc d’adresses partageant le même début. IPv4, la quatrième version du protocole Internet encore très utilisée, représente ces adresses sur 32 bits. Lorsqu’un routeur reçoit plusieurs possibilités, sa politique de routage — l’ensemble des règles qui déterminent les chemins acceptés, préférés ou retransmis — choisit la route que le trafic empruntera.

Une mauvaise information ne détruit pas forcément le serveur visé. Elle peut plutôt détourner les paquets vers un chemin qui ne mène pas à leur destination ou qui ne dispose pas d’une capacité suffisante. La joignabilité désigne précisément cette possibilité d’atteindre un service depuis un point donné. Un serveur peut donc continuer à fonctionner tout en devenant injoignable pour ses utilisateurs ou en envoyant ses réponses au mauvais endroit.

Zello a décrit ce second mécanisme depuis la position d’un client affecté. Son compte rendu fait état de nombreuses routes injectées qui ont conduit des serveurs hébergés chez IBM Cloud à diriger du trafic IPv4 sortant vers des destinations incorrectes. Cette observation n’identifie pas le routeur fautif et ne révèle pas les routes concernées, mais elle relie un comportement de routage à un effet concret sur les communications du client.

Les effets décrits par Zello et par les partenaires d’IBM

Zello a recensé des échecs de connexion et de reconnexion à grande échelle. Des utilisateurs déjà connectés ont perdu leurs communications, les consoles d’administration sont devenues indisponibles et quatre services de l’entreprise ont été touchés. Ce témoignage apporte une granularité que le message général d’un fournisseur cloud ne peut pas offrir : il distingue l’accès initial, le maintien d’une session, la communication en cours et les outils employés par les opérateurs du client.

CRN a également rapporté que des clients et partenaires ne pouvaient plus accéder à certains environnements, consoles et écrans d’état. Le média a indiqué que les équipes réseau d’IBM avaient modifié des politiques de routage pendant le rétablissement. Il s’agit d’une mesure rapportée par la presse, et non d’un relevé public de chaque modification appliquée.

Pris ensemble, ces constats montrent plusieurs formes d’indisponibilité sans fournir un dénominateur complet. Le dossier public ne permet pas de compter tous les clients, régions, transactions ou pertes éventuelles. Il ne permet pas non plus de conclure que chaque service a subi le même mécanisme au même moment.

Ce qu’IBM a affirmé après le rétablissement

IBM a déclaré avoir rétabli les services et pris des mesures d’atténuation. L’entreprise a aussi indiqué que son travail d’analyse des causes profondes n’avait mis en évidence ni perte de données ni problème de cybersécurité. Ces deux constats doivent rester attribués à IBM : ils ne valent pas audit indépendant de l’état de chaque client.

L’absence de problème de cybersécurité signalé par IBM ne transforme pas automatiquement l’événement en preuve d’une attaque. Les sources publiques n’établissent ni détournement malveillant de routes, ni attaque distribuée par déni de service (DDoS), une opération dans laquelle de nombreuses machines envoient du trafic pour saturer une cible. Elles n’établissent pas davantage un sabotage, une compromission ou une intention malveillante.

De même, les mesures historiques annoncées ne prouvent pas la robustesse actuelle du réseau. Leur contenu détaillé, leur périmètre, leur déploiement et leur efficacité présente ne sont pas documentés dans les éléments publics examinés. Une appréciation honnête s’arrête donc à ce qu’IBM a dit avoir fait en 2020.

La frontière d’interconnexion partage les actions, pas nécessairement les torts

La frontière entre IBM Cloud et le fournisseur extérieur est le point opérationnel où un réseau envoie des routes et où l’autre décide lesquelles accepter. Le fournisseur maîtrise la construction et l’envoi de ses propres annonces. IBM maîtrise les règles appliquées à l’entrée de son réseau, les alertes qu’il associe à ces règles et les changements qu’il autorise dans son environnement.

Cette répartition technique ne révèle pas le partage contractuel des obligations. Les documents publics ne disent pas quelle entité devait filtrer telle route, surveiller tel seuil, avertir telle équipe ou retirer une annonce dans un délai donné. Ils ne permettent donc pas de conclure à une faute contractuelle, une négligence, une violation réglementaire, un dommage juridique ou une responsabilité individuelle.

La bonne question opérationnelle consiste à identifier une action et son détenteur. Le fournisseur peut vérifier les routes avant de les envoyer et retirer celles qu’il sait incorrectes. IBM peut définir ce que ses routeurs acceptent, repérer un écart et isoler une interconnexion. Les deux organisations peuvent conserver des preuves horodatées et maintenir un chemin d’escalade commun. Ce sont des possibilités de conception et de gouvernance, pas la description certaine de leur configuration en 2020.

La RFC 7454 indique des pratiques, pas la configuration de 2020

La RFC 7454 rassemble des recommandations de sécurité pour les échanges BGP entre réseaux. Elle décrit des politiques de bordure, le filtrage entrant et sortant des préfixes ainsi que des plafonds de préfixes propres à chaque voisin. Un plafond de préfixes fixe le nombre de blocs d’adresses qu’un routeur est prêt à recevoir d’un voisin avant d’appliquer le comportement prévu par l’opérateur.

Le filtrage entrant permet au réseau récepteur de refuser des annonces qui ne correspondent pas à ses attentes. Le filtrage en amont, effectué par le réseau émetteur avant l’envoi, peut empêcher qu’une route manifestement indue atteigne le voisin. Aucun de ces mécanismes n’est une garantie absolue : une règle obsolète, une attente mal définie ou une route plausible mais incorrecte peut encore passer.

Surtout, la RFC ne prouve pas qu’IBM ou le fournisseur non nommé avait configuré tel filtre ou tel plafond en juin 2020. Elle offre un cadre pour poser des questions prospectives et vérifier une architecture future. La présenter comme un relevé de la configuration de l’incident effacerait précisément ce que les sources laissent inconnu.

Le rétablissement doit être démontré depuis plusieurs points

Après une modification de route, les routeurs mettent un certain temps à adopter un nouvel état cohérent. Cette convergence du routage ne se mesure pas par un seul voyant vert : il faut observer si les utilisateurs atteignent de nouveau le service, si les réponses suivent un chemin valide et si les opérateurs disposent encore de leurs outils.

Le plan d’administration regroupe les consoles, accès et fonctions utilisés pour exploiter le service, par opposition au chemin emprunté par l’utilisateur ordinaire. S’il dépend de la même interconnexion que l’application, l’équipe peut perdre son principal moyen d’intervention au moment où elle en a le plus besoin. Un accès d’administration de secours sur un chemin séparé, accompagné d’un canal d’état indépendant, réduit cette dépendance commune.

Pour chaque service, l’exploitant peut donc cartographier trois parcours : celui des utilisateurs, celui des administrateurs et celui des messages d’état. Lorsque ces trois parcours partagent le même point de défaillance, un incident unique peut les interrompre ensemble. Les séparer ne garantit pas l’absence de panne, mais donne aux équipes davantage de moyens pour comprendre la situation et agir.

La fin de l’incident ne devrait pas être décidée à partir d’un seul test interne. Des vérifications distinctes peuvent confirmer l’accès utilisateur depuis plusieurs réseaux, le fonctionnement des consoles, la validité du trafic sortant et la disponibilité du canal d’information. Cette méthode respecte la diversité des expériences rapportées en 2020 sans inventer une remise en service simultanée partout.