Résumé
- L’IESG a ouvert le 17 septembre 2026 une consultation se terminant le 1er octobre sur la version 21 de l’analyse interdomaines de SAVNET. Il s’agit d’un projet destiné à devenir un RFC informatif, pas d’une norme déjà publiée.
- Le texte distingue le rejet à tort d’un trafic licite et l’acceptation à tort d’une source usurpée. Sa section consacrée au dépannage explique que le routeur filtrant ne peut pas, à lui seul, reconnaître toutes ses erreurs.
- Le signal peut venir du réseau client ou pair touché. Conserver le chemin entre plainte, règle examinée et correction est une recommandation éditoriale, non un formulaire imposé par l’IETF.
Le compteur d’un routeur peut montrer des paquets rejetés. Il ne dit pas toujours si ces paquets auraient dû passer. Cette limite sépare l’exécution d’une règle de la connaissance de sa justesse. Le projet du groupe SAVNET, actuellement en Last Call auprès de l’IESG, en fait un problème de conception des méthodes futures de validation des adresses source entre systèmes autonomes. Son intérêt n’est pas d’annoncer une nouvelle appliance : il expose les cas où la logique du filtre et la réalité du réseau divergent.
Une table SAV se construit à partir d’informations disponibles au réseau qui filtre. Or une adresse légitime n’est pas nécessairement visible dans toutes les annonces BGP auxquelles ce réseau a accès. Le document décrit notamment les préfixes annoncés de manière sélective et ceux qui servent à l’émission sans apparaître comme destinations ordinaires, y compris certains usages anycast avec retour direct. Un filtre qui déduit trop de la visibilité de routage peut bloquer ce trafic. À l’inverse, élargir trop généreusement les directions d’entrée autorisées pour éviter ces blocages augmente le risque de laisser passer des sources falsifiées.
Il existe une seconde limite, souvent perdue dans les promesses de sécurité : un déploiement partiel ne supprime pas par magie l’usurpation possible au sein d’un ensemble de réseaux clients. La protection obtenue par un opérateur dépend aussi de ce qui se passe en aval. Le texte demande que les futurs mécanismes apportent un bénéfice aux premiers adoptants sans présupposer une adoption générale, tout en réduisant la charge des mises à jour et en protégeant les informations propres à SAV si de telles informations sont introduites.
La section 6 déplace ensuite le regard vers le terrain. Le routeur frontalier ne dispose pas nécessairement des éléments permettant de conclure qu’il a provoqué un faux positif ou laissé passer un faux négatif. Le réseau voisin lésé peut signaler une panne d’accessibilité ; l’opérateur qui applique le filtre doit alors rapprocher ce signal des interfaces, des versions de table et des données qui ont servi à produire la règle. Une plainte n’établit pas automatiquement une faute du filtre, mais une décision locale ne suffit pas non plus à écarter la plainte.
Pour rendre cette enquête reproductible, Daniel Kade propose une trace limitée : interface d’entrée, catégorie de relation avec le voisin, préfixe et trafic concernés, version de la table et des entrées, heure du signalement, responsable de l’analyse, modification ou maintien motivé de la règle, puis vérification de clôture. Il faut éviter de diffuser des captures de trafic ou des détails commerciaux au-delà des personnes compétentes. Rien dans le projet n’instaure cette « fiche » universelle ni une obligation de réponse entre opérateurs. C’est une façon de faire correspondre un pouvoir de filtrer et un devoir de comprendre ses conséquences.
La chronologie évite enfin un contresens. La version 21 porte la date du 19 juillet ; l’événement de septembre est l’ouverture de la consultation de l’IESG, non la mise en service d’une solution. Ce projet est une analyse des lacunes et des exigences, pas un protocole achevé et pas une mesure du nombre de réseaux affectés. Le sujet à suivre est plus étroit et plus utile : comment une correction peut-elle rejoindre le bon propriétaire de règle lorsque l’observation de l’erreur naît de l’autre côté de la frontière ?
Sources
- https://datatracker.ietf.org/doc/draft-ietf-savnet-inter-domain-problem-statement/
- https://datatracker.ietf.org/doc/draft-ietf-savnet-inter-domain-problem-statement/history/
- https://www.ietf.org/archive/id/draft-ietf-savnet-inter-domain-problem-statement-21.txt
- https://datatracker.ietf.org/wg/savnet/about/
- https://www.rfc-editor.org/rfc/rfc2827.html
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance

