Résumé

  • La version 03 du projet de travail GROW Current Options for Securing Global Routing, datée du 2 octobre, ajoute une section sur la manière dont une configuration devient effective : validation d’une transaction entière ou exécution immédiate de chaque commande. Le texte est un Internet-Draft, pas une norme achevée.
  • Son scénario met en scène une règle action permit qui agit avant l’ajout prévu de set large-community add 65536:0:0. Placée avant un refus des routes reçues d’un amont, elle peut laisser partir des annonces vers des pairs. Il s’agit d’un mode de défaillance décrit, non d’un incident constaté.

Une politique BGP n’est pas seulement un document que l’on compare avant et après maintenance. Elle est aussi une succession d’états réellement atteints par le routeur. C’est la distinction rendue explicite dans la version 03 de draft-ietf-grow-routing-ops-sec-inform. La fiche du Datatracker présente toujours ce texte comme un projet actif du groupe GROW, au stade I-D Exists, avec un statut Informational envisagé. Son ambition déclarée est un inventaire non exhaustif des options de sécurisation du routage mondial, sans classement d’efficacité ni méthode unique imposée aux exploitants.

La nouvelle section oppose deux mécanismes de changement. Dans une interface transactionnelle, on prépare plusieurs éléments puis on les valide ensemble de façon atomique. Dans une interface à effet immédiat, une commande peut modifier le comportement en production dès sa saisie. L’exemple du projet commence par action permit dans une route-map ; l’ajout de la Large Community 65536:0:0 vient ensuite. Si la nouvelle règle précède le refus des routes apprises auprès d’un fournisseur amont, la première étape peut exporter ces routes vers des pairs avant l’étape suivante. Le numéro de communauté appartient à cet exemple : il ne prouve ni autorisation, ni filtrage, ni réception à lui seul.

Il faut préciser la nouveauté. La version 02 connaissait déjà le problème des changements non atomiques. Sa section sur la cohérence des filtres de préfixes expliquait qu’une mise à jour partielle pouvait brièvement accepter des préfixes indésirables ou laisser une politique incohérente après une intervention interrompue. La version 03 généralise la question à la « configuration paradigm » et donne une illustration d’ordre d’exécution dans une route-map. Dire que le risque de transition vient seulement d’être découvert fausserait le dossier.

La règle de refus par défaut de RFC 8212 ne ferme pas non plus cette brèche par magie. Ce RFC demande des politiques explicites à l’import et à l’export EBGP, et rejette en l’absence de politique. Il rappelle toutefois qu’une configuration explicite incorrecte reste possible. Or une autorisation provisoire est précisément une configuration explicite. La présence d’un refus final dans le fichier et la présence d’un mécanisme de refus par défaut ne démontrent donc pas ce qui a été annoncé pendant l’opération.

Pour vérifier la transition, il faut distinguer trois preuves : la commande acceptée par la plateforme, la politique complète effectivement attachée et les routes annoncées au voisin. Une comparaison finale de texte renseigne surtout sur la deuxième. Construire une politique de remplacement avant la bascule peut limiter l’exposition lorsque le matériel le permet ; encore faut-il vérifier que le changement de référence est lui-même appliqué comme prévu. Une ligne unique n’est pas automatiquement une transaction atomique. Ces précautions relèvent d’une déduction opérationnelle, pas d’une procédure décrétée par le projet GROW.

Le document ne désigne aucun opérateur touché, aucun logiciel défectueux et aucune fréquence mesurée de fuite. Sa portée demeure celle d’un projet de travail. Il fournit pourtant un objet précis au contrôle interne : non pas seulement le résultat souhaité, mais tous les états intermédiaires dans lesquels une annonce interdite pourrait quitter le réseau.

Sources