Résumé

  • Une partie SNMPv2 associait identité, domaine de transport, adresse, taille maximale, authentification, confidentialité et périmètre d’opérations ; l’adresse seule n’était donc pas le principal.
  • Une requête nouvelle partait vers les coordonnées configurées, tandis que sa réponse devait revenir vers le domaine et l’adresse réellement observés à l’arrivée, même si la base les contredisait.
  • Cette exception assurait la continuité d’un échange sans mettre à jour automatiquement l’inventaire, élargir l’accès ni prouver l’effet de l’opération.

Le carnet d’adresses ouvrait l’échange

Dans la RFC 1445, une « partie » n’était pas un simple point réseau. Elle constituait un environnement virtuel d’exécution, muni d’une identité unique et limité à un sous-ensemble d’opérations. Son emplacement logique réunissait un domaine de transport et une adresse ; d’autres champs fixaient taille de message, authentification et confidentialité.

Chaque entité conservait localement les parties connues, les ressources gérées et la politique d’accès. Pour créer une requête, elle nommait origine, destination, contexte et opération, puis cherchait dans cette base les paramètres des deux parties. Le transport utilisait ensuite les coordonnées enregistrées pour le destinataire.

La configuration avait donc une fonction précise : fournir un premier chemin avant toute observation récente. Elle ne certifiait ni la présence actuelle de la partie, ni son identité effective à cette adresse, ni l’acceptation distante de la demande.

La notice RFC classe aujourd’hui ce modèle comme historique. L’architecture des parties n’est pas un conseil de déploiement contemporain ; sa séparation des preuves reste instructive.

Recevoir ne suffisait pas à autoriser

Le traitement entrant franchissait plusieurs contrôles. L’enveloppe devait être décodable. La partie destinataire devait exister et être réalisée par l’entité locale. La destination intérieure devait correspondre à celle de l’enveloppe. La partie source déclarée devait elle aussi être connue.

L’entité évaluait ensuite le protocole d’authentification configuré, cherchait le contexte et appliquait une règle croisant cible, sujet, ressources et classes d’opérations. Ce n’est qu’après ces étapes qu’elle agissait sur une vue MIB locale ou par une relation de proxy.

Le tuple réseau observé n’était donc jamais, à lui seul, une autorisation. Même la valeur historique noAuth, qui faisait considérer un message comme authentique selon ce choix, ne transformait pas son adresse source en preuve cryptographique.

La réponse appartenait à cette requête

La section 3.3 inverse les identités source et destination de la communication reçue, conserve le contexte et insère le résultat de l’opération. Mais elle modifie surtout l’étape de transport : la réponse doit employer le domaine et l’adresse d’où provenait la requête correspondante, même s’ils diffèrent des informations de la base locale.

Pour ce retour seulement, le fait observé l’emportait sur le catalogue. Il évitait de rouvrir une résolution générale susceptible de conduire ailleurs et maintenait la réponse dans l’état de l’échange qui l’avait produite.

Cette priorité était bornée. La procédure ne contient pas d’écriture automatique de la nouvelle coordonnée dans la base des parties. Elle ne dit pas si l’écart vient d’une donnée périmée, d’une interface alternative, d’un intermédiaire ou d’une autre cause. Le paquet fournit un chemin ; l’opérateur garde la décision durable.

Répondre ne corrigeait pas le monde

Un retour réussi établissait que cette réponse avait utilisé cette destination. Il ne prouvait pas que la prochaine requête devait suivre le même trajet, que l’ancienne adresse était morte ou que l’inventaire avait été réparé.

Il ne remplaçait pas non plus les contrôles du message. Identités de partie, authentification, contexte et ACL demeuraient nécessaires. Une réponse positive à un Set ne démontrait pas la persistance après redémarrage ni l’effet attendu sur le réseau.

La distinction correspond à une règle de réalité : une observation doit gouverner l’acte qu’elle éclaire, sans être promue en vérité universelle. Ici, l’arrivée du paquet justifiait son retour, pas une mutation de politique.

Les tables modifiables portaient une autorité supérieure

La RFC 1447 exposait les tables de parties, contextes, contrôle d’accès et vues. Elle avertissait qu’un accès complet aux quatre donnait l’équivalent d’un pouvoir root : le gestionnaire pouvait créer des parties avec toutes les capacités.

Modifier une adresse de partie n’était donc pas une simple optimisation de routage. Dans ce modèle, l’adresse rejoignait clés, protocoles, contextes et privilèges. Transformer automatiquement une source observée en état permanent aurait franchi une limite d’autorité.

Le modèle permettait d’accorder à un gestionnaire moindre la maintenance de ses propres parties sans lui permettre d’en augmenter les capacités. Maintenir la joignabilité et gouverner l’accès restaient deux fonctions.

L’architecture suivante conserva un état de réponse

La RFC 3411 sépara plus tard répartition, traitement des messages, sécurité, contrôle d’accès, applications et transports. La RFC 3412 associa à une requête entrante une stateReference réutilisée pour préparer une éventuelle réponse.

Cet état fournit le domaine et l’adresse de destination ; le répartiteur envoie la réponse à l’auteur de la requête. Pour SNMPv3, les coordonnées de transport figurent parmi les données mises en cache. Le vocabulaire a changé, mais la réponse resta rattachée à un échange observé plutôt que reconstruite à partir d’un inventaire abstrait.

Cette filiation ne prouve ni conformité universelle ni déploiement actuel. Elle montre seulement que l’état éphémère d’une conversation et le catalogue durable ont des rôles différents.

Sources