Résumé

  • L’appel final lancé le 17 septembre concerne la version 21 d’un projet de RFC informatif ; les commentaires substantiels sont attendus le 1er octobre.
  • Client, pair et fournisseur ne donnent pas au routeur la même preuve sur la provenance d’un paquet.
  • Accord du groupe de travail, examen par l’IESG, future spécification et décision de déploiement restent quatre actes distincts.

Un préfixe absent de la vue BGP d’une interface n’est pas nécessairement une source frauduleuse. Un client multihébergé peut limiter la propagation d’une annonce tout en envoyant un trafic légitime par une autre liaison. Dans une architecture à retour direct, un serveur périphérique peut répondre avec une adresse anycast dont l’annonce se fait ailleurs. Le projet SAVNET, version 21, présente ces situations comme des scénarios d’analyse, non comme des incidents constatés. Un contrôle trop strict risque d’écarter les réponses ; élargir indistinctement la liste admise risque de laisser passer une usurpation au sein du cône client.

Cette tension explique l’objet du message de l’IESG du 17 septembre. L’instance sollicite des avis avant le 1er octobre sur un diagnostic, une analyse des lacunes et des exigences destinés à un RFC informatif. Le suivi officiel indique encore « Publication Requested ». Ni un RFC définitif, ni une nouvelle méthode universelle, ni un résultat sur le trafic ne découlent de cette étape.

Le pair latéral est un autre cas : l’asymétrie des chemins rend la vérification par trajet inverse fragile. Si l’opérateur assouplit le contrôle, la présence d’une route vers le préfixe n’atteste plus que le pair qui a envoyé le paquet était autorisé à le faire. Côté fournisseur, Loose uRPF peut laisser passer une source usurpée parce que son préfixe existe dans la table de transfert ; une liste de contrôle d’accès plus précise exige davantage de maintenance. Le document ne confond pas ces coûts et ces preuves avec ceux de l’interface client.

Les exigences proposées pour un futur mécanisme comprennent une validation précise, une charge d’exploitation supportable, des bénéfices en déploiement partiel, la protection des informations propres à SAV et une convergence correcte des tables. Il faudra aussi distinguer données de routage ou RPKI préexistantes et nouvelles assertions spécifiquement échangées pour SAV. La validité d’un objet et l’autorisation locale d’un flux ne répondent pas à la même question.

La note du rapporteur du document relate deux appels au sein du groupe de travail et un large accord, mais précise qu’il ne s’agit pas d’un protocole ni d’une extension BGP ou RPKI. Une évaluation précoce de la version 20 interrogeait la portée de l’objectif de « zéro blocage indu » et le modèle de confiance des données. Il serait faux d’en faire un verdict encore ouvert sur la version 21 ; c’est un exemple daté de la précision que l’examen public peut demander.

Sources