Résumé

  • Une politique BGP peut être sûre avant et après une modification, mais permissive entre deux commandes. Une interface à exécution immédiate active chaque fragment, tandis qu’un réordonnancement non atomique peut supprimer un rejet avant d’installer son remplaçant.
  • La révision 03 relie cette fenêtre à l’ordre des règles, à la charge du plan de contrôle, au remplacement complet, à l’idempotence et à l’échec du générateur. Il faut prouver l’état effectif et le delta de routes, pas seulement la réussite de l’API.

Les comparaisons avant et après étaient identiques à l’intention approuvée. Pourtant, le routeur avait brièvement annoncé une route interdite. Le système de changement avait inspecté deux états stables et ignoré celui dans lequel l’autorité de routage s’était réellement exercée.

C’est l’angle neuf de la révision 03 de Current Options for Securing Global Routing, publiée le 2 octobre 2026. Il s’agit d’un Internet-Draft actif du groupe GROW, dans le flux IETF, à statut prévu Informational et expirant le 5 avril 2027. Ce n’est ni un RFC, ni un consensus final, ni une BCP, ni une preuve de conformité ou d’incident. Le texte se présente comme un répertoire contemporain, non exhaustif et non normatif des options disponibles.

L’interface détermine les états possibles

Une interface transactionnelle peut préparer plusieurs changements puis les appliquer atomiquement. Une interface impérative exécute chaque commande dès sa réception. Les deux peuvent converger vers le même fichier final sans exposer la même sécurité pendant le trajet.

Le brouillon donne l’exemple d’une route-map. L’opérateur crée une règle, lui donne action permit, puis ajoute une large community. Sur une interface immédiate, le permit agit déjà. Placée avant le rejet des routes apprises des transitaires, la règle inachevée accepte tout et peut exporter ces routes vers les pairs.

L’erreur ne réside donc pas seulement dans l’ordre du script. L’interface transforme chaque construction partielle en politique réelle. Le fichier désiré parle au nom du contrôleur ; la politique effective parle au nom du routeur. C’est cette dernière qui accepte ou annonce des NLRI.

Réordonner n’est pas neutre

Un second exemple part d’une politique d’export qui rejette les routes amont, les bogons et les NLRI RPKI invalides avant d’accepter le reste. Pour permuter les deux rejets centraux, une plateforme non atomique peut d’abord supprimer la règle bogon, puis installer son remplacement. Entre ces étapes, un bogon passe. Si l’application s’arrête après la suppression, l’état intermédiaire devient durable.

Dire que l’intervalle est court ne le mesure pas. Une charge élevée ou un plan de contrôle contraint peut l’allonger. Un délai dépassé côté gestionnaire ne prouve pas un retour arrière côté routeur, et une relance peut réappliquer des commandes sur un état déjà modifié.

Le texte conseille donc d’évaluer l’atomicité. Si elle manque, une option consiste à construire un nouveau jeu complet, à faire basculer la référence du voisin, puis à supprimer l’ancien après activation. Mais même cette bascule exige un reçu : les notions NETCONF de candidate, running et commit illustrent un modèle transactionnel sans garantir l’atomicité de chaque sous-système d’un produit. La distinction NMDA entre état intended et operational garde toute sa force.

L’ordre dépense aussi du calcul

Dans l’exemple quantitatif du brouillon, un pair envoie un million de NLRI IPv4 alors que 60 seulement appartiennent à son cône autorisé. Ajouter d’abord deux communities puis vérifier ASN privés, bogons et RPKI avant le cône produit 5 986 500 opérations. Rejeter le hors-cône en premier réduit l’exemple à 1 000 300.

Ce ne sont pas des mesures d’un produit nommé. Elles montrent qu’un prédicat peu coûteux et très sélectif doit précéder le travail dont le résultat sera jeté. Le brouillon propose aussi, selon l’implémentation, scalaires, arbres, listes puis expressions régulières.

La performance rejoint ici l’intégrité. La politique inefficace charge le même plan de contrôle qui doit terminer sa propre modification. Plus l’application ralentit, plus l’état intermédiaire dangereux persiste. L’ordre porte donc le sens, le coût et la durée du risque.

Idempotence, validation et échec

Générer les filtres sur un système dédié et ne déployer qu’un changement réel évite une charge périodique inutile. Mais une opération idempotente peut toujours traverser le même état dangereux à sa première exécution. Elle peut aussi converger efficacement vers une mauvaise politique.

Il faut distinguer les empreintes des données sources, de la politique désirée, de la politique générée et des états effectifs avant et après. La validation préparatoire, l’accusé d’activation, le delta de routes et le résultat du rollback sont d’autres reçus.

Si la génération échoue, aucun défaut n’est neutre. Tout accepter dépense la sécurité ; tout rejeter dépense la joignabilité ; conserver l’ancien filtre dépense la justesse avec le temps. Le brouillon laisse le choix à l’administrateur. Il doit être décidé à l’avance par type de voisin et assorti d’une durée de tolérance.

RFC 8212 fournit le rejet par défaut en l’absence de politique eBGP. Il ne prouve pas une transition sûre entre deux politiques présentes. ROV, RPKI, BGP Roles et OTC donnent des prédicats utiles ; ils ne rendent pas atomique l’opération qui les installe.