Résumé

  • Dans la version 03, l’intégration de RFC 7606 est la principale contribution. La section 6.4.1 ordonne quatre réponses aux erreurs UPDATE : réinitialiser la session, désactiver une famille d’adresses, retirer les routes de l’UPDATE concernée ou abandonner un attribut sans effet.
  • Chaque erreur mène à une réponse déterminée par le protocole. Le retrait ciblé exige de pouvoir lire les NLRI ; l’abandon d’attribut est réservé aux attributs sans effet sur la sélection ou l’installation des routes.

Une UPDATE mal formée arrive d’un voisin. La première question de l’opérateur n’est plus seulement « faut-il réinitialiser la session ? ». La bonne question est : jusqu’où porte l’incident ?

Daté du 22 octobre, le projet draft-ietf-idr-bgp4-rfc4271bis fait entrer cette question dans la spécification BGP-4 elle-même. Son annexe B précise que l’apport principal de la version 03 est l’intégration de RFC 7606, publiée en 2015 pour revoir le traitement des erreurs dans les messages BGP UPDATE. La section 6.4.1 présente quatre réponses, de la plus forte à la plus faible. Cette échelle classe la sévérité. Le type d’erreur détermine la réponse ; une mise en œuvre peut rétablir la réinitialisation par configuration.

Quatre dimensions d’un incident

En haut de l’échelle : réinitialisation de session. Le routeur envoie une notification puis ferme la session BGP. La conséquence englobe la relation qui transporte toutes les familles d’adresses négociées. L’état des routes passe alors par les mécanismes de convergence et de reprise de l’opérateur. Si le parseur ne peut pas repérer les routes contenues dans le message, le protocole ne peut pas réduire proprement le problème à quelques préfixes.

Un cran plus bas, désactivation AFI/SAFI. AFI et SAFI désignent le protocole réseau et le type de portée annoncée. Le projet s’appuie sur la procédure Multiprotocol BGP permettant à un routeur d’ignorer les annonces ultérieures de la famille concernée reçues de ce voisin. L’IPv4 unicast peut être touché tandis que l’IPv6 unicast continue sur la même session. La frontière est une famille d’adresses sur un peering, pas toute la relation avec le voisin.

Avec treat-as-withdraw, l’action vise les routes contenues dans l’UPDATE fautive. Elles sont retirées de l’Adj-RIB-In comme si le message les avait explicitement retirées. Cette précision suppose de pouvoir parser correctement les NLRI. Un routeur qui ignore quels préfixes figuraient dans l’UPDATE ne peut pas en fabriquer une liste de retrait fiable.

Enfin, abandon de l’attribut. Le routeur écarte l’attribut mal formé et poursuit le traitement du reste de l’UPDATE. La réponse perturbe le moins le flux, mais sa limite est stricte : l’attribut ne doit influer ni sur la sélection ni sur l’installation de la route. Supprimer une préférence, un next hop ou une autre donnée qui pilote une décision transformerait silencieusement le chemin choisi en « nettoyage ».

La distinction utile tient en une phrase : l’échelle mesure la portée de la réponse ; ce qui reste lisible dans le message détermine la réponse possible. Quand les longueurs des attributs se contredisent, le projet s’appuie sur la longueur totale des attributs pour localiser les NLRI et impose treat-as-withdraw, sauf erreur plus grave. Si les NLRI ne peuvent pas être identifiées avec confiance, les règles reviennent à la réinitialisation de session.

Le travail discret de la version 03

RFC 7606 avait déjà introduit le traitement révisé des erreurs UPDATE. La version 03 l’intègre au texte principal de BGP-4 : les implémenteurs peuvent consulter la spécification de base et sa politique d’erreur au même endroit. Le projet déprécie également plusieurs anciens sous-codes d’erreur UPDATE dont les conditions ne déclenchent plus de NOTIFICATION selon les nouvelles procédures. Il remplace le traitement « ignorer » d’un NEXT_HOP sémantiquement incorrect par treat-as-withdraw et permet à une mise en œuvre de revenir au reset par configuration.

L’intégration reste partielle : les modifications de RFC 7606 qui touchent d’autres RFC ne sont pas toutes reprises dans ce projet. Au 24 octobre, le Datatracker le classe comme Active Internet-Draft du groupe IDR, avec l’état IESG « I-D Exists ». L’échéance indiquée est l’envoi à l’IESG, en mai 2027, du texte de base BGP comme Internet Standard. L’en-tête dit que le document met à jour RFC 7606 si le projet est approuvé. Voilà où en est le texte aujourd’hui.

Les conséquences dépassent le parseur. Un reset transforme une erreur de message en incident de voisinage. La désactivation d’une famille modifie la voie de reprise de ce service sur le peering. Treat-as-withdraw peut détourner le trafic des préfixes concernés pendant que les autres UPDATE continuent. L’abandon d’attribut garde la route tout en supprimant une information ; sa sûreté dépend donc de la sémantique exacte de cet attribut.

Le réseau en fonctionnement fournit le test. Pour chaque classe d’erreur, l’opérateur doit relier la cause signalée, l’action choisie, les routes qui ont changé et la conséquence de transfert. Un badge Established répond à une seule question. La preuve utile suit la décision prise sur l’UPDATE dans l’Adj-RIB-In, la route sélectionnée, la FIB et un paquet.

Sources