Fuite de routes Indosat 2014: contrôles d’export de table

Résumé

Le périmètre de l’événement est étroit:cet article porte sur la mauvaise origine massive d’AS4761 observée le 2 avril 2014 entre environ 18 h 26 et 21 h 15 UTC. Il exclut un incident Indosat distinct de 2011, les anomalies ultérieures d’AS4761 et les incidents de routage indonésiens sans rapport.
Le chiffre mis en avant exige un observateur:BGPMon a signalé 417 038 nouvelles origines, tandis que RIPE NCC a décrit plus de 400 000 préfixes touchés. Ces mesures établissent une échelle extraordinaire à des points d’observation nommés. Elles ne prouvent pas que chaque réseau a installé chaque chemin ni fait transiter le trafic par Indosat.
La cause première reste attribuée:Les comptes rendus contemporains ont décrit un problème opérationnel et des signalements répétés d’une fenêtre de maintenance échouée ou d’un amont non filtré. La configuration complète d’Indosat, l’enregistrement des modifications, l’état de génération des politiques et le rapport d’incident interne ne sont pas publics.
La responsabilité suit le contrôle du routage:Indosat contrôlait ce qu’AS4761 annonçait et exportait. Les voisins directs contrôlaient les filtres de préfixes, d’origine, de relation et de nombre maximal de préfixes. Les autres systèmes autonomes contrôlaient l’acceptation, la préférence, l’export en aval, la surveillance et l’escalade.
Les registres consignent l’autorité; les routeurs appliquent la joignabilité:Les enregistrements ASN et de ressources numériques identifient les détenteurs et les origines attendues. RIS, RouteViews et d’autres collecteurs conservent une partie de l’état en cours. Ni une entrée de registre ni un collecteur ne bloquent automatiquement une annonce.
L’autorisation d’origine et la politique de chemin sont différentes:La validation d’origine de route peut rejeter une origine en conflit avec une ROA valide, lorsque les enregistrements et la validation pertinents existent. Elle ne prouve pas à elle seule qu’un chemin de relation ou un volume de routes est approprié.
La reprise n’est pas une simple déclaration de configuration locale:Une clôture crédible montre les retraits, les origines de remplacement, la convergence à plusieurs points d’observation indépendants, les exceptions résiduelles, la politique modifiée, un comportement de nombre maximal de préfixes testé et la preuve par rejeu que la même classe de défaillance est désormais contenue.
La norme de responsabilité est le confinement reproductible:Les opérateurs doivent pouvoir montrer l’ensemble de routes autorisé, la politique générée et en cours, l’écart anormal, la première occasion de confinement, la chronologie des actions et un test de récurrence indépendant.

Figer l’incident avant de l’interpréter

La première discipline de la responsabilité en matière de routage consiste à définir exactement l’événement examiné. Le 2 avril 2014, des observateurs BGP publics ont signalé qu’AS4761, associé à Indosat, a commencé à annoncer un nombre extraordinaire de préfixes normalement annoncés par d’autres systèmes autonomes. BGPMon a compté 417 038 nouveaux préfixes et a situé l’intervalle visible approximativement entre 18 h 26 et 21 h 15 UTC.

L’analyse de RIPE NCC a décrit plus de 400 000 préfixes touchés et a utilisé les données de RIPE Routing Information Service et les visualisations RIPEstat pour reconstituer des exemples de propagation et de joignabilité. [1][2]

Ces observations suffisent à établir un incident majeur de routage interdomaine. Elles ne suffisent pas à établir toutes les affirmations qui pourraient y être associées.

Le présent article ne combine pas l’événement d’avril 2014 avec un incident de routage Indosat antérieur en 2011. Il n’incorpore pas les anomalies ultérieures d’AS4761 ni d’autres incidents impliquant des réseaux indonésiens. Il ne déduit pas un défaut opérationnel continu à partir d’événements séparés par des années. Une telle agrégation pourrait produire un récit plus large, mais elle affaiblirait les preuves nécessaires pour attribuer le contrôle, mesurer la correction et tester la récurrence.

L’événement délimité commence avec les premières origines anormales d’AS4761 observées par les moniteurs cités vers 18 h 26 UTC. Il inclut leur propagation à travers certains réseaux, les changements de joignabilité visibles depuis des points d’observation particuliers, la détection et la communication entre opérateurs, le retrait des origines anormales et le retour vers l’état de chemin attendu. Il se termine avec les dernières observations pertinentes vers 21 h 15 UTC, tout en reconnaissant que différents collecteurs peuvent voir des heures de début et de fin différentes.

Cette limite restreint également l’affirmation de cause première. BGPMon a qualifié l’échelle comme compatible avec un problème opérationnel et a évoqué des signalements de fenêtre de maintenance échouée. Les discussions entre opérateurs ont mentionné un amont non filtré. [2][3] Ce sont des descriptions contemporaines, et non un relevé forensique publié de la commande exacte, du mécanisme de redistribution des routes, de l’état du compilateur de politique, de la décision d’approbation ou du comportement de l’équipement qui ont créé les annonces.

Une analyse responsable commence donc par ce que le réseau en fonctionnement a exposé: AS4761 est apparu comme origine de centaines de milliers de préfixes; les origines anormales étaient visibles au-delà du réseau source; certains chemins et certaines joignabilités ont changé; et les origines ont ensuite été retirées. Elle traite l’intention, la cause interne et la remédiation complète comme inconnues, sauf preuve complémentaire.

Cette distinction n’est pas une prudence gratuite. Elle crée un problème réparable. Une affirmation telle que « une erreur de maintenance a provoqué un détournement mondial » est trop large pour être testée. Une affirmation telle que « AS4761 a exporté un ensemble de routes radicalement au-delà de ses origines autorisées attendues, les voisins directs ont accepté suffisamment de cet ensemble pour le propager, et les preuves publiques ne montrent pas l’ensemble complet des contrôles qui ont ensuite empêché la récurrence » identifie des limites observables et des enregistrements manquants.

Le nombre de routes est une mesure, pas une carte de chaque décision de transfert

Le nombre 417 038 est central dans le dossier public parce qu’il traduit l’échelle extraordinaire de l’événement. Il doit aussi rester lié à sa source et à sa méthode. BGPMon a signalé ce nombre comme de nouvelles origines associées à AS4761. RIPE NCC a utilisé la formulation plus large de plus de 400 000 préfixes touchés. [1][2] Les chiffres sont assez proches pour corroborer une anomalie à l’échelle d’une table complète, mais aucun ne doit être présenté comme un décompte universel installé par chaque système autonome.

BGP est un protocole de contrôle distribué. Un collecteur de routes reçoit des mises à jour sélectionnées de la part de pairs entités. Son enregistrement reflète les chemins que ces pairs ont choisi d’exporter vers le collecteur, à quel moment, selon leurs propres politiques. Un autre collecteur avec des pairs différents peut voir un sous-ensemble différent, un premier horodatage différent et une séquence de retrait différente.

Plusieurs grandeurs sont souvent confondues dans les comptes rendus d’incident:

le nombre de préfixes uniques pour lesquels une origine anormale a été observée;
le nombre de messages de mise à jour BGP;
le nombre de variantes de chemin;
le nombre de collecteurs ou de pairs ayant vu une mise à jour;
le nombre de réseaux ayant sélectionné le chemin anormal comme meilleur;
le nombre de tables de transfert l’ayant installé;
le volume de trafic transporté sur ces chemins; et
le nombre d’utilisateurs ayant subi une perte, un délai, un détournement ou aucun effet visible.

Ces grandeurs ne sont pas interchangeables. Un préfixe peut générer de nombreuses mises à jour. Un collecteur peut voir un chemin que son pair n’a pas utilisé pour tout le trafic. Un réseau peut accepter une route dans une base d’informations de routage sans la sélectionner. Un chemin sélectionné ne peut affecter que le trafic de certaines sources, car les chemins de l’Internet sont asymétriques et dépendent des politiques. Un service peut rester joignable par un chemin alternatif pendant qu’un autre réseau perd l’accès.

Le décompte soutient néanmoins une conclusion de contrôle solide. AS4761 était normalement associé à un petit ensemble de routes par rapport à la table mondiale. Une augmentation observée à plus de 400 000 origines dépassait largement toute marge de croissance ordinaire. Un voisin direct n’avait pas besoin d’un décompte mondial parfait pour reconnaître que l’ensemble reçu s’écartait d’un contrat attendu de client, de pair ou de fournisseur.

C’est pourquoi la responsabilité doit se concentrer sur l’ensemble de routes attendu et l’écart observé. Le responsable d’une session devrait pouvoir dire combien de préfixes et d’origines étaient autorisés immédiatement avant un changement, quelle augmentation était attendue, quels seuils d’avertissement et seuils durs s’appliquaient, et ce qui s’est produit lorsque l’ensemble reçu ou annoncé les a dépassés.

Une mesure d’incident reproductible documenterait les noms des collecteurs, les pairs des collecteurs, les familles d’adresses, les intervalles UTC exacts, les règles de déduplication, le comptage préfixe par rapport au comptage des mises à jour, et le prédicat de chemin AS utilisé pour identifier les routes touchées. Elle préserverait les références brutes de mise à jour ou les commandes d’extraction. Le but n’est pas de produire un nombre parfait unique. C’est de permettre à un autre opérateur de reproduire l’échelle, la chronologie et les limites de propagation sans se fier à un titre non examiné.

La mauvaise origine est visible; l’intention ne l’est pas

En fonctionnement ordinaire, un système autonome d’origine signale qu’il peut acheminer le trafic pour un préfixe annoncé. Pendant l’événement d’avril 2014, AS4761 est apparu comme origine de préfixes normalement associés à de nombreux autres réseaux. Ce comportement est souvent décrit comme un détournement, car l’origine a changé vers un système autonome qui n’était pas censé annoncer l’espace d’adressage. BGPMon a utilisé le langage du détournement dans son rapport contemporain. [2]

L’état d’origine observable n’établit pas une intention malveillante. Un détournement de route malveillant, une redistribution accidentelle, une affectation de politique incorrecte, une erreur de serveur de routes, une fuite de test et une procédure de maintenance échouée peuvent produire des symptômes de plan de contrôle qui se recouvrent. Les distinguer exige la configuration interne, des journaux, des enregistrements d’autorisation, des témoignages d’opérateurs et souvent des preuves de trafic ou de sécurité que les collecteurs publics ne possèdent pas.

L’échelle de cet événement est compatible avec une défaillance opérationnelle large. C’est une inférence, pas un rapport de cause première complet. L’article attribue donc les explications de maintenance et de filtrage à des observateurs contemporains et n’affirme pas qu’une commande exacte ou une action d’opérateur a été prouvée.

Cette limite compte à la fois pour l’équité et pour la qualité d’ingénierie. Si un événement accidentel est décrit comme une interception intentionnelle sans preuve, le compte rendu devient juridiquement et techniquement fragile. Si le même événement est balayé comme « une simple erreur », la défaillance des contrôles à plusieurs frontières de routage disparaît. La responsabilité n’exige ni accusation ni excuse. Elle exige un enregistrement de ce qui a été autorisé à s’exécuter.

Les questions de preuve sont concrètes:

Quel processus a fourni les préfixes annoncés par AS4761?
Quelle politique a permis à ces origines d’entrer dans une annonce externe?
L’ensemble de routes a-t-il été généré à partir d’un inventaire autorisé ou hérité d’une autre session?
La modification a-t-elle passé une revue, une simulation ou un déploiement progressif?
Quel instantané des routes annoncées existait avant et après la modification?
Quel voisin direct a accepté en premier l’ensemble anormal?
Quelles alertes se sont déclenchées, qui en était responsable et quelle action a suivi?
Quelles données ont montré que le retrait et la normalisation étaient complets?

Le dossier public ne répond qu’à une partie de cette liste. Cette incomplétude doit être consignée comme un manque de responsabilité, et non comblée par des spéculations.

Le réseau source détient la première frontière d’exportation

AS4761 contrôlait la frontière côté source. Quel que soit le déclencheur interne, le système de routage en fonctionnement d’Indosat a annoncé et exporté un ensemble de routes qui dépassait radicalement le périmètre attendu associé au système autonome. La première obligation est donc de définir et d’appliquer ce qu’AS4761 était autorisé à annoncer et à exporter.

Un inventaire d’origines autorisées doit relier les enregistrements de ressources numériques, les délégations clients, les dossiers de service internes, les données des registres de routage et les exceptions explicites. Il doit avoir une version, un responsable, un historique d’approbation et une date d’effet. La politique de routeur générée doit être liée par somme de contrôle à cet inventaire afin qu’un auditeur puisse distinguer l’entrée prévue de la configuration réellement déployée.

Le contrat d’exportation doit répondre à quatre questions différentes:

Quels préfixes AS4761 peut-il annoncer lui-même?
Quels préfixes clients AS4761 peut-il transporter en transit?
Quelles routes apprises de fournisseurs ou de pairs peuvent être ré-annoncées, et à qui?
Quelles exceptions temporaires existent, pourquoi existent-elles et quand expirent-elles?

Combiner ces ensembles dans un seul filtre permissif crée les conditions d’un export de table complète. Une route apprise d’un fournisseur, une table de routage complète utilisée en interne ou un flux de serveur de routes large peut traverser une session externe si la politique d’exportation est absente, attachée dans la mauvaise direction, générée à partir de mauvaises données ou contournée par une exception.

Des valeurs par défaut de politique explicites réduisent ce risque. La RFC 8212, publiée des années après l’incident, précise que les routes eBGP ne doivent pas être importées ou exportées sans politique explicite. [8] Elle ne doit pas être projetée rétroactivement comme preuve de l’implémentation d’Indosat en 2014. Elle est utile comme comparaison durable: une session doit se fermer en mode sécurisé lorsque la politique prévue est absente, plutôt que d’échanger tout jusqu’à l’ajout d’un filtre.

L’exportateur a également besoin d’un contrôle du volume de routes sur son propre ensemble annoncé. Le nombre maximal de préfixes est souvent discuté comme une fonctionnalité entrante, mais les opérateurs peuvent surveiller le nombre de routes sortantes et l’écart avant que les mises à jour ne quittent un réseau. Un contrôle avant déploiement peut comparer les annonces candidates à l’ensemble autorisé. Un garde-fou en direct peut alerter ou bloquer une augmentation qui n’a pas d’enregistrement de modification approuvé.

La preuve la plus précieuse est la différence entre l’état attendu et l’état en cours. Une déclaration post-incident selon laquelle « des filtres ont été ajoutés » ne suffit pas. Un enregistrement responsable préserverait:

l’ensemble de préfixes et d’origines autorisé avant l’événement;
la source de configuration et la politique générée;
les empreintes de configuration candidate et validée de l’équipement;
les instantanés de routes annoncées pour la session concernée;
l’ensemble anormal et la manière dont il est entré dans le traitement d’exportation;
les commandes de retrait ou la modification de politique;
l’ensemble autorisé après la reprise; et
un rejeu montrant que l’ensemble anormal est rejeté.

Cette preuve transforme un récit de configuration en test de contrôle. Elle empêche aussi qu’un nettoyage ultérieur de politique ne masque ce qui tournait réellement pendant l’événement.

Les voisins directs détiennent la première occasion de confinement externe

Le réseau source n’est pas le seul opérateur disposant d’un contrôle. Un voisin direct recevant un ensemble de routes d’AS4761 avait la première occasion externe de le contenir. Ce voisin connaissait, ou aurait dû documenter, le type de relation, l’ensemble de préfixes attendu, le volume de routes ordinaire et le contact d’escalade de la session.

Le dossier public indique qu’une grande partie de la visibilité anormale des routes est passée par des fournisseurs en Thaïlande, certaines routes se propageant plus loin. [1][2] Les relations commerciales et techniques complètes ne sont pas publiques; chaque étiquette spécifique de client, de pair ou de fournisseur ne doit donc être utilisée que lorsqu’elle est étayée. Le principe de contrôle ne dépend pas d’une étiquette contestée. Tout voisin acceptant un ensemble de routes radicalement hors du périmètre bilatéral attendu contrôlait une frontière d’importation.

Plusieurs garde-fous peuvent y opérer.

Le filtrage de préfixescompare les routes reçues à un inventaire autorisé de client ou de voisin. Il est le plus efficace lorsque l’ensemble de routes bilatéral est borné et lorsque les mises à jour de l’inventaire sont possédées et opportunes.

Le filtrage ou la validation d’originevérifie si l’origine est autorisée pour un préfixe. La validation d’origine de route fondée sur RPKI peut fournir une autorisation cryptographique lorsqu’une ROA couvrante existe et que des validateurs sont déployés. Elle n’est pas la seule source de preuve d’origine et était beaucoup moins largement déployée en 2014.

La politique de chemin AS et de relationteste si le chemin est plausible pour la session. Un client ne devrait normalement pas fournir de transit entre des amonts sans rapport. Les relations réelles peuvent être complexes; la politique a donc besoin d’exceptions explicites plutôt que de supposer que tout chemin est acceptable.

Les contrôles de nombre maximal de préfixescomparent le volume de routes reçues à une plage documentée. Une session normalement associée à des centaines ou des milliers de routes ne devrait pas livrer silencieusement des centaines de milliers. Les seuils d’avertissement et les seuils durs exigent des réponses opérationnelles différentes, et tous deux nécessitent une responsabilité désignée.

Des valeurs par défaut d’importation explicitesempêchent une session nouvelle ou mal classifiée d’accepter tout parce qu’une route map est absente.

Les contrôles d’export en avalséparent ce qu’un réseau reçoit de ce qu’il annonce aux clients, aux pairs et aux fournisseurs. Une route conservée pour diagnostic n’a pas besoin d’être propagée.

La RFC 7454 décrit le filtrage opérationnel, les limites de nombre maximal de préfixes, les contrôles de bogon et d’autres pratiques de sécurité BGP. [9] NIST SP 800-189 a ensuite organisé des pratiques d’échange interdomaine résilient, notamment le filtrage, la validation d’origine de route, la surveillance et la coordination. [13] MANRS encadre de même le filtrage, l’anti-usurpation, la coordination et l’information de routage comme des actions d’opérateurs. [14] Ce sont des points de comparaison modernes, et non la preuve que chaque garde-fou était disponible ou déployé sur les sessions pertinentes de 2014.

La question du voisin direct n’est pas « pourquoi l’Internet a-t-il fait confiance à BGP? ». C’est « pourquoi une politique bilatérale en cours a-t-elle accepté cet ensemble, et quelles preuves montrent désormais que le même ensemble serait rejeté ou mis en quarantaine? »

Le contrôle du nombre maximal de préfixes est nécessaire, mais un nombre seul n’est pas une politique

Le volume de routes extraordinaire fait de la protection par nombre maximal de préfixes un contrôle évident. Il est aussi facile de le décrire trop simplement. Une limite dure peut contenir une fuite massive, mais une limite mal choisie peut déconnecter des clients légitimes, se déclencher pendant une croissance normale ou inciter les opérateurs à fixer des seuils si élevés qu’ils n’agissent jamais.

Une conception responsable du nombre maximal de préfixes commence par l’ensemble autorisé. Le seuil doit refléter les routes actuelles, la croissance documentée, le comportement d’agrégation, les annonces de secours et les exceptions approuvées. Il ne doit pas être une fraction générique de la table mondiale ni une valeur copiée d’une autre relation.

Une conception mature comporte au moins trois états:

une plage de fonctionnement normale;
une plage d’avertissement qui alerte un canal de réponse possédé et gèle les changements risqués; et
un seuil de confinement dur avec une action documentée.

L’action dure peut varier. Un routeur peut rejeter les préfixes supplémentaires, couper la session, mettre en quarantaine l’ensemble reçu, abaisser la préférence ou invoquer l’automatisation. Chaque choix a des conséquences. Rejeter de nouvelles routes peut préserver la joignabilité établie tout en bloquant la croissance. Réinitialiser une session peut créer une panne plus large. Continuer à accepter des routes tout en envoyant seulement une alerte peut laisser le système ouvert pendant la période où la propagation compte le plus.

La réponse doit donc être testée. Les opérateurs doivent rejouer un ensemble de routes semblable à la défaillance d’avril 2014 et enregistrer si l’équipement avertit, rejette, réinitialise ou continue. Ils doivent tester à la fois une augmentation soudaine à l’échelle d’une table complète et une fuite plus lente conçue pour rester sous une alerte fondée sur le débit. Ils doivent vérifier que l’escalade atteint un responsable doté de personnel et que celui-ci a l’autorité pour contenir la session.

Le nombre maximal de préfixes doit aussi être protégé contre la dérive des exceptions. Les augmentations d’urgence et les migrations ponctuelles peuvent devenir permanentes. Chaque dérogation doit avoir une raison, un approbateur, un intervalle d’effet et une expiration ou une revue automatique. Le seuil en cours doit être visible dans les preuves de l’incident à côté du nombre de routes autorisé.

La question de responsabilité n’est pas de savoir si une configuration contient une instructionmaximum-prefix. C’est de savoir si le seuil correspond au contrat de relation, si la réponse est sûre, si les alarmes sont possédées et si un rejeu prouve le confinement.

L’autorisation d’origine et l’autorisation de chemin résolvent des problèmes différents

L’événement Indosat plaide fortement pour la validation d’origine, car AS4761 est apparu comme origine de préfixes associés à de nombreux autres réseaux. Lorsqu’une ROA valide autorise une origine différente et qu’un réseau récepteur effectue la validation d’origine de route, la route inattendue peut être classée invalide et rejetée ou dépréciée selon la politique.

La RFC 6811 spécifie la validation d’origine de préfixe BGP à l’aide de RPKI. La RFC 6483 fournit des recommandations sur les opérations de validation d’origine. [10][11] Ces documents expliquent le mécanisme, mais ne prouvent pas la couverture pertinente de 2014, l’état des ROA, la disponibilité des validateurs ni la politique de routage des voisins d’Indosat.

Trois limites doivent rester explicites.

Premièrement, la couverture RPKI en 2014 était limitée. Une route sans ROA couvrante n’est pas automatiquement invalide; elle est généralement « introuvable ». L’état actuel des ROA ne doit pas être projeté rétroactivement sur l’événement.

Deuxièmement, la validation d’origine vérifie la relation entre un préfixe et son ASN d’origine. Elle ne valide pas chaque relation de chemin AS. Une route peut avoir une origine autorisée et néanmoins fuir par un chemin de fournisseur, de pair ou de client non prévu.

Troisièmement, la validation ne modifie le routage que lorsque les opérateurs déploient des validateurs, maintiennent la disponibilité du cache, attachent une politique et décident comment traiter chaque état. Un enregistrement de registre ne s’applique pas de lui-même.

La RFC 9234 a ensuite introduit les rôles BGP et l’attribut Only-to-Customer pour améliorer la prévention des fuites de routes par une signalisation explicite des relations. [12] Là encore, c’est une comparaison de contrôle moderne, pas une description du réseau de 2014. Les rôles et OTC peuvent aider les routeurs à détecter les annonces qui violent les attentes de relations sans vallée, mais ils dépendent du déploiement et d’une configuration correcte des rôles.

L’architecture défendable superpose les contrôles:

enregistrements de ressources et d’origines pour l’autorité attendue;
filtres de préfixes et d’origines aux frontières clients;
validation d’origine de route lorsque les données existent;
politique d’importation et d’exportation sensible aux relations;
rôles BGP et OTC lorsqu’ils sont pris en charge;
confinement par nombre maximal de préfixes et par écart de routes;
politique par défaut explicite;
surveillance indépendante des anomalies; et
coordination et retrait testés.

Aucun contrôle unique ne doit être présenté comme une solution complète. L’objectif de responsabilité est une défense en profondeur avec la preuve que chaque couche traite un mode de défaillance défini.

Les registres sont des registres de responsabilité, pas des souverains de la joignabilité

Les registres de numéros Internet, les registres de routage, les ROA et les bases de données d’opérateurs sont des surfaces de preuve essentielles. Ils aident à identifier les détenteurs de ressources, l’autorité d’origine, les contacts et la politique attendue. La vue AS4761 de RIPEstat fournit une interface actuelle vers les observations d’enregistrement et de routage, tandis que l’analyse historique doit lier les affirmations à la période pertinente. [4]

Ces enregistrements ne déterminent pas la joignabilité en cours par simple déclaration. Un routeur accepte, rejette, sélectionne et exporte des routes selon le logiciel et la configuration déployés. Un registre exact peut coexister avec un filtre permissif. Un registre inexact ou obsolète peut amener un filtre généré à rejeter des routes légitimes. Une ROA signée peut classer une origine, mais seule la politique d’un réseau validant détermine le résultat opérationnel.

Cette distinction soutient un modèle de responsabilité fondé sur la réalité. Les registres doivent être évalués comme des registres comptables:

Les enregistrements de ressources et de contacts sont-ils exacts?
Les modifications sont-elles enregistrées et attribuables?
Les opérateurs peuvent-ils dériver des filtres de manière reproductible?
Les exceptions sont-elles visibles?
Les métadonnées de sécurité sont-elles à jour?
Un autre réseau peut-il vérifier l’origine attendue?

Les routeurs et les systèmes de politique doivent être évalués comme une application en cours:

La politique dérivée a-t-elle réellement été déployée?
Quelle version tournait sur la session concernée?
Rejetait-elle par défaut?
L’équipement a-t-il accepté l’ensemble anormal?
L’export en aval a-t-il préservé ou amplifié l’erreur?
L’état en cours correspondait-il à l’intention dérivée du registre?

L’événement d’avril 2014 ne peut pas être expliqué uniquement comme un problème de registre ni uniquement comme un problème de routeur. Il a exposé la couture entre l’autorité enregistrée et la politique exécutable. Si les enregistrements étaient exacts mais les filtres absents, l’application a échoué. Si la génération de politique reposait sur des enregistrements inexacts, le registre et son usage opérationnel doivent tous deux être corrigés. Si une redistribution large contournait le chemin de données prévu, les contrôles de déploiement ont échoué.

Les preuves nécessaires pour distinguer ces cas ne sont pas exotiques. Elles incluent des enregistrements de ressources datés, des données sources de politique, des filtres générés, des empreintes de configuration, des routes reçues et annoncées, et des observations de collecteurs indépendants. L’absence d’un tel enregistrement joint est elle-même une constatation de responsabilité.

Les preuves des collecteurs prouvent des observations sélectionnées, pas une convergence universelle

RIPE RIS et RouteViews préservent des données BGP historiques qui rendent possible une reconstitution indépendante. RIPE décrit RIS comme un système de mesure qui collecte et stocke des données de routage Internet. RouteViews archive les mises à jour d’avril 2014. [5][6] BGPStream du CAIDA fournit un cadre de traitement des données BGP issues des principaux projets de collecte. [18]

Ces systèmes sont une infrastructure de responsabilité, car ils préservent des preuves en dehors du réseau qui a provoqué ou propagé un incident. Ils permettent aux analystes de tester si une origine anormale est apparue, quels chemins AS l’ont portée jusqu’à certains pairs, quand les retraits sont devenus visibles et si les origines attendues sont revenues.

Leurs limites doivent faire partie de chaque affirmation.

Un collecteur voit les routes exportées par ses pairs. Il ne voit pas toutes les routes que ces pairs ont reçues ni toutes les alternatives qu’ils ont envisagées. Un horodatage de première observation est la première observation à ce collecteur, pas nécessairement la première annonce à la source. Un retrait observé chez un pair ne prouve pas la convergence mondiale. Un meilleur chemin visible sur un collecteur ne prouve pas le chemin de transfert depuis chaque utilisateur.

La diversité des collecteurs améliore la confiance. Une reconstitution d’incident doit comparer les pairs de RIS et de RouteViews dans différents réseaux et régions. Elle doit déterminer si l’origine anormale était visible depuis chaque point d’observation, combien de temps elle est restée visible, quels chemins l’ont portée et quand l’origine attendue est revenue. Les différences doivent être préservées plutôt que lissées.

L’analyse a aussi besoin d’un prédicat reproductible. Pour cet événement, un analyste pourrait identifier les mises à jour dans lesquelles AS4761 est l’origine de préfixes en dehors de son ensemble attendu. La source exacte de l’ensemble attendu, l’heure, la famille d’adresses, la gestion des doublons et la normalisation des chemins doivent être documentées. Les décomptes de routes dérivés doivent renvoyer aux intervalles d’archives brutes ou aux commandes.

Des systèmes de recherche comme BGPInspector montrent comment les événements historiques peuvent être examinés à travers plusieurs dimensions et vues de preuve. [15] Des travaux universitaires ultérieurs sur les fuites de routes et la détection démontrent en outre que la classification dépend de la topologie, des relations et de l’observation. [16] Ces outils ne remplacent pas la télémétrie des opérateurs, mais ils rendent possible une contestation indépendante.

Une clôture d’opérateur doit donc associer preuves internes et externes. Les routes internes reçues et annoncées expliquent ce qui a traversé une session. Les collecteurs externes montrent ce qui s’est échappé dans le système de routage plus large. Les deux enregistrements doivent converger vers une chronologie bornée tout en conservant l’incertitude des points d’observation.

L’impact doit être mesuré comme joignabilité, et non déduit du volume de routes

La reconstitution de RIPE NCC a montré que les effets variaient selon le point d’observation et la route. BGPMon a signalé que de nombreuses routes anormales étaient visibles via des fournisseurs en Thaïlande et que certaines se propageaient plus largement. [1][2] Cela étaye une constatation de propagation inégale et d’impact variable sur la joignabilité.

Cela n’étaye pas l’affirmation selon laquelle l’événement aurait redirigé la majeure partie du trafic Internet mondial par l’Indonésie. Un décompte proche de la taille de la table mondiale peut sembler équivalent à un contrôle de l’Internet, mais les décisions de routage sont distribuées. Les réseaux appliquent la préférence locale, la politique de chemin AS, la spécificité des préfixes, la validation d’origine et les relations commerciales. Certains conservent une route non affectée; certains préfèrent l’origine anormale; certains ne la reçoivent jamais.

L’impact doit être mesuré en couches:

Visibilité au plan de contrôle:quels collecteurs et pairs ont vu AS4761 comme une origine inattendue?

Sélection de route:quels réseaux ont sélectionné le chemin, lorsque cette information est observable?

Preuves de transfert:depuis quelles sources des données de traceroute, de looking glass ou de flux ont-elles montré un trafic suivant un chemin modifié?

Performance de service:quelles destinations ont subi des pertes, de la latence, de l’instabilité ou aucune dégradation observable?

Périmètre utilisateur:quels clients, régions ou services ont été touchés, sur la base de la télémétrie du fournisseur plutôt que du seul nombre de routes?

Conséquence de sécurité:existait-il des preuves d’accès, d’inspection ou d’altération des paquets? Le seul enregistrement public de routes ne l’établit pas.

Cette superposition évite à la fois l’exagération et la minimisation. Elle évite de traiter chaque préfixe visible comme un chemin de transfert installé mondialement. Elle évite aussi de minimiser l’incident parce que certains réseaux ont maintenu la joignabilité.

Pour les événements futurs, les opérateurs doivent préserver les mesures actives, les tables de routage, les résumés de flux, la santé des applications et les données d’impact client avec des horodatages synchronisés. La méthodologie doit tenir compte des chemins asymétriques, des sauts masqués, de l’anycast, de l’équilibrage de charge et de la géolocalisation incomplète.

La mesure clé de responsabilité n’est pas la plus grande population potentiellement touchée. C’est la capacité de chaque opérateur à relier un état de route anormal à des effets concrets sur la joignabilité, à expliquer l’incertitude et à montrer comment ses contrôles ont limité ou non la propagation.

La surveillance n’a de valeur que si elle est liée à l’action

L’événement était visible pour les moniteurs externes parce que le changement d’origine et le volume de routes étaient extraordinaires. Les systèmes publics et les communautés d’opérateurs ont aidé à faire remonter l’anomalie. Cette visibilité ne contient pas à elle seule une fuite de routes.

La surveillance doit relier quatre éléments:

une base de référence définissant les origines, préfixes, chemins et volumes de routes attendus;
une règle de détection expliquant pourquoi l’état observé est anormal;
un responsable avec autorité et canaux de contact; et
une action sûre capable de contenir ou de retirer la route.

Une alerte disant « AS4761 a annoncé 417 038 nouveaux préfixes » est utile pour le triage. Une alerte opérationnelle devrait ajouter les sessions concernées, les nombres reçus et acceptés, l’inventaire attendu, les amonts observés, la version de politique actuelle, les modifications récentes et une action de confinement recommandée.

L’horodatage des alertes doit être préservé. Une chronologie complète distingue la première mise à jour anormale, la première observation par un collecteur, la première alerte automatisée, le premier accusé de réception humain, le premier contact avec la source ou l’amont, la première action de confinement, le premier retrait et la normalisation ultérieure. Ces horodatages révèlent si le retard venait de la détection, de l’escalade, de l’autorité, du diagnostic ou de la convergence.

Les données de coordination comptent aussi. Les incidents de routage traversent les frontières organisationnelles. Les contacts doivent être à jour, joignables et habilités. MANRS traite la validation mondiale et la coordination comme une responsabilité centrale des opérateurs. [14] Un enregistrement de contact qui existe mais n’atteint pas un responsable opérationnel n’est pas un contrôle fonctionnel.

L’automatisation peut accélérer le confinement, mais elle a besoin de garde-fous. Une coupure automatique de session fondée sur un faux positif peut créer une panne. Une alerte laissant le système ouvert peut permettre à une fuite de table complète de se propager pendant que des humains enquêtent. Une conception bornée peut mettre en quarantaine les nouvelles routes, geler les modifications, abaisser la préférence ou exiger une confirmation sous des seuils définis.

L’événement teste donc plus que la détection d’anomalies. Il teste si l’observation devient une action responsable assez rapidement pour avoir une importance.

Le retrait amorce la reprise; il ne prouve pas la clôture

Les comptes rendus publics indiquent que les origines anormales ont été retirées après plusieurs heures et que l’état de routage est revenu vers les origines attendues. [1][2] Le retrait est essentiel, mais il n’est que le début d’un enregistrement de reprise.

La convergence BGP dépend de l’observateur. Les réseaux reçoivent et traitent les retraits à des moments différents. Certains peuvent conserver des routes périmées, des chemins anormaux alternatifs ou l’état de session plus longtemps que d’autres. L’amortissement des battements de route, les réinitialisations de session, la politique locale et la visibilité des collecteurs peuvent modifier l’heure de fin apparente.

Un enregistrement de reprise crédible devrait montrer:

l’ensemble exact de routes visé par le retrait;
la commande, la modification de politique ou l’action de session utilisée;
qui l’a autorisée;
quand les voisins concernés l’ont reçue;
quand les nombres internes de routes reçues, sélectionnées et annoncées se sont normalisés;
quand plusieurs collecteurs indépendants ont cessé de voir AS4761 comme origine inattendue;
quand les origines attendues sont réapparues;
quelles exceptions résiduelles subsistaient; et
si la joignabilité orientée utilisateur s’est rétablie sur la même chronologie.

L’enregistrement doit séparer le retrait de routes de la réparation de configuration. Un opérateur peut retirer manuellement de mauvaises routes en laissant le mécanisme de défaillance intact. Inversement, une modification de configuration peut être correcte localement alors que des routes périmées ou alternatives restent visibles ailleurs.

La reprise nécessite aussi une base de référence connue et saine. « Normal » doit signifier un état d’origine et de chemin autorisé lié par somme de contrôle, et non simplement l’absence d’alarme courante. Si l’ensemble autorisé a changé pendant l’incident, le changement doit être documenté plutôt que masqué dans la clôture.

Les preuves indépendantes sont particulièrement précieuses, car elles vérifient les affirmations hors du réseau source. RIS, RouteViews, les looking glasses et les opérateurs touchés peuvent montrer si les origines anormales ont disparu depuis différents points d’observation. Leurs observations ne seront pas parfaitement simultanées, et cet écart doit faire partie de l’enregistrement.

Le dossier public ne fournit pas de rapport de remédiation signé complet, de rejeu de routes ou d’inventaire d’exceptions pour l’événement de 2014. L’absence ne prouve pas qu’aucune remédiation n’a eu lieu. Elle signifie que les observateurs extérieurs ne peuvent pas vérifier la durabilité de la remédiation à partir des preuves disponibles.

Un test de récurrence doit reproduire la classe de défaillance sans l’exporter

La clôture la plus solide est un test de récurrence contrôlé. Il n’envoie pas des centaines de milliers de routes non autorisées sur l’Internet public. Il recrée la classe de défaillance dans un laboratoire, un simulateur de politique, un système de rejeu de routes ou une session isolée et prouve que chaque frontière prévue répond correctement.

Le test doit commencer par un ensemble attendu figé pour la relation AS4761. Il doit ensuite introduire:

une origine non autorisée;
un petit lot de préfixes non autorisés;
un ensemble à l’échelle d’une table complète;
une augmentation progressive conçue pour échapper à un détecteur de pic soudain;
un chemin qui viole la relation documentée;
une exception expirée;
une politique explicite manquante;
un enregistrement de registre ou de client périmé; et
un retrait suivi d’une tentative de ré-annonce.

Pour chaque cas, l’enregistrement doit montrer le filtre généré, la configuration candidate, le résultat de l’équipement ou du simulateur, l’alerte, l’accusé de réception du responsable, le comportement de confinement et la preuve exportée vers la surveillance indépendante.

Le test doit être exécuté aux frontières source et voisine. L’exportateur doit rejeter ou empêcher l’annonce non autorisée. Le voisin direct doit rejeter ou mettre en quarantaine un ensemble qui dépasse le périmètre bilatéral. La politique d’export en aval doit empêcher que des routes de diagnostic acceptées ne se propagent davantage.

Les contrôles négatifs sont importants. Le système doit continuer à accepter la croissance légitime des clients, les chemins de secours autorisés et les modifications de maintenance documentées. Sinon, un filtre strict peut devenir un risque de disponibilité et les opérateurs le contourneront.

Le test de récurrence doit être réexécuté lorsque l’inventaire de routage, les générateurs de politique, le logiciel du routeur, la topologie ou les relations changent. Un test réussi dans un environnement ne prouve pas que chaque session de production reste protégée.

Cette approche fait évoluer la question de responsabilité de « l’opérateur a-t-il promis d’être prudent? » vers « l’opérateur peut-il reproduire la défaillance et montrer que ses contrôles en cours la contiennent? »

Les contrôles modernes doivent servir de comparaisons, pas de revendications rétroactives

Plusieurs normes et cadres opérationnels publiés avant ou après 2014 fournissent une carte de contrôle utile.

La RFC 7908 définit les catégories de fuites de routes et la terminologie. [7] Sa taxonomie aide à séparer la propagation non intentionnelle du détournement d’origine, mais appliquer un type de fuite spécifique exige de connaître des relations qui peuvent ne pas être publiques.

La RFC 8212 promeut une politique explicite d’importation et d’exportation eBGP. [8] Elle traite la valeur par défaut dangereuse selon laquelle les routes circulent lorsque la politique prévue est absente.

La RFC 7454 décrit les pratiques de sécurité BGP, notamment les filtres, le nombre maximal de préfixes, la gestion des bogon et les protections opérationnelles. [9]

Les RFC 6811 et RFC 6483 traitent de la validation d’origine de route par RPKI. [10][11] Elles aident à tester si une origine est autorisée, mais n’établissent pas l’adéquation complète des chemins.

La RFC 9234 ajoute les rôles BGP et OTC pour soutenir la prévention des fuites de routes par une signalisation de relation. [12]

NIST SP 800-189 encadre l’échange de trafic interdomaine résilient autour du filtrage, de RPKI, de la surveillance, de la sécurité et de la coordination. [13]

MANRS identifie des actions d’opérateurs pour le filtrage, l’anti-usurpation, la coordination et la validation mondiale. [14]

Les outils de recherche et de mesure ajoutent une analyse indépendante. BGPInspector illustre l’inspection multidimensionnelle des incidents, les recherches ultérieures sur les fuites de routes examinent la détection et la classification, RIPEstat relie les vues d’enregistrement et de routage, et BGPStream soutient un traitement reproductible. [15][16][17][18]

La discipline historique est essentielle: ces documents ne prouvent pas ce qu’Indosat ou ses voisins avaient déployé le 2 avril 2014. Certains contrôles étaient immatures, rares ou pas encore normalisés. Une comparaison moderne peut identifier ce qui réduirait la récurrence aujourd’hui sans réécrire l’histoire.

L’objectif de contrôle en couches est stable dans le temps: définir l’autorité, restreindre l’export, valider l’import, contraindre le périmètre de relation, détecter les volumes anormaux, préserver des preuves indépendantes, coordonner la réponse, retirer en sécurité et tester la récurrence.

La responsabilité doit être répartie par frontière, et non diluée dans tout l’Internet

Les incidents interdomaines impliquent de nombreux réseaux, ce qui peut donner à la responsabilité une apparence collective et donc vague. Un meilleur modèle attribue les devoirs selon le contrôle.

Indosat / AS4761contrôlait l’état d’origine et d’exportation. Sa charge de preuve inclut l’ensemble d’origines autorisé, la source de politique, la configuration générée et en cours, l’enregistrement des modifications, les routes annoncées, l’action de retrait et le test de récurrence.

Les voisins directscontrôlaient la première acceptation externe. Leur charge inclut la documentation des relations, les filtres de préfixes et d’origines, les seuils de nombre maximal de préfixes, la politique d’importation, la politique d’export en aval, la gestion des alertes et la preuve de confinement.

Les autres systèmes autonomescontrôlaient leur propre acceptation, préférence, propagation, surveillance et communication client. Ils pouvaient avoir moins d’informations relationnelles spécifiques, mais ils restaient propriétaires de leur politique en cours.

Les registres de numéros et de routagecontrôlaient l’exactitude, la disponibilité et l’auditabilité des enregistrements de ressources et de politique dans leur périmètre. Ils ne contrôlaient pas l’application par les routeurs.

Les opérateurs de surveillance et les chercheurscontrôlaient la qualité des mesures, l’horodatage, la rétention, la méthodologie et les limites des affirmations publiques. Ils pouvaient exposer l’événement, mais pas retirer les routes.

Les fournisseurs de services et d’accèscontrôlaient la résilience, la diversité des chemins, la mesure d’impact et la communication aux clients touchés par leurs réseaux.

Les clients et utilisateurs finauxn’avaient généralement aucun contrôle pratique sur l’acceptation des routes interdomaines. Ils ne doivent pas porter le fardeau de découvrir ou de réparer la défaillance de politique d’un fournisseur.

Cette répartition évite deux erreurs. Elle empêche l’opérateur source de traiter la propagation en aval comme le problème de quelqu’un d’autre. Elle empêche aussi les autres réseaux d’affirmer que toute route reçue d’un voisin relève uniquement de la responsabilité de l’émetteur d’origine.

La première frontière évitable mérite une attention particulière. Si l’exportateur aurait pu arrêter la route, sa défaillance est primaire. Si un voisin direct disposait d’un contrat de routes attendu et a néanmoins accepté une table complète, c’était une défaillance de confinement distincte. Si des réseaux en aval pouvaient détecter un chemin ou un volume invraisemblable et ne l’ont pas fait, leurs contrôles exigent aussi un examen.

Le contrôle distribué crée des devoirs multiples, pas une absence de devoir.

La gouvernance doit exiger des preuves sans prétendre que la topologie privée est publique

Certaines preuves de routage sont nécessairement privées: contrats, configurations complètes, topologie, contrôles de sécurité et détails clients. La responsabilité n’exige pas une divulgation indiscriminée. Elle exige suffisamment de preuves vérifiables indépendamment pour étayer les affirmations sur le contrôle et la reprise.

Les opérateurs peuvent publier ou partager des attestations bornées:

la plage de nombre de routes attendue sans révéler chaque client;
les empreintes des inventaires autorisés et des filtres générés;
la confirmation qu’une politique d’importation et d’exportation explicite est attachée;
le comportement d’avertissement et de limite dure du nombre maximal de préfixes;
les horodatages des alertes, du confinement et du retrait;
les références de collecteurs indépendants;
les résultats de test pour le rejeu de table complète et de violation de relation;
le nombre et le type d’exceptions;
le responsable et le processus d’expiration de ces exceptions; et
une déclaration des lacunes de preuve non résolues.

Les régulateurs, clients, pairs et assureurs doivent demander ces artefacts plutôt que des assurances générales. Le langage contractuel peut exiger la notification, la conservation des preuves, le test des politiques de routage, des contacts à jour et un confinement coordonné.

La divulgation doit distinguer les faits, les inférences et les inconnues. Pour l’événement Indosat, l’état d’origine massif et le large intervalle temporel sont des faits solides. Une explication de maintenance ou de filtrage est un compte rendu attribué. Le mécanisme interne exact et la remédiation complète restent inconnus dans le dossier public.

Ce format protège la confidentialité légitime tout en rendant les affirmations opérationnelles contestables. Il rend aussi possible la comparaison entre incidents. Un opérateur capable de fournir une différence d’ensemble de routes reproductible et un résultat de rejeu a des preuves plus solides qu’un opérateur qui n’offre qu’une étiquette de cause première.

La gouvernance ne doit pas transformer les registres en autorités centrales imaginaires du routage. Les enregistrements de numéros, les ROA, les objets IRR et les contacts sont des entrées critiques. La joignabilité reste le résultat de politiques distribuées en cours. Une supervision efficace teste donc la connexion entre l’autorité enregistrée et le comportement déployé.

L’événement d’avril 2014 a été un test de contrôle de table complète

La leçon la plus durable de l’événement AS4761 n’est pas que BGP repose sur la confiance ni qu’un opérateur a commis une grande erreur. Ces affirmations sont trop générales pour attribuer une réparation.

L’événement a testé si un réseau pouvait empêcher un ensemble d’origines non autorisé à l’échelle d’une table complète de quitter sa frontière. Il a testé si les voisins directs pouvaient comparer les routes reçues à une attente bilatérale et contenir un écart radical. Il a testé si les réseaux en aval pouvaient éviter d’amplifier l’état. Il a testé si les moniteurs pouvaient fournir des preuves précises et liées à l’observateur. Il a testé si le retrait et la normalisation pouvaient être prouvés plutôt qu’affirmés.

Les preuves publiques établissent que plus de 400 000 origines inattendues associées à AS4761 sont devenues visibles le 2 avril 2014 et ont été retirées après plusieurs heures. Elles étayent une propagation inégale et des effets sur la joignabilité. Elles n’établissent ni intention malveillante, ni transfert universel, ni cause interne complète unique, ni programme de remédiation publiquement vérifiable.

Une réponse d’opérateur responsable comblerait ces lacunes avec:

un inventaire figé des préfixes et origines autorisés;
une politique d’importation et d’exportation explicite avec rejet par défaut;
des filtres de préfixes et d’origines générés;
des contrôles de chemin sensibles aux relations;
un avertissement et un confinement dur par nombre maximal de préfixes;
une validation d’origine de route lorsque les données pertinentes existent;
des exceptions contrôlées avec responsables et expiration;
une surveillance indépendante multi-points;
un enregistrement horodaté de confinement et de retrait; et
un rejeu prouvant que la même classe de défaillance est rejetée aux frontières source et voisines.

La norme n’est pas la perfection. Le routage interdomaine est distribué, les relations changent, les enregistrements peuvent retarder et la visibilité est incomplète. La norme est que chaque opérateur puisse identifier la frontière qu’il contrôle, montrer quelle politique y tournait, expliquer ce qui s’est écarté de l’attente, agir dans un processus testé et fournir la preuve que l’état de route autorisé est revenu.

C’est la différence entre un incident qui se termine simplement et un incident qui produit de la responsabilité.

Sources

[1]RIPE NCC Labs, « Fuites BGP en Indonésie »

[2]BGPMon, « Incident de détournement aujourd’hui par Indosat »

[3]Archive de la liste de diffusion RIPE BCOP, discussion d’opérateurs d’avril 2014

[4]RIPEstat, AS4761

[5]RIPE NCC, Service d’information de routage

[6]RouteViews, archive des mises à jour BGP d’avril 2014

[7]RFC 7908, Définition du problème et classification des fuites de routes BGP

[8]RFC 8212, Comportement de propagation de route BGP externe par défaut sans politiques

[9]RFC 7454, Opérations et sécurité BGP

[10]RFC 6811, Validation d’origine des préfixes BGP

[11]RFC 6483, Validation de l’origine des routes à l’aide de RPKI et des ROA

[12]RFC 9234, Prévention et détection des fuites de routes à l’aide des rôles dans les messages UPDATE et OPEN

[13]NIST SP 800-189, Échange de trafic interdomaine résilient

[14]MANRS, Actions pour les opérateurs de réseau

[15]Université de l’Oregon, rapport de recherche BGPInspector

[16]arXiv, recherche sur la détection des fuites de routes

[17]RIPE 68, présentation RIPEstat

[18]Documentation de BGPStream du CAIDA

La fuite de routes d’Indosat en 2014 a érigé les contrôles d’export de table complète en test de responsabilité