Summary

  • La RFC 3430 a permis d’utiliser le contrôle de flux TCP pour les échanges SNMP volumineux, mais le flux fiable ne prouvait pas qu’une opération avait été traitée.
  • Le type d’opération restait décisif : snmpV2-trap demeurait sans confirmation, tandis que inform-request produisait une réponse SNMP ayant un sens précis côté récepteur.

Le mot « fiable » appliqué à un transport invite à monter trop vite dans les couches. La connexion reste ouverte, TCP accuse réception des octets, puis la fermeture est propre : peut-on en conclure que l’application de gestion a reçu l’événement ? La RFC 3430 répond par son propre intitulé de section 2.4 : « Reliable Transport versus Confirmed Operations ».

Publiée en décembre 2002 au statut Experimental, la RFC définit une correspondance de transport SNMP sur TCP. Elle ne remplace pas le modèle de messages SNMP et ne transforme pas toutes les notifications en opérations confirmées. Elle vise d’abord les transferts en volume. Cette correspondance optionnelle n’exempte pas les moteurs SNMP d’implémenter aussi le transport sur UDP défini par la RFC 3417. Et l’initiateur choisit le transport pour toute la transaction requête-réponse : il ne peut pas en changer au milieu.

TCP apporte contrôle de flux et segmentation, utiles lorsque UDP exigerait de nombreuses petites interactions. Mais une connexion a un coût : établissement, fermeture et état conservé par le système d’exploitation. Un répondeur sous pression peut refuser de nouvelles connexions TCP. La RFC recommande aussi de retarder les temporisateurs de retransmission SNMP par rapport aux temporisateurs TCP, afin que l’application n’expire pas avant le transport.

Le passage du datagramme au flux modifie le cadrage. UDP livre une frontière de datagramme par message ; TCP remet une suite d’octets dont les découpes de lecture ne coïncident pas nécessairement avec les messages SNMP. Le récepteur doit donc utiliser le champ de longueur BER pour séparer les messages. L’émetteur ne doit pas entrelacer leurs octets. Une connexion persistante, bidirectionnelle, peut néanmoins porter plusieurs paires requête-réponse en attente, et les réponses peuvent revenir dans un ordre différent de celui des requêtes. La frontière du message reste explicite même quand l’ordre des réponses change.

Ce cadrage ne prouve pas que l’application a agi. Dans les limites posées par la RFC, TCP protège le flux d’octets ordonné entre ses extrémités ; il ne démontre pas que le processus SNMP distant a analysé ou traité le message. Même une fermeture TCP normale ne prouve pas que tous les octets ont été remis à l’application. Et l’emploi de TCP ne garantit pas qu’un message envoyé finira par atteindre son système distant.

Une réponse liée à l’opération offre un reçu différent. La RFC distingue le trap snmpV2-trap, non confirmé, de l’inform-request, confirmé. Transporter le trap sur TCP ne lui ajoute pas une confirmation SNMP. La réponse à un Inform indique que la notification a franchi le transport et le modèle de sécurité, puis a été mise en file pour l’application réceptrice. La réponse à set-request indique que le répondeur de commandes a traité l’écriture. Ces accusés sont significatifs au niveau du protocole, mais ne prouvent ni qu’une personne a vu l’alerte, ni qu’un processus métier a réagi, ni que l’état réel visé a changé.

L’échec d’établissement de connexion sépare aussi l’intention du reçu. Selon la RFC, si la connexion TCP ne peut être établie, la transaction est abandonnée et signalée à l’application comme expirée. L’annexe examine le repli vers UDP et d’autres procédures, sans prétendre effacer l’incertitude : un émetteur de notifications qui exige une livraison fiable doit conserver dans un journal local celles dont la connexion a échoué. Le repli ou les tentatives ne suppriment pas ce besoin. Le journal garde une obligation à traiter ; il ne prouve pas que le destinataire l’a reçue.

La sécurité reste distincte. La correspondance TCP ne modifie pas les mécanismes SNMPv3. La RFC recommande le modèle de sécurité fondé sur l’utilisateur et le contrôle d’accès fondé sur les vues, tout en signalant le risque de déni de service, notamment par SYN flood. Authentification, autorisation, livraison d’octets, mise en file d’une notification et effet opérationnel sont des reçus différents.

La contribution historique de la RFC 3430 est donc plus précise que « SNMP sur TCP est fiable ». Elle fournit un transport en flux aux gros échanges, spécifie le cadrage des messages dans ce flux, puis rappelle que la fiabilité du transport n’est qu’un mauvais substitut à une opération confirmée. Un trap reste un trap ; un Inform reste une opération avec une réponse. Le même flux peut porter les deux sans déterminer ce que le récepteur a fait.

Cet article décrit le contrat de la RFC, sans prétendre mesurer son adoption, ses performances, son support dans un produit ou une panne particulière. La chaîne de preuve est composée : connexion établie, message BER cadré, octets livrés, opération reçue ou traitée par le moteur SNMP, notification mise en file dans l’application, puis action ultérieure. La RFC ne définit des réponses qu’à certains de ces stades.

Sources : RFC 3430 ; RFC 3417 ; RFC 3411 ; RFC 3413 ; RFC 3414 ; RFC 3415 ; RFC 3419 ; RFC 9293. Statut : RFC Editor.