Résumé

  • RFC 1215 proposait la macro TRAP-TYPE pour relier une autorité d’enregistrement, une suite de variables, une description et un entier aux champs d’un Trap-PDU SNMPv1. Son expansion se faisait lors de l’implémentation, pas lors d’un incident.
  • Le trap exprimait ce que l’entité émettrice disait reconnaître. Il ne démontrait ni panne physique, ni cause, ni impact utilisateur, ni identité authentifiée.
  • SNMPv1 reposait sur un service de datagrammes non fiable et la destination dépendait de l’implémentation. Définition, reconnaissance, génération, envoi, réception et action formaient des preuves distinctes.

Le formulaire précédait le fait

RFC 1215 contient une phrase qui empêche de confondre un catalogue d’alertes avec un journal d’incidents : l’expansion de la macro TRAP-TYPE a lieu conceptuellement pendant l’implémentation, et non à l’exécution.

Un fabricant pouvait donc définir un trap de lien défaillant, choisir les objets associés et rédiger sa signification sans qu’aucun lien ne tombe. L’outil de compilation pouvait vérifier la forme. Le gestionnaire pouvait préparer une règle d’affichage. Ces opérations créaient un vocabulaire commun ; elles ne créaient pas une observation.

La distinction est moins évidente qu’elle n’en a l’air. Une description emploie le présent : l’entité reconnaît une défaillance. Un numéro ressemble à un code d’alarme. Une liste de variables paraît fournir le dossier complet. Mais le module reste un formulaire vierge. Il explique comment lire une instance éventuelle.

La notice du RFC Editor date le document de mars 1991 et le classe Informational. La fiche IETF Datatracker conserve la même identité. Le mémo souligne que l’usage des traps était controversé, le déconseille fortement et présente la macro comme un moyen de décrire les traps existants, non d’en multiplier les nouveaux.

Cette réserve ne permet pas d’affirmer que les traps étaient absents ou inutiles. Elle borne l’autorité du texte : une convention descriptive, pas une approbation générale ni une norme Internet.

Chaque clause gardait sa propre autorité

La clause obligatoire ENTERPRISE indiquait l’entreprise de gestion sous l’autorité d’enregistrement de laquelle le trap était défini. Sa valeur entrait dans le champ enterprise du Trap-PDU.

C’était une indication de registre. Elle ne signait pas le datagramme. Elle ne disait pas quel opérateur humain l’avait envoyé, quelle société possédait désormais l’équipement, ni qui avait le droit d’intervenir. Pour les traps SNMP génériques, la convention plaçait sysObjectID dans ce champ. Là encore, l’identifiant aidait à interpréter un objet configuré ; il n’authentifiait pas une personne.

VARIABLES énumérait, dans l’ordre, les objets MIB présents dans toute instance de ce type. L’ordre faisait partie du contrat, car les objets étaient copiés dans les liaisons de variables. L’agent pouvait toutefois ajouter d’autres variables.

La clause définissait donc un noyau attendu. Elle ne contenait pas les valeurs d’une occurrence future et ne garantissait pas une complétude opérationnelle. Un ifIndex localise une interface dans la configuration. Il ne prouve pas à lui seul qu’un câble est coupé, qu’un circuit est indisponible ou qu’un client a perdu son service.

DESCRIPTION donnait le sens textuel du type ; REFERENCE pouvait relier ce sens à une alarme ou à un événement défini dans un autre module. Le premier restait du texte normatif, le second un lien entre définitions. Ni l’un ni l’autre ne devenait un témoin indépendant d’un cas réel.

Enfin, la valeur entière alimentait specific-trap pour un trap d’entreprise, tandis que generic-trap prenait enterpriseSpecific(6). Dans la convention spéciale snmp, la valeur allait dans generic-trap et specific-trap valait zéro. Ce nombre appartenait à un espace de noms. Il ne mesurait ni gravité, ni confiance, ni durée, ni ordre chronologique.

« Link down » décrivait une reconnaissance locale

L’exemple myLinkDown est soigneusement formulé. Il signifie que l’application SNMP émettrice reconnaît une défaillance sur un lien représenté dans la configuration de l’agent.

Le sujet de la phrase n’est pas le monde physique, mais l’application émettrice. Cette application peut avoir interprété un état de pilote, un compteur, un seuil ou une transition locale. Le trap ne fournit pas une mesure indépendante, une cause racine, un diagnostic de l’opérateur de transport ou l’impact observé par les utilisateurs.

RFC 1157 définit de la même manière le trap générique linkDown : l’entité de protocole émettrice reconnaît une défaillance. La première liaison de variable désigne l’instance ifIndex concernée. L’index donne un objet de configuration ; il ne donne pas tout l’incident.

L’horodatage du Trap-PDU exige la même prudence. Il compte le temps écoulé depuis la dernière réinitialisation de l’entité réseau jusqu’à la génération du trap. Ce n’est pas forcément l’heure murale de la panne, sa première manifestation, ni l’arrivée chez le gestionnaire.

Une chronologie fiable conserve donc séparément l’observation supposée, la reconnaissance par l’application, la génération du PDU, son départ et sa réception.

Une définition pouvait ne jamais produire de paquet

RFC 1157 place la génération sous le contrôle d’un autre acteur : l’entité de protocole ne génère un Trap-PDU qu’à la demande de l’application SNMP. La destination est choisie selon des moyens propres à l’implémentation.

Entre le type et son lecteur se trouvent donc une politique de détection, une demande de génération, une configuration de destinations et éventuellement une règle de suppression. Un trap parfaitement défini peut n’avoir aucun destinataire, viser un ancien gestionnaire ou être ignoré par une application qui ne connaît pas son sens d’entreprise.

L’exemple d’échec d’authentification rend cette absence ambiguë. Une implémentation doit pouvoir produire ce trap, mais aussi pouvoir en supprimer l’émission. Le silence ne signifie donc pas « aucun échec ». Il peut résulter d’une non-détection, d’une suppression, d’une mauvaise destination, d’une perte ou d’un traitement absent.

RFC 1215 précise que les questions de sécurité ne sont pas abordées. Il serait incorrect d’en déduire une authentification de la source, une intégrité, une confidentialité ou une protection contre la répétition.

Le port 162 n’était pas un accusé de réception

SNMPv1 utilisait des messages autonomes transportés par un service de datagrammes non fiable. RFC 1157 réservait le port UDP 162 à la réception des messages de trap pour traitement ultérieur.

Cette convention indiquait une adresse de service, pas le résultat. Elle ne prouvait pas qu’un processus écoutait, qu’un pare-feu laissait passer le paquet, que la mémoire tampon l’acceptait, que le contenu était conservé ou qu’un opérateur le voyait.

À la réception, l’entité de protocole présente le Trap-PDU à son application SNMP. C’est une étape attestable. Elle reste en amont de la corrélation, de l’ouverture d’un ticket, de la décision et de la réparation.

Les textes ultérieurs éclairent la même frontière. RFC 2578 range RFC 1215 dans SMIv1 et emploie NOTIFICATION-TYPE pour décrire de façon concise la syntaxe et la sémantique d’une notification SMIv2. Le changement de macro ne transforme toujours pas un type en occurrence.

RFC 3416 indique qu’un SNMPv2-Trap ne possède aucune confirmation liée à son mécanisme de livraison. Un InformRequest est confirmé, mais sa livraison n’est malgré tout pas garantie. Le destinataire qui le reçoit présente le contenu et renvoie un Response-PDU.

Cette réponse réduit une incertitude : elle apporte une preuve de l’échange avec une entité réceptrice. Elle ne valide pas indépendamment l’événement décrit et n’atteste ni accord humain, ni action corrective, ni rétablissement du service.

L’alerte gagnait sa valeur par les preuves qui la rejoignaient

RFC 1215 laisse apparaître une chaîne de garde. L’auteur du module contrôle la définition. L’autorité d’enregistrement contrôle le nom. L’application de l’agent contrôle la reconnaissance. L’implémentation contrôle génération, suppression et destinations. Le réseau offre une possibilité de transport. Le récepteur contrôle l’acceptation. L’opérateur ou l’automate contrôle la suite.

Confondre ces pouvoirs transforme un code propre en verdict. Les séparer permet d’utiliser le trap comme une assertion bornée : suffisamment précise pour déclencher une enquête, insuffisante pour déclarer seule la cause ou le résultat.

Sources