Groupe de travail Réseau	D. Harrington, Huawei Technologies (USA)	
Request for Comments: 5591	W. Hardaker, Cobham Analytic Solutions	
Catégorie : Sur la voie de la normalisation	juin 2009	
Traduction Claude Brière de L'Isle		

Modèle de sécurité du transport pour le protocole simple de gestion de réseau (SNMP)

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet sur la voie de la normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de droits de reproduction
Copyright (c) 2009 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document. 

Le présent document peut contenir des matériaux provenant de documents de l’IETF ou de contributions à l’IETF publiées ou rendues disponibles au public avant le 10 novembre 2008. La ou les personnes qui ont le contrôle des droits de reproduction sur tout ou partie de ces matériaux peuvent n’avoir pas accordé à l’IETF Trust le droit de permettre des modifications de ces matériaux en dehors du processus de normalisation de l’IETF. Sans l’obtention d’une licence adéquate de la part de la ou des personnes qui ont le contrôle des droits de reproduction de ces matériaux, le présent document ne peut pas être modifié en dehors du processus de normalisation de l’IETF, et des travaux dérivés ne peuvent pas être créés en dehors du processus de normalisation de l’IETF, excepté pour le formater en vue de sa publication comme RFC ou pour le traduire dans une autre langue que l’anglais.

Résumé
Le présent mémoire décrit un modèle de sécurité du transport pour le protocole simple de gestion du réseau (SNMP, Simple Network Management Protocol).

Le présent mémoire définit aussi une portion de la base de données d'informations de gestion (MIB, Management Information Base) pour surveiller et gérer le modèle de sécurité du transport pour SNMP.

Table des matières
1. Introduction	2
1.1 Cadre de gestion standard de l'Internet	2
1.2 Conventions	2
1.3 Modularité	3
1.4 Motifs	3
1.5 Contraintes	3
2. Comment le modèle de sécurité du transport s'intègre dans l'architecture	4
2.1 Capacités de sécurité de ce modèle	4
2.2 Sessions de transport	4
2.3 Coexistence	4
3. Informations et références en antémémoire	5
3.1 Informations du modèle de sécurité du transport en antémémoire	5
4. Traitement d'un message sortant	6
4.1 Traitement de sécurité d'un message sortant	6
4.2 Éléments de procédure pour les messages sortants	7
5. Traitement d'un message SNMP entrant	8
5.1 Traitement de sécurité d'un message entrant	8
5.2 Éléments de procédure pour les messages entrants	8
6. Vue d'ensemble du module de MIB	9
6.1 Structure du module de MIB	9
6.2 Relations aux autres modules de MIB	9
7. Définition du module de MIB	9
8. Considérations sur la sécurité	13
8.1 Sécurité du module de MIB	13
9. Considérations relatives à l'IANA	14
10. Remerciements	14
11. Références	14
11.1 Références normatives	14
11.2 Références pour information	15
Appendice A. Configuration des tableaux de notification	15
A.1 Traitement du modèle de sécurité du transport pour les notifications	16
Appendice B. Différences de traitement entre USM et transport sûr	17
B.1 USM et l'architecture de la RFC 3411	17
B.2 Sous système de transport et l'architecture de la RFC 3411	17
Adresse des auteurs	17

 	1.	Introduction

Le présent mémoire décrit un modèle de sécurité du transport pour le protocole simple de gestion de réseau à utiliser avec des modèles de transport sûr dans le sous système de transport [RFC5590].

Le présent mémoire définit aussi une portion de la base de données d'informations de gestion (MIB, Management Information Base) pour surveiller et gérer le modèle de sécurité du transport pour SNMP.

Il est important de comprendre l'architecture SNMP et la terminologie de l'architecture pour comprendre comment le modèle de sécurité du transport décrit dans le présent mémoire s'inscrit dans l'architecture et interagit avec les autres sous systèmes et modèles au sein de l'architecture. Les lecteurs sont aussi supposés avoir lu et compris les [RFC3411], [RFC3412], [RFC3413], et [RFC3418].

 	1.1	Cadre de gestion standard de l'Internet
Pour une vue détaillée des documents qui décrivent le cadre actuel de gestion des normes de l'Internet, voir la Section 7 de la [RFC3410].

Les objets gérés sont accédés via un magasin virtuel d'informations, appelé une base de données d'informations de gestion 'MIB, Management Information Base). Les objets de MIB sont généralement accédés par le protocole simple de gestion de réseau (SNMP). Les objets de la MIB sont définis en utilisant les mécanismes définis dans la structure des informations de gestion (SMI, Structure of Management Information). Le présent mémoire spécifie un module de MIB conforme à SMIv2, qui est décrit dans le STD 58, [RFC2578], [RFC2579] et [RFC2580].

 	1.2	Conventions
Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

Les versions en minuscules des mots-clés devraient être lues comme en français normal. Elles vont généralement, mais pas toujours, être utilisées dans un contexte en relation avec la compatibilité avec l'architecture de la RFC3411 ou le sous système défini ici, mais qui pourraient n'avoir pas d'impact sur la compatibilité sur le réseau. Ces termes sont utilisés comme des indications pour les concepteurs de modèles proposés à l'IETF pour rendre la conception compatible avec les sous systèmes de la RFC 3411 et les interfaces de service abstraites (ASI). Les mises en œuvrer sont libres d'en faire une application différente. Certains usages de ces termes en minuscules sont simplement un usage normal français.

Pour la cohérence avec les spécifications relatives à SNMP, le présent document préfère la terminologie définie dans le STD 62, plutôt que la terminologie des spécifications non SNMP qui utilisent des variantes différentes de la même terminologie. Ceci est conforme à la décision de l'IESG de ne pas exiger que la terminologie de SNMPv3 soit modifiée pour correspondre à l'usage d'autres spécifications non SNMP quand SNMPv3 a été avancé au statut de norme.

L'authentification dans le présent document se réfère normalement à la signification française de "servir à prouver l'authenticité" du message, et non à l'authentification de la source des données ou à l'authentification de l'identité de l'homologue.

Les termes "gestionnaire" et "agent" ne sont pas utilisés dans le présent document parce que, dans l'architecture de la RFC3411, toutes les entités SNMP ont la capacité d'agir comme gestionnaire, agent, ou les deux, selon les applications SNMP incluses dans le moteur. Lorsque la distinction est nécessaire, les noms d'application du générateur de commande, répondeur de commande, générateur de notification, receveur de notification, et transmetteur mandataire sont utilisés. Voir plus d'informations dans "Applications du protocole simple de gestion de réseau (SNMP)" [RFC3413].

Bien que les protocoles de sécurité se réfèrent fréquemment à un utilisateur, la terminologie utilisée dans la [RFC3411] et dans le présent mémoire est "principal". Un principal est "celui" au nom duquel les services sont fournis ou chez lequel le traitement a lieu. Un principal peut être, entre autres choses, un individu qui agit dans un rôle particulier, un ensemble d'individus agissant chacun dans un rôle particulier, une application ou un ensemble d'applications, ou une combinaison d'eux au sein d'un domaine administratif.

 	1.3	Modularité
Le lecteur est supposé avoir lu et compris la description de l'architecture SNMP, définie dans la [RFC3411], et l'extension à l'architecture spécifiée dans "Sous système de transport pour le protocole simple de gestion de réseau (SNMP)" [RFC5590], qui permet l'utilisation de protocoles externes de "transport de couche inférieure" pour assurer la sécurité du message. Les modèles de transport sont liés dans l'architecture SNMP par le sous système de transport. Le modèle de sécurité du transport est conçu pour fonctionner avec de tels modèles de transport sûr de couche inférieure

Conformément aux décisions de conception de la RFC 3411 d'utiliser des documents auto suffisants, le présent mémoire inclut les éléments de procédure plus les objets de MIB associés qui sont nécessaires pour traiter le modèle de sécurité du transport pour SNMP. Ces objets de MIB NE DEVRAIENT PAS être référencés dans d'autres documents. Cela permet que le modèle de sécurité du transport soit conçu et documenté comme indépendant et auto-suffisant, n'ayant pas d'impact direct sur les autres modules. Cela permet aussi que ce module soit mis à niveau et complété lorsque le besoin s'en fait sentir, et d'avancer sur la voie de la normalisation sur un rythme différent de celui des autres modules.

Cette modularité de spécification n'est pas destinée à être interprétée comme imposant des exigences spécifiques à la mise en œuvre.

 	1.4	Motifs
Le présent mémoire décrit un modèle de sécurité pour utiliser les modèles de transport qui utilisent des transports sûrs de couche inférieure et des infrastructures de sécurité existantes et couramment déployées. Ce modèle de sécurité est conçu pour satisfaire les besoins de sécurité et de fonctionnement des administrateurs de réseau, maximiser l'utilisabilité dans les environnements opérationnels pour réaliser un haut niveau de succès de déploiement, et en même temps minimiser les coûts de mise en œuvre et de déploiement pour minimiser le délai avant la possibilité du déploiement.

 	1.5	Contraintes
La conception de ce modèle de sécurité SNMP est aussi influencée par les contraintes suivantes :

1.	Dans les périodes de tension du réseau, le protocole de sécurité et ses mécanismes de sécurité sous-jacents NE DEVRAIENT PAS dépendre seulement de la disponibilité directe d'autres services du réseau (par exemple, le protocole de l'heure du réseau (NTP) ou de protocoles d'authentification, autorisation, et comptabilité (AAA)).

2.	Quand le réseau n'est pas sous tension, le modèle de sécurité et ses mécanismes de sécurité sous-jacents PEUVENT dépendre de la disponibilité directe d'autres services du réseau.

3.	Il pourrait n'être pas possible au modèle de sécurité de déterminer quand le réseau est sous tension.

4.	Un modèle de sécurité NE DEVRAIT PAS exiger de changement à l'architecture SNMP.

5.	Un modèle de sécurité NE DEVRAIT PAS exiger de changement au protocole de sécurité sous-jacent.

 	2.	Comment le modèle de sécurité du transport s'intègre dans l'architecture

Le modèle de sécurité du transport est conçu pour tenir dans l'architecture de la RFC3411 comme modèle de sécurité dans le sous système de sécurité et pour utiliser les services d'un modèle de transport sûr.

Pour les messages entrants, un modèle de transport sûr va passer une antémémoire tmStateReference, décrite dans la [RFC5590]. Pour conserver la modularité de la RFC 3411, le modèle de transport ne va pas savoir quel securityModel va traiter le message entrant ; le modèle de traitement de messages va le déterminer. Si le modèle de sécurité du transport est utilisé avec un modèle de transport non sûr, alors l'antémémoire ne va pas exister ou ne va pas être remplie avec les paramètres de sécurité, ce qui va causer le retour d'une erreur par le modèle de sécurité du transport (voir le paragraphe  5.2).

Le modèle de sécurité du transport va créer le securityName et securityLevel à passer aux applications, et va vérifier que le tmTransportSecurityLevel rapporté par le modèle de transport est au moins aussi fort que le securityLevel demandé par le modèle de traitement de messages.

Pour les messages sortants, le modèle de sécurité du transport va créer une antémémoire tmStateReference (ou en utiliser une existante) et va passer le tmStateReference au modèle de transport spécifié.

 	2.1	Capacités de sécurité de ce modèle
 	2.1.1	Menaces
Le modèle de sécurité du transport est compatible avec l'architecture de la RFC3411 et fournit une protection contre les menaces identifiées par l'architecture de la RFC3411. Cependant, le modèle de sécurité du transport ne fournit pas lui-même de mécanismes de sécurité comme l'authentification et le chiffrement. Les menaces traitées et comment elles sont atténuées dépend du modèle de transport utilisé. Pour éviter de créer de potentielles vulnérabilités de la sécurité, les opérateurs devraient configurer leur système afin que ce modèle de sécurité soit toujours utilisé avec un modèle de transport qui fournisse une sécurité appropriée, où "approprié" pour un déploiement particulier est une décision administrative.

 	2.1.2	Niveaux de sécurité
L'architecture de la RFC3411 reconnaît trois niveaux de sécurité :
-	sans authentification et sans confidentialité (noAuthNoPriv)
-	avec authentification mais sans confidentialité (authNoPriv)
-	avec authentification et avec confidentialité (authPriv)

Le paramètre securityLevel indépendant du modèle est utilisé pour demander des niveaux spécifiques de sécurité pour les messages sortants et pour affirmer que des niveaux spécifiques de sécurité ont été appliqués durant le transport et le traitement des messages entrants.

Les algorithmes de couche de transport utilisés pour fournir la sécurité ne devraient pas être exposés au modèle de sécurité du transport, car le modèle de sécurité du transport n'a pas de mécanisme pour vérifier si une assertion faite par un modèle de transport est exacte.

Le modèle de sécurité du transport fait confiance à la connexion de transport sûr sous-jacente comme ayant été configurée de façon adéquate pour prendre en charge des caractéristiques de sécurité au moins aussi fortes que rapporté dans tmTransportSecurityLevel.

 	2.2	Sessions de transport
Le modèle de sécurité du transport ne fonctionne pas directement avec les sessions de transport. L'état relatif au transport est plutôt associé à une combinaison unique de transportDomain, transportAddress, securityName, et securityLevel, et est référencé via le paramètre tmStateReference. Comment et si ceci est transposé en un transport ou canal particulier est de la responsabilité du sous système de transport.

 	2.3	Coexistence
Dans l'architecture de la RFC3411, un modèle de traitement de messages détermine quel modèle de sécurité DEVRA être invoqué. Au moment de la rédaction du présent mémoire, l'IANA a enregistré quatre modèles de traitement de message (SNMPv1, SNMPv2c, SNMPv2u/ SNMPv2*, et SNMPv3) et trois autres modèles de sécurité (SNMPv1, SNMPv2c, et le modèle de sécurité fondé sur l'utilisateur (USM)).

 	2.3.1	Coexistence avec les modèles de traitement de message
Les traitements de message SNMPv1 et SNMPv2c décrits dans le BCP 74 [RFC3584] choisissent toujours les modèles de sécurité SNMPv1(1) et SNMPv2c(2). Comme il n'y a pas de mécanisme défini dans la RFC 3584 pour choisir un modèle de sécurité de remplacement, les messages SNMPv1 et SNMPv2c ne peuvent pas utiliser le modèle de sécurité du transport. Les messages pourraient quand même être capables d'être portés sur un protocole de transport sûr, mais le modèle de sécurité du transport ne va pas être invoqué.

Le modèle de traitement de messages SNMPv2u/SNMPv2* est une construction historique pour laquelle il n'y a pas de spécification existante de l'IETF.

Le traitement du message SNMPv3 défini dans la [RFC3412] extrait le securityModel du champ msgSecurityModel d'un message SNMPv3 entrant. Quand cette valeur est transportSecurityModel(4), le traitement de sécurité est dirigé sur le modèle de sécurité du transport. Pour qu'un message sortant soit sécurisé en utilisant le modèle de sécurité du transport, l'application DOIT spécifier une valeur de paramètre securityModel de transportSecurityModel(4) dans l'interface de service abstrait (ASI, Abstract Service Interface) sendPdu.

 	2.3.2	Coexistence avec d'autres modèles de sécurité
Le modèle de sécurité du transport utilise son propre module de MIB pour le traitement afin de conserver l'indépendance aux autres modèles de sécurité. Cela permet que le modèle de sécurité du transport coexiste avec d'autres modèles de sécurité, comme le modèle de sécurité fondé sur l'utilisateur (USM) [RFC3414].

 	2.3.3	Coexistence avec les modèles de transport
Le modèle de sécurité du transport (TSM) PEUT fonctionner avec plusieurs modèles de transport, mais les interfaces de service abstraites (ASI) de la RFC 3411 ne portent pas de valeur pour le modèle de transport. Le module de MIB défini dans le présent mémoire permet à un administrateur de configurer si le TSM ajoute ou non un préfixe de modèle de transport au securityName. Cela va permettre aux applications SNMP de considérer le modèle de transport comme un facteur quand elles prennent des décisions, comme de contrôle d'accès, de génération de notification, et de transmission par mandataire.

Pour que SNMP utilise de façon appropriée les services de sécurité coordonnés par le modèle de sécurité du transport, ce modèle de sécurité DOIT seulement être utilisé avec des modèles de transport qui savent comment traiter une tmStateReference, comme le modèle de transport Secure Shell [RFC5592].

 	3.	Informations et références en antémémoire

Quand on effectue le traitement SNMP, il y a deux niveaux d'informations d'état qui pourraient devoir être conservés : l'état immédiat reliant une paire de demande-réponse et un état potentiellement à plus long terme relatif au transport et à la sécurité. La [RFC5590] "Sous système de transport pour le protocole simple de gestion de réseau (SNMP)" définit les exigences générales pour les antémémoires et les références.

Le présent document définit des exigences d'antémémoire supplémentaires relatives au modèle de sécurité du transport.

 	3.1	Informations du modèle de sécurité du transport en antémémoire
Le modèle de sécurité du transport a des responsabilités spécifiques concernant les informations mises en antémémoire.

 	3.1.1	securityStateReference
Le modèle de sécurité du transport ajoute la tmStateReference reçue de l'ASI processIncomingMsg à la securityStateReference. Cette tmStateReference peut alors être restituée durant l'ASI generateResponseMsg afin qu'elle puisse être repassée au modèle de transport.

 	3.1.2	tmStateReference
Pour les messages sortants, le modèle de sécurité du transport utilise les paramètres fournis par l'application SNMP pour chercher ou créer une tmStateReference.

Pour le modèle de sécurité du transport, les paramètres de sécurité utilisés pour une réponse DOIVENT être les mêmes que ceux utilisés pour la demande correspondante. Ce modèle de sécurité utilise la tmStateReference mémorisée au titre de la securityStateReference quand c'est approprié. Pour les réponses et les rapports, ce modèle de sécurité règle le fanion tmSameSecurity à VRAI dans la tmStateReference avant de les passer à un modèle de transport.

Pour les messages entrants, le modèle de sécurité du transport utilise les paramètres fournis dans l'antémémoire tmStateReference pour établir un securityName, et pour vérifier les niveaux de sécurité adéquats.

 	3.1.3	Préfixes et securityNames
Le module de MIB SNMP-VIEW-BASED-ACM [RFC3415], le module de MIB SNMP-TARGET [RFC3413], et les autres modules de MIB contiennent des objets pour configurer les paramètres de sécurité à utiliser par les applications, comme contrôle d'accès, génération de notification, et transmission par mandataire.

Les domaines de transport et leurs préfixes correspondants sont coordonnés via le registre "Domaines de transport SNMP" de l'IANA.

Si snmpTsmConfigurationUsePrefix est réglé à VRAI, alors tous les securityNames fournis par le ou au modèle de sécurité du transport DOIVENT inclure un préfixe de domaine de transport valide.

Si snmpTsmConfigurationUsePrefix est réglé à FAUX, alors tous les securityNames fournis par le ou au modèle de sécurité du transport NE DOIVENT PAS inclure de préfixe de domaine de transport.

Le tmSecurityName dans la tmStateReference mémorisée au titre de la securityStateReference ne contient pas de préfixe.

 	4.	Traitement d'un message sortant

Une indication d'erreur pourrait retourner un identifiant d'objet (OID, Object Identifier) et une valeur pour un compteur incrémentaire, une valeur pour securityLevel, des valeurs pour contextEngineID et contextName pour le compteur, et la securityStateReference, si ces informations sont disponibles au moment où l'erreur est détectée.

 	4.1	Traitement de sécurité d'un message sortant
Ce paragraphe décrit la procédure suivie par le modèle de sécurité du transport.

Les paramètres nécessaires pour générer un message sont fournis au modèle de sécurité par le modèle de traitement de messages via l'ASI generateRequestMsg() ou generateResponseMsg(). L'extension architecturale du sous système de transport a ajouté les paramètres transportDomain, transportAddress, et tmStateReference aux ASI originales de la RFC  3411.

statusInformation =	-- succès ou errorIndication
      generateRequestMsg(
      IN   messageProcessingModel	-- normalement, version SNMP
      IN   globalData	-- en-tête de message, données administratives
      IN   maxMessageSize	-- de l'entité SNMP envoyeuse
      IN   transportDomain	-- (NOUVEAU) spécifié par l'application
      IN   transportAddress	-- (NOUVEAU) spécifié par l'application
      IN   securityModel	-- pour le message sortant
      IN   securityEngineID	-- entité SNMP d'autorité
      IN   securityName	-- au nom de ce principal
      IN   securityLevel	-- niveau de sécurité demandé
      IN   scopedPDU	-- charge utile du message (texte en clair)
      OUT  securityParameters	-- rempli par le module de sécurité
      OUT  wholeMsg	-- message généré complet
      OUT  wholeMsgLength	-- longueur du message généré
      OUT  tmStateReference	-- (NOUVEAU) informations de transport
      )

statusInformation =	-- succès ou errorIndication
      generateResponseMsg(
      IN   messageProcessingModel	-- normalement, version SNMP
      IN   globalData	-- en-tête de message, données administratives
      IN   maxMessageSize	-- de l'entité SNMP envoyeuse
      IN   transportDomain	-- (NOUVEAU) spécifié par l'application
      IN   transportAddress	-- (NOUVEAU) spécifié par l'application
      IN   securityModel	-- pour le message sortant
      IN   securityEngineID	-- entité SNMP d'autorité
      IN   securityName	-- au nom de ce principal
      IN   securityLevel	-- niveau de sécurité demandé
      IN   scopedPDU	-- charge utile du message (en clair)
      IN   securityStateReference	-- référence aux informations d'état d'état dans la demande originale
      OUT  securityParameters	-- rempli par le module de sécurité
      OUT  wholeMsg	-- message généré complet
      OUT  wholeMsgLength	-- longueur du message généré
      OUT  tmStateReference	-- (NOUVEAU) informations de transport
      )

 	4.2	Éléments de procédure pour les messages sortants
1.	Si il y a une securityStateReference (message de réponse ou de rapport) alors ce modèle de sécurité utilise les informations mises en antémémoire plutôt que celles fournies par l'ASI. Extraire la tmStateReference de l'antémémoire securityStateReference. Régler tmRequestedSecurityLevel à la valeur du paramètre extrait tmTransportSecurityLevel. Régler le paramètre tmSameSecurity dans l'antémémoire tmStateReference à VRAI. Les cachedSecurityData pour ce message peuvent maintenant être éliminées.

2.	Si il n'y a pas de securityStateReference (par exemple, un message Request-type ou Notification) créer alors une antémémoire tmStateReference. Régler tmTransportDomain à la valeur de transportDomain, tmTransportAddress à la valeur de transportAddress, et tmRequestedSecurityLevel à la valeur de securityLevel. (Les mises en œuvre pourraient optimiser en pointant sur les copies sauvegardées de ces valeurs spécifiques de session.) Régler le paramètre tmSameSecurity spécifique de la transaction à FAUX.

Si l'objet snmpTsmConfigurationUsePrefix est réglé à FAUX, régler alors tmSecurityName à la valeur de securityName.

Si l'objet snmpTsmConfigurationUsePrefix est réglé à VRAI, utiliser alors le transportDomain pour chercher le préfixe correspondant. (Comme la securityStateReference mémorise la tmStateReference avec le tmSecurityName pour le message entrant, et comme tmSecurityName n'a jamais de préfixe, l'étape de suppression de préfixe ne se produit que quand on n'utilise pas la securityStateReference).

Si la recherche de préfixe échoue pour une raison quelconque, le compteur snmpTsmUnknownPrefixes est alors incrémenté, une indication d'erreur est retournée au module appelant, et le traitement de message s'arrête.
Si la recherche réussit, mais qu'il n'y a pas de préfixe dans le securityName, ou que le préfixe retourné ne correspond pas à celui dans le securityName, ou si la longueur du préfixe est inférieure à 1 ou supérieure à 4 caractères alpha-numériques US-ASCII, le compteur snmpTsmInvalidPrefixes est alors incrémenté, une indication d'erreur est retournée au module appelant, et le traitement du message cesse.
On supprime le préfixe spécifique du transport et le caractère ':' (US-ASCII 0x3a) en queue du securityName. On règle tmSecurityName à la valeur de securityName.

3.	Régler les securityParameters à une CHAINE D'OCTETS de longueur zéro ("0400").

4.	Combiner les parties de message en un wholeMsg et calculer wholeMsgLength.

5.	Les wholeMsg, wholeMsgLength, securityParameters, et tmStateReference sont retournés au modèle de traitement de messages appelant avec statusInformation réglé à succès.

 	5.	Traitement d'un message SNMP entrant

Une indication d'erreur pourrait retourner un OID et une valeur pour un compteur à incrémenter, une valeur pour securityLevel, des valeurs pour contextEngineID et contextName pour le compteur, et la securityStateReference, si ces informations sont disponibles au moment où l'erreur est détectée.

 	5.1	Traitement de sécurité d'un message entrant
Ce paragraphe décrit la procédure suivie par le modèle de sécurité du transport chaque fois qu'il reçoit un message entrant d'un modèle de traitement de messages. L'ASI d'un modèle de traitement de messages au sous système de sécurité pour un message reçu est :

statusInformation =	-- errorIndication ou succès, OID/valeur de compteur d'erreurs si erreur
   processIncomingMsg(
   IN   messageProcessingModel	-- normalement, version SNMP
   IN   maxMessageSize	-- provenant du message reçu
   IN   securityParameters	-- provenant du message reçu
   IN   securityModel	-- provenant du message reçu
   IN   securityLevel	-- provenant du message reçu
   IN   wholeMsg	-- comme reçu sur le réseau
   IN   wholeMsgLength	-- longueur comme reçue sur le réseau
   IN   tmStateReference	-- (NOUVEAU) provenant du modèle de transport
   OUT  securityEngineID	-- entité SNMP d'autorité
   OUT  securityName	-- identification du principal
   OUT  scopedPDU,	-- charge utile du message (en clair)
   OUT  maxSizeResponseScopedPDU	-- taille maximum que l'envoyeur peut traiter
   OUT  securityStateReference	-- référence aux informations d'état de sécurité, nécessaire pour la réponse
    )

 	5.2	Éléments de procédure pour les messages entrants
1.	Régler le securityEngineID au snmpEngineID local.

2.	Si tmStateReference ne se réfère pas à une antémémoire contenant des valeurs pour tmTransportDomain, tmTransportAddress, tmSecurityName, et tmTransportSecurityLevel, alors le compteur snmpTsmInvalidCaches est incrémenté, une indication d'erreur est retournée au module appelant, et le traitement du modèle de sécurité cesse pour ce message.

3.	Copier le tmSecurityName en securityName.

Si l'objet snmpTsmConfigurationUsePrefix est réglé à VRAI, utiliser alors le tmTransportDomain pour chercher le préfixe correspondant.
Si la recherche de préfixe échoue pour une raison quelconque, le compteur snmpTsmUnknownPrefixes est alors incrémenté, une indication d'erreur est retournée au module appelant, et le traitement du message cesse.
Si la recherche réussit mais si la longueur du préfixe fait moins que 1 ou plus que 4 octets, le compteur snmpTsmInvalidPrefixes est alors incrémenté, une indication d'erreur est retournée au module appelant, et le traitement du message cesse.
Régler le securityName à être l'enchaînement du préfixe, d'un caractère ':' (US-ASCII 0x3a) et du tmSecurityName.

4.	Comparer la valeur de tmTransportSecurityLevel dans l'antémémoire tmStateReference à la valeur du paramètre securityLevel passée dans l'ASI processIncomingMsg. Si le securityLevel spécifie la confidentialité (Priv) et si tmTransportSecurityLevel spécifie "pas de confidentialité" (noPriv), ou si securityLevel spécifie l'authentification (auth) et si un tmTransportSecurityLevel qui spécifie pas d'authentification (noAuth) a été fourni par le modèle de transport, alors le compteur snmpTsmInadequateSecurityLevels est incrémenté, une indication d'erreur (unsupportedSecurityLevel) avec l'OID et la valeur du compteur incrémenté est retournée au module appelant, et le traitement du modèle de sécurité du transport cesse pour ce message.

5.	La tmStateReference est mise en antémémoire comme cachedSecurityData afin qu'une réponse possible à ce message utilise les mêmes paramètres de sécurité. Alors securityStateReference est réglé pour les références suivantes à ces données en antémémoire.

6.	Le composant scopedPDU est extrait du wholeMsg.

7.	La maxSizeResponseScopedPDU est calculée. C'est la taille maximum permise pour une scopedPDU pour un message de réponse possible.

8.	Les statusInformation sont réglées à succès et un retour est fait au module appelant en repassant les paramètres OUT comme spécifié dans l'ASI processIncomingMsg.

 	6.	Vue d'ensemble du module de MIB

Ce module de MIB fournit des objets à utiliser seulement par le modèle de sécurité du transport. Il définit une configuration scalaire et les compteurs d'erreur qui s'y rapportent.

 	6.1	Structure du module de MIB
Les objets dans ce module de MIB sont arrangés en sous arborescences. Chaque sous arborescence est organisée comme un ensemble d'objets en rapports. La structure globale et l'allocation des objets dans leurs sous arborescences, et l'objet prévu pour chaque sous arborescence, sont montrés ci-dessous.

 	6.1.1	Sous arborescence snmpTsmStats
Cette sous arborescence contient des compteurs d'erreur spécifiques du modèle de sécurité du transport.

 	6.1.2	Sous arborescence snmpTsmConfiguration
Cette sous arborescence contient un objet de configuration qui permet aux administrateurs de spécifier si ils veulent qu'un préfixe de domaine de transport soit ajouté devant les securityNames pour qu'il soit utilisé par les applications.

 	6.2	Relations aux autres modules de MIB
Certains objets de gestion définis dans d'autres modules de MIB sont applicables à une entité qui met en œuvre le modèle de sécurité du transport. En particulier, on suppose qu'une entité qui met en œuvre le modèle de sécurité du transport va mettre en œuvre la SNMP-FRAMEWORK-MIB [RFC3411], la SNMP-TARGET-MIB [RFC3413], la SNMP-VIEW-BASED-ACM-MIB [RFC3415], et la SNMPv2-MIB [RFC3418]. Elles ne sont pas nécessaires pour mettre en œuvre la SNMP-TSM-MIB.

 	6.2.1	Modules de MIB exigés pour IMPORTS
Le module de MIB suivant importe des éléments des [RFC2578], [RFC2579], et [RFC2580].

 	7.	Définition du module de MIB

DÉFINITIONS de SNMP-TSM-MIB ::= DÉBUT

IMPORTE
    MODULE-IDENTITY, TYPE D'OBJET, mib-2, Counter32
      DE SNMPv2-SMI -- RFC2578
    MODULE-COMPLIANCE, OBJECT-GROUP
      DE SNMPv2-CONF -- RFC2580
    TruthValue
      DE SNMPv2-TC -- RFC2579
    ;

snmpTsmMIB MODULE-IDENTITY
    LAST-UPDATED "200906090000Z"
    ORGANISATION "Groupe de travail ISMS"
    CONTACT-INFO "WG-EMail:   isms@lists.ietf.org
                  Abonnement : isms-request@lists.ietf.org

                  Présidents :
                    Juergen Quittek
                    NEC Europe Ltd.
                    Network Laboratories
                    Kurfuersten-Anlage 36
                    69115 Heidelberg
                    Germany
                    +49 6221 90511-15
                    quittek@netlab.nec.de

                    Juergen Schoenwaelder
                    Jacobs University Bremen
                    Campus Ring 1
                    28725 Bremen
                    Germany
                    +49 421 200-3587
                    j.schoenwaelder@jacobs-university.de

                  Éditeur :
                    David Harrington
                    Huawei Technologies USA
                    1700 Alma Dr.
                    Plano TX 75075
                    USA
                    +1 603-436-8634
                    ietfdbh@comcast.net

                    Wes Hardaker
                    Cobham Analytic Solutions
                    P.O. Box 382
                    Davis, CA  95617
                    USA
                    +1 530 792 1913
                    ietf@hardakers.net
                 "
DESCRIPTION
"MIB du modèle de sécurité du transport.
Conformément aux décisions de conception de la RFC 3411 d'utiliser des documents auto suffisants, la RFC qui contient les définitions de ce module de MIB inclut aussi les éléments de procédure qui sont nécessaires pour traiter le modèle de sécurité du transport pour SNMP. Ces objets de MIB NE DEVRAIENT PAS être modifiés via d'autres sous systèmes ou modèles définis dans d'autres documents. Cela permet que le modèle de sécurité du transport pour SNMP soit conçu et documenté comme indépendant et auto suffisant, n'ayant aucun impact direct sur les autres modules, et cela permet que ce module soit mis à niveau et complété lorsque le besoin s'en fait sentir, et d'avancer sur la voie de la normalisation selon un rythme différent des autres modules.

Copyright (c) 2009 IETF Trust et les personnes identifiées comme auteurs du code. Tous droits réservés.

La redistribution et l'utilisation en forme source et binaire, avec ou sans modification, sont permises pourvu que les conditions suivantes soient satisfaites :
o	Les redistributions de code source doivent conserver la notice de droits de reproduction ci-dessus, cette liste de conditions et le déclinatoire de responsabilité qui suit.
o	Les redistributions en forme binaire doivent reproduire la notice de droits de reproduction ci-dessus, cette liste de conditions et le déclinatoire de responsabilité qui suit dans la documentation et/ou autres matériaux fournis avec la distribution.
o	Ni le nom de la Internet Society, de l'IETF ou de l'IETF Trust, ni les noms des contributeurs spécifiques, ne peuvent être utilisés pour avaliser ou promouvoir des produits dérivés de ce logiciel sans permission écrite spécifique préalable.

Ce logiciel est fourni par les détenteurs du droit de reproduction et les contributeurs "TEL QUEL" et toutes garanties expresses ou implicites, incluant, sans s'y limiter, les garanties implicites de commercialisabilité et de convenance à un objet particulier sont déclinées. En aucun cas les détenteurs du droit de reproduction et les contributeurs ne seront responsables de dommages directs, indirects, incidents, spéciaux, exemplaires, ou consécutifs (incluant, sans s'y limiter, la fourniture de biens ou services de substitution, perte d'usage, données, ou profits, ou interruption d'affaires) cependant causés, et aucune théorie de responsabilité, contractuelle, stricte, ou pour tort (incluant la négligence ou autrement) survenant d'une façon quelconque de l'utilisation de ce logiciel, même si on est avisé de la possibilité de tels dommages.

Cette version de ce module de MIB fait partie de la RFC 5591 ; voir la RFC elle-même pour les notices légales complètes."

REVISION    "200906090000Z"
DESCRIPTION "Version initiale, publiée dans la RFC 5591."

::= { mib-2 190 }

-- ---------------------------------------------------------- --
-- sous arborescences dans la SNMP-TSM-MIB
-- ---------------------------------------------------------- --

IDENTIFIANT D'OBJET snmpTsmNotifications ::= { snmpTsmMIB 0 }
IDENTIFIANT D'OBJET snmpTsmMIBObjects  ::= { snmpTsmMIB 1 }
IDENTIFIANT D'OBJET snmpTsmConformance ::= { snmpTsmMIB 2 }

-- -------------------------------------------------------------
-- Objets
-- -------------------------------------------------------------

-- Statistiques pour le modèle de sécurité du transport

IDENTIFIANT D'OBJET snmpTsmStats  ::= { snmpTsmMIBObjects 1 }

TYPE D'OBJET snmpTsmInvalidCaches 
SYNTAXE : Counter32
MAX-ACCESS : lecture seule
STATUT : courant
DESCRIPTION "Nombre de messages entrants éliminés parce que la tmStateReference fait référence à une antémémoire invalide."
::= { snmpTsmStats 1 }

TYPE D'OBJET snmpTsmInadequateSecurityLevels 
SYNTAXE : Counter32
MAX-ACCESS : lecture seule
STATUT : courant
DESCRIPTION "Nombre de messages entrants éliminés parce que le securityLevel affirmé par le modèle de transport est inférieur au securityLevel demandé par l'application."
::= { snmpTsmStats 2 }

TYPE D'OBJET snmpTsmUnknownPrefixes 
SYNTAXE : Counter32
MAX-ACCESS : lecture seule
STATUT : courant
DESCRIPTION "Nombre de messages éliminés parce que snmpTsmConfigurationUsePrefix était réglé à VRAI et qu'il n'y a pas de préfixe connu pour le domaine de transport spécifié."
::= { snmpTsmStats 3 }

TYPE D'OBJET snmpTsmInvalidPrefixes 
SYNTAXE : Counter32
MAX-ACCESS : lecture seule
STATUT : courant
DESCRIPTION "Nombre de messages éliminés parce que le securityName associé à un message sortant ne contenait pas de préfixe de domaine de transport valide."
::= { snmpTsmStats 4 }

-- -------------------------------------------------------------
-- Configuration
-- -------------------------------------------------------------

-- Configuration pour le modèle de sécurité du transport

IDENTIFIANT D'OBJET snmpTsmConfiguration ::= { snmpTsmMIBObjects 2 }

TYPE D'OBJET snmpTsmConfigurationUsePrefix 
SYNTAXE : TruthValue
MAX-ACCESS : lecture-écriture
STATUT: courant
DESCRIPTION : "Si cet objet est réglé à VRAI, alors les securityNames passant de et vers l'application sont supposés contenir un préfixe spécifique du domaine de transport. Si cet objet est réglé à VRAI, alors un préfixe spécifique du domaine va être ajouté par le TSM au securityName pour les messages entrants et supprimé du securityName lors du traitement des messages sortants. Les domaines de transport et les préfixes sont conservés dans un registre de l'IANA. Cet objet DEVRAIT persister à travers les réamorçages du système."
DEFVAL { false }
::= { snmpTsmConfiguration 1 }

-- -------------------------------------------------------------
-- snmpTsmMIB - Informations de conformité
-- -------------------------------------------------------------

IDENTIFIANT D'OBJET snmpTsmCompliances ::= { snmpTsmConformance 1 }

IDENTIFIANT D'OBJET snmpTsmGroups ::= { snmpTsmConformance 2 }

-- -------------------------------------------------------------
-- Déclarations de conformité
-- -------------------------------------------------------------

snmpTsmCompliance MODULE-COMPLIANCE
STATUT : courant
DESCRIPTION "Déclarations de conformité pour les moteurs SNMP qui prennent en charge la SNMP-TSM-MIB."
MODULE GROUPES OBLIGATOIRES { snmpTsmGroup }
::= { snmpTsmCompliances 1 }

-- -------------------------------------------------------------
-- Unités de conformité
-- -------------------------------------------------------------
GROUPE D'OBJETS snmpTsmGroup
OBJETS {
        snmpTsmInvalidCaches,
        snmpTsmInadequateSecurityLevels,
        snmpTsmUnknownPrefixes,
        snmpTsmInvalidPrefixes,
        snmpTsmConfigurationUsePrefix
    }
STATUT : courant
DESCRIPTION : "Collection d'objets pour maintenir les informations d'un moteur SNMP qui met en œuvre le modèle de sécurité du transport SNMP."
 ::= { snmpTsmGroups 2 }

FIN

 	8.	Considérations sur la sécurité

Le présent document décrit un modèle de sécurité, compatible avec l'architecture de la RFC3411, qui permet à SNMP d'utiliser les services de sécurité fournis à travers un modèle de transport SNMP. Le modèle de sécurité du transport s'appuie sur les modèles de transport pour l'authentification mutuelle, le lien des clés, la confidentialité, et l'intégrité.

Le modèle de sécurité du transport s'appuie sur des modèles de transport sûr pour fournir un identifiant de principal  authentifié et une assertion de si l'authentification et la confidentialité sont utilisées durant le transport. Ce modèle de sécurité DEVRAIT toujours être utilisé avec les modèles de transport qui fournissent une sécurité adéquate, mais "sécurité adéquate" est une décision de configuration et/ou au moment du début du fonctionnement de l'opérateur ou de l'application de gestion. Les menaces pour la sécurité et comment ces menaces sont atténuées devraient être couvertes en détail dans les spécifications des modèles de transport et des transports sûrs sous-jacents.

Un identifiant de principal authentifié (securityName) est utilisé dans les applications SNMP pour des besoins comme le contrôle d'accès, la génération de notification, et la transmission par mandataire. Ce modèle de sécurité prend en charge plusieurs modèles de transport. Les opérateurs pourraient juger que certains transports sont plus sûrs que d'autres, de sorte que ce modèle de sécurité peut être configuré à faire précéder le securityName d'un préfixe pour indiquer le modèle de transport utilisé pour authentifier le principal. Les opérateurs peuvent utiliser le securityName avec préfixe quand ils prennent des décisions d'application sur les niveaux d'accès.

 	8.1	Sécurité du module de MIB
Un certain nombre d'objets de gestion sont définis dans ce module de MIB avec une clause MAX-ACCESS de lecture-écriture et/ou lecture-création. De tels objets peuvent être considérés comme sensibles ou vulnérables dans certains environnements de réseau. La prise en charge des opérations SET dans un environnement non sûr sans une protection appropriée peut avoir un effet négatif sur le fonctionnement du réseau. Voici les tableaux et les objets et leur sensibilité/vulnérabilité :

o	L'objet snmpTsmConfigurationUsePrefix pourrait être modifié, créant un déni de service ou autorisant des messages SNMP qui n'auraient pas été précédemment autorisés par un modèle de contrôle d'accès (par exemple, le modèle de contrôle d'accès fondé sur la vue (VACM)).

Certains des objets lisibles dans ce module de MIB (c'est-à-dire, les objets avec un MAX-ACCESS autre que non accessible) peuvent être considérés comme sensibles ou vulnérables dans certains environnements de réseau. Il est donc important de contrôler même les accès GET et/ou NOTIFY à ces objets et éventuellement même de chiffrer les valeurs de ces objets quand on les envoie sur le réseau via SNMP. Voici les tableaux et les objets et leur sensibilité/vulnérabilité :

o	Tous les compteurs dans ce module se réfèrent à des erreurs de configuration et n'exposent pas d'informations sensibles.

Les versions SNMP antérieures à SNMPv3 n'incluaient pas de sécurité adéquate. Même si le réseau lui-même est sûr (par exemple en utilisant IPsec) il n'y a pas de contrôle sur qui dans le réseau sûr est autorisé à accéder et faire des GET/SET (lire/changer/créer/supprimer) sur les objets dans ce module de MIB.

Il est RECOMMANDÉ que les mises en œuvre considèrent les caractéristiques de sécurité telles que fournies par le cadre SNMPv3 (voir la [RFC3410], section 8) incluant la pleine prise en charge des mécanismes cryptographiques de USM et du modèle de sécurité du transport (pour l'authentification et la confidentialité).

De plus, le déploiement de versions SNMP antérieures à SNMPv3 est NON RECOMMANDÉ. À la place, il est RECOMMANDÉ de déployer SNMPv3 et d'activer la sécurité cryptographique. Il est alors de la responsabilité du consommateur/opérateur de s'assurer que l'entité SNMP qui donne accès à une instance de ce module de MIB est configurée de façon appropriée pour donner accès aux objets aux seuls principaux (utilisateurs) qui ont des droits légitimes à effectuer des GET ou SET (changement/création/suppression) sur eux.

 	9.	Considérations relatives à l'IANA

L'IANA a alloué :

1.	Un numéro de SMI (190) avec un préfixe de mib-2 dans le registre de module de MIB pour le module de MIB du présent document.

2.	Une valeur (4) pour identifier le modèle de sécurité du transport, dans le registre des modèles de sécurité du registre des espaces de numéros SNMP. Il en résulte le tableau de valeurs suivant :

Valeur	Description	Références
     0	réservé pour "any"	[RFC3411]
     1	réservé pour SNMPv1	[RFC3411]
     2	réservé pour SNMPv2c	[RFC3411]
     3	modèle de sécurité fondé sur l'utilisateur (USM)	[RFC3411]
     4	modèle de sécurité du transport (TSM)	[RFC5591]

 	10.	Remerciements

Les éditeurs tiennent à remercier Jeffrey Hutzelman d'avoir partagé ses vues sur SSH et Dave Shield pour son travail en cours sur la terminologie du document existant pour en améliorer l'organisation et la clarté.

De plus, une utile relecture du document a été effectuée par Juergen Schoenwaelder.

 	11.	Références
 	11.1	Références normatives

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997. DOI 10.17487/RFC2119, (MàJ par RFC8174)

[RFC2578]	K. McCloghrie, D. Perkins, J. Schoenwaelder, "Structure des informations de gestion, version 2 (SMIv2)", avril 1999. (STD0058)

[RFC2579]	K. McCloghrie, D. Perkins, J. Schoenwaelder, "Conventions textuelles pour SMIv2", avril 1999. (STD0058)

[RFC2580]	K. McCloghrie, D. Perkins, J. Schoenwaelder, "Déclarations de conformité pour SMIv2", avril 1999. (STD0058)

[RFC3411]	D. Harrington, R. Presuhn, B. Wijnen, "Architecture de description des cadres de gestion du protocole simple de gestion de réseau (SNMP)", décembre 2002. (MàJ par RFC5343) (STD0062)

[RFC3412]	J. Case et autres, "Traitement et distribution de message pour le protocole simple de gestion de réseau (SNMP)", décembre 2002. (STD0062)

[RFC3413]	D. Levi, P. Meyer et B. Stewart, "Applications du protocole simple de gestion de réseau (SNMP)", STD 62, décembre  2002.

[RFC3414]	U. Blumenthal, B. Wijnen, "Modèle de sécurité fondée sur l'utilisateur (USM) pour la version 3 du protocole simple de gestion de réseau (SNMPv3)", décembre 2002. (STD0062)

[RFC3417]	R. Presuhn, éd. "Transpositions de transport pour le protocole simple de gestion de réseau (SNMP)", décembre 2002. (MàJ par RFC4789) (STD0062)

[RFC5590]	D. Harrington, J. Schoenwaelder, "Sous-système de transport pour le protocole simple de gestion de réseau (SNMP)", juin  2009. (MàJ RFC3411, RFC3412, RFC3414, RFC3417) (P. S.)

 	11.2	Références pour information

[RFC3410]	J. Case et autres, "Introduction et déclarations d'applicabilité pour le cadre de gestion standard de l'Internet", décembre  2002. (Information)

[RFC3415]	B. Wijnen, R. Presuhn, K. McCloghrie, "Modèle de contrôle d'accès fondé sur la vue (VACM) pour le protocole simple de gestion de réseau (SNMP)", décembre 2002. (STD0062)

[RFC3418]	R. Presuhn, éd., "Base de données d'informations de gestion (MIB) pour le protocole simple de gestion de réseau (SNMP)", décembre 2002. (STD0062)

[RFC3584]	R. Frye et autres, "Coexistence entre version 1, version 2, et version 3 du cadre de gestion de réseau standard de l'Internet", août 2003. (BCP0074)

[RFC5592]	D. Harrington, J. Salowey, W. Hardaker, "Modèle de transport à enveloppe sécurisée pour le protocole simple de gestion de réseau (SNMP)", juin 2009. (P. S.)

 	Appendice A.	Configuration des tableaux de notification

La SNMP-TARGET-MIB et la SNMP-NOTIFICATION-MIB [RFC3413] sont utilisées pour configurer les générateurs de notification avec les destinations auxquelles les notifications devraient être envoyées.

La plus grande partie de la configuration est indépendante du modèle de sécurité et du modèle de transport.

Les valeurs qu'on utilise dans les exemples pour les cinq paramètres de sécurité et de transport indépendants du modèle sont :
transportDomain = snmpSSHDomain
transportAddress = 192.0.2.1:5162
securityModel = modèle de sécurité du transport
securityName = alice
securityLevel = authPriv

L'exemple suivant va configurer l'origine de notification à envoyer des informations à un receveur de notification à 192.0.2.1:5162 en utilisant le securityName "alice". "alice" est le nom pour le receveur du point de vue de l'origine de notification et est utilisé pour traiter les contrôles d'accès avant d'envoyer une notification.

La colonne marquée d'une "*" contient les éléments qui sont spécifiques du modèle de sécurité ou du modèle de transport.

La configuration pour les réglages de "alice" dans les objets de la SNMP-VIEW-BASED-ACM-MIB ne sont pas montrés ici pour faire court. D'abord, on configure quel type de notification va être envoyé pour cette liste d'étiquettes (toCRTag). Dans cet exemple, on choisit d'envoyer un Inform.

rangée snmpNotifyTable :
          snmpNotifyName                 CRNotif
          snmpNotifyTag                     toCRTag
          snmpNotifyType                   inform
          snmpNotifyStorageType       nonVolatile
          snmpNotifyColumnStatus     createAndGo

Ensuite on configure une adresse de transport à laquelle les notifications associées à cette liste d'étiquettes vont être envoyées, et on spécifie quelle snmpTargetParamsEntry va être utilisée (toCR) lors de l'envoi à cette adresse de transport.

rangée snmpTargetAddrTable :
             snmpTargetAddrName                 toCRAddr
         *  snmpTargetAddrTDomain           snmpSSHDomain
         *  snmpTargetAddrTAddress           192.0.2.1:5162
             snmpTargetAddrTimeout             1500
             snmpTargetAddrRetryCount        3
             snmpTargetAddrTagList              toCRTag
             snmpTargetAddrParams               toCR (DOIT correspondre ci-dessous)
             snmpTargetAddrStorageType      nonVolatile
             snmpTargetAddrColumnStatus    createAndGo

Ensuite on configure quel principal chez l'hôte va recevoir les notifications associées à cette liste d'étiquettes. Ici, on choisit "alice", qui utilise le modèle de sécurité du transport.

rangée snmpTargetParamsTable :
             snmpTargetParamsName                  toCR
             snmpTargetParamsMPModel           SNMPv3
         *  snmpTargetParamsSecurityModel   TransportSecurityModel
             snmpTargetParamsSecurityName    "alice"
             snmpTargetParamsSecurityLevel     authPriv
             snmpTargetParamsStorageType       nonVolatile
             snmpTargetParamsRowStatus          createAndGo

 	A.1	Traitement du modèle de sécurité du transport pour les notifications
Le modèle de sécurité du transport est invoqué en utilisant l'ASI generateRequestMsg(), avec les paramètres suivants (ceux avec une * sont des tableaux ci-dessus) :

statusInformation =	-- succès ou errorIndication
    generateRequestMsg(
    IN   messageProcessingModel	-- *snmpTargetParamsMPModel
    IN   globalData	-- en-tête de message, données administratives
    IN   maxMessageSize	-- de l'entité SNMP envoyeuse
    IN   transportDomain	-- *snmpTargetAddrTDomain
    IN   transportAddress	-- *snmpTargetAddrTAddress
    IN   securityModel	-- *snmpTargetParamsSecurityModel
    IN   securityEngineID	-- immatériel ; TSM va l'ignorer.
    IN   securityName	-- snmpTargetParamsSecurityName
    IN   securityLevel	-- *snmpTargetParamsSecurityLevel
    IN   scopedPDU	-- charge utile du message (en clair)
    OUT  securityParameters	-- rempli par le module de sécurité
    OUT  wholeMsg	-- message généré complet
    OUT  wholeMsgLength	-- longueur du message généré
    OUT  tmStateReference	-- référence aux informations de transport
    )

Le modèle de sécurité du transport va déterminer le modèle de transport sur la base du snmpTargetAddrTDomain. Le modèle de transport choisi va choisir la connexion de transport appropriée en utilisant l'antémémoire tmStateReference créée à partir des valeurs de snmpTargetAddrTAddress, snmpTargetParamsSecurityName, et snmpTargetParamsSecurityLevel.

 	Appendice B.	Différences de traitement entre USM et transport sûr

USM et les transports sûrs diffèrent dans l'ordre de traitement et les responsabilités au sein de l'architecture de la RFC3411.  Bien que les étapes soient les mêmes, elles surviennent dans un ordre différent et pourraient être faites par des sous systèmes différents. Les listes suivantes illustrent la différence dans le flux et la responsabilité pour les différentes étapes de traitement des messages entrants quand on utilise USM et quand on utilise un transport sûr. (Ces listes sont simplifiées à des fins d'illustration, et ne représentent pas tous les détails du traitement. Les modèles de transport DOIVENT fournir le détail des éléments de procédure.)

Avec les modèles de sécurité USM, SNMPv1, et SNMPv2c, le traitement de sécurité commence quand le modèle de traitement de messages décode des portions du message ASN.1 pour extraire les champs d'en-tête qui sont utilisés pour déterminer quel modèle de sécurité va traiter le message pour effectuer l'authentification, le déchiffrement, les vérifications d'opportunité, les vérifications d'intégrité, et la traduction des paramètres en paramètres indépendants du modèle. En comparaison, un transport sûr effectue ces fonctions de sécurité sur le message, avant le décodage de l'ASN.1.

L'étape 6 ne peut survenir qu'après le déchiffrement. Les étapes 6 et au-delà sont les mêmes pour USM et un transport sûr.

 	B.1	USM et l'architecture de la RFC 3411
1)	Décode l'en-tête ASN.1 (modèle de traitement de messages).
2)	Détermine le modèle de sécurité et paramètres SNMP (modèle de traitement de messages).
3)	Vérifie le securityLevel (modèle de sécurité).
4)	Traduit les paramètres en paramètres indépendants du modèle (modèle de sécurité).
5)	Authentifie le principal, vérifie l'intégrité et l'opportunité du message, et décrypte le message (modèle de sécurité).
6)	Détermine le pduType dans les portions décryptées (modèle de traitement de messages).
7)	Passe les portions décryptées avec les paramètres indépendants du modèle.

 	B.2	Sous système de transport et l'architecture de la RFC 3411
1)	Authentifie le principal, vérifie l'intégrité et l'opportunité du message, et décrypte le message (modèle de transport).
2)	Traduit les paramètres en paramètres indépendants du modèle (modèle de transport).
3)	Décode l'en-tête ASN.1 (modèle de traitement de messages).
4)	Détermine le modèle de sécurité et paramètres SNMP (modèle de traitement de messages).
5)	Vérifie le securityLevel (modèle de sécurité).
6)	Détermine le pduType dans les portions décryptées (modèle de traitement de messages).
7)	Passe les portions décryptées avec les paramètres indépendants du modèle.
Si un message est sécurisé en utilisant une couche de transport sûr, alors le modèle de transport va fournir la traduction de l'identité authentifiée (par exemple, un nom d'utilisateur SSH) en un identifiant lisible par l'homme (tmSecurityName) dans l'étape 2. Le modèle de sécurité va fournir une transposition de cet identifiant en un securityName indépendant du modèle.

 	Adresse des auteurs
David Harrington	Wes Hardaker	
Huawei Technologies (USA)	Cobham Analytic Solutions	
1700 Alma Dr. Suite 100	P.O. Box 382	
Plano, TX 75075	Davis, CA  95617	
USA	USA	
téléphone : +1 603 436 8634	téléphone : +1 530 792 1913	
mél : ietfdbh@comcast.net	mél : ietf@hardakers.net