Deux mois se sont écoulés depuis que Rogers Telecom a subi une panne d’Internet à l’échelle nationale, privant des dizaines de millions de Canadiens de services de télécommunications.
Le matin du 8 juillet 2022, les abonnés de Rogers à travers le Canada se sont retrouvés sans service Internet. La panne s’est étendue au câble, aux services mobiles et à la téléphonie fixe, y compris l’accès aux services d’urgence E911. La panne a affecté les services mobiles des trois unités commerciales et marques exploitées séparément par Rogers (Rogers Wireless, Fido et Chatr). Même les clients mobiles de Rogers à l’étranger ont été coupés, ce qui suggère que les protocoles de signalisation qui permettent de négocier l’itinérance avec les réseaux visités ont été affectés. La panne a duré 19 heures et a affecté la sécurité publique, le service frontalier canadien, les banques, les réseaux de paiement de détail et le fonctionnement des tribunaux.
Après l’une des plus grandes pannes d’Internet de l’histoire de l’Amérique du Nord, le moment est venu de réfléchir aux enseignements tirés : les coûts cachés de la centralisation et de la concentration du marché, les défis liés à la mesure de la résilience de l’Internet et la mesure dans laquelle les technologies de l’Internet en sont venues à sous-tendre tous les aspects de la société, des paiements à la médecine en passant par la politique. Mais avant d’entamer ce processus, la communauté des opérateurs Internet doit collectivement comprendre la panne de Rogers de manière plus approfondie.
En attendant le rapport d’après action
La communauté Internet s’est habituée à recevoir des rapports de panne honnêtes et transparents de la part d’entreprises telles que Cloudflare, Facebook et Fastly. Dans les jours qui ont suivi l’événement, les ingénieurs de Rogers ont eu l’occasion de décrire la chronologie de l’activité de maintenance à l’origine du problème initial, la manière dont il s’est propagé d’un service à l’autre et la manière dont les flux de travail techniques existants, conçus pour limiter les dommages au réseau pendant les fenêtres de maintenance, n’ont pas été suffisants ce jour-là. (Certaines réponses allaient finalement être apportées dans une réponse au Conseil de la radiodiffusion et des télécommunications canadiennes (CRTC) plus d’un mois plus tard, dans laquelle de nombreux détails du processus opérationnel étaient expurgés).
Un rapport après action plus rapide et plus transparent aurait permis à d’autres opérateurs de réseaux dans le monde de savoir si leurs propres réseaux étaient exposés aux mêmes modes de défaillance. L’équipe d’ingénieurs de Rogers pourrait avoir présenté ses conclusions lors de la réunion d’octobre du North American Network Operators’ Group. Les responsables des opérations auraient pu tirer des leçons de la malchance de Rogers, sachant que la prochaine fois, ce sont leurs propres ingénieurs qui seront sur la sellette lors d’une fenêtre de maintenance ratée.
Que s’est-il passé le 8 juillet ?
L’histoire technique, du moins telle qu’elle a été vue depuis l’Internet public, a été racontée le 15 juillet par Doug Madory sur le blog de Kentik. Kentik a vu les flux réseau destinés aux clients de Rogers se tarir un peu avant 09:00 UTC (05:00 dans l’est du Canada) le vendredi 8 juillet. Rogers annonce normalement près de 1 000 blocs de réseau IPv4 et IPv6 dans la table BGP globale, mais lorsque ces annonces ont été retirées à grande échelle au cours de l’heure suivante, laissant la plupart des adresses IP de Rogers inaccessibles à partir de l’internet mondial, leur trafic est tombé à zéro.
Cependant, il est rapidement devenu évident que la perte du routage externe et l’arrêt soudain du trafic à la frontière Internet de Rogers avec d’autres fournisseurs n’étaient que la manifestation externe d’un très grave problème de réseau interne. Quelle qu’en soit la cause, l’impact a été beaucoup plus important qu’une panne d’Internet pour un seul système autonome sur l’Internet (même un système aussi important).
Réponse de Rogers
Le public a appris par une première communication du PDG de Rogers le lendemain de la panne, le 9 juillet, que :
“Nous pensons maintenant avoir réduit la cause à une défaillance du système de réseau à la suite d’une mise à jour de maintenance dans notre réseau central, qui a entraîné un dysfonctionnement de certains de nos routeurs tôt dans la matinée de vendredi. Nous avons déconnecté l’équipement spécifique et redirigé le trafic, ce qui a permis à notre réseau et à nos services de revenir en ligne au fur et à mesure que nous gérions les volumes de trafic revenant à des niveaux normaux.“
Deux semaines plus tard, le 21 juillet, le directeur de la technologie et de l’information de Rogers a été remplacé, sans autre commentaire.
Un mois plus tard, le 12 août, Rogers a répondu à une demande du CRTC, confirmant dans les grandes lignes que la panne était le résultat d’un changement de configuration qui a supprimé un filtre d’itinéraire, inondant “certains équipements de routage du réseau” et entraînant une défaillance du réseau central avec un impact important.
Rogers a reconnu la nécessité de “planifier et de mettre en œuvre la séparation des fonctions du réseau sans fil et du réseau filaire“.
Le calendrier proposé pour la mise en œuvre des changements a été expurgé, de même que les mesures spécifiques qui seraient prises pour remanier le réseau IP central de l’entreprise. L’entreprise a justifié la rétention de la plupart des détails techniques par des raisons de sécurité, observant dans un autre document que “tout intérêt public éventuel dans la divulgation des informations contenues dans ces réponses est largement compensé par le préjudice direct spécifique qui en résulterait pour Rogers et pour ses clients“.
Leçons apprises : La décentralisation et la transparence réduisent les risques
L’internet est construit à partir de réseaux de réseaux. Au fil du temps, la convergence de l’internet conduit inévitablement différents services à se heurter les uns aux autres dans le cœur d’un grand fournisseur de réseau. Il fut un temps où il aurait été impensable que le réseau téléphonique public commuté (RTPC), ou les protocoles de signalisation SS7 entre les commutateurs téléphoniques qui contrôlent l’établissement des appels et l’itinérance, ou l’acheminement des services d’urgence E911, soient affectés par une panne du réseau IP. Il s’agit de protocoles et de fonctions qui, historiquement, occupaient des réseaux physiquement distincts, protégés contre les dommages ou les compromis.
Comme on peut s’y attendre, le monde actuel du “tout sur IP” pose des défis particuliers aux équipes chargées de la sécurité et de l’exploitation des réseaux. Veiller à ce qu’une panne ou une compromission dans une partie du réseau n’entraîne pas un risque de contagion à d’autres services non liés est le prix que les équipes d’ingénieurs doivent payer pour la réduction des coûts et de la complexité, ainsi que pour l’amélioration des performances et de l’évolutivité, lors du transfert des services et des réseaux existants sur un réseau fédérateur IP.
Par conséquent, la communauté mondiale des opérateurs de réseaux aimerait toujours connaître les détails de ce qui s’est passé au cœur du réseau de Rogers le 8 juillet : comment la compartimentation a échoué, comment elle s’est propagée à presque tous les services de leur portefeuille diversifié, et pourquoi il a fallu plus d’une journée pour redémarrer et restaurer les services. Il ne devrait pas y avoir besoin d’une enquête parlementaire ou d’une attention particulière de la part de l’autorité de régulation des télécommunications du Canada, ni de la crainte de voir sa fusion avec un autre énorme réseau IP bloquée, pour que ces leçons techniques soient mises en lumière.
La culture de l’exploitation de l’internet exige que les opérateurs tirent des leçons des mésaventures des uns et des autres. L’internet stable et fiable d’aujourd’hui est le fruit d’une longue tradition de partage d’informations sur les pannes et les rétablissements. Les mêmes modes de défaillance et anti-modèles d’ingénierie qui ont fait tomber le réseau de Rogers le 8 juillet se cachent très certainement dans les réseaux d’autres grands fournisseurs et sont tout à fait évitables. Le fait de dissimuler les défaillances opérationnelles dans l’obscurité n’aide personne ; cela ne fait qu’augmenter la probabilité que les vulnérabilités inévitables du réseau se développent, sans être détectées, jusqu’à atteindre une échelle cataclysmique.
Photo de Javon Swaby VIA Pexels.