Résumé

  • Un domaine de routage interne a annoncé un grand nombre de préfixes vers un backbone de centres de données. Tous portaient une communauté BGP légitime et ont franchi la route-map d’entrée; les routeurs d’agrégation ont ensuite épuisé leur mémoire et leurs démons de routage ont redémarré.
  • La proposition de Daria Shantalova sépare trois questions: quelle est l’identité du préfixe, à quelle frontière peut-il passer et l’état de production correspond-il toujours à l’intention?
  • La présentation affirme que presque toutes les violations observées ont été supprimées en quelques mois, sans publier de décompte initial, de reliquat précis ni de série datée.

Le badge était bon; le contrôle d’accès était incomplet

Le détail embarrassant du cas raconté par Daria Shantalova à RIPE 93 tient en une phrase: les routes fautives portaient le bon badge. Un domaine interne voisin a envoyé beaucoup de préfixes vers l’Express Backbone reliant les centres de données. Chaque route portait une communauté BGP attribuée à ce domaine. La route-map d’entrée reconnaissait cette valeur et acceptait les annonces.

Les routes se sont ensuite propagées dans le maillage BGP interne. Les routeurs d’agrégation des centres de données ont reçu l’ensemble; leur démon de routage a manqué de mémoire puis redémarré. Les sources publiques ne donnent ni le nombre exact de préfixes, ni celui des routeurs, ni la durée de l’incident. Elles décrivent le mécanisme: le filtre vérifiait l’appartenance de la communauté au domaine émetteur, pas le droit de chaque préfixe à traverser cette frontière.

Une étiquette valide n’est pas un permis universel. Une communauté peut identifier un domaine d’origine ou préciser la portée d’une route; elle ne prouve pas que chaque préfixe qui la porte est autorisé partout.

Un plafond de volume ne remplace pas une liste d’autorisations

La distinction est pratique. Une limite de préfixes demande combien de routes arrivent. Une liste de préfixes autorisés demande lesquelles peuvent entrer. Un filtre de communautés vérifie si une valeur est reconnue ou doit être conservée. Les trois contrôles peuvent coexister, mais aucun ne répond à la place des deux autres. Le RFC 7454 traite séparément le filtrage de préfixes, les limites de volume et le traitement des communautés; le RFC 4271 décrit l’échange de joignabilité et les décisions BGP.

Le modèle proposé commence par l’identité: chaque préfixe reçoit une communauté BGP ID unique qui indique son domaine d’origine et sa portée de propagation. Une valeur absente, incorrecte, multiple ou contradictoire devient une violation. Ensuite, un registre interne des routes associe chaque préfixe à son domaine et à sa communauté attendus. Il produit des filtres entrants pour chaque frontière. Enfin, des données RIB de production sont comparées en continu au registre; les préfixes inconnus, les communautés erronées et les écarts déclenchent une alerte.

Le registre exprime l’intention; le RIB montre l’état effectivement accepté. La valeur du dispositif tient à leur comparaison continue, pas au joli schéma d’un filtre installé une fois.

« Presque toutes »: le résultat sans son dénominateur

Le résumé de la session dit que l’équipe a supprimé « presque toutes » les violations observées en quelques mois et que l’application automatisée empêche leur retour. Les diapositives ne donnent ni volume de départ, ni reliquat exact, ni chronologie des violations, ni couverture des frontières protégées. Une série datée avant-après, avec le nombre de frontières couvertes, permettrait de distinguer le nettoyage initial de l’effet de l’application automatique.

La leçon opérationnelle ne tient pas à « ajouter un filtre ». Elle consiste à assigner une tâche précise à chaque contrôle, puis à rendre leur passage de relais vérifiable. Le préfixe doit avoir une identité, la frontière doit vérifier son autorisation et la surveillance doit détecter tout écart en production.

Sources: session et résumé RIPE 93; transcription officielle; diapositives originales; RFC 4271; RFC 7454.