Safe Host 2019: fuite de routes et responsabilité

Synthèse

Périmètre d’événement figé:Cet article couvre la fuite de routes de Safe Host AS21217 vers China Telecom AS4134 observée le 6 juin 2019 ainsi que les preuves immédiates de propagation et de reprise. Il ne fusionne pas l’événement avec la fuite distincte du 24 juin 2019 impliquant Verizon, DQE et Cloudflare, ni avec d’autres controverses de routage liées à China Telecom.
Les chiffres doivent être attribués:Les comptes publics évoquent plus de 70 000 routes dans certaines mesures et plus de 40 000 routes IPv4 dans une autre reconstitution. Les chiffres dépendent du collecteur, de l’intervalle, de la famille de routes, du traitement des doublons et de ce qu’un analyste considère comme faisant partie de l’événement. Aucun décompte public ne doit être présenté comme une table globale universelle.
Un chemin du plan de contrôle n’est pas une constatation de surveillance:Les collecteurs de routes et les mesures de chemins peuvent montrer que l’AS4134 est entré dans les chemins observés et qu’une partie du trafic a suivi des routes inattendues depuis des points de vue spécifiques. Ils ne prouvent pas à eux seuls l’emplacement physique de chaque paquet, l’inspection des paquets, l’accès aux données ou une intention malveillante.
La responsabilité suit le contrôle opérationnel:Safe Host contrôlait ce que l’AS21217 exportait. China Telecom contrôlait ce que l’AS4134 acceptait et propageait. Les autres réseaux de transit et d’accès contrôlaient leurs propres décisions d’import, de préférence, d’export en aval, de surveillance et d’escalade. Les utilisateurs finaux n’avaient aucun moyen pratique de corriger l’état des routes.
L’incertitude relationnelle doit rester visible:Les discussions publiques entre opérateurs n’ont pas établi une étiquette commerciale unique et incontestée pour la connexion Safe Host–China Telecom. La défaillance de responsabilité observable est la propagation au-delà du périmètre prévu, et non une affirmation rétrospective selon laquelle toutes les conditions contractuelles privées seraient connues.
Les registres sont nécessaires mais ne s’auto-appliquent pas:Les enregistrements ASN, d’adresses, IRR et RPKI peuvent identifier les ressources et les origines attendues. Ils ne peuvent pas encoder chaque relation ni forcer un routeur à rejeter un chemin non prévu. La politique en vigueur a déterminé quelles annonces devenaient des chemins atteignables.
RPKI ne traite qu’une partie du problème:La validation d’origine de route peut rejeter une origine conflictuelle lorsqu’un ROA valide existe. Une fuite de route peut conserver une origine autorisée tout en transitant par un fournisseur, pair ou client non prévu. Les filtres tenant compte des relations, la validation du cône client, les contrôles de nombre maximal de préfixes, les valeurs par défaut explicites, la surveillance et la coordination restent nécessaires.
La reprise exige une preuve indépendante:Une correction locale de configuration n’est pas un enregistrement complet de reprise. Une remédiation responsable montre les retraits, les chemins de remplacement, la convergence depuis plusieurs points de vue, les exceptions résiduelles, les filtres mis à jour, les alarmes testées et une relecture démontrant que la même classe d’annonces est désormais rejetée ou contenue.

Figer l’événement avant d’attribuer les responsabilités

La responsabilité des infrastructures commence par fixer le périmètre de l’événement. Le 6 juin 2019, des observateurs publics du routage ont signalé que Safe Host, système autonome 21217, a annoncé un très grand ensemble de routes à China Telecom, système autonome 4134, via une interconnexion à Francfort. China Telecom a accepté les annonces et les a propagées. Pour certaines destinations et certains points de vue observés, l’AS4134 est par conséquent apparu dans des chemins qui ne l’auraient normalement pas inclus.

Des rapports contemporains et ultérieurs ont associé l’événement à une accessibilité perturbée ou dégradée touchant des parties de l’infrastructure mobile et de services européenne. [1][2][3][4][5][6][7]

Ces propositions sont suffisamment solides pour étayer une analyse de responsabilité de routage. Elles ne soutiennent pas toutes les affirmations qui ont circulé autour de l’incident.

Le dossier public ne divulgue pas la configuration complète d’export de Safe Host, la configuration complète d’import de China Telecom, chaque objet de politique de routage, toutes les conditions bilatérales, chaque décision de préférence locale, tous les historiques d’alertes, ni l’identité de chaque personne ayant approuvé ou modifié la politique. Il n’établit pas d’intention malveillante. Il ne montre pas que tout le trafic européen a été affecté. Il ne prouve pas que chaque paquet dont le chemin du plan de contrôle comprenait l’AS4134 a été physiquement acheminé par la même géographie, inspecté, conservé ou altéré.

La date est importante parce que juin 2019 a connu d’autres incidents de routage. La fuite ultérieure impliquant Verizon, DQE et Cloudflare a concerné des réseaux, des mécanismes et des effets de service différents. Combiner ces événements produirait un récit spectaculaire mais un dossier de responsabilité faible. Un responsable de remédiation ne peut pas corriger un incident dont l’ensemble de routes, l’intervalle de temps, la frontière relationnelle et les contrôles responsables ont été flous avec un autre événement.

La question délimitée est donc précise: comment un ensemble extraordinaire de routes est-il sorti de l’AS21217, pourquoi l’AS4134 a-t-il accepté et propagé ces routes, comment les autres réseaux ont-ils réagi, quelles preuves montrent les changements de chemin qui en ont résulté, et quelles preuves démontreraient que l’état des routes a été retiré et contraint contre toute récurrence?

Ce cadrage empêche également qu’une inférence géopolitique remplace les preuves d’ingénierie. Le routage transfrontalier peut avoir des implications de sécurité, et les opérateurs doivent prendre au sérieux les chemins internationaux inattendus. Mais un chemin inattendu est d’abord un événement de routage observable. L’intention, l’accès et les conséquences juridiques exigent des preuves supplémentaires. L’analyse de responsabilité doit devenir plus prudente, et non moins prudente, lorsque la route traverse une frontière politiquement sensible.

Le désaccord sur le nombre de routes est un problème de preuve, pas une raison d’écarter l’événement

Les descriptions publiques indiquent couramment que l’AS21217 a fait fuiter plus de 70 000 routes et que l’événement a duré plus de deux heures. Une autre reconstitution de l’incident décrit plus de 40 000 routes IPv4. [1][2][4][5] Ces chiffres ne sont pas nécessairement mutuellement exclusifs. Ils peuvent refléter différents collecteurs, familles d’adresses, fenêtres temporelles, comptages mises à jour contre préfixes, déduplication de chemins et définitions des annonces appartenant à l’événement.

Un collecteur BGP enregistre ce que ses pairs entités lui exportent. Un collecteur peut recevoir un chemin anormal qu’un autre ne voit jamais. Un pair peut n’exporter que son meilleur chemin sélectionné. Un analyste peut compter les préfixes uniques, les mises à jour de route, les variantes de chemin ou les combinaisons d’origines. La première mise à jour observée chez un collecteur n’est pas nécessairement la première mauvaise annonce partout, et le dernier retrait chez un collecteur n’est pas nécessairement la fin de l’état obsolète sur tous les réseaux.

Un rapport responsable exige donc un protocole de comptage. Un rapport d’incident défendable indiquerait:

quels points de vue RouteViews, RIPE RIS, opérateur ou de mesure ont été utilisés;
les horodatages exacts de début et de fin ainsi que la norme de temps;
si IPv4 et IPv6 ont été tous deux inclus;
si la métrique compte les préfixes uniques, les mises à jour, les variantes de chemin ou les origines;
comment les annonces dupliquées et les remplacements de routes ont été traités;
quel motif de chemin AS définissait une route affectée;
comment les retraits et les chemins normaux ultérieurs ont été appariés à l’ensemble anormal; et
quelles parties du réseau sont restées hors observation.

Sans ce protocole, un décompte de routes peut devenir un signal d’autorité plutôt qu’une preuve. Un nombre plus élevé peut attirer l’attention, tandis qu’un nombre plus faible peut sembler plus prudent. Ni l’un ni l’autre n’est fiable à moins qu’un autre analyste puisse reproduire la méthode.

L’incertitude ne rend pas l’événement petit. Des dizaines de milliers de routes étaient extraordinaires par rapport à tout ensemble d’annonces borné plausible pour une interconnexion. Un contrôle de nombre maximal de préfixes ou de volume de routes ne devrait pas avoir besoin d’un décompte final d’incident parfaitement convenu avant de détecter que l’ensemble reçu est radicalement hors attente.

Cette distinction est importante sur le plan opérationnel. Les seuils doivent être fondés sur l’ensemble de routes autorisé et attendu pour une relation, avec des marges de croissance documentées et des exceptions explicites. Ils ne doivent pas reposer sur l’hypothèse que la prochaine défaillance ressemblera au nombre final d’un rapport historique. Le contrôle doit réagir lorsque la réalité s’écarte du contrat relationnel, et pas seulement lorsqu’un décompte d’incident célèbre est dépassé.

Une fuite de route est une défaillance exécutable de politique relationnelle

BGP distribue l’accessibilité entre des systèmes autonomes exploités indépendamment. Le protocole de base transporte préfixes, chemins, attributs et retraits. Il ne contient pas de vérité commerciale universelle pour chaque session. Les opérateurs expriment les relations client, fournisseur, pair, serveur de routes, de secours et à usage spécial par la configuration, la génération de politiques, les communautés, les filtres et les processus opérationnels.

Une route apprise dans une relation n’est pas automatiquement éligible à l’exportation dans toutes les autres relations. Un client annonce généralement ses propres préfixes et les routes pour lesquelles il est autorisé à fournir un service. Un fournisseur peut annoncer une large accessibilité à un client. Les pairs échangent généralement leur propre accessibilité et celle de leurs clients plutôt que de fournir un transit gratuit entre fournisseurs non liés. Les accords réels peuvent être plus complexes, mais l’existence d’exceptions rend la politique explicite plus importante, et non moins.

La RFC 7908 a fourni plus tard une taxonomie pour les routes propagées au-delà du périmètre prévu. [14] La valeur de cette taxonomie est qu’elle se concentre sur la propagation observable et la politique relationnelle plutôt que de supposer une intention malveillante. Les discussions entre opérateurs autour de l’événement de 2019 n’ont pas réglé chaque étiquette relationnelle ni un type de fuite incontesté. [8][9] Cette incertitude doit rester dans le dossier.

Le comportement externe central reste néanmoins visible. L’AS21217 a annoncé un ensemble de routes dont l’échelle et la portée étaient incompatibles avec une attente d’interconnexion étroite. L’AS4134 a accepté et exporté suffisamment de cet ensemble pour que les chemins se propagent. D’autres réseaux ont ensuite appliqué leur propre politique: certains ont accepté le chemin, certains l’ont peut-être préféré, certains l’ont propagé, certains l’ont filtré, et certains ont conservé des alternatives non affectées.

Qualifier cela de défaillance distribuée ne doit pas le rendre sans propriétaire. Safe Host contrôlait la frontière d’export à l’AS21217. China Telecom contrôlait la première frontière visible d’import et d’export en aval à l’AS4134. Chaque système autonome ultérieur contrôlait si le chemin entrait dans sa base d’informations de routage, devenait un chemin sélectionné, entrait dans la table de transfert ou était annoncé à un autre voisin. Les collecteurs de routes contrôlaient la qualité et la conservation des preuves indépendantes. Les opérateurs de services et d’accès contrôlaient la résilience et la communication avec les utilisateurs.

Les obligations ne sont pas identiques. L’exportateur a l’obligation la plus directe de contraindre ce qui quitte son réseau. Un importateur direct a une puissante opportunité de confinement parce qu’il connaît la relation bilatérale et peut rejeter les annonces qui n’y correspondent pas. Les réseaux plus éloignés peuvent avoir moins de connaissances spécifiques, mais ils contrôlent toujours les limites de nombre maximal de préfixes, la validation d’origine, la politique relationnelle, la surveillance des anomalies et l’escalade.

L’expression « BGP a accepté les routes » est donc incomplète. Un logiciel exécutant une politique configurée a accepté les routes. Le protocole a transporté l’annonce; les opérateurs ont déterminé les contraintes.

La responsabilité d’export commence par un contrat de routes autorisé

Un exportateur doit pouvoir définir l’ensemble de routes qu’une session est autorisée à annoncer. Ce contrat peut être construit à partir de l’inventaire client, des objets de registre de routage, des données RPKI, des enregistrements de service internes, de l’autorité déléguée et d’exceptions explicites. Quelles que soient les sources, la politique résultante a besoin d’un propriétaire, d’un temps de génération, d’une version, d’un chemin de révision et d’une méthode pour prouver ce qui est parvenu au routeur.

Pour l’AS21217, un dossier de responsabilité post-événement distinguerait au moins quatre ensembles:

les routes que Safe Host était autorisé à faire naître;
les routes clients que Safe Host était autorisé à faire transiter;
les routes larges apprises d’un autre fournisseur ou pair;
les routes que la politique AS21217-vers-AS4134 a effectivement exportées pendant l’événement.

La différence entre l’ensemble prévu et l’ensemble réel est la constatation technique centrale. Elle est plus utile qu’une déclaration générique selon laquelle une erreur de configuration s’est produite.

La politique d’export devrait par défaut ne rien annoncer jusqu’à ce qu’une politique prévue soit attachée. La RFC 8212 formalise la valeur opérationnelle d’une politique d’import et d’export eBGP explicite. [15] Une posture de rejet par défaut ne résout pas toutes les erreurs de génération ou d’attachement, mais elle élimine l’hypothèse dangereuse selon laquelle une session nouvelle ou mal classée devrait tout échanger jusqu’à ce que quelqu’un ajoute des filtres.

Le contrat de routes a également besoin de tests négatifs. Un pipeline de politique devrait prouver qu’il rejette:

une table de routage complète reçue d’une source censée annoncer un ensemble borné;
un préfixe absent de l’inventaire client autorisé;
un chemin contenant une séquence de relations impossible ou non autorisée;
une route par défaut inattendue;
une augmentation soudaine du nombre de routes hors d’une fenêtre de croissance documentée;
des routes obsolètes qui subsistent après le retrait de l’autorité; et
une exception dont l’approbation a expiré.

La seule revue de configuration est une preuve faible parce que la source revue peut différer de la configuration générée, du candidat déployé ou de l’état en cours d’exécution. Un processus crédible enregistre les données source, le filtre généré, le diff de l’appareil, le résultat de la validation, l’ensemble de routes annoncées observé et le résultat indépendant du collecteur.

Le contrôle des changements doit être échelonné. Une mise à jour de politique peut être testée contre les données BGP enregistrées, appliquée à une session canari, surveillée pour tout delta de route inattendu et annulée sans propagation large. Une simulation de fuite de route doit faire partie des tests de résilience, et non être réservée à un incident.

La responsabilité d’export inclut également la préparation au retrait. Un opérateur doit savoir arrêter rapidement une annonce anormale sans remplacer un événement de routage par une panne plus large. Cela exige une autorité nommée, des commandes ou une automatisation testées, des contacts de pairs, des critères de route-refresh et de réinitialisation de session, ainsi que des moniteurs externes montrant si le changement s’est propagé.

La responsabilité d’import est la première opportunité de confinement externe

La responsabilité d’un importateur est parfois décrite comme secondaire parce qu’il n’a pas créé la mauvaise annonce. C’est trop faible pour une infrastructure interdomaine. Un voisin direct contrôle la première frontière externe et dispose souvent d’informations que les réseaux distants n’ont pas: la relation bilatérale, le volume de routes attendu, les préfixes autorisés, les chemins AS connus, l’historique des exceptions et le canal de contact.

L’AS4134 compte donc indépendamment de l’AS21217. Les preuves publiques soutiennent que China Telecom a accepté et propagé l’ensemble de routes extraordinaire. Le dossier ne divulgue pas tous les filtres ni toutes les décisions internes, mais le résultat observé montre que les contrôles d’import et d’export en aval n’ont pas contenu l’événement à cette frontière.

Un importateur tenant compte de la relation peut combiner plusieurs contrôles.

Premièrement, les filtres de préfixes peuvent être générés à partir des enregistrements autorisés de clients et de ressources. Les données doivent être à jour, versionnées et réconciliées avec le contrat de service réel. Une liste d’autorisation obsolète peut rejeter une croissance légitime; une liste d’autorisation trop large peut transformer le filtre en théâtre.

Deuxièmement, les contraintes de chemin AS peuvent tester si une annonce est plausible pour la relation. Un client ne devrait généralement pas annoncer un chemin impliquant un transit entre fournisseurs non liés. Les données de cône client sont imparfaites, de sorte que les exceptions et l’incertitude exigent un traitement opérationnel, mais des preuves relationnelles imparfaites peuvent encore soutenir la détection et la révision.

Troisièmement, les contrôles de nombre maximal de préfixes et de volume de routes peuvent détecter un écart radical par rapport à l’attente. Le seuil d’avertissement doit alerter un canal détenu avant la limite dure. La réponse dure doit être documentée: rejeter les nouvelles routes, fermer la session, mettre en quarantaine l’ensemble ou invoquer une autre action bornée. Le comportement d’ouverture en cas d’échec doit être explicite plutôt qu’accidentel.

Quatrièmement, une politique d’import explicite empêche une session de devenir permissive parce qu’une route map est absente, mal nommée ou attachée dans la mauvaise direction.

Cinquièmement, la validation d’origine peut rejeter une origine invalide lorsqu’un ROA valide couvre le préfixe. Elle ajoute une preuve solide mais ne prouve pas que le chemin est approprié.

Sixièmement, la surveillance des anomalies peut comparer les routes reçues et acceptées avec la base relationnelle, les collecteurs mondiaux et les changements connus. Une alerte doit inclure le chemin fautif, le nombre de routes, l’ensemble attendu, la version de politique, les pairs affectés et une action de confinement sûre.

L’importateur contrôle également l’export en aval. Même si une route est conservée pour le diagnostic, elle n’a pas besoin d’être propagée aux clients, pairs et fournisseurs. Séparer l’acceptation, la sélection, le transfert et les contrôles d’annonce peut empêcher qu’une défaillance ne devienne un événement distribué.

Ces contrôles imposent des coûts opérationnels. Les filtres exigent une maintenance. Les limites de nombre maximal de préfixes peuvent créer des pannes si elles sont définies avec négligence. Les données relationnelles peuvent être incomplètes. Des exceptions d’urgence peuvent être nécessaires. La responsabilité ne nie pas ces compromis. Elle exige des opérateurs de les documenter, de les tester et de montrer pourquoi l’exposition résultante est acceptable.

Les preuves de chemin AS ne doivent pas être confondues avec une preuve concernant chaque paquet

La nature transfrontalière de l’événement a suscité une inquiétude compréhensible. Les analyses publiques ont montré l’AS4134 apparaissant dans des chemins pour des destinations associées à des opérateurs et services mobiles européens. Des rapports de mesure ont également décrit un trafic suivant des chemins inattendus depuis des points de vue spécifiques. [1][2][3][4][5][7]

Quatre couches de preuve doivent rester distinctes.

La première est lapropagation du plan de contrôle. Une mise à jour BGP observée par RouteViews, RIPE RIS ou un autre collecteur montre qu’un chemin a été annoncé au pair de ce collecteur. Elle soutient des déclarations sur la visibilité de la route à un moment et depuis un point de vue.

La deuxième est lasélection de route. Un réseau peut recevoir plusieurs chemins et en sélectionner un selon la préférence locale, la longueur du chemin, les communautés, la validation d’origine et d’autres politiques. Un collecteur ne voit souvent que le chemin que son pair exporte, et non tous les chemins considérés.

La troisième est lecomportement de transfert. Une route sélectionnée peut entrer dans la table de transfert et transporter du trafic, mais un traceroute ou une mesure active est nécessaire pour tester le chemin depuis une source spécifique. Même alors, la correspondance IP-localisation, les sauts cachés, MPLS, le routage asymétrique, l’équilibrage de charge et les différences de chemin de réponse limitent l’inférence.

La quatrième est lagestion des paquets et la conséquence de sécurité. Un chemin de transfert traversant un système autonome ne prouve pas à lui seul l’inspection des paquets, l’accès au contenu, la conservation, l’altération ou l’intention. Le chiffrement, les protocoles d’application, le comportement des terminaux et les opérations réseau internes comptent.

Un compte rendu solide d’incident aligne ces couches par horodatage. Il peut dire qu’une route avec un chemin AS particulier est devenue visible, que des mesures actives depuis des emplacements spécifiés ont ensuite observé un chemin de transfert modifié ou un service dégradé, et que le comportement s’est normalisé après les retraits. Il ne doit pas réduire ces observations à une déclaration universelle sur tout le trafic.

Cette discipline est particulièrement importante lorsque le chemin est politiquement sensible. Les preuves peuvent justifier une enquête de sécurité et des contrôles plus stricts. Elles ne justifient pas de substituer une suspicion géopolitique à une preuve au niveau paquet.

Les opérateurs doivent préserver les données nécessaires à cette distinction: mises à jour brutes, bases d’informations de routage, résultats de looking glass, traceroutes, résumés de flux, mesures de perte de paquets, santé des applications, enregistrements de synchronisation temporelle et méthode utilisée pour cartographier les sauts réseau. La conservation doit être suffisante pour reconstituer la période avant, pendant et après l’événement.

Les collecteurs de routes sont une infrastructure de responsabilité avec des angles morts connus

RouteViews et RIPE RIS fournissent des preuves indépendantes indispensables pour les incidents interdomaines. Leurs archives de juin 2019 et leur documentation de mesure rendent possible une reconstitution ultérieure. [12][13] RIPEstat fournit également une surface de preuve pour l’AS21217 et l’AS4134, bien que les enregistrements actuels ne doivent pas être projetés dans le passé sans qualification. [10][11]

Les collecteurs ne sont pas omniscients. Ils reçoivent des routes de pairs sélectionnés selon les politiques d’export de ces pairs. Ils peuvent ne pas voir un chemin confiné à une autre partie de la topologie. Ils peuvent voir un meilleur chemin mais pas les alternatives. Leurs horodatages enregistrent l’arrivée au collecteur, et non la première cause mondiale. Les réinitialisations de session, les mises à jour dupliquées, l’amortissement des battements de route et la disponibilité du collecteur peuvent affecter l’enregistrement.

Une reconstitution responsable doit utiliser plus d’un collecteur et documenter leurs différences. Elle doit conserver les fichiers bruts ou des références d’archives précises, le code ou les commandes d’analyse, les règles de normalisation et les jeux de données dérivés. Elle doit enregistrer le pair collecteur utilisé pour chaque affirmation.

La télémétrie des opérateurs peut combler certaines lacunes. Les instantanés de routes reçues et annoncées à la session directe montrent ce qui a traversé la frontière relationnelle. Les bases d’informations de routage locales montrent la sélection. Les tables de transfert et les flux échantillonnés montrent l’utilisation. Les journaux de modifications et les dépôts de politiques relient l’état observé à la configuration déployée. Les rapports de pairs ajoutent une confirmation indépendante.

Les preuves doivent également conserver les résultats négatifs. Si un collecteur n’a pas vu le chemin, cela ne prouve pas l’absence globale du chemin, mais cela peut contraindre la propagation. Si un service est resté accessible depuis un emplacement, cela ne réfute pas l’impact ailleurs, mais cela peut révéler une diversité de chemins.

Les rapports d’incident publics citent souvent un graphique de collecteur sans expliquer ces limites. Cela crée une fausse précision et transforme les conflits sur les nombres en conflits sur la question de savoir si l’événement a eu lieu. Un meilleur rapport traite le collecteur comme un témoin borné: précieux, reproductible et incomplet.

Les enregistrements de registre sont des registres, pas une application de routeur

L’événement Safe Host se situe directement sur la surface de contrôle du routage BGP, des preuves de registre ASN et IP, et des relations de peering ou de transit.

Un enregistrement ASN peut identifier l’AS21217 et l’AS4134. Les registres d’adresses peuvent identifier les allocations et les assignations. Les objets de l’Internet Routing Registry peuvent publier les origines et politiques prévues. RPKI peut fournir une autorisation d’origine signée. Ces enregistrements améliorent l’unicité, l’exactitude, l’historique de transfert, les métadonnées de sécurité et la coordination opérationnelle.

Ils ne déterminent pas le chemin en cours d’exécution.

Une entrée de registre ne connaît pas chaque relation commerciale privée. Un objet IRR ne force pas un routeur à charger un filtre généré. Un ROA indique quelle origine est autorisée pour un préfixe et la longueur maximale; il n’indique pas quels fournisseurs ou pairs peuvent transporter cette route. Un contact abuse ou NOC ne garantit pas qu’une alerte atteigne une personne habilitée à retirer des routes.

C’est pourquoi la légitimité du registre doit être comprise à travers la qualité du registre plutôt qu’une souveraineté imaginée sur le routage. Le conservateur fournit des preuves que les opérateurs peuvent utiliser. Les systèmes en cours d’exécution, les politiques et les interconnexions déterminent l’accessibilité.

La primauté du code en cours d’exécution rend la gouvernance testable. Un conseil d’administration peut exiger des enregistrements d’autorisation de route, mais il doit aussi exiger des preuves que ces enregistrements sont récupérés, validés, transformés en politique, déployés et surveillés. Un auditeur peut inspecter un objet de route IRR, mais il doit tracer l’objet à travers le générateur de politique jusqu’à un appareil et injecter une annonce de test conflictuelle.

Le registre lui-même a besoin de contrôles. Les enregistrements de ressources doivent être uniques, à jour, authentifiés, transférables par un processus documenté et récupérables en cas de perturbation organisationnelle ou d’infrastructure. Des enregistrements obsolètes ou ambigus peuvent rendre le filtrage strict opérationnellement risqué. Les opérateurs peuvent alors créer de larges exceptions, qui doivent avoir des propriétaires, des dates d’expiration et une surveillance.

La couche de réalité rejette deux récits faciles. L’un dit que le routage décentralisé signifie que personne n’est responsable. L’autre dit qu’un registre central peut commander la correction des routes. Le système réel est un réseau d’opérateurs autonomes utilisant des preuves partagées, une politique bilatérale, du code en cours d’exécution et de la coordination. La responsabilité suit les points où ces éléments peuvent être modifiés et vérifiés.

Supprimer l’AS21217, l’AS4134, les annonces BGP, la politique relationnelle, les collecteurs de routes et les preuves de retrait de cet article détruit la thèse. La surface de contrôle du réseau n’est pas une métaphore ajoutée à un incident d’entreprise générique. C’est l’incident.

RPKI est précieux, mais la validité d’origine n’est pas une autorisation de chemin

RPKI et la validation d’origine de route sont souvent proposés après des incidents de routage. Ils méritent un traitement précis.

La RFC 6811 décrit comment un routeur peut classer une route par rapport aux données ROA validées. [16] Une route peut être valide, invalide ou introuvable selon l’origine annoncée, le préfixe, la longueur maximale et les enregistrements validés disponibles. Rejeter ou déprécier les routes invalides peut prévenir certaines erreurs d’origine et détournements.

Une fuite de route peut conserver l’origine légitime. Le problème peut être qu’une route autorisée a été exportée par une relation non prévue puis propagée plus loin. L’origine reste valide tandis que la politique de chemin est erronée. La validation d’origine seule n’encode pas qui est client, fournisseur ou pair, ni si une route apprise d’une relation peut être exportée dans une autre.

Cette limitation n’est pas un argument contre RPKI. C’est un argument en faveur de contrôles en couches.

Un opérateur doit déployer la validation d’origine avec une politique documentée, surveiller les routes invalides et introuvables, maintenir ses propres ROA et coordonner les exceptions. Il doit également maintenir des filtres de préfixes et de chemins, des politiques d’import et d’export explicites, des preuves de cône client, des contrôles de nombre maximal de préfixes, la détection de fuites de route, la coordination entre pairs et une surveillance indépendante.

RPKI peut également renforcer la responsabilité après un incident. Il aide à distinguer un conflit d’origine d’une fuite relationnelle et fournit des preuves signées sur l’autorisation à un moment donné. La validation historique exige un état validé archivé; utiliser les ROA d’aujourd’hui pour juger une route de 2019 sans qualification peut être trompeur.

La même prudence s’applique aux normes et pratiques ultérieures. La RFC 8212, les actions MANRS et les orientations NIST fournissent des cadres de contrôle utiles. [15][17][18] Ils doivent être utilisés pour concevoir la remédiation actuelle, et non pour inventer une preuve sur ce que chaque opérateur avait déployé ou devait contractuellement pendant l’événement.

Les limites de nombre maximal de préfixes sont nécessaires et faciles à mal utiliser

Le volume de routes extraordinaire fait du contrôle de nombre maximal de préfixes une question évidente. Un voisin direct qui annonce normalement un ensemble borné ne devrait pas pouvoir envoyer des dizaines de milliers de routes inattendues sans avertissement ni confinement.

Pourtant, une limite de nombre maximal de préfixes n’est pas un nombre unique copié d’une liste de contrôle sectorielle. Elle doit être dérivée de l’ensemble de routes attendu de la relation, de la croissance légitime, des schémas de maintenance, des familles d’adresses et de l’impact de défaillance. Une limite trop élevée ne contient pas l’événement. Une limite trop basse peut fermer une session saine et provoquer une panne.

Une conception mature sépare les seuils d’avertissement et d’action. L’avertissement doit atteindre un canal opérationnel détenu avec contexte avant la réponse dure. La réponse dure peut rejeter les routes en excès, préserver le dernier ensemble autorisé connu, mettre la session en quarantaine ou la fermer. Le comportement choisi doit être testé.

Les changements de seuil exigent une gouvernance. Une augmentation d’urgence doit identifier le demandeur, les preuves, l’approbateur, l’expiration et la surveillance. Sinon, une exception temporaire peut devenir une exposition permanente.

Le volume n’est également qu’une dimension. Un petit nombre de préfixes stratégiquement importants peut causer un impact grave. Les contrôles doivent combiner volume et autorisation, validité d’origine, plausibilité du chemin, périmètre relationnel, criticité de la destination et taux de changement.

L’événement Safe Host illustre pourquoi les importateurs doivent connaître le nombre de routes attendu avant un incident. Si la base n’est assemblée qu’après le début d’une fuite, le confinement devient une négociation sous pression. Un ensemble autorisé figé et un seuil testé transforment le volume anormal en signal immédiat et actionnable.

D’autres réseaux contrôlent toujours leur propre acceptation et propagation

L’exportateur et l’importateur directs sont centraux, mais la route a traversé un écosystème plus large. Cogent et d’autres réseaux sont apparus dans les discussions et rapports contemporains, parfois avec des corrections ou clarifications ultérieures. [3][5][6] La leçon n’est pas d’attribuer un score de blâme indifférencié. C’est de cartographier chaque segment de chemin observé au contrôle disponible dans ce réseau.

Un réseau de transit plus éloigné peut ne pas connaître les détails privés de la relation Safe Host-China Telecom d’origine. Il peut encore se demander si le chemin est plausible, si l’origine de la route est autorisée, si le volume est anormal, si le chemin entre en conflit avec les données de cône client et si des flux indépendants signalent une fuite.

Les opérateurs d’accès et mobiles contrôlent la diversité des routes et la résilience des services. Si des services critiques dépendent de chemins partageant des dépendances en amont, une fuite peut affecter plusieurs marques ou régions malgré une apparente diversité contractuelle. Les preuves de topologie doivent donc compléter le nombre de fournisseurs.

Les opérateurs de contenu et de cloud peuvent surveiller leurs préfixes depuis des points de vue externes, maintenir des contacts d’alerte de route et se coordonner avec les fournisseurs en amont. Ils ne peuvent pas configurer directement chaque réseau de transit, mais ils peuvent détecter des chemins inattendus et fournir des preuves qui accélèrent le confinement.

Les opérateurs de points d’échange Internet et de serveurs de routes ont des rôles différents selon la topologie. Leurs contrôles peuvent inclure la politique des entités, le filtrage des serveurs de routes, les paramètres de nombre maximal de préfixes et la coordination d’incident. Les preuves doivent établir qu’ils étaient réellement sur le chemin pertinent avant d’attribuer des devoirs.

Les régulateurs et les clients doivent éviter de traiter toutes ces parties comme interchangeables. Les questions les plus efficaces suivent la route:

Qu’est-ce que ce réseau a reçu?
Qu’est-ce qu’il a accepté?
Qu’est-ce qu’il a sélectionné?
Qu’est-ce qu’il a transféré?
Qu’est-ce qu’il a annoncé en aval?
Quelle politique et quelles preuves ont régi chaque décision?
Quelle alerte s’est déclenchée, qui la possédait et quelle action a suivi?
Comment le réseau a-t-il prouvé que l’état anormal a été retiré?

Cette méthode route par route rend la responsabilité distribuée concrète sans prétendre que chaque opérateur avait la même visibilité ou autorité.

La résilience transfrontalière doit être conçue, et non déduite des noms de fournisseurs

L’événement a également exposé une faiblesse de planification. Les organisations comptent souvent les fournisseurs, centres de données ou contrats et supposent que chaque nom représente un chemin réseau indépendant. La politique BGP peut faire converger des services nominalement distincts vers un transit, point d’échange, câble ou système autonome partagé.

L’évaluation de la résilience doit inspecter les chemins réels depuis les régions d’utilisateurs pertinentes vers les préfixes critiques. Elle doit tester les conditions normales et de défaillance, inclure IPv4 et IPv6, et identifier les systèmes autonomes et installations communs. Une fuite de route peut modifier ces chemins dynamiquement, de sorte qu’une surveillance externe continue ou échantillonnée est plus utile qu’un diagramme ponctuel.

Les contraintes transfrontalières exigent un traitement explicite. Un service peut avoir des exigences de latence, de juridiction, d’accès opérationnel ou d’exposition. Ces exigences ne peuvent pas être appliquées par une seule clause contractuelle si les changements de routage sont invisibles. La surveillance doit alerter lorsqu’un chemin entre dans un AS ou une géographie inattendue, mais l’alerte doit préserver l’incertitude de géolocalisation et distinguer les preuves du plan de contrôle du transfert de paquets.

Le chiffrement reste essentiel parce que le contrôle des chemins est imparfait. Il réduit la conséquence d’un transit inattendu, mais n’élimine pas les risques de disponibilité, de métadonnées, d’analyse de trafic ou de terminaux. Les contrôles de routage et les contrôles cryptographiques résolvent des problèmes différents.

Les exercices d’incident doivent inclure une fuite de chemin qui envoie des routes par un réseau international inattendu. L’exercice doit tester la détection technique, l’escalade NOC, les contacts fournisseurs, la communication client, l’évaluation juridique et la conservation des preuves. L’objectif n’est pas de dramatiser le risque géopolitique, mais de rendre les responsabilités de réponse exécutables avant qu’un événement ambigu ne se produise.

Un dossier de reprise crédible prouve le retrait et la normalisation

Les rapports publics indiquent que le routage anormal a persisté plus de deux heures dans certaines observations avant que les chemins ne se normalisent. [1][2][4][5][7] Comme pour les décomptes de routes, la durée exacte dépend du point de vue et de la définition. La dernière route anormale d’un observateur peut ne pas représenter une convergence mondiale.

Un dossier de reprise responsable doit distinguer:

le moment où l’export déclencheur a commencé;
le moment où le premier observateur externe l’a détecté;
le moment où une alerte a atteint une équipe dédiée;
le moment où Safe Host a modifié ou désactivé l’export;
le moment où l’AS4134 a cessé d’accepter ou de propager les routes;
le moment où les voisins directs ont observé des retraits;
le moment où les principaux collecteurs sont revenus aux chemins attendus;
le moment où le transfert et la santé des services se sont normalisés; et
le moment où les routes obsolètes ou exceptionnelles résiduelles ont été purgées.

Le dossier doit identifier la source de chaque horodatage. Les journaux de routeurs, les mises à jour des collecteurs, les systèmes de tickets, les enregistrements de chat, les mesures actives et la santé des applications peuvent utiliser des horloges différentes. La synchronisation temporelle et la normalisation font partie de la preuve.

La preuve de retrait doit opérer à plusieurs couches. Un routeur local peut montrer qu’il n’annonce plus la route. Un voisin direct peut montrer la réception d’un retrait ou d’un remplacement. Les collecteurs de routes peuvent montrer le chemin AS anormal disparaissant de leurs pairs. Les mesures actives peuvent montrer la normalisation du transfert. La télémétrie de service peut montrer la reprise.

Aucune de ces observations ne prouve à elle seule une convergence universelle. Ensemble, elles forment un dossier borné et auditable.

Le rapport doit également identifier ce qui a changé de façon permanente. Exemples:

une correction du rôle de session ou de l’attachement de route map;
un filtre de préfixes autorisés généré;
une contrainte de cône client ou de chemin;
des seuils d’avertissement et durs de nombre maximal de préfixes plus bas;
une politique de rejet par défaut explicite;
la validation RPKI et la maintenance des ROA;
une alerte d’anomalie détenue;
des données de contact et d’escalade améliorées;
un processus de déploiement canari ou échelonné; et
un test de relecture utilisant le motif de route historique.

Dire « des filtres ont été ajoutés » ne suffit pas. La preuve doit montrer l’entrée du filtre, la sortie générée, le résultat du déploiement, l’état en cours, le test négatif et le résultat de surveillance.

Le risque résiduel doit rester visible. Les données relationnelles peuvent être incomplètes. Une fuite à origine valide peut échapper à la validation d’origine. Les exceptions peuvent élargir la portée. Les collecteurs ont des angles morts. Un arrêt brutal de session peut lui-même affecter la disponibilité. Le dossier de remédiation doit expliquer comment ces compromis sont gérés.

Le test de récurrence est plus important qu’une déclaration de politique

La preuve la plus solide que la remédiation fonctionne est une relecture contrôlée de la classe de défaillance.

L’environnement de test doit reproduire une session avec le rôle relationnel pertinent et un ensemble de routes attendu figé. Il doit ensuite introduire:

une route hors de l’ensemble de préfixes autorisés;
une annonce de table complète ou à volume élevé;
un chemin AS inattendu;
une route à origine valide propagée par une relation non prévue;
une exception expirée;
une route obsolète après retrait d’autorité; et
une défaillance d’une source de données de politique.

L’opérateur doit montrer ce que fait chaque couche. L’exportateur doit rejeter ou supprimer l’ensemble invalide. L’importateur doit contenir ce qui s’échappe. Les contrôles de nombre maximal de préfixes et d’anomalies doivent alerter. L’export en aval doit rester borné. Le propriétaire de la réponse doit recevoir un contexte suffisant pour agir. La restauration doit rétablir le dernier état autorisé connu.

Les tests doivent utiliser le chemin réel de génération et de déploiement de politique. Un filtre de laboratoire différent de la production ne prouve presque rien. Les résultats doivent inclure les versions logicielles et politiques, les empreintes de configuration, les routes attendues et réelles, le calendrier, la livraison d’alerte, les décisions humaines et l’observation indépendante.

Le test doit également inclure la défaillance du contrôle lui-même. Que se passe-t-il si le flux IRR est obsolète, si le validateur RPKI est indisponible, si le compilateur de politique échoue ou si le collecteur de surveillance perd une session? Les choix d’ouverture ou de fermeture en cas d’échec doivent être délibérés et liés à la criticité du service.

Les dirigeants n’ont pas besoin d’inspecter chaque route. Ils doivent exiger des preuves que le test a eu lieu, que les exceptions ont été expliquées, que les défaillances ont des propriétaires et que le prochain test est planifié. Les auditeurs peuvent échantillonner les artefacts sous-jacents.

Cette approche transforme la sécurité du routage d’une aspiration en une affirmation opérationnelle falsifiable.

Les questions de gouvernance doivent suivre le contrôle plutôt que les gros titres

Les conseils d’administration, les régulateurs, les clients et les auditeurs peuvent poser des questions efficaces sans prétendre exploiter des sessions BGP.

Les conseils d’administration doivent demander:

Quelles personnes et quels systèmes peuvent modifier les annonces de routes publiques?
Combien de sessions externes n’ont pas de rôle relationnel explicite?
Quelle proportion de sessions clients utilise des filtres de préfixes autorisés à jour?
Quelles sessions ont des limites d’avertissement et dures de nombre maximal de préfixes?
Combien d’exceptions sont ouvertes, qui les possède et quand expirent-elles?
Quand a eu lieu la dernière relecture de fuite de route, et qu’est-ce qui a échoué?
À quelle vitesse l’organisation peut-elle prouver le retrait depuis des points de vue indépendants?

Les fournisseurs de transit doivent demander si les enregistrements clients et pairs correspondent à la configuration en direct, si les filtres sont générés et testés, si la validation d’origine est appliquée de manière cohérente et si l’export en aval est contraint séparément.

Les opérateurs de centres de données et d’hébergement doivent demander si les responsabilités de routage sont claires entre l’installation, le réseau, le locataire, le revendeur et le fournisseur de transit. Un contrat d’hébergement physique ne définit pas automatiquement qui possède la politique d’export de l’AS21217.

Les clients d’entreprise et mobiles doivent demander des preuves de topologie, une surveillance externe des routes, des contacts d’incident et une preuve d’état de route dans les rapports post-incident. Ils doivent éviter d’assimiler la diversité des marques de fournisseurs à la diversité des chemins.

Les auditeurs doivent tracer un échantillon de ressource depuis les preuves de registre, à travers la génération de politique, jusqu’à la configuration en cours et un test de route négatif. Des captures d’écran d’un portail ou une politique écrite ne constituent pas une preuve d’application.

Les régulateurs doivent éviter d’imposer un seul contrôle comme remède universel. Les ROA améliorent la preuve d’origine. Ils n’encodent pas chaque relation. Les limites de nombre maximal de préfixes contiennent le volume mais peuvent provoquer des pannes si elles ne sont pas gérées. Des exigences efficaces doivent se concentrer sur les résultats: périmètre autorisé, confinement en couches, preuves conservées, coordination et reprise testée.

Les examinateurs d’incident doivent rejeter « erreur humaine » comme cause profonde. L’expression n’explique pas pourquoi une action a pu exporter un énorme ensemble de routes, pourquoi un voisin direct l’a accepté, pourquoi les sauvegardes en aval ne l’ont pas contenu, pourquoi les alertes se sont ou non déclenchées, ni pourquoi la reprise a pris le temps observé.

Les rapports publics doivent distinguer fait, inférence et inconnu. Ils doivent attribuer les décomptes de routes, la durée, les descriptions de relations, les services affectés, les observations de transfert et le calendrier de reprise. Ils doivent corriger les erreurs sans effacer la piste de preuve.

Le test de responsabilité est une propagation bornée et une reprise vérifiable

L’événement Safe Host du 6 juin 2019 reste instructif parce qu’il joint la politique de routage technique à une conséquence transfrontalière.

L’AS21217 a exporté un ensemble de routes extraordinaire. L’AS4134 a accepté et propagé suffisamment de cet ensemble pour modifier les chemins observés et affecter l’accessibilité de parties de l’infrastructure réseau européenne. D’autres réseaux ont pris leurs propres décisions d’acceptation et de propagation. Les collecteurs publics et les systèmes de mesure ont préservé une partie du dossier.

Les preuves ne justifient pas une conclusion d’intention malveillante, un décompte unique universel, une étiquette relationnelle commerciale incontestée, ni une affirmation selon laquelle chaque paquet a été inspecté ou a physiquement suivi la même route. Ces limites font partie du dossier de responsabilité.

La responsabilité reste concrète. L’exportateur contrôlait l’ensemble de routes. L’importateur direct contrôlait la première frontière de confinement. Les autres réseaux contrôlaient la propagation en aval et la résilience. Les opérateurs de surveillance contrôlaient les preuves. Les opérateurs de services contrôlaient la réponse d’impact utilisateur. Les utilisateurs finaux ont subi des conséquences sans autorité sur l’état BGP.

L’ensemble de contrôles durables est en couches: politiques d’import et d’export explicites, filtres de préfixes et de chemins autorisés, preuves relationnelles, contrôles de nombre maximal de préfixes, validation d’origine, surveillance des anomalies, changements échelonnés, contacts de coordination nommés, observation indépendante des routes et retrait vérifié.

Les registres et les enregistrements de politique de routage sont des registres indispensables. Ils identifient les ressources, les origines et les contacts. Ils n’appliquent pas un chemin. Le code en cours d’exécution détermine l’accessibilité.

Un opérateur crédible doit donc être capable de prouver quatre choses:

il sait quelles routes un voisin est autorisé et censé annoncer;
sa politique en vigueur rejette ou contient les annonces au-delà de ce périmètre;
sa surveillance détecte les changements anormaux de chemin et de volume assez rapidement pour qu’un propriétaire agisse; et
après le confinement, des preuves indépendantes montrent que les retraits se sont propagés et que le transfert attendu est revenu.

C’est le test de filtrage entre pairs et de responsabilité transfrontalière exposé par la fuite de Safe Host. La norme n’est pas la prévention parfaite. C’est la propagation bornée, le contrôle attribué, des preuves reproductibles et une reprise qui peut être vérifiée en dehors du réseau qui fait la déclaration.

La fuite de routes de Safe Host en 2019 a fait du filtrage entre pairs un test de responsabilité transfrontalier

Pourquoi c'est important