Résumé

  • RFC 3511 demandait de déclarer si le NAT était activé et recommandait de tester les deux états, parce que la traduction ajoute un travail mesurable ; règles, cache, authentification, topologie et tailles de trafic appartenaient au même reçu.
  • RFC 9411 a rendu RFC 3511 obsolète et élargi le contrat aux fonctions de sécurité modernes, au trafic applicatif et chiffré, à la validation d’efficacité et à une phase soutenue. Aucun résultat ne prouve à lui seul la capacité de production ni la sécurité.

Deux nombres affichaient la même unité. Le premier venait d’un pare-feu sans NAT. Le second d’un chemin où chaque flux devait traduire une adresse et maintenir l’état associé. Le tableau les classa comme s’ils mesuraient la même chose.

RFC 3511, publié en avril 2003 comme RFC informatif, ne laissait pourtant aucune ambiguïté sur ce point. Le NAT impose un traitement supplémentaire ; les essais devraient être exécutés avec puis sans cette fonction, et le rapport doit indiquer l’état retenu.

En mars 2023, RFC 9411 a rendu cette méthode obsolète afin de couvrir les équipements de sécurité modernes. Le changement ne transforme pas un ancien chiffre en erreur. Il oblige à conserver le contrat temporel et technique qui lui donnait un sens.

Le NAT change l’objet mesuré

Traduire une adresse ne consiste pas seulement à modifier quelques octets. Le système choisit une liaison, alloue et retrouve un état, ajuste parfois des contrôles, gère des temporisations puis libère la ressource. Le coût dépend du type de trafic, de la durée des sessions et de la pression sur les tables.

Un essai NAT désactivé répond donc à une question utile : quelle est la performance du chemin qui ne réalise pas cette traduction ? Un essai NAT activé en pose une autre. La faute n’est pas de mesurer l’un ou l’autre ; elle est de supprimer cette distinction après coup.

Le reçu doit préciser le type de traduction, les espaces d’adresses, la direction des flux, la politique d’allocation, les délais d’expiration et l’état initial de la table. Sinon, « NAT activé » reste lui-même trop vague pour reproduire l’expérience.

Les règles fabriquent le chemin rapide

RFC 3511 définit un jeu de règles comme l’ensemble des politiques qui déterminent les paquets transmis ou rejetés. Il recommande un refus par défaut pour le trafic non défini et demande que les règles configurées soient incluses dans le rapport.

Le nombre, l’ordre et la distribution des correspondances peuvent déplacer le coût. Une règle fréquemment trouvée en tête n’est pas équivalente à une décision après une longue recherche. Un paquet rejeté avant inspection n’exécute pas le même chemin qu’un flux autorisé avec suivi complet.

Un résultat sans export de politique ne permet donc pas de savoir si le banc a mesuré le produit, une politique minimale ou une optimisation particulière. Le nom du pare-feu ne reconstitue pas le chemin de décision.

Le cache et l’authentification déplacent le travail

Un agent de cache peut répondre depuis sa mémoire au lieu de solliciter le serveur d’origine. L’authentification peut appeler un service extérieur et ajouter son délai. Ces deux fonctions changent le système dont on attribue la performance au pare-feu.

Le rapport doit distinguer réponses en cache et travail d’origine, authentification locale et distante, latence du service associé, succès et échecs. Une moyenne qui mélange ces cas ne décrit ni le pare-feu seul ni la chaîne complète.

La même règle vaut pour les segments Protected, Unprotected et DMZ. Lorsque plusieurs chemins participent, RFC 3511 exige une mesure agrégée clairement nommée. L’agrégat ne doit pas être revendu comme propriété de chacun de ses composants.

« Zéro perte » possède des coordonnées

Le débit IP de RFC 3511 conserve charge prévue, charge offerte, taux de transmission, taille des paquets et nombres émis ou transmis. La latence légitime est mesurée au niveau de débit le plus élevé sans perte.

Zéro perte ne signifie donc pas que le dispositif ne perd jamais de trafic. Cela signifie qu’avec cette taille, cette direction, cette durée, ces règles et cette charge, le critère n’a observé aucune perte.

Changer la taille des paquets, le mélange ou le temps soutenu change le dénominateur. Un graphique qui ne garde que la valeur maximale ne conserve pas l’expérience, même s’il affiche beaucoup de décimales.

La capacité de connexions n’est pas leur cycle de vie

RFC 3511 sépare le nombre de connexions TCP simultanées, le taux maximal d’établissement et le taux maximal de fermeture. Ces métriques ne sont pas interchangeables.

Une grande table peut maintenir des connexions presque inactives et mal absorber de nouvelles ouvertures. Un système peut accepter rapidement puis libérer lentement. Il peut réussir les handshakes et échouer les transactions HTTP.

Le reçu doit préserver ouverture, maintien, travail applicatif, fermeture, délais, resets et échecs de validation. Sans ces étapes, « connexions par seconde » devient une étiquette capable de désigner plusieurs expériences incompatibles.

La sécurité reste une preuve séparée

RFC 3511 comportait des essais de déni de service et de trafic illégal, mais sa section Sécurité excluait explicitement l’évaluation générale de la sécurité.

Dans l’essai de trafic illégal, le rapport doit compter les connexions interdites néanmoins autorisées. Sans ce résultat, laisser tout passer peut sembler rapide. Dans l’essai de déni de service, une charge d’attaque définie affecte des taux définis ; elle ne représente pas toutes les attaques possibles.

Un débit n’hérite donc jamais d’un verdict de protection. La conformité de la politique, l’efficacité de détection, les faux positifs, les faux négatifs et le résultat applicatif demandent leurs propres reçus.

RFC 9411 a agrandi l’enveloppe

Les pare-feux de nouvelle génération et les systèmes de prévention ne se réduisent plus à une liste ACL. RFC 9411 retient l’inspection TLS, IDS/IPS, anti-malware, identification applicative, journalisation et inspection approfondie selon la classe d’équipement.

La configuration d’efficacité doit être définie avant les performances et rester cohérente entre essais. Les fonctions omises ainsi que leur effet probable doivent être déclarés. Un nombre de règles réaliste est recommandé.

Le banc doit aussi être isolé et mesuré sans le DUT/SUT. Cette référence empêche un switch, un routeur, une fonction virtuelle, la chaleur ou une charge concurrente de devenir une prétendue limite du pare-feu.

Le chiffrement rend le profil indispensable

Le nouveau contrat décrit le mélange applicatif, la part chiffrée, les directions, les tailles d’objets et les protocoles de couche 7. HTTP/1.1, HTTP/2, HTTP/3, TCP, QUIC et TLS ne créent pas le même travail.

La base HTTPS effectue des handshakes complets et désactive la reprise de session. Le profil QUIC de référence désactive le 0-RTT. Versions TLS, suites cryptographiques, tailles de clés, SNI, ALPN, certificats et inspection doivent accompagner le résultat.

Un débit HTTPS obtenu sans inspection TLS n’est pas faux. Il mesure un chemin sans cette fonction. Le présenter comme capacité inspectée efface précisément le coût que l’acheteur cherche à connaître.

Le résultat doit survivre à la phase soutenue

RFC 9411 distingue initialisation, montée en charge, maintien et descente. Les KPI sont mesurés pendant le maintien, pas au premier pic.

Les transactions échouées, resets TCP inattendus et, en HTTP/3, certaines erreurs QUIC doivent rester sous les seuils de validation. Une transaction réussie transfère tout l’objet et reçoit une réponse valide.

La série temporelle est aussi importante que la moyenne : elle révèle le remplissage d’une table, une file d’inspection, une réduction thermique ou une instabilité que le pic dissimule.

Frontière de preuve

Cet article ne nomme aucun fournisseur, modèle, logiciel, laboratoire, client ou déploiement. Il ne publie aucun score, test d’exploit, classement, incident ni taux d’adoption.

RFC 3511 est traité comme une méthode informative d’avril 2003 désormais obsolète. RFC 9411 est une méthode informative de mars 2023, pas une certification ni une garantie de production. Ses seuils de validation ne sont pas un taux d’échec de sécurité acceptable en général.

Les principes de spécification minimale et de primauté du code en exécution de Heng Lu sont des cadres éditoriaux déclarés. Ils conduisent à préserver un reçu comparable et à laisser l’extrapolation au responsable local ; ils ne constituent pas des données de pare-feu.

La conclusion est étroite : lorsqu’un état NAT disparaît, le chiffre ne mesure plus un objet identifiable.

Sources