Résumé

  • La révision 04 du projet BMWG sur le benchmark SAV impose d’identifier, pour chaque test de précision, les paquets légitimes et usurpés, puis d’expliquer ce classement.
  • Le taux de faux positifs porte sur les paquets légitimes bloqués, tandis que le taux de faux négatifs porte sur les paquets usurpés autorisés : une mauvaise étiquette fausse donc le dénominateur pertinent.
  • Il s’agit d’une méthode de mesure en laboratoire, sans seuil universel de conformité, sans nouveau protocole SAV et sans résultat sur un produit.

Le chiffre arrive à la fin, mais la décision décisive se prend au début. Avant de mesurer un dispositif de validation de l’adresse source, le laboratoire constitue deux populations : le trafic qu’il estime autorisé et celui qu’il estime usurpé. Si cette séparation est erronée, une exécution parfaitement répétable ne fait que reproduire une erreur de qualification.

Publié le 14 septembre 2026, draft-ietf-bmwg-savnet-sav-benchmarking-04 rend ce point explicite. Le rapport doit dire quels paquets de chaque essai sont légitimes, quels paquets sont usurpés, et pourquoi. La nouvelle formulation éclaire aussi la portée du résultat : la méthode consigne les blocages indus et les autorisations indues, mais elle ne prononce pas une réussite ou un échec de conformité.

La symétrie apparente des deux erreurs peut tromper. Un faux positif est un paquet légitime bloqué à tort ; son taux se calcule sur le nombre de paquets légitimes envoyés. Un faux négatif est un paquet usurpé laissé passer ; son taux se calcule sur le nombre de paquets usurpés envoyés. Modifier la qualification d’un paquet peut donc changer à la fois le numérateur, le dénominateur et le récit de sécurité associé au résultat.

La légitimité n’est pas contenue dans l’adresse

Une adresse source ne porte pas seule la preuve qu’elle est acceptable sur une interface. Cette conclusion dépend de la place de l’interface dans la topologie, de la relation commerciale qu’elle représente, des informations de routage et de SAV disponibles au dispositif, des réglages locaux et du scénario examiné. Le projet demande de documenter cet environnement afin que le lecteur puisse comprendre le jugement initial.

Les cas de préfixe caché et de propagation limitée montrent pourquoi. Un trafic peut être autorisé alors que le préfixe correspondant n’est pas visible dans la vue BGP ordinaire de l’observateur. Un déploiement à retour direct du serveur peut également produire un chemin retour qui contredit une hypothèse naïve de symétrie. L’attente n’est pas identique sur une interface tournée vers un client, un fournisseur, un pair ou un serveur de routes.

Le protocole de compte rendu devient ainsi une composante essentielle du benchmark. Il doit préciser la version et le type du dispositif, son déploiement, la topologie, l’interface soumise à l’essai, la relation associée, la configuration, les sources d’informations de routage ou de SAV et leur calendrier de mise à jour. Il doit aussi conserver les caractéristiques du trafic, les horodatages, les répétitions et le traitement statistique.

La méthode reste volontairement en boîte noire. Le dispositif peut être un routeur matériel ou logiciel, une machine virtuelle ou un conteneur. Le laboratoire constate ce qui est transmis ou bloqué sans exiger une architecture interne donnée. Cette neutralité évite de transformer le benchmark en prescription de mise en œuvre, mais elle ne protège pas contre un oracle externe mal construit.

Autre précaution : toute disparition de paquet n’est pas une décision SAV. La congestion, un filtre sans rapport ou une panne du chemin de transfert peuvent causer une perte. À l’inverse, le blocage volontaire d’un paquet usurpé ne doit pas gonfler une mesure générique de perte. Dans un trafic mêlé, le transfert du sous-ensemble légitime doit rester identifiable.

Un document de travail, pas un certificat

La révision 04 est un Internet-Draft actif du groupe BMWG, destiné à une publication de type Informational. Elle n’est pas un RFC et n’a pas reçu l’approbation de l’IETF. Elle ne présente aucun essai de produit. Le jalon du groupe vise actuellement une soumission à l’IESG en janvier 2027 ; ce calendrier décrit une intention de travail, pas une issue acquise.

Le texte ne fixe pas non plus un niveau d’erreur acceptable pour tous les réseaux. Des laboratoires peuvent appliquer la méthode et obtenir des résultats différents parce que leurs dispositifs, topologies, entrées d’information et populations de trafic diffèrent. La comparabilité dépend précisément de la visibilité de ces différences.

La répartition institutionnelle compte ici. SAVNET décrit les problèmes intra-domaine et inter-domaine auxquels doivent répondre les mécanismes de validation de l’adresse source. BMWG construit une méthode de mesure contrôlée. Le benchmark peut éclairer un choix ; il ne crée pas un mécanisme SAV et ne recommande pas à un opérateur d’en déployer un en particulier.

Sources