Fuite de route Telekom Malaysia 2015: responsabilité

Résumé

Une surveillance indépendante situe le début d'une importante rafale d'annonces BGP depuis l'AS4788 de Telekom Malaysia vers 08h43 UTC le 12 juin 2015. BGPMon a signalé environ 179 000 préfixes annoncés, tandis que le RFC 7908 a ensuite cité l'événement comme un exemple majeur de fuite de route dans lequel Level 3 a accepté et propagé environ 179 000 préfixes. [2][10]
Différentes analyses rapportent différents comptages de routes car elles utilisent des collecteurs, des fenêtres temporelles et des définitions différentes. L'analyse de Geoff Huston a discuté d'environ 2 500 routes nouvellement visibles et a examiné un ensemble de 22 577 routes affectées. Ces chiffres ne peuvent pas être fusionnés de manière responsable en une seule fausse précision. [1][2]
L'AS3549 de Level 3 n'a pas simplement observé les annonces AS4788. Il les a acceptées et propagées, étendant le rayon d'explosion à travers un important réseau de transit mondial. ThousandEyes a mesuré une perte de paquets sévère et des chemins terminaux à plusieurs points de présence Level 3. [2][3]
Les preuves soutiennent une fuite de politique de relation: les routes apprises des pairs semblent avoir été réannoncées vers les fournisseurs de transit en amont. La configuration exacte du routeur Telekom Malaysia, la route-map, la commande, le logiciel et la chaîne d'approbation ne sont pas publics dans ce paquet. [1]
La responsabilité est divisée par le contrôle. AS4788 contrôlait sa politique d'exportation et le cycle de vie de la route-map. AS3549 contrôlait ce qu'il acceptait d'un client, les vérifications de volume et de chemin appliquées, et si les routes acceptées étaient propagées. Les réseaux en aval contrôlaient leur propre politique d'importation et leur surveillance.
La validation ordinaire de l'origine RPKI n'est pas une réponse complète à cet événement. La plupart des chemins divulgués ont conservé des origines légitimes. L'autorisation d'origine peut être valide tandis qu'un chemin viole l'intention d'exportation du client, du pair ou du fournisseur. [1][15][16]
Les normes ultérieures clarifient les contrôles possibles. Le RFC 8212 rend la politique d'importation et d'exportation explicite comme exigence par défaut pour eBGP, tandis que le RFC 9234 ajoute des rôles BGP conscients des relations et l'attribut Only to Customer. Ils sont des conseils de contrôle rétrospectifs, pas une preuve de violation de conformité en 2015. [11][12]
Une revendication de réparation crédible nécessite plus qu'une restauration. Elle nécessite une reconstruction gelée de l'ensemble des annonces, la politique de session prévue, des preuves de configuration avant/après, des tests contre la même classe de fuite, une observation indépendante des routes, et une preuve que les côtés à la fois exportateur et acceptant peuvent contenir une récurrence.

Une annonce de route est devenue une autorité sur le trafic d'autrui

BGP est souvent présenté comme le protocole qui indique à Internet où se trouvent les réseaux. Cette description est exacte mais incomplète. Une annonce BGP est aussi une revendication d'autorité opérationnelle.

Lorsqu'un système autonome dit à un autre qu'un préfixe est atteignable via lui, le destinataire peut préférer ce chemin et l'annoncer plus loin. D'autres réseaux peuvent alors diriger le trafic vers le chemin annoncé. La route ne comporte pas de garantie que le réseau annonceur a une capacité suffisante, que le chemin est conforme aux relations commerciales, ou que chaque opérateur intermédiaire avait l'intention de fournir un transit. BGP distribue des informations d'atteignabilité et des données de chemin AS; la politique détermine quelles revendications un réseau accepte et répète. [8]

C'est cette couche politique qui a rendu l'événement Telekom Malaysia 2015 globalement conséquent.

Des sources indépendantes disent qu'une importante rafale d'annonces a commencé vers 08h43 UTC le 12 juin. L'AS4788 de Telekom Malaysia a annoncé un énorme ensemble de routes à l'AS3549 de Level 3. Level 3 a accepté ces routes et les a propagées à ses pairs et clients. Le trafic a suivi les chemins modifiés. Le chemin via AS3549 et AS4788 pouvait sembler attrayant selon la politique de routage même si les interconnexions ne pouvaient pas transporter en toute sécurité le volume résultant.

La perte de paquets et la latence ont augmenté, et des services bien au-delà de la propre clientèle de Telekom Malaysia sont devenus difficiles ou impossibles à atteindre. [2][3]

L'événement n'était pas un certificat falsifié, un compromis de nom de domaine, ou une origine de route fabriquée au sens le plus simple. De nombreux préfixes affectés aboutissaient toujours à leurs systèmes autonomes d'origine légitimes. Le changement nuisible était que AS4788 s'est inséré comme transit pour des routes qu'il n'était pas censé exporter dans cette direction. Un chemin peut être syntaxiquement valide, sans boucle et d'origine valide tout en violant la relation économique et opérationnelle sous laquelle il a été appris.

Cette distinction est importante pour la responsabilité. Si le problème est décrit seulement comme \"Telekom Malaysia a divulgué des routes,\" la responsabilité semble s'arrêter au réseau exportateur. Mais la propagation BGP est bilatérale à chaque session. Un côté annonce; l'autre côté décide quoi accepter, préférer et annoncer plus loin. Un grand réseau de transit a un pouvoir de propagation plus important qu'un client isolé. Ce pouvoir crée un devoir correspondant de filtrage et de preuve.

La question centrale n'est pas quel opérateur a fait la première erreur. C'est combien de contrôles indépendants avaient la capacité pratique d'arrêter l'erreur avant qu'elle ne devienne une panne pour d'autres réseaux.

La chronologie est claire aux bords et incomplète à l'intérieur des réseaux

BGPMon a rapporté que AS4788 a commencé à annoncer un ensemble massif de routes à 08h43 UTC. Sa surveillance a vu une forte augmentation des messages de mise à jour BGP au même moment où la perte de paquets a commencé. L'analyse a décrit environ 179 000 préfixes annoncés et a donné un préfixe Facebook affecté comme exemple d'un chemin qui traversait AS3549 et AS4788 avant d'atteindre l'origine légitime. [2]

ThousandEyes a décrit indépendamment la même séquence large. Il a observé de nouveaux chemins via Telekom Malaysia et Level 3, une perte de paquets sévère, et des routes terminales dans des endroits incluant Amsterdam, Chicago, Francfort, Londres, Los Angeles, Seattle et Washington. Il a dit que Level 3 a cessé d'accepter les routes vers 10h45 UTC et que le service a commencé à revenir à la normale. [3]

BGPMon a signalé une amélioration vers 10h40 et un dégagement plus large vers 11h15. Ces heures doivent rester attribuées. Un collecteur de routes, une plateforme de mesure active, un opérateur de transit et un utilisateur final n'observent pas le même événement au même instant. Un filtre peut arrêter les nouvelles annonces tandis que des routes obsolètes restent sélectionnées ailleurs. Les retraits peuvent se propager de manière inégale. La congestion peut persister après la suppression du déclencheur du plan de contrôle. La récupération est donc une séquence, pas un horodatage universel.

L'analyse RIPE Atlas a ensuite utilisé l'événement pour examiner comment les grandes défaillances de l'infrastructure centrale affectent la connectivité de bout en bout. Il a trouvé des preuves à la fois de routage du trafic contournant l'infrastructure sous stress et de défaillances de bout en bout. Les auteurs étaient explicites sur la représentativité: même un système de mesure mondial diversifié n'observe qu'un ensemble fini de chemins et de destinations. [4]

La chronologie publique a un enregistrement externe fort et un enregistrement interne faible.

Les observateurs externes peuvent identifier le début approximatif, les chemins qui ont changé, le volume de mises à jour de routes, la perte de paquets, la latence et la récupération large. Ils ne peuvent pas voir la route-map privée, le terminal de l'opérateur, le changement approuvé, la limite de préfixes configurée, la file d'alerte, ou la conversation décisionnelle entre Telekom Malaysia et Level 3.

Cet écart devrait façonner le langage de l'article.

Il est défendable de dire que AS4788 a émis les routes, AS3549 les a acceptées et propagées, et que l'atteignabilité mondiale en a souffert. Il est défendable de dire que le modèle est cohérent avec des routes apprises de pairs étant exportées vers un fournisseur en amont. Il n'est pas défendable d'identifier la commande exacte, le routeur, l'employé, le ticket de changement ou le défaut logiciel sans un enregistrement opérateur authentifié.

L'analyse de Geoff Huston utilise un langage probabiliste concernant une défaillance de politique de route et contient des variantes typographiques apparentes de numéros AS dans certains passages. Le réseau de Telekom Malaysia est AS4788. L'article ne doit pas transformer des références apparentes à AS4877 ou AS4778 en acteurs supplémentaires ou les utiliser pour fabriquer de la certitude sur un dispositif interne. [1]

Un dossier de responsabilité complet relierait la chronologie externe aux preuves internes:

la dernière politique d'exportation connue bonne;
le changement proposé et normalisé;
l'heure à laquelle chaque routeur ou session l'a reçu;
le nombre et le type de préfixes sélectionnés pour l'exportation;
les alertes pour le volume de routes et les violations de relation;
l'état d'acceptation et de préfixe maximum chez AS3549;
les contacts et messages d'escalade;
la commande ou l'action automatisée qui a arrêté la propagation;
les preuves de collecteur montrant le retrait et la convergence;
les tests prouvant que la politique réparée rejette la même classe de route.

Sans cette chaîne, la restauration est visible mais l'apprentissage institutionnel reste difficile à vérifier.

Les comptages de préfixes décrivent des vues différentes, pas un fait contesté

Les grands incidents Internet attirent un seul nombre mémorable. Ici, cet instinct peut rendre le dossier moins précis.

BGPMon a écrit que AS4788 a commencé à annoncer environ 179 000 préfixes et a ensuite fait référence à environ 176 000 préfixes divulgués. Le RFC 7908 cite la \"fuite de route massive de Telekom Malaysia\" d'environ 179 000 préfixes. ThousandEyes a décrit une grande partie de la table de routage mondiale. [2][3][10]

L'analyse de Huston a utilisé différentes vues de l'événement. Elle a montré un changement net de la table de routage impliquant des milliers de routes nouvellement visibles et retirées, puis a examiné 22 577 routes dans un ensemble affecté spécifique. [1]

Ces chiffres peuvent coexister car un événement BGP n'a pas une seule unité naturelle.

Un observateur peut compter chaque message UPDATE, chaque préfixe unique annoncé via un chemin inattendu, chaque préfixe nouvellement visible chez un collecteur, chaque meilleur chemin modifié, chaque route plus spécifique, chaque route encore présente à un moment sélectionné, ou chaque origine affectée. Les collecteurs reçoivent différentes alimentations. Une route peut être annoncée, retirée et réannoncée. Certains chemins sont visibles chez un collecteur et pas chez un autre. Une table complète et un ensemble affecté filtré répondent à différentes questions.

Le choix éditorial responsable est de préserver la définition de la mesure.

L'article peut dire que BGPMon et le RFC 7908 ont décrit environ 179 000 annonces ou préfixes divulgués dans leurs reconstructions. Il peut dire que l'analyse distincte de Huston a examiné un ensemble de 22 577 routes et observé des milliers d'ajouts et de retraits de table. Il ne doit pas faire la moyenne des valeurs, choisir la plus grande pour le drame, ou en présenter une comme un recensement complet de l'impact utilisateur.

La même discipline s'applique aux services affectés. BGPMon et ThousandEyes ont identifié des exemples impliquant des plateformes majeures et des services financiers. Ces exemples démontrent l'ampleur et les effets collatéraux. Ils n'établissent pas que chaque préfixe a subi la même perte de paquets, que chaque service est devenu indisponible, ou que chaque utilisateur a été routé via AS4788.

Les comptages deviennent des preuves de responsabilité lorsque leurs définitions sont retenues:

nombre d'annoncesteste si le volume d'exportation était anormal;
nombre de préfixes uniquesteste l'étendue de l'autorité de routage revendiquée;
nombre de meilleurs chemins modifiésteste combien de réseaux ont sélectionné la fuite;
visibilité du collecteurteste la propagation;
volume de trafic et perte de paquetsteste le préjudice opérationnel;
nombre de clients et d'applications affectésteste l'impact commercial;
durée de retraitteste le confinement.

Chaque mesure devrait avoir un propriétaire, un seuil et un enregistrement conservé. Un fournisseur de transit peut accepter l'ensemble normal de quelques milliers de préfixes d'un client mais mettre en quarantaine un changement soudain d'ordre de grandeur. Un système de surveillance de routes peut détecter des chemins qui violent les attentes du cône client même lorsque le volume brut de préfixes reste en dessous d'une limite statique. Un post-mortem public peut expliquer les deux mesures plutôt que d'offrir un seul total en titre.

La fausse précision n'est pas seulement un problème d'écriture. Elle peut cacher quel contrôle a échoué.

La politique de relation est la structure invisible derrière l'atteignabilité BGP

Internet n'est pas un maillage plat dans lequel chaque système autonome offre un transit gratuit à tous les autres systèmes. Les réseaux achètent du transit, vendent du transit et s'interconnectent sous des relations qui façonnent la politique de routage.

Une règle opérationnelle simplifiée fonctionne comme ceci:

les routes apprises des clients peuvent être annoncées aux clients, pairs et fournisseurs;
les routes apprises des pairs peuvent être annoncées aux clients, mais ordinairement pas à un autre pair ou fournisseur;
les routes apprises des fournisseurs peuvent être annoncées aux clients, mais ordinairement pas à un autre fournisseur ou pair.

Ces règles produisent le modèle familier \"sans vallée\". Un chemin peut monter des clients vers les fournisseurs, traverser au plus une relation de pair, et descendre vers les clients. Un chemin qui descend puis remonte peut indiquer qu'un réseau fournit un transit non intentionnel. [1][10]

Les relations commerciales réelles sont plus compliquées. Deux réseaux peuvent avoir différents rôles dans différents endroits, familles d'adresses ou services. Le transit partiel, le peering payant, les serveurs de routes et les arrangements régionaux ne correspondent pas toujours à une seule étiquette. Cette complexité est une raison pour documenter et tester la politique, pas une raison pour l'omettre.

La reconstruction de Huston dit que AS4788 semblait collecter des routes de pairs sur des points d'échange et les réannoncer aux réseaux de transit en amont. Dans ce modèle, les routes apprises latéralement étaient exportées \"vers le haut.\" Level 3 a ensuite accepté et propagé les chemins. [1]

Le protocole lui-même ne peut pas déduire chaque relation commerciale privée du chemin AS. Une séquence de numéros AS légitimes ne dit pas si une route était contractuellement et opérationnellement autorisée à voyager à travers eux. Cette connaissance doit être encodée dans la politique locale, les objets de routage publiés, les rôles négociés, les communautés, les données de cône client, ou un autre système de validation.

C'est pourquoi les fuites de routes restent difficiles. Un routeur peut recevoir une mise à jour BGP valide d'un voisin authentifié, voir une origine légitime, construire un chemin AS sans boucle, et quand même accepter une route qui viole la relation intentionnelle.

La responsabilité opérationnelle exige donc que les réseaux rendent leurs attentes vérifiables par machine là où c'est possible:

classer chaque session eBGP et chaque politique exceptionnelle;
définir les préfixes et les chemins clients attendus du voisin;
contraindre les exportations selon comment les routes ont été apprises;
comparer une politique proposée avec la relation intentionnelle;
rejeter ou mettre en quarantaine une expansion inexpliquée;
conserver une explication lisible par l'homme pour les exceptions;
tester la politique contre des conditions de table complète représentatives.

L'événement public montre ce qui se passe lorsque l'intention de relation reste implicite ou que l'application est inefficace. Une route peut traverser une session et devenir une revendication mondiale avant qu'un humain ne lise un ticket.

AS4788 contrôlait l'exportation, mais AS3549 contrôlait l'acceptation et la propagation

Telekom Malaysia avait le contrôle le plus direct sur l'ensemble des annonces sortant de AS4788. Un réseau exportateur devrait savoir quelles routes il a originait, lesquelles il a apprises des clients, lesquelles il a apprises des pairs ou fournisseurs, et quelles classes peuvent être envoyées à chaque voisin.

Ce contrôle commence avant l'activation de la configuration.

Un changement devrait être compilé dans la politique réelle de préfixes et de chemin AS qu'un routeur appliquera. Une révision devrait comparer le résultat avec les cônes clients attendus, les comptages de routes et les règles de relation. Un environnement de test ou un évaluateur hors ligne devrait alimenter des routes représentatives à travers la politique et montrer ce qui serait exporté. Une vérification indépendante devrait signaler les routes apprises de pairs ou de fournisseurs sélectionnées pour une autre session non client.

Le dossier public n'établit pas si de tels contrôles existaient chez AS4788, si une configuration de routine a changé, ou si un état latent a été déclenché. Il établit la sortie: un ensemble de routes large et dangereux a été exporté.

La frontière de contrôle de Level 3 est séparée et tout aussi importante pour la propagation mondiale.

AS3549 a choisi si les routes reçues de AS4788 étaient éligibles, comment elles étaient préférées, et où elles étaient annoncées. Un fournisseur de transit majeur a une connaissance spécifique du client que des tiers arbitraires n'ont pas. Il peut connaître le nombre de préfixes attendu, les routes client enregistrées, l'historique observé, les relations de cône client et le but de la session. Il peut appliquer:

une politique d'importation explicite;
des listes de préfixes dérivées de données de routage authentifiées;
des contraintes de chemin AS et de cône client;
des seuils de préfixe maximum;
des vérifications de longueur de route et de bogons;
une détection de fuite consciente des relations;
une politique de quarantaine ou de moindre préférence pour les anomalies;
une approbation humaine pour une expansion exceptionnelle.

Le compte rendu de BGPMon dit que Level 3 a accepté les annonces et les a annoncées à ses pairs et clients. Les routes ont ensuite attiré le trafic et contribué à la congestion chez Level 3 et dans les principaux lieux de peering. [2]

Cela ne signifie pas qu'un amont peut garantir que chaque route client est correcte. Les filtres statiques peuvent devenir obsolètes. Les clients multi-hébergés peuvent légitimement changer les annonces. Le routage d'urgence peut étendre un ensemble. Une politique complexe peut rendre les cônes clients difficiles à calculer. Un filtre trop strict peut provoquer sa propre panne.

Mais ces coûts n'effacent pas le pouvoir d'agir du fournisseur. Ils définissent le problème d'ingénierie.

Un fournisseur de transit avec un pouvoir de propagation mondial devrait être capable de répondre:

Quelle gamme de nombre de routes et de forme de chemin était normale pour ce client?
Quels changements nécessitaient une pré-coordination?
L'ensemble accepté incluait-il des routes avec d'autres pairs ou fournisseurs majeurs derrière le client?
Existait-il un seuil de préfixe maximum, et était-il fixé par rapport à une base réaliste?
La session avait-elle une exception qui désactivait ou affaiblissait les vérifications?
Quelle alerte s'est déclenchée en premier?
Qui pouvait supprimer les routes sans attendre le client?
Comment le trafic collatéral était-il protégé pendant l'investigation?

La responsabilité suit cette capacité pratique à limiter le préjudice. L'erreur d'exportation d'AS4788 et l'acceptation d'AS3549 ne sont pas des explications mutuellement exclusives. Ce sont des défaillances de contrôle successives dans la même chaîne de propagation.

La concentration du transit a transformé une erreur de politique en préjudice partagé

Toutes les fuites de routes ne provoquent pas un incident mondial. Le rayon d'explosion dépend de l'endroit où la fuite est acceptée, de l'attrait du chemin, de sa large propagation, et de la capacité des réseaux récepteurs à transporter le trafic redirigé.

Level 3 était un important fournisseur de transit mondial. Une fois que AS3549 a propagé les chemins, des réseaux et des clients loin de la Malaisie ont pu les sélectionner. Le trafic qui suivait normalement des chemins directs, régionaux ou mieux provisionnés a été attiré vers un chemin passant par Level 3 et AS4788. [2][3]

Deux mécanismes de préjudice ont suivi.

Le premier était la déviation directe du chemin. Un préfixe de destination pouvait acquérir un chemin sélectionné via AS3549 et AS4788. Les paquets voyageaient alors vers Telekom Malaysia même si elle n'était pas destinée à fournir un transit mondial pour cette destination. L'interconnexion pouvait saturer, les paquets pouvaient être perdus, et la latence augmenter.

Le second était la congestion collatérale. Un service n'avait pas besoin de sélectionner lui-même un chemin divulgué pour en souffrir. S'il dépendait de la capacité de Level 3 ou d'un point de présence congestionné, la charge de trafic extraordinaire pouvait altérer sa route normale. ThousandEyes a décrit des exemples où la propre route d'un service restait inchangée mais la congestion à l'intérieur de Level 3 réduisait la disponibilité. [3]

Ce second mécanisme est important car il élargit le prisme de responsabilité au-delà d'une liste de préfixes divulgués. L'infrastructure de transit partagée peut transmettre le préjudice à des clients dont la politique de routage n'est pas directement erronée. La capacité, l'isolation et l'ingénierie du trafic deviennent partie du problème de confinement.

Les réseaux ne peuvent pas provisionner chaque lien pour qu'une fraction arbitraire de la table mondiale le choisisse soudainement. Les limites économiques sont réelles. Pourtant, un fournisseur de transit peut concevoir des contrôles pour qu'un ensemble de routes anormal n'acquière pas cette autorité de trafic en premier lieu.

L'événement relie donc la sécurité du routage au risque de concentration. Un réseau de transit hautement connecté améliore l'atteignabilité dans des conditions normales. La même connectivité amplifie une défaillance politique lorsque des routes dangereuses sont acceptées et propagées. L'échelle est à la fois un atout de résilience et un multiplicateur de rayon d'explosion.

Une exploitation responsable devrait traiter la portée de propagation comme une variable de risque:

une petite annonce client locale peut utiliser un traitement automatisé normal;
une annonce client soudaine de routes provenant de nombreux grands réseaux non liés devrait nécessiter une quarantaine ou une validation;
un changement qui modifierait les chemins à travers de nombreuses régions devrait déclencher une mesure de l'extérieur vers l'intérieur;
un fournisseur devrait savoir quels points de présence et interconnexions recevraient le trafic redirigé;
le confinement devrait être possible sans désactiver inutilement les routes client saines.

Le but n'est pas d'éliminer l'automatisation. C'est de rendre l'automatisation proportionnelle à l'autorité qu'elle accorde.

Les contrôles de préfixe maximum aident, mais ils ne sont pas une politique complète

Les limites de préfixe maximum sont une défense intuitive contre une fuite énorme. Si un client annonce normalement un ensemble borné et envoie soudainement une table énorme, le fournisseur peut avertir, rejeter les nouvelles routes ou fermer la session.

BGPMon a suggéré que le volume anormal de routes pouvait également déclencher les limites de préfixe maximum sur les sessions de Level 3 avec d'autres grands réseaux, produisant davantage de changements et de modifications de chemins. [2]

Cette observation révèle à la fois la valeur et le danger des seuils simples.

À la périphérie du client, un contrôle de préfixe maximum bien calibré peut stopper une expansion invraisemblable avant une large propagation. Aux sessions en aval, le même mécanisme peut réagir après que les mauvaises routes sont déjà entrées dans un fournisseur majeur, potentiellement en faisant tomber une session entière et en déplaçant le trafic ailleurs. Une limite peut contenir un chemin tout en en déstabilisant un autre.

Des limites efficaces nécessitent un contexte:

l'agrégat normal du client et les préfixes plus spécifiques;
la croissance attendue;
les scénarios de maintenance et d'urgence;
le comportement séparé IPv4 et IPv6;
si les routes rejetées échouent fermées ou conservent le dernier ensemble connu bon;
l'escalade des alertes avant un arrêt dur;
un processus de dérogation sécurisé avec expiration;
le test de la réponse sous un trafic réaliste.

Le nombre de routes ne peut pas non plus détecter toutes les fuites. Un client pourrait divulguer un petit nombre de routes plus spécifiques très attractives. Il pourrait exporter des routes d'un pair puissant sans augmenter beaucoup le volume total. Il pourrait remplacer des routes client légitimes par un ensemble non autorisé de taille similaire.

Le préfixe maximum n'est donc qu'une couche. La propriété des préfixes, la validation du cône client, les relations de chemin AS, les étiquettes de source de route et la détection d'anomalies traitent différentes formes de défaillance.

Un dossier post-incident devrait dire quelles couches existaient, pas simplement que \"les filtres ont été améliorés.\" Un seuil de préfixe maximum ajouté après l'événement serait une preuve significative si l'opérateur publiait la base de référence, la logique du seuil, le mode de réponse et un test utilisant l'ensemble d'annonces reconstruit.

La validation d'origine RPKI n'aurait pas résolu la défaillance de politique de chemin

Les discussions sur la sécurité du routage utilisent souvent RPKI comme une réponse générale aux incidents BGP. Ce raccourci est dangereux ici.

L'infrastructure à clé publique des ressources permet aux détenteurs de ressources numériques Internet de créer des déclarations cryptographiquement vérifiables. Une autorisation d'origine de route identifie quel système autonome est autorisé à originer un préfixe, sous réserve des règles de longueur de préfixe de l'autorisation. La validation d'origine de route peut classer une annonce reçue en comparant son préfixe et son AS d'origine avec ces autorisations. [15][16]

L'événement AS4788 de 2015 était en grande partie une fuite de politique de chemin, pas une simple origine non autorisée.

Pour de nombreuses routes divulguées, l'origine légitime restait à la fin du chemin AS. AS4788 s'est inséré comme transit et a annoncé la route à une relation où elle n'était pas attendue. Un validateur d'origine pourrait voir une origine autorisée et la classer comme valide même si la route violait l'intention d'exportation pair/fournisseur.

L'analyse de Huston a fait ce point directement. Dans l'ensemble de routes qu'il a examiné, seule une petite minorité impliquait AS4788 apparaissant comme l'origine d'une manière que le filtrage ROA ordinaire pourrait traiter. La plupart du problème concernait les informations de transit. [1]

Cela ne rend pas RPKI sans importance. La validation d'origine peut arrêter les origines non autorisées, les mauvaises origines accidentelles et de nombreux détournements. Elle peut réduire une classe de fausse atteignabilité. Elle fournit également des informations de ressources authentifiées qui peuvent soutenir des contrôles plus larges.

Cela signifie que la revendication de contrôle doit être précise.

\"Nous avons déployé ROV\" ne prouve pas la protection contre des routes qui ont des origines valides mais des chemins de relation invalides. Un réseau a besoin d'informations supplémentaires sur qui peut fournir le transit pour qui et quels chemins sont cohérents avec la politique. RPSL, les données de cône client, les communautés, les rôles BGP, l'attribut Only to Customer, les travaux liés à ASPA et les filtres spécifiques à l'opérateur traitent des parties de ce problème à différents niveaux de maturité.

Le message responsable est en couches:

RPKI valide l'autorité d'origine;
la politique explicite d'importation et d'exportation contraint les sessions;
les contrôles conscients des relations contraignent la propagation des chemins;
la surveillance détecte les anomalies que les données statiques manquent;
la coordination opérationnelle contient ce que la prévention n'arrête pas.

Confondre ces couches produit une fausse assurance et un apprentissage post-incident faible.

Les registres de routes peuvent publier l'intention, mais une intention obsolète n'est pas un contrôle

Le langage de spécification de politique de routage (RPSL) a été conçu pour décrire la politique de routage dans les registres de routage Internet. RPSL et RPSLng peuvent exprimer la politique d'importation et d'exportation, des ensembles de systèmes autonomes, des ensembles de routes et des intentions connexes. [13][14]

En principe, un fournisseur peut utiliser des données de politique authentifiées et maintenues pour générer des filtres pour un client. Un client peut publier les préfixes et les relations AS qu'il prévoit d'annoncer. Les pairs peuvent comparer les routes observées avec l'intention déclarée.

L'analyse de Huston explique l'attrait et les limites. Les données de registre peuvent être incomplètes, obsolètes, dupliquées entre bases de données ou trop grossières pour des relations spécifiques à une session. Une politique complexe peut être difficile à exprimer et à maintenir. Certains registres ont historiquement permis des entrées tierces avec une faible autorité. [1]

La mauvaise leçon est que les registres de routes sont inutiles. La bonne leçon est qu'un objet de registre n'est une preuve que lorsque sa propriété, sa fraîcheur, sa portée et son utilisation sont vérifiables.

Un pipeline de filtrage mature devrait enregistrer:

le registre et les objets utilisés;
l'authentification et l'autorité de maintenance;
la dernière actualisation réussie;
l'expansion des ensembles AS en préfixes et chemins concrets;
les conflits entre registres;
les exceptions locales;
le diff du filtre généré;
le résultat du déploiement sur le routeur;
la surveillance de la divergence entre la politique publiée et observée.

MANRS cadre la sécurité du routage comme une responsabilité opérationnelle collective. Ses actions pour les opérateurs mettent l'accent sur le filtrage des annonces, le maintien des contacts de coordination et la publication d'informations que d'autres peuvent valider. Le guide de mise en œuvre actuel discute de la granularité des préfixes et des chemins AS et recommande des contrôles qui empêchent les routes apprises des clients ou intermédiaires d'être exportées vers des pairs non clients inappropriés. [17][18]

Ces documents actuels postdatent l'événement de 2015 dans leur forme présente. Ils devraient être utilisés comme un cadre de contrôle, pas comme une preuve légale rétroactive.

L'événement montre pourquoi le cadre importe. Une politique connue seulement d'une configuration de routeur est difficile à valider pour un autre réseau. Une politique publiée mais jamais compilée en filtres n'est qu'une documentation. Un filtre compilé à partir de données obsolètes peut rejeter des routes valides ou en accepter d'invalides. La responsabilité nécessite la chaîne de l'intention déclarée au comportement déployé jusqu'aux routes observées.

Le rejet par défaut modifie le mode de défaillance

Le RFC 8212, publié en 2017, met à jour le comportement BGP afin que les routes sur une session eBGP ne soient ni importées ni exportées à moins qu'une politique explicite n'ait été configurée. [11]

C'est un choix de conception d'une importance trompeuse.

Un défaut permissif rend l'atteignabilité facile lors de la configuration initiale. Cela signifie aussi qu'une politique manquante peut silencieusement devenir \"tout accepter\" ou \"tout annoncer.\" Un opérateur doit se souvenir d'ajouter chaque règle de protection avant que la session ne transporte des routes.

Une posture de rejet par défaut change le mode de défaillance. Une politique manquante ne produit aucun échange de routes, ce qui est visible et local, plutôt qu'une propagation mondiale non intentionnelle. Les opérateurs peuvent toujours écrire une politique explicite incorrecte. Le RFC 8212 le dit. Le contrôle ne résout pas les erreurs sémantiques, les filtres obsolètes ou les exceptions intentionnelles.

Il encode cependant un principe de responsabilité solide: l'atteignabilité mondiale devrait nécessiter une décision politique affirmative.

Pour une session client-transit, cette décision devrait être révisable:

quels préfixes peuvent être acceptés;
quelles origines et chemins clients sont attendus;
quelles routes peuvent être exportées en retour;
comment les exceptions sont approuvées;
ce qui se passe lorsque les données politiques sont indisponibles;
quel système possède le rollback;
quelle preuve prouve le déploiement.

Si chaque bord eBGP pertinent avait utilisé un défaut strict avec une politique explicite correcte, un filtre manquant aurait échoué fermé. Les preuves publiques ne peuvent pas montrer si un comportement de type RFC 8212 aurait empêché cet incident exact car elles n'exposent pas les configurations réelles de 2015. Le RFC reste un test rétrospectif utile: l'échange de routes nécessitait-il une autorité explicite et bornée des deux côtés?

Les rôles BGP et Only to Customer traitent l'information de relation

Le RFC 9234, publié en 2022, normalise les rôles BGP et l'attribut Only to Customer. Les voisins peuvent négocier des rôles tels que fournisseur, client, pair, serveur de routes et client de serveur de routes. Les routes propagées peuvent transporter des informations qui aident à appliquer la direction de relation attendue et à détecter les fuites. [12]

Ce mécanisme cible le fossé visible dans l'événement AS4788. Une origine légitime et un chemin sans boucle ne révèlent pas si une route apprise d'un pair peut être envoyée à un fournisseur. L'information de relation rend cette politique plus explicite dans l'échange de protocole.

La norme dépend toujours d'une configuration et d'un déploiement corrects. Les réseaux doivent attribuer les rôles avec précision. Les relations complexes nécessitent de la prudence. L'adoption partielle limite la protection. Les routes et équipements hérités demeurent. Aucune fonctionnalité de protocole n'élimine le besoin de surveillance et de coordination opérationnelle.

La valeur est que les deux côtés peuvent comparer leurs attentes. Une étiquette locale unilatérale peut être erronée sans retour immédiat. Un rôle négocié peut échouer l'établissement de session ou marquer un chemin lorsque les deux extrémités divergent. L'attribut Only to Customer peut aider à identifier les routes qui ne devraient pas voyager vers un autre fournisseur ou pair.

Encore une fois, ce sont des conseils ultérieurs. Il serait historiquement inexact de dire que AS4788 ou AS3549 n'ont pas utilisé une norme de 2022 en 2015.

L'incident fournit plutôt le cas de test:

Une route apprise d'un pair peut-elle être exportée vers un amont sans violation de politique détectable?
L'amont peut-il identifier que le chemin du client inclut des routes en dehors de la relation client attendue?
L'un ou l'autre côté peut-il arrêter la route avant la propagation mondiale?
Les preuves distinguent-elles une exception politique d'une fuite accidentelle?

Les mécanismes modernes conscients des rôles devraient être évalués par rapport à un ensemble de routes reconstruit de type AS4788, pas seulement contre des exemples synthétiques correspondant à une topologie propre.

La surveillance doit comparer les routes avec l'intention, pas seulement la disponibilité

La surveillance de la disponibilité détecte le préjudice après que les utilisateurs commencent à perdre l'atteignabilité. La surveillance des routes peut identifier l'anomalie du plan de contrôle plus tôt.

Le dossier public de 2015 a été préservé par plusieurs formes d'observation:

BGPMon a traité les flux de mises à jour et identifié la rafale d'annonces;
RouteViews et RIPE RIS ont conservé les archives BGP brutes;
ThousandEyes a combiné les mesures de routes et de réseau;
RIPE Atlas a fourni des mesures actives de bout en bout;
des analystes indépendants ont comparé les chemins, les comptages de préfixes et le timing. [2][3][4][5][6]

Ces systèmes ont vu différentes tranches. Cette diversité est une force. La vue interne d'un seul fournisseur peut manquer comment ses routes apparaissent ailleurs. Une sonde active peut voir la perte de paquets mais pas la politique qui l'a causée. Un collecteur de routes peut voir un chemin AS mais pas tous les chemins de trafic ou sessions privées.

Les systèmes de détection modernes peuvent rechercher des fuites de routes en utilisant la topologie, les relations AS, l'historique des routes et la propagation anormale. Cloudflare décrit la détection publique de fuites de routes comme un moyen de signaler des chemins anormaux, tandis que la documentation RIPE Atlas soutient une mesure reproductible à partir de sondes distribuées. [19][20]

La détection devrait être liée à l'action.

Une alerte qui dit \"le nombre de routes a augmenté\" est faible si personne ne possède le seuil ou ne peut supprimer la route. Un chemin d'incident utile définit:

la relation attendue et l'ensemble de routes;
la condition d'anomalie;
la confiance et le traitement des faux positifs;
l'opérateur autorisé à mettre en quarantaine;
une action de confinement sécurisée;
la confirmation externe;
la conservation des preuves;
la révision post-événement.

La première réponse n'a pas toujours besoin de faire tomber toute la session. Un fournisseur peut réduire la préférence, mettre en quarantaine les routes inattendues, préserver le dernier ensemble accepté connu bon, ou rejeter seulement les chemins en dehors du cône client. La bonne action dépend de la capacité du routeur et de la conception du client.

La surveillance devrait également distinguer la prévention de la détection. Publier une alerte de fuite de route après une propagation mondiale est une preuve publique précieuse. Cela ne prouve pas que le fournisseur avait un contrôle avant propagation. Les rapports de responsabilité devraient dire quel stade a détecté l'événement et quel stade l'a arrêté.

Un changement de politique de route sûr nécessite des preuves d'octets courants

La configuration de routage passe souvent par des modèles, bases de données, automatisation, compilateurs de politique et syntaxe spécifique au fournisseur avant d'atteindre un routeur. Un réviseur humain peut approuver une représentation tandis que le dispositif en reçoit une autre.

La chaîne de preuves devrait lier les octets courants à chaque étape:

politique source ou demande de changement;
données de relation et de préfixes normalisées;
route-map générée ou langage de politique;
configuration spécifique au dispositif;
diff de configuration candidate;
hash de configuration validée;
ensemble de routes annoncées et acceptées résultant;
observation du collecteur externe.

C'est important car \"la politique a été révisée\" est ambigu. Quelle version a été révisée? Un travail d'automatisation a-t-il étendu un ensemble AS après approbation? Un instantané de registre obsolète a-t-il produit le filtre? Une commande manuelle d'urgence a-t-elle contourné le pipeline normal? Tous les routeurs ont-ils reçu la même sortie?

Un système de changement responsable devrait échouer si ces liaisons divergent.

Avant le déploiement, il devrait rejouer des routes représentatives à travers la politique compilée. Pour des conditions de type AS4788, les tests devraient inclure:

des routes d'origine client;
des routes de cône client;
des routes apprises de pairs;
des routes apprises de fournisseurs;
des routes contenant de grands réseaux de transit;
des plus spécifiques inattendus;
une entrée soudaine à l'échelle de la table complète;
des annonces mixtes valides et invalides.

Le test devrait affirmer à la fois le comportement positif et négatif. Les routes client valides doivent continuer à passer. Les routes apprises de pairs et de fournisseurs ne doivent pas s'échapper vers un amont. Le fournisseur acceptant devrait indépendamment rejeter les chemins incompatibles avec le rôle attendu du client.

Après le déploiement, des collecteurs de routes ou des looking glasses devraient vérifier le résultat observable. Un hash de configuration seul ne prouve pas que le routeur a annoncé seulement les routes intentionnelles. L'état du plan de contrôle, les bogues des dispositifs et l'interaction avec d'autres politiques peuvent modifier le comportement effectif.

Cette discipline des octets courants n'est pas de la bureaucratie pour elle-même. C'est ainsi qu'une organisation prouve que le code, la politique et les routes discutés sont les mêmes objets qui ont produit ou empêché le préjudice.

La restauration n'est pas la même chose qu'une réparation vérifiée

Les sources publiques montrent que les routes ont été retirées ou ont cessé d'être acceptées et que le service s'est rétabli au cours des heures suivantes. C'est une restauration opérationnelle.

La réparation pose une question plus difficile: la même classe de route pourrait-elle s'échapper à nouveau?

Un programme de remédiation crédible gèlerait un ensemble d'incidents représentatif de RouteViews, RIPE RIS et des journaux internes. Il identifierait la relation intentionnelle pour chaque route et reproduirait les décisions d'exportation et d'importation dans un environnement de test.

Pour AS4788, le test vérifierait que les routes apprises de pairs ou de fournisseurs ne peuvent pas être sélectionnées pour l'exportation vers AS3549 à moins qu'une exception explicite et révisée ne s'applique. Pour AS3549, il vérifierait qu'un client ne peut pas annoncer des chemins en dehors du cône client attendu ou dépasser un volume justifié sans quarantaine.

Le programme générerait ensuite des preuves:

des tests échoués avant le correctif;
des changements de politique ou de système;
des tests réussis après le correctif;
les versions de dispositif et de logiciel;
la couverture du déploiement;
des exercices d'alerte et de confinement;
des observations de routes externes;
un inventaire des exceptions et leur expiration;
la propriété de la surveillance continue.

La réparation devrait également tester des conditions dégradées. Que se passe-t-il si les données de registre sont indisponibles? Le système échoue-t-il fermé, utilise-t-il un dernier ensemble connu bon, ou accepte-t-il tout? Que se passe-t-il si le détecteur d'anomalies est en panne? Un opérateur peut-il isoler la session via un chemin de gestion indépendant? Un arrêt de préfixe maximum préserve-t-il les routes client critiques ou les supprime-t-il tous?

La divulgation publique n'a pas besoin d'exposer des termes commerciaux privés ou une configuration exploitable. Elle peut énoncer la classe de défaillance, la frontière politique affectée, les contrôles ajoutés, la méthode de test, la couverture de déploiement et la date de vérification.

Sans ces preuves, \"nous avons réparé le filtre\" est une affirmation sur l'intention. Avec elles, les clients et les pairs peuvent évaluer si l'opérateur a changé le système qui a permis la propagation mondiale.

La responsabilité ne devrait pas se réduire au blâme personnel

Une fuite de route Internet devient souvent une histoire sur un ingénieur entrant une mauvaise commande. Le dossier public ici n'établit pas cette histoire. Même si une seule action a déclenché l'événement, l'impact mondial a nécessité plusieurs systèmes et décisions organisationnelles.

Un opérateur conçoit l'interface de configuration. Il choisit si les changements sont générés ou écrits à la main. Il définit les relations avec les pairs et les fournisseurs. Il décide quels tests sont obligatoires, si un second réviseur est requis, à quelle vitesse la politique se propage, et si le rollback est indépendant.

Un fournisseur de transit décide combien de confiance accorder à une annonce client, quels filtres sont économiquement et opérationnellement réalisables, et quelle anomalie déclenchera un confinement. La direction décide si le travail de sécurité du routage a du personnel, des fenêtres de maintenance et l'autorité d'interrompre le trafic générateur de revenus.

Le blâme personnel peut obscurcir ces contrôles. Il peut aussi décourager la divulgation. Un meilleur modèle de responsabilité demande:

Qui avait la capacité d'empêcher la route de sortir?
Qui avait la capacité de la rejeter?
Qui avait la capacité de limiter sa propagation?
Qui pouvait détecter le préjudice indépendamment?
Qui pouvait retirer ou mettre en quarantaine?
Qui a conservé les preuves?
Qui avait l'autorité de financer et vérifier la remédiation?

Ces questions peuvent identifier la responsabilité sans revendiquer une intention ou une négligence que les sources publiques ne prouvent pas.

Elles empêchent également la responsabilité de se dissoudre dans \"Internet est décentralisé.\" La décentralisation signifie qu'aucun opérateur unique ne contrôle tous les chemins. Cela ne signifie pas que chaque opérateur manque de contrôle sur ses propres annonces, sessions et décisions de propagation.

Ce que les clients et les pairs peuvent raisonnablement exiger

La plupart des clients ne peuvent pas auditer les routeurs d'un fournisseur de transit. Les pairs ne peuvent pas voir chaque processus de changement privé. Ils peuvent encore exiger des preuves appropriées à la dépendance.

Avant un incident, un opérateur peut publier:

des contacts de routage précis;
des préfixes et systèmes autonomes enregistrés;
des ensembles de routes et d'AS;
une politique de peering et de filtrage de haut niveau;
la couverture RPKI;
le support des mécanismes de rôle et de validation pertinents;
des canaux de statut et d'incident.

Pendant un incident, il peut communiquer:

la classe de route ou de session affectée;
si les annonces se propagent encore;
l'action de confinement;
les régions et services connus;
l'incertitude de mesure;
les preuves de récupération;
l'heure de la prochaine mise à jour.

Après un incident, il peut fournir:

les frontières de source et d'acceptation;
les définitions de comptage de routes;
une chronologie avec provenance;
les contrôles qui ont échoué;
les contrôles qui ont contenu le préjudice;
une remédiation testable;
les limitations restantes.

Les clients devraient également tester leur propre exposition. Le multi-hébergement ne garantit pas l'indépendance si les deux fournisseurs dépendent du même amont. Une route de secours peut exister mais perdre en préférence locale. Des annonces plus spécifiques peuvent outrepasser la diversité intentionnelle. Le trafic peut éviter un chemin divulgué mais souffrir de congestion chez un fournisseur de transit partagé.

La surveillance indépendante des routes, les mesures RIPE Atlas et les vérifications de looking glass peuvent révéler une partie de cette exposition. [4][5][6][20]

Le devoir est proportionnel. Un service public critique ou une plateforme financière devrait comprendre la concentration en amont plus profondément qu'un site personnel à faible impact. Mais aucun client ne peut compenser pleinement un fournisseur de transit qui accepte et répand un ensemble massif de routes dangereuses.

Ce que le dossier public ne peut pas prouver

L'ensemble de sources soutient une analyse solide de responsabilité réseau, mais il ne soutient pas un post-mortem interne complet.

Il ne peut pas prouver:

le routeur ou l'emplacement exact de Telekom Malaysia;
la commande ou le modèle de configuration exact;
si le déclencheur était un changement planifié, un état obsolète, une faute d'automatisation ou une erreur manuelle;
la version logicielle ou matérielle;
les termes de relation privés entre AS4788 et AS3549;
les paramètres exacts d'importation, d'exportation et de préfixe maximum des deux côtés;
la première alerte interne et la réponse de l'opérateur;
les messages de coordination privés;
un comptage de préfixes réconcilié sur tous les collecteurs;
un recensement complet des utilisateurs affectés ou des pertes financières;
la responsabilité légale ou la violation contractuelle;
la remédiation durable déployée par l'un ou l'autre opérateur.

Le paquet ne devrait pas non plus transformer des contrôles ultérieurs en exigences historiques. Le RFC 8212 a été publié en 2017, le RFC 9234 en 2022, et le guide de mise en œuvre MANRS actuel reflète un travail opérationnel ultérieur. Ils définissent des tests actuels utiles. Ils ne prouvent pas quelles configurations ou obligations existaient en 2015. [11][12][18]

De même, les données RIPEstat actuelles sont un contexte de ressources réseau actuel, pas un instantané de registre de 2015 gelé. [7]

Ces limites rendent la conclusion plus crédible. La défaillance observable est suffisante pour identifier le contrôle divisé. Le dossier interne manquant est lui-même un écart de responsabilité, mais ce n'est pas une permission d'inventer.

Un test de responsabilité de filtrage amont réutilisable

L'événement soutient un test pratique pour tout client, fournisseur de transit ou pair exploitant BGP à une échelle significative.

1. Définir la relation pour chaque session.
Enregistrer les rôles de fournisseur, client, pair, serveur de routes et exceptionnels à la granularité où la politique diffère.

2. Lier les routes intentionnelles à des preuves authentifiées.
Maintenir les préfixes, origines, cônes clients, ensembles AS et exceptions avec propriété, fraîcheur et provenance.

3. Compiler la politique avant le déploiement.
Montrer les routes et chemins concrets que la politique d'importation et d'exportation acceptera. Réviser le comportement effectif, pas seulement le texte du modèle.

4. Échouer fermé lorsque la politique explicite est manquante.
Aucune route eBGP ne devrait acquérir une autorité mondiale parce qu'un filtre était absent ou que la récupération de données a échoué.

5. Tester les violations de relation.
Rejouer les routes apprises de pairs et de fournisseurs contre les sessions clients et amont. Vérifier que la direction invalide est rejetée à la fois chez l'exportateur et le récepteur.

6. Calibrer les contrôles de volume.
Fixer les seuils de préfixe maximum et d'anomalie par rapport au comportement normal, à la croissance justifiée et aux cas d'urgence. Définir un confinement sécurisé plutôt que de se fier seulement à la fermeture complète de session.

7. Séparer la validation d'origine et de chemin.
Utiliser RPKI pour l'autorité d'origine, mais ne pas décrire ROV comme une preuve de propagation valide des relations. Ajouter des contrôles de chemin et de cône client.

8. Surveiller de l'extérieur.
Utiliser des collecteurs indépendants et des mesures actives pour comparer les routes observées et l'atteignabilité avec la politique intentionnelle.

9. Donner un propriétaire au confinement.
Identifier qui peut mettre en quarantaine les routes, réduire la préférence, restaurer un dernier ensemble connu bon ou réinitialiser une session, y compris en dehors des fenêtres de changement ordinaires.

10. Préserver les preuves d'octets courants.
Lier la politique approuvée, la configuration générée, les octets déployés, l'état des routes, les alertes, les décisions et les observations externes.

11. Prouver la réparation avec la classe d'événement originale.
Exécuter la fuite reconstruite à travers les deux côtés de la session et montrer où elle s'arrête. Tester des variantes sémantiques, pas seulement une liste de préfixes sauvegardée.

12. Publier assez pour que les réseaux dépendants puissent vérifier.
Expliquer la frontière de contrôle, les définitions de comptage de routes, la remédiation et l'incertitude restante sans exposer de termes privés sensibles.

Ce test ne promet pas que les fuites de routes disparaissent. Il rend les devoirs de prévention, de confinement et de preuve explicites à chaque réseau qui peut accorder à la route une autorité supplémentaire.

Conclusion

La fuite de route de Telekom Malaysia du 12 juin 2015 a démontré à quelle vitesse une politique de routage locale peut devenir un préjudice d'infrastructure mondial.

AS4788 a émis un ensemble très important de routes. AS3549 les a acceptées et propagées. Le trafic s'est déplacé vers des chemins passant par Level 3 et Telekom Malaysia. La perte de paquets, la latence et les défaillances d'atteignabilité se sont répandues à travers les régions et ont affecté à la fois les services directement reroutés et les utilisateurs exposés à la congestion dans un réseau de transit partagé. Des collecteurs de routes indépendants et des plateformes de mesure ont préservé le contour public. [1][2][3][4]

L'événement ne peut pas être expliqué de manière responsable comme une seule mauvaise annonce par un seul réseau. L'exportation et l'importation sont des contrôles séparés. Un client a le devoir d'annoncer seulement les routes autorisées. Un fournisseur de transit a un devoir proportionnel à son pouvoir d'accepter et de répandre ces routes. Les pairs et les réseaux en aval ont des contrôles supplémentaires de surveillance et d'importation. Aucune couche ne peut garantir la perfection, mais chacune peut empêcher une erreur d'acquérir plus de portée.

La validation d'origine RPKI est précieuse et insuffisante pour cette défaillance de politique de chemin. Les registres de routes peuvent publier l'intention et encore devenir obsolètes. Les contrôles de préfixe maximum peuvent contenir le volume et encore manquer des fuites plus petites. Les normes ultérieures de rejet par défaut et de connaissance des relations améliorent le modèle de contrôle mais ne prouvent pas rétroactivement une violation en 2015.

La réponse durable est en couches: politique explicite, données de route authentifiées, vérifications de relation, limites calibrées, surveillance indépendante, confinement rapide et réparation reproductible.

Le risque suit la portée qu'une annonce peut acquérir. La responsabilité suit qui aurait pu contraindre cette portée, qui a choisi de la propager, et qui peut prouver que la même classe de défaillance s'arrêtera maintenant avant que le trafic d'autrui ne devienne le test.

La fuite de route de 2015 de Telekom Malaysia a fait du filtrage en amont un test de responsabilité de transit