Résumé

  • Dans le RFC 1503, une application remet un texte au « context resolver » au lieu d’exiger de l’utilisateur les parties et le contexte SNMPv2.
  • À défaut de contexte connu, le gestionnaire peut créer des parties noAuth/noPriv, un contexte et une ACL volatils pour get, get-next et get-bulk. Les exigences de sécurité de l’opération restent décisives.

La promesse tient en une ligne de saisie. L’utilisateur indique une machine ; le gestionnaire trouve comment lui parler. Keith McCloghrie et Marshall Rose décrivent ce mécanisme dans un mémo d’août 1993. Leur résolveur consulte d’abord une base locale que l’administrateur a préparée. Il ne part donc pas d’une confiance abstraite dans le nom : il commence par les fiches déjà rangées.

Une correspondance exacte choisit un contexte. Le texte router.xyz.com-public désigne ainsi le contexte public de l’exemple. Un préfixe plus court, router.xyz.com, peut désigner deux contextes, public et -all. Ce dernier dispose dans l’exemple d’un chemin authentifié incluant set, tandis que le premier autorise les interrogations. La facilité offerte à l’opérateur produit parfois plusieurs candidats ; l’opération demandée et le niveau de sécurité exigé départagent ensuite les ACL.

En l’absence de correspondance, l’adresse IP ou le nom résolu entraîne une autre action. Pour une adresse, le résolveur inscrit une paire de parties noAuth/noPriv, un contexte et une ACL volatils, limités à get, get-next et get-bulk. Un nom renvoyant plusieurs adresses déclenche autant de contextes. Les identifiants suivent les conventions initialPartyId et initialContextId du Party MIB. Rien dans cette fabrication locale ne constate que l’agent distant a accepté la requête.

Le mémo prévoit même une notation avec barre oblique : après le nom d’hôte, les caractères deviennent une communauté SNMPv1. Le résolveur peut alors créer un contexte d’interrogation temporaire pour cette version. Sous l’allure d’un raccourci ergonomique, le champ de saisie transporte aussi un élément de configuration.

Au moment d’émettre l’opération, le gestionnaire recherche une ACL autorisant celle-ci et satisfaisant les exigences minimales de sécurité. Il privilégie une entrée SNMPv2 admissible ; si une authentification est requise et qu’aucune entrée convenable n’existe, l’opération n’est pas lancée. Le nom ouvre la recherche, il ne signe pas l’autorisation.

La fiche du RFC Editor classe le texte comme Informational. Son modèle est illustratif ; aucun déploiement nommé n’y est documenté. Le chapitre final annonce simplement que les questions de sécurité n’y sont pas traitées. La trace historique est ailleurs : pour retirer des questions à l’utilisateur, le logiciel doit répondre lui-même à ces questions, et garder la réponse quelque part.