Résumé

  • La RFC 1441 décrivait SNMPv2 comme sept domaines articulés, dont un cadre administratif donnant au message son sens en matière d’authentification et d’autorisation. « Version 2 » ne désignait pas un protocole monolithique.
  • Le modèle originel fondé sur les parties n’a pas constitué la voie durable. La RFC 1901 a marié les opérations de SNMPv2 à l’ancien mécanisme de communautés ; le nouveau numéro distinguait la grammaire des PDU, pas une sécurité forte.
  • La RFC 3411 a ensuite séparé formellement traitement des messages, sécurité et contrôle d’accès. Pour connaître le risque, il faut inventorier les modèles et la politique observés, non extrapoler à partir de la version.

Un chiffre discret, une promesse beaucoup trop large

Un analyseur affiche version: 1. Un inventaire humain traduit volontiers : première version. Pourtant, dans l’enveloppe de SNMPv2c, zéro correspond à SNMPv1 et un à SNMPv2. Le champ est une valeur d’énumération destinée au décodeur, pas une phrase destinée au responsable de la sécurité.

À côté figurent une chaîne de communauté et une PDU de SNMPv2. Le chiffre choisit le mode de traitement du message. La chaîne appartient au dispositif administratif hérité. La PDU décrit une opération. La proximité des octets ne fusionne pas leurs fonctions.

Ce paquet concentre une histoire que la succession habituelle « v1, v2, v3 » rend illisible. Des composants ont continué, d’autres ont été abandonnés, d’autres encore ont été recombinés. Le nom général est resté assez stable pour masquer le changement de montage.

La RFC 1441 dressait une carte du système

Publié en avril 1993 puis reclassé Historic, le dossier de la RFC 1441 présente le deuxième cadre Internet de gestion de réseau. Il faut prendre le mot cadre au sérieux.

Le texte de la RFC 1441 répartissait l’ensemble en sept domaines. La SMI donnait une langue aux objets gérés. Les conventions textuelles ajoutaient une sémantique humaine précise aux types primitifs. Les opérations définissaient les PDU. Les adaptations de transport indiquaient comment porter les messages. L’instrumentation décrivait le comportement des entités. Le cadre administratif fixait authentification et autorisation. Les déclarations de conformité distinguaient minimum exigé et capacité effectivement réalisée.

Aucun domaine ne valait preuve des six autres. La définition d’un objet MIB ne choisissait pas son transport. Une adresse de transport ne donnait aucun droit. Une opération bien formée n’authentifiait pas son émetteur. Une capacité déclarée ne démontrait pas son activation sur l’équipement observé.

Le document indiquait surtout que la forme et le sens de l’enveloppe dépendaient du cadre administratif. L’autorité ne se trouvait donc pas dans le verbe Get ou Set. Il restait à déterminer de qui venait la demande et ce que ce principal pouvait accomplir.

Les « parties » devaient porter l’administration

Le dessin de 1993 s’organisait autour d’une party SNMPv2, contexte virtuel d’exécution limité à un sous-ensemble d’opérations défini administrativement. Une partie était associée à un protocole d’authentification et à un protocole de confidentialité ; une MIB en exposait les propriétés.

Ce mécanisme n’était pas une annexe facultative collée au protocole. Il devait fournir le contexte dans lequel l’opération recevait sa signification administrative. Changer l’enveloppe et la partie revenait donc à changer l’histoire d’authentification et d’autorisation, même si l’on conservait une PDU portant le nom SNMPv2.

On aperçoit ici un défaut courant des versions. La spécification décompose proprement le système, puis le marché le recompresse en une seule étiquette. Tant que tous les éléments voyagent ensemble, l’abréviation paraît honnête. Dès qu’un composant est remplacé, elle devient équivoque.

SNMPv2c a gardé les opérations, pas le contrat initial

En janvier 1996, la RFC 1901 a défini SNMPv2 communautaire, ou SNMPv2c. Elle n’a pas simplifié le modèle des parties. Elle a repris le cadre administratif de SNMPv1, associé chaque message à une communauté et placé dans cette enveloppe les PDU et erreurs nouvelles de SNMPv2.

Le numéro de version de l’enveloppe est alors devenu 1. Cette nouvelle valeur était nécessaire parce que les types de PDU et les codes d’erreur exigeaient la bonne grammaire. Mais elle n’a pas métamorphosé la communauté en authentification robuste. Elle permettait au destinataire de savoir comment lire les données.

Le compromis explique la postérité étrange de SNMPv2. Les compteurs plus larges, la récupération en masse, les notifications confirmées, les erreurs enrichies et la création de lignes pouvaient rester utiles. Leur survie n’emportait pas celle de l’administration originelle. Grâce à la modularité, le langage de gestion a franchi l’échec d’un dispositif de sécurité ; à cause de cette même modularité, le simple nom de version a perdu sa valeur de description complète.

La norme a tranché sans effacer le terrain

La rétrospective publiée par l’IETF en 2002, la RFC 3410, ne dissimule pas le désaccord. Elle situe SNMPv2p, fondé sur les parties, entre 1993 et 1995. Le cadre SNMPv2 ultérieur ne possédait plus son propre cadre normalisé de sécurité et d’administration. SNMPv2c recueillait le soutien le plus important, mais sans sécurité ni administration ; les variantes qui en proposaient n’avaient pas obtenu de consensus.

Quand la sécurité et l’administration de SNMPv3 ont atteint le niveau Standard, SNMPv1 et SNMPv2c expérimental ont été rendus Historic en raison de la faiblesse fondamentale des chaînes de communauté en clair. Les autres voies de SNMPv2 étaient déjà historiques ou n’avaient jamais rejoint la filière normative.

La même RFC prévoyait pourtant que constructeurs et utilisateurs conserveraient des moteurs multilingues capables de parler v1 ou v2c avec v3. Le processus de normalisation ne commandait pas leurs déploiements. Une qualification documentaire et une réalité d’exploitation ne sont pas le même fait.

Historic ne veut donc pas dire absent. Présent ne veut pas dire recommandé. Une réponse v2c observée prouve qu’un chemin fonctionne encore ; elle ne transforme pas ce chemin en choix de sécurité actuel. À l’inverse, un changement de statut dans le catalogue ne prouve pas que les communautés ont disparu des interfaces.

La version est devenue une entrée du répartiteur

La RFC 3411 a donné à cette expérience une architecture plus nette. Elle sépare transport, traitement et répartition des messages, sécurité, opérations, applications et contrôle d’accès. Les documents et les modèles peuvent avancer selon des calendriers différents derrière des interfaces définies.

Elle distingue aussi trois mots que l’usage confond : un cadre rassemble des sous-systèmes ; un modèle décrit précisément l’un d’eux ; une implémentation instancie un ou plusieurs modèles. Le texte va jusqu’à préciser que SNMPv2 n’a pas de définition de message : SNMPv2c lui ajoute un format voisin de celui de SNMPv1.

Le champ de version identifie normalement un modèle de traitement des messages. Un même moteur peut en accepter plusieurs. La sécurité des messages traite séparément authentification, chiffrement et fraîcheur. Le contrôle d’accès décide encore séparément si l’opération peut atteindre l’objet géré. Plusieurs modèles de sécurité peuvent coexister dans un moteur.

Le premier chiffre du paquet sert donc d’aiguillage. Il n’est pas le résumé signé de la posture de l’équipement. Même l’étiquette SNMPv3 ne garantit pas qu’une session observée utilise authentification et confidentialité : il faut connaître le modèle et le niveau sélectionnés.

Remplacer la colonne « version » par un registre des modules

Un inventaire à une seule colonne—v2, v2c ou v3—est séduisant parce qu’il est compact. Il devient dangereux pendant une migration. Le même moteur peut répondre à plusieurs modèles ; une interface ancienne peut garder une communauté alors qu’une nouvelle chaîne utilise une sécurité plus forte ; deux principaux peuvent recevoir des vues très différentes.

Le registre utile conserve d’abord le point de transport réellement atteint. Il note ensuite le modèle de traitement décodé, puis le modèle et le niveau de sécurité. Il enregistre l’identité revendiquée ou authentifiée, le contexte, le modèle de contrôle d’accès et la vue accordée. Enfin, il garde la PDU, la réponse et une observation indépendante de l’effet matériel allégué.

Ces éléments peuvent être reliés par un identifiant de requête. Ils ne sont pas interchangeables. Une version ne prouve pas un principal. Un principal ne prouve pas l’accès à cet objet. Une autorisation ne prouve pas la modification du dispositif. Une réponse positive ne prouve pas la persistance après redémarrage.

L’échec du paquet de 1993 porte ainsi une leçon constructive. La modularité a sauvé des investissements utiles lorsque l’administration par parties n’a pas survécu. Elle interdit en retour d’utiliser le nom du cadre comme vérité opérationnelle. Il faut enregistrer le montage qui a effectivement tourné.

Sources

  • Dossier et statut de la RFC 1441.
  • Introduction au cadre dans la RFC 1441.
  • Supplément communautaire de la RFC 1901.
  • Histoire normative et applicabilité dans la RFC 3410.
  • Architecture modulaire de la RFC 3411.