La fuite de routes de Vodafone Idea en 2021 a mis à l’épreuve la responsabilité des opérateurs en amont

Résumé

• Des analyses publiques ont associé Vodafone Idea AS55410 à un ensemble exceptionnellement vaste d’origines de routes observées le 16 avril 2021.
• Catchpoint a indiqué qu’à 13:48:58 GMT, l’AS55410 apparaissait comme origine de plus de 34 000 réseaux.
• Sur le collecteur RIPE RIS rrc00, Catchpoint a décrit environ 225 000 messages de mise à jour BGP entre 13:45 et 15:00 GMT, avec au moins un réseau concerné reçu par 64 des 73 pairs observés.
• MANRS a publié un décompte distinct : l’AS55410 annonçait normalement 824 routes, puis aurait annoncé plus de 31 000 routes supplémentaires.
• La responsabilité commence dans le réseau qui produit ou exporte l’annonce, mais elle s’étend aux opérateurs en amont qui décident quelles routes clientes accepter et propager.
• Les registres, objets IRR, ROA et collecteurs constituent des éléments de preuve. Ils ne configurent pas les routeurs et ne démontrent pas, à eux seuls, le chemin effectivement choisi par chaque réseau.
• La validation d’origine RPKI peut rejeter une origine invalide lorsqu’un préfixe est couvert par un ROA pertinent. Elle ne valide toutefois ni le chemin AS complet ni les préfixes non couverts.
• Les données de RIPE RIS et de RouteViews montrent ce que certains pairs ont annoncé à certains collecteurs. Elles n’autorisent aucune route et ne prouvent pas que tous les réseaux ont pris la même décision.
• Les termes fuite de routes, mauvaise annonce d’origine et détournement décrivent des dimensions différentes. Les éléments publics examinés ne permettent pas d’établir une intention malveillante.
• Une analyse de responsabilité doit suivre les points de contrôle concrets : origine, export, acceptation du client, propagation, détection, confinement, retrait vérifié et réparation durable.

Un événement visible dans le plan de contrôle

Le 16 avril 2021, plusieurs observateurs du routage public ont décrit un événement de grande ampleur impliquant l’AS55410, associé à Vodafone Idea. Il ne s’agit pas simplement d’un chiffre inhabituel dans un registre. L’événement est apparu dans les annonces BGP reçues par des observateurs externes, puis dans la quantité de mises à jour diffusées pendant la période étudiée.

Catchpoint a rapporté qu’à 13:48:58 GMT, l’AS55410 apparaissait comme origine de plus de 34 000 réseaux. Cette formulation doit rester attachée à son auteur et à son unité : Catchpoint parle de réseaux pour lesquels l’AS55410 était alors visible comme origine dans son analyse. Le nombre ne constitue pas une mesure universelle de tous les préfixes présents sur tous les routeurs de l’Internet à cette seconde précise.

L’entreprise a également examiné les données du collecteur RIPE RIS rrc00. Elle a décrit environ 225 000 messages de mise à jour BGP entre 13:45 et 15:00 GMT. Parmi les 73 pairs observés par ce collecteur, 64 auraient reçu au moins un réseau concerné. Selon la même analyse, la plupart des routes anormales auraient été retirées au bout d’environ une heure. Catchpoint a enfin associé les effets de l’événement à plus de 3 500 entreprises.

Ces chiffres forment un ensemble cohérent d’observations attribuées à Catchpoint, mais ils ne doivent pas être transformés en vérité absolue sur l’ensemble de l’Internet. Le collecteur rrc00 n’observe qu’un ensemble défini de pairs. Les messages BGP qu’il reçoit décrivent le plan de contrôle visible depuis ces sessions, non chaque décision de transfert de paquets prise dans chaque réseau. De même, la référence à plus de 3 500 entreprises ne permet pas de conclure que chacune a connu la même perte de connectivité, pendant la même durée, avec les mêmes conséquences.

MANRS a publié une analyse distincte. Elle a indiqué que l’AS55410 annonçait normalement 824 routes et qu’il avait annoncé plus de 31 000 routes supplémentaires. Ce décompte ne doit pas être fusionné artificiellement avec les plus de 34 000 réseaux rapportés par Catchpoint : les sources emploient des méthodes, des fenêtres et des formulations différentes. La convergence générale porte sur l’ampleur exceptionnelle de l’anomalie, non sur l’existence d’un nombre unique qui résumerait parfaitement l’événement.

MANRS a qualifié l’incident de détournement BGP. Dans son analyse de la propagation observée, l’organisation a mis en cause le passage des routes par Bharti Airtel AS9498, tout en relevant que d’autres opérateurs en amont identifiés n’avaient pas propagé le même ensemble de routes. Cette comparaison est importante pour la responsabilité opérationnelle : elle suggère que les décisions d’acceptation et d’export différaient entre certaines frontières réseau.

Elle ne révèle cependant ni toutes les relations commerciales privées ni la configuration détaillée de chaque routeur, et elle ne permet pas de généraliser le comportement observé à chaque fournisseur de Vodafone Idea.

The Register a résumé l’événement en évoquant plus de 30 000 préfixes erronés. Cette description journalistique apporte un témoignage supplémentaire sur l’ampleur publiquement rapportée. Elle ne remplace pas les données route par route, les journaux des opérateurs ou les configurations qui permettraient de reconstituer toutes les décisions prises.

Fuite, mauvaise origine ou détournement

La qualification technique mérite plus de prudence qu’une étiquette unique. Une fuite de routes désigne généralement la propagation d’informations de routage au-delà du périmètre prévu par les relations entre réseaux. Une route reçue d’un fournisseur ou d’un pair peut, par exemple, être exportée vers un autre fournisseur alors que la politique économique et opérationnelle attendue ne le permet pas. La taxonomie des fuites traite donc largement de la manière dont une route franchit des frontières où elle n’aurait pas dû être annoncée.

Une mauvaise annonce d’origine concerne un autre aspect : un système autonome se présente comme origine d’un préfixe alors qu’il n’est pas censé l’originer. Cette situation peut provenir d’une erreur de configuration, d’une redistribution incontrôlée, d’un défaut d’automatisation, d’une politique trop permissive ou d’une action intentionnelle. L’observation de la mauvaise origine ne permet pas, à elle seule, de choisir entre ces explications.

Le mot détournement est souvent utilisé quand un AS annonce l’espace d’adressage associé à un autre acteur et attire ainsi une partie du trafic. MANRS a employé ce terme pour l’événement AS55410. Cela justifie de restituer fidèlement sa qualification. Il serait toutefois incorrect de convertir automatiquement cette terminologie en preuve d’intention malveillante.

Les données publiques utilisées ici établissent l’existence d’annonces anormales et une propagation étendue dans les vues étudiées. Elles ne prouvent pas le mobile de l’opérateur, une volonté de détourner le trafic, une négligence juridiquement caractérisée ou une tentative de dissimulation. Elles ne suffisent pas davantage à déterminer une illégalité, une responsabilité civile ou pénale, ni un montant de dommage.

La formulation la plus utile pour l’analyse consiste donc à séparer trois questions. L’AS55410 a-t-il été observé comme origine de routes qu’il n’aurait normalement pas dû annoncer ? Jusqu’où ces routes ont-elles été acceptées et propagées ? Quels contrôles opérationnels, chez la source et chez ses voisins, pouvaient interrompre la chaîne ? Cette séparation permet d’examiner les faits sans attribuer une intention que les sources ne démontrent pas.

Comment une anomalie d’origine devient un événement mondial

BGP permet aux systèmes autonomes d’échanger des informations de joignabilité. Une annonce présente notamment un préfixe, une origine apparente et un chemin AS. Le protocole ne dispose pas, dans son fonctionnement historique de base, d’une autorité universelle qui garantit que chaque origine est légitime ou que chaque relation du chemin correspond à une exportation autorisée.

Le premier point de contrôle se trouve dans le réseau source. Un opérateur décide quels préfixes ses routeurs peuvent originer, quelles routes peuvent être redistribuées dans BGP, quelles sessions peuvent les recevoir et vers quels voisins elles peuvent être exportées. Des listes de préfixes, des politiques déclaratives, des contrôles d’automatisation et des procédures de changement peuvent limiter cet ensemble.

Une configuration sûre ne devrait pas dépendre de la seule intention de l’ingénieur qui prépare une modification. Elle doit exprimer une autorisation vérifiable : tels préfixes peuvent être originés par telle infrastructure, dans telles conditions, sur telles sessions. Une différence massive entre l’ensemble attendu et l’ensemble produit devrait provoquer un rejet local ou, au minimum, une alerte avant que les annonces quittent le réseau.

Le deuxième point de contrôle appartient à l’opérateur en amont. Une session client ne devrait pas être traitée comme une source illimitée d’informations légitimes. Le fournisseur peut construire une liste de préfixes autorisés à partir du contrat, des données opérationnelles convenues, des objets de routage et d’autres preuves vérifiées. Il peut refuser une annonce qui sort de ce périmètre.

Une limite de nombre maximal de préfixes constitue un autre contrôle. Lorsqu’un client qui annonce habituellement un volume relativement stable présente soudainement des dizaines de milliers de routes supplémentaires, un seuil raisonnablement défini peut déclencher une alerte, bloquer les nouvelles routes ou fermer la session selon la politique choisie. Cette mesure n’est pas parfaite : un seuil mal calibré peut perturber une expansion légitime, et un seuil trop large ne détectera pas une anomalie plus petite. Son intérêt tient à sa capacité à rendre visible un changement de magnitude.

Le troisième point est l’export vers les autres voisins. Une route acceptée d’un client peut être retransmise à des pairs ou à d’autres fournisseurs. À chaque étape, la décision d’export étend ou réduit la portée de l’anomalie. L’observation rapportée par MANRS — propagation attribuée dans son analyse à Bharti Airtel AS9498, alors que d’autres opérateurs en amont identifiés n’auraient pas propagé le même ensemble — illustre cette autonomie des frontières réseau. Elle ne révèle pas la politique privée exacte, mais elle montre pourquoi l’événement ne peut pas être expliqué uniquement par l’action de l’AS source.

Les rôles BGP explicites et l’attribut Only-to-Customer offrent des moyens supplémentaires de décrire les relations et de limiter certaines propagations inattendues. Ils peuvent aider un routeur à reconnaître qu’une annonce reçue porte une indication incompatible avec son export vers un autre type de voisin. Là encore, les normes décrivent des options de contrôle. Les sources ne prouvent pas leur déploiement chez Vodafone Idea, Bharti Airtel ou un autre réseau nommé au moment de l’incident.

Ce que la RPKI peut vérifier — et ce qu’elle ne vérifie pas

La RPKI permet au détenteur d’une ressource de publier une autorisation d’origine, généralement sous la forme d’un ROA. Ce document lie un préfixe, une longueur maximale et un système autonome autorisé à l’originer. Un opérateur peut utiliser ces données pour classer une annonce reçue.

Lorsqu’un préfixe est couvert par un ROA pertinent et que l’origine observée ou la longueur annoncée contredit cette autorisation, le résultat de validation peut être invalide. Une politique de rejet des routes invalides aurait alors la capacité d’empêcher leur acceptation à la frontière où elle est appliquée. Il s’agit d’un contrôle concret, à condition que le ROA existe, que les données soient disponibles et à jour, que la validation fonctionne et que le routeur applique effectivement une politique de rejet.

Si aucun ROA ne couvre un préfixe, la validation d’origine ne peut pas inventer une autorisation. Le résultat est alors non trouvé plutôt qu’invalide. Une politique qui n’écarte que les annonces invalides ne bloquera pas nécessairement les préfixes non couverts. L’efficacité de la RPKI dépend donc aussi de la couverture créée par les détenteurs de ressources.

Même lorsqu’elle fonctionne parfaitement, la validation d’origine ne valide pas le chemin AS complet. Une route peut présenter une origine autorisée tout en ayant été propagée dans une direction incompatible avec les relations attendues. À l’inverse, une anomalie de chemin ou d’export ne devient pas automatiquement une origine invalide. La RPKI réduit une classe de risque ; elle ne remplace ni les filtres clients, ni la politique d’import-export, ni l’analyse du chemin.

Les objets IRR peuvent fournir une autre base pour construire des filtres, mais leur existence n’est pas équivalente à leur utilisation. Il faut déterminer qui maintient l’objet, comment sa fraîcheur est contrôlée, comment les données sont transformées en configuration, à quelle fréquence cette configuration est actualisée et comment les incohérences sont traitées.

Un registre ASN ou IP, un objet de route et un ROA sont donc des preuves structurées. Ils documentent des associations ou des autorisations. Ils ne poussent pas spontanément une politique correcte dans tous les routeurs. La disponibilité réelle dépend du code et des configurations exécutés aux frontières où les annonces sont acceptées et exportées.

Les collecteurs observent, ils ne gouvernent pas

RIPE RIS et RouteViews collectent des annonces BGP auprès de pairs participants. Ces plateformes sont essentielles pour reconstruire une chronologie publique, comparer plusieurs points d’observation et vérifier qu’une route a été visible depuis certaines sessions.

Une entrée de collecteur peut démontrer qu’un pair a annoncé une route au collecteur à un moment donné. Elle peut montrer des changements d’origine, de chemin ou de visibilité. Une série de retraits et de nouvelles annonces peut aider à estimer la durée pendant laquelle une anomalie est restée visible dans cette vue.

Cette preuve possède néanmoins des limites nettes. Un collecteur n’autorise pas une route. Il n’oblige pas un pair à l’accepter. Il ne configure ni le réseau source ni les opérateurs de transit. Il ne voit pas nécessairement les meilleures routes internes, les routes non exportées vers lui, les décisions prises par d’autres voisins ou les paquets réellement transférés.

La réception d’une annonce ne prouve pas non plus que le pair l’a utilisée comme meilleur chemin pour tout son trafic. Un réseau peut recevoir plusieurs routes, appliquer des préférences locales et exporter une sélection différente selon les sessions. Deux réseaux voyant la même anomalie peuvent donc prendre des décisions distinctes.

Le chiffre de 64 pairs sur 73 fourni par Catchpoint pour rrc00 décrit une propagation particulièrement large dans cet échantillon. Il ne signifie pas que 64 réseaux ont subi un résultat identique, ni que les neuf autres étaient nécessairement protégés par le même mécanisme. Une absence dans cette vue peut résulter d’un filtrage, d’une préférence de route, d’une absence d’export vers le collecteur ou d’un autre facteur non visible.

Les données actuelles de CAIDA ASRank, du CIDR Report et de RIPE Stat offrent un contexte utile sur l’AS55410, ses ressources ou sa topologie publique. Elles ne doivent pas être présentées comme une photographie parfaite du 16 avril 2021. Les relations changent, les préfixes évoluent, les méthodes d’inférence diffèrent et les API actuelles peuvent refléter un état ultérieur.

Mesurer l’impact sans dépasser les preuves

Une annonce d’origine anormale peut attirer du trafic, créer un détour, provoquer une perte, envoyer des paquets vers une destination incapable de les délivrer ou entrer en concurrence avec la route légitime. Le résultat dépend de la longueur de préfixe, des politiques locales, de la visibilité, des chemins disponibles et de la capacité de l’origine apparente à traiter le trafic reçu.

Il serait donc excessif d’affirmer que chaque préfixe annoncé est devenu inaccessible partout. Certains réseaux ont pu préférer une route légitime. D’autres ont pu filtrer l’annonce. Certains préfixes ont pu connaître une visibilité différente selon la région ou le moment. Les effets peuvent aussi avoir varié entre perte totale, instabilité, détour et absence d’effet perceptible.

La référence de Catchpoint à plus de 3 500 entreprises doit être comprise dans ce cadre. Elle signale une portée potentielle ou observée selon la méthodologie de cette source. Elle ne constitue pas un recensement complet de tous les utilisateurs finaux affectés et ne permet pas de calculer une perte financière précise.

Les sources ne prouvent pas que toutes les organisations ont souffert pendant environ une heure. L’indication temporelle concerne le retrait de la plupart des routes anormales selon l’analyse de Catchpoint. Une entreprise peut avoir été exposée plus brièvement, plus longtemps ou pas du tout. La convergence BGP, les caches, les politiques locales et les routes alternatives peuvent modifier l’expérience.

Aucune preuve examinée n’établit un nombre total d’utilisateurs affectés, une perte économique exacte, l’intégralité des chemins de propagation ou toutes les configurations privées. Une évaluation honnête doit donc privilégier les faits de plan de contrôle : volume d’annonces, vues des collecteurs, chronologie, origine observée, propagation attribuée et retrait.

Prévenir l’origine et l’export anormaux

La première ligne de prévention consiste à définir un ensemble d’origines autorisées dans l’AS source. Cet ensemble doit être suffisamment précis pour empêcher l’annonce de ressources arbitraires et suffisamment maintenu pour accompagner les changements légitimes. Une automatisation ne devrait générer la configuration qu’à partir de données validées, avec une comparaison entre l’état prévu et l’état réellement déployé.

Les changements affectant les politiques BGP méritent un contrôle proportionné à leur portée. Une modification capable d’ajouter des milliers de préfixes ne doit pas être traitée comme une mise à jour ordinaire. Une prévisualisation du diff, une validation par un second opérateur, un déploiement progressif et un mécanisme de retour arrière réduisent le risque qu’une erreur locale devienne immédiatement mondiale.

La surveillance pré-export est tout aussi importante. Le réseau peut mesurer le nombre de préfixes par famille d’adresses et par voisin, comparer ce nombre à une base attendue et détecter une nouvelle origine non autorisée. Il peut aussi générer une alerte lorsqu’un changement dépasse une proportion ou un volume absolu défini.

Ces contrôles locaux ne dispensent pas les opérateurs en amont de leurs propres obligations opérationnelles. Un fournisseur dispose du pouvoir pratique d’accepter ou de refuser les routes de son client. Il peut maintenir une matrice client-préfixes, imposer des limites maximales, vérifier la cohérence avec les autorisations convenues et appliquer la validation d’origine.

Une politique d’importation explicite est préférable à une acceptation implicite. Les recommandations de sécurité BGP insistent sur la valeur de politiques définies pour chaque session. Le principe opérationnel est simple : l’absence d’une autorisation claire ne devrait pas ouvrir automatiquement un chemin d’export mondial.

La validation RPKI des origines invalides peut bloquer une partie des mauvaises annonces. Elle doit cependant être combinée à des filtres clients parce que tous les préfixes ne sont pas couverts et que la RPKI ne vérifie pas le chemin complet. La comparaison de plusieurs sources de données peut améliorer la qualité du filtre, mais aucune base ne doit être consommée aveuglément.

Les mécanismes de rôles BGP et d’OTC peuvent renforcer les contrôles de propagation. Leur intérêt est de rendre certaines attentes de relation plus explicites dans le protocole. Ils ne suppriment pas la nécessité d’une politique locale et ne prouvent pas que les réseaux impliqués dans l’événement de 2021 les utilisaient.

Le RFC 7999 définit une communauté bien connue pour le blackholing déclenché à distance. Ce mécanisme constitue un contexte général de contrôle du routage et de gestion de trafic indésirable. Aucune source examinée ne démontre toutefois que cette communauté a été employée dans l’événement AS55410. Elle ne doit donc pas être présentée comme explication du retrait ou du confinement observé.

Détecter avant que l’anomalie ne devienne ordinaire

Un opérateur source devrait détecter un écart avant ou immédiatement après l’export. Les indicateurs les plus simples comprennent le nombre total de préfixes originés, le nombre de nouvelles origines, le volume de mises à jour, la présence de ressources hors inventaire et la différence entre configuration prévue et table annoncée.

L’opérateur en amont possède une vue différente. Il peut comparer le volume reçu sur la session à la base du client, repérer une croissance soudaine, observer des résultats RPKI invalides et détecter des préfixes absents de la liste autorisée. Une anomalie de plusieurs dizaines de milliers de routes devrait être distinguable du bruit quotidien lorsque ces contrôles sont actifs et correctement calibrés.

La détection externe complète ces systèmes. Des observateurs indépendants, des collecteurs et des services de surveillance peuvent signaler une nouvelle origine ou une propagation inattendue. Leur avantage est de révéler l’effet déjà visible hors du réseau. Leur faiblesse est qu’ils interviennent souvent après le franchissement de la frontière initiale.

Une alerte utile doit être associée à une action. Si un centre d’exploitation reçoit seulement un message sans propriétaire désigné, sans seuil de gravité et sans procédure de blocage, la détection ne garantit pas le confinement. Les opérateurs doivent savoir qui peut modifier la politique, fermer une session, contacter un voisin et confirmer le retrait.

Contenir sans aggraver l’incident

Le confinement commence par l’arrêt de la création et de l’export des routes anormales. Selon la cause, cela peut nécessiter le retrait d’une configuration, l’arrêt d’une redistribution, la restauration d’une politique précédente ou le blocage temporaire d’une session.

L’opérateur en amont peut appliquer un filtre précis aux préfixes non autorisés. Si la situation ne permet pas une correction fine assez rapide, il peut envisager une mesure plus large, comme la suspension de l’acceptation de nouvelles routes ou la fermeture de la session. Cette décision doit équilibrer deux risques : laisser l’anomalie se propager ou interrompre aussi des routes légitimes du client.

Les autres réseaux qui reçoivent les routes peuvent mettre à jour leurs politiques, rejeter les origines invalides ou coordonner le retrait avec leurs voisins. Leur capacité d’action dépend des preuves disponibles et de leurs propres contrôles. Une correction globale ne survient pas instantanément simplement parce que la source a modifié sa configuration.

La communication doit porter sur des objets vérifiables : préfixes concernés, ASN d’origine observé, heure de début, sessions touchées, état du retrait et identifiant de l’incident. Une affirmation vague selon laquelle « le problème est résolu » ne permet pas aux voisins de vérifier que les annonces ont réellement disparu.

Vérifier le retrait et organiser la récupération

La récupération ne se limite pas à envoyer des retraits BGP. L’opérateur doit confirmer que les routes anormales ne sont plus présentes dans ses annonces, que ses principaux fournisseurs ne les reçoivent plus et que plusieurs points d’observation externes montrent une convergence cohérente.

Une seule vue ne suffit pas. L’absence d’une route sur un collecteur peut coexister avec sa présence ailleurs. La vérification devrait donc combiner les journaux du réseau source, les données des fournisseurs, plusieurs collecteurs et, lorsque cela est pertinent, des mesures de joignabilité.

Il faut également vérifier les routes légitimes. Une mesure de confinement trop large peut supprimer l’anomalie tout en laissant le client sans connectivité correcte. La récupération exige que les origines autorisées soient rétablies, que les politiques soient cohérentes et que les services dépendants soient testés.

La réparation durable commence après le retour apparent à la normale. Elle demande une reconstitution de la chaîne de changement : source de la configuration, validations exécutées, personnes ou systèmes ayant approuvé le déploiement, alertes déclenchées, décisions prises et heure de chaque action.

Les sources publiques ne prouvent pas quelles mesures correctives Vodafone Idea, Bharti Airtel ou d’autres réseaux ont durablement déployées après l’incident. Il serait donc injustifié d’affirmer qu’un contrôle précis a été ajouté, qu’une faiblesse a été totalement corrigée ou qu’aucune amélioration n’a eu lieu. La bonne question publique est celle de la preuve disponible : quelles mesures peuvent être démontrées, testées et suivies dans le temps ?

Une chaîne de responsabilité fondée sur le contrôle pratique

La responsabilité principale de l’origine repose sur le réseau qui contrôle les configurations ayant produit ou exporté l’annonce. Il doit limiter les préfixes autorisés, protéger les changements, surveiller son état BGP et disposer d’une procédure de retrait rapide.

L’opérateur en amont contrôle l’acceptation des routes clientes. Sa responsabilité opérationnelle porte sur la qualité des listes de préfixes, les limites maximales, l’usage des données d’autorisation, la validation d’origine, l’escalade des anomalies et la décision de propager ou non une route acceptée.

Les détenteurs de préfixes contrôlent une autre partie du système. Ils peuvent maintenir des informations de registre et des ROA suffisamment exacts pour permettre aux autres réseaux de distinguer une origine autorisée d’une origine incompatible. Leur capacité ne s’étend toutefois pas au déploiement des politiques dans les réseaux tiers.

Les registres et dépôts fournissent des éléments de référence. Ils doivent viser l’unicité, l’exactitude, la traçabilité des changements et la disponibilité des métadonnées de sécurité. Ils ne deviennent pas pour autant les opérateurs des routeurs qui prennent les décisions BGP.

Les réseaux récepteurs contrôlent leur propre importation et leur sélection de routes. Ils peuvent choisir d’appliquer la validation, des préférences ou des filtres supplémentaires. Il serait cependant trompeur de leur attribuer tous la même information, la même visibilité ou la même capacité d’intervention.

Les collecteurs et chercheurs préservent des observations qui rendent l’incident auditable. Ils contribuent à la chronologie et à la comparaison des chemins. Leur rôle probatoire ne doit pas être confondu avec un pouvoir de prévention.

La responsabilité complète suit donc huit étapes : empêcher une origine non autorisée, contrôler l’export, vérifier les annonces du client, limiter la propagation, détecter l’anomalie, la contenir, confirmer le retrait et conserver les preuves de la réparation. Une défaillance en amont ne supprime pas celle de la source ; inversement, une erreur de la source n’efface pas le pouvoir de filtrage exercé par ses fournisseurs.

Ce que l’illustration montre

L’image associée à cet article est un diagramme éditorial déterministe et générique. Elle représente une route cliente arrêtée à une frontière de filtrage, tandis que d’autres chemins continuent vers des nœuds de réseau.

Il ne s’agit ni d’une photographie, ni d’un site de Vodafone Idea ou de Bharti Airtel, ni d’une carte, ni d’une reconstruction visuelle de l’incident. Le schéma illustre uniquement le principe abstrait selon lequel une frontière en amont peut accepter ou rejeter une annonce.