Résumé

  • Dans RFC 2012, tcpConnState était accessible en lecture-écriture. La seule valeur qu’une station de gestion pouvait imposer, deleteTCB(12), supprimait le TCB correspondant et terminait immédiatement la connexion locale.
  • L’index IPv4 à quatre éléments et les compteurs TCP rendaient l’état observable, mais ne reliaient pas l’identité de l’opérateur, la décision d’autorisation, l’acceptation par l’agent, la réaction des applications et l’impact sur le service.
  • RFC 4022 a conservé l’action, séparé les écouteurs des connexions, ajouté le type d’adresse et le processus, rendu l’écriture facultative pour la conformité et qualifié l’accès non autorisé de risque de déni de service.

Une instrumentation munie d’un actionneur

RFC 2012 proposait d’abord des mesures : algorithme et bornes de retransmission, limite de connexions, ouvertures actives et passives, échecs, fermetures depuis un état établi, segments reçus, émis ou retransmis, erreurs et segments RST. La tcpConnTable descendait ensuite jusqu’à la connexion courante, indexée par adresses et ports locaux et distants.

La colonne d’état rompait avec la simple observation. Son accès maximal était read-write. Une station ne pouvait pas fabriquer un état ordinaire ; toute autre écriture que deleteTCB(12) pouvait être rejetée par badValue. En revanche, cette valeur devait supprimer le Transmission Control Block de la connexion visée et provoquer sa terminaison immédiate sur le nœud géré.

L’émission d’un RST vers l’autre extrémité restait un choix d’implémentation, et RFC 2012 rappelait que ce segment n’est pas fiable. La disparition locale, l’information du pair, la réaction de l’application distante et l’expérience de l’utilisateur ne sont donc pas un événement unique.

Le TCB était la mémoire de la connexion

RFC 793 plaçait dans le TCB les sockets local et distant, les paramètres de sécurité et de priorité, les pointeurs vers les tampons, la file de retransmission, le segment courant et les variables de séquence. CLOSED y était un état fictif : sans TCB, il n’y avait plus de connexion.

deleteTCB n’était donc pas un changement cosmétique. Il retirait l’état qui permettait au TCP local de poursuivre l’échange. Or la ligne de MIB ne conservait ni identifiant d’action, ni motif, ni ticket, ni principal initiateur, ni propriétaire applicatif. Une fois la ligne transitoire disparue, le même quadruplet pouvait plus tard désigner autre chose.

Le pouvoir venait de MIB-II. Dès 1991, RFC 1213 avait rendu tcpConnState inscriptible « pour permettre la suppression du TCB ». RFC 2012 transportait ces objets dans SMIv2. Son introduction renvoyait authentification, autorisation, contrôle d’accès et confidentialité au cadre administratif ; sa section de sécurité ne développait aucune de ces questions.

Un compteur n’était pas le journal de la commande

Après une coupure, tcpCurrEstab pouvait baisser, tcpEstabResets augmenter ou un RST apparaître dans tcpOutRsts. Ces variations ne suffisent pas à attribuer la cause. La jauge décrit un stock courant. Le compteur de réinitialisations agrège certaines transitions vers CLOSED, quelle qu’en soit l’origine. Le compteur RST indique un segment émis, pas sa livraison ni l’intention qui l’a produit.

La preuve exige une chaîne distincte : ligne et instant observés, requête authentifiée, identité de sécurité et rôle humain, contexte, droit d’écriture sur cette instance, motif enregistré, réponse de l’agent, disparition du TCB, notification de l’application, observation du pair, nouvelle tentative, durée et effet de service. Le tableau ne contenait pas cette jointure.

RFC 4022 a enrichi l’identité sans achever l’imputabilité

Le successeur de 2005 a conservé deleteTCB(12) et la même terminaison locale immédiate. Il a toutefois abandonné l’ancienne table, parce qu’elle ne couvrait qu’IPv4 et mélangeait connexions et points d’écoute. La nouvelle table associe type d’adresse, adresse et port pour les deux extrémités. Une table séparée décrit les écouteurs génériques, par famille ou liés à une adresse précise. Des identifiants de processus peuvent relier connexion et écouteur aux MIB de ressources de l’hôte.

Cette surface répond mieux à « quel socket, quel processus ? ». Elle ne prouve ni la personne qui a approuvé l’action, ni son motif, ni son résultat métier. Un PID peut valoir zéro, être réutilisé ou n’avoir de sens que dans un hôte. RFC 4001 améliore encore l’identité avec le couple type-valeur d’adresse et les indices de zone, sans créer un historique d’action.

Autre nuance décisive : la déclaration de conformité de RFC 4022 autorise une mise en œuvre en lecture seule. L’écriture et deleteTCB ne sont pas obligatoires. La présence du modèle ne prouve donc pas la capacité ; la capacité ne prouve pas l’autorisation ; l’autorisation ne prouve pas l’exécution.

La section de sécurité de RFC 4022 nomme enfin le danger : une écriture non autorisée peut mettre fin à une connexion arbitraire et provoquer un déni de service. Même la lecture des connexions, écouteurs et processus peut être sensible.

Sécuriser la requête ne prouve pas le résultat

Avec SNMPv3, RFC 3414 apporte identité d’utilisateur, intégrité, contrôle de fraîcheur et confidentialité facultative. RFC 3415 sépare les vues de lecture, d’écriture et de notification selon le modèle de sécurité, le nom, le niveau, le contexte et l’instance.

Ces mécanismes consolident le trajet jusqu’à l’agent. Ils ne fournissent pas le ticket, la justification, l’accusé applicatif, la réception par le pair, la durée d’interruption ou l’effet client. RFC 3414 précise même que l’identité authentifiée est l’utilisateur au nom duquel le message a été produit, pas nécessairement la personne précise qui l’a émis.

La leçon n’est pas d’interdire tout actionneur d’urgence. Elle est de ne jamais confondre voir, être autorisé, agir et démontrer la conséquence. Le document définit le levier ; le réseau en fonctionnement subit son mouvement.

Sources

Limites de la preuve

Les sources établissent les textes normatifs, la filiation, les objets et les options de conformité. Elles ne prouvent ni l’implémentation par un fournisseur, ni l’usage réel de l’écriture, ni un incident, ni un taux de déploiement, ni une exigence de service actuelle.