Groupe de travail Réseau	D. Harrington, Huawei Technologies (USA)	
Request for Comments: 5590	J. Schoenwaelder, Jacobs University Bremen	
RFC mises à jour : 3411, 3412, 3414, 3417	juin 2009	
Catégorie : Sur la voie de la normalisation 	Traduction Claude Brière de L'Isle	

Sous système de 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 document définit un sous système de transport qui étend l'architecture du protocole simple de gestion de réseau (SNMP, Simple Network Management Protocol) définie dans la RFC 3411. Le présent document définit un sous système pour contenir des modèles de transport, comparable aux autres sous systèmes de l'architecture de la RFC 3411. Comme des travaux sont en cours pour étendre les transports à inclure des transports sécurisés, comme le protocole Secure Shell (SSH) et la sécurité de la couche transport (TLS, Transport Layer Security) utiliser un sous système va permettre une conception cohérente et modulaire de tels modèles de transport. Le présent document identifie et décrit des aspects clés qui doivent être pris en compte par tout modèle de 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 Conditions d'utilisation de cette extension	2
2. Motifs	3
3. Exigences d'un modèle de transport	4
3.1 Exigences de sécurité du message	4
3.2 Exigences de SNMP	5
3.3 Exigences de session	8
4. Diagrammes de scénario et sous système de transport	10
5. Informations et références en antémémoire	10
5.1 securityStateReference	10
5.2 tmStateReference	10
6. Interfaces abstraites de service 	12
6.1 ASI sendMessage	12
6.2 Changements aux ASI sortantes de la RFC 3411	13
6.3 ASI receiveMessage	15
6.4 Changements aux ASI entrantes de la RFC 3411	15
7. Considérations sur la sécurité	16
7.1 Coexistence, paramètres de sécurité, et contrôle d'accès	17
8. Considérations relatives à l'IANA	17
9. Remerciements	18
10. Références	18
10.1 Références normatives	18
10.2 Références pour information	18
Appendice A. Pourquoi tmStateReference ?	19
A.1 Définir une interface abstraite de service 	19
A.2 Utilisation d'un en-tête d'encapsulation	19
A.3 Modification des champs existants dans un message SNMP	19
A.4 Utilisation d'une antémémoire	20
Adresse des auteurs	20

 	1.	Introduction

Le présent document définit un sous système de transport, qui étend l'architecture du protocole simple de gestion de réseau (SNMP, Simple Network Management Protocol) définie dans la [RFC3411]. Le présent document identifie et décrit des aspects clés qui doivent être considérés pour tout modèle de transport pour SNMP.

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

 	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 qui se rapporte à la compatibilité avec l'architecture de la RFC 3411 ou au sous système défini ici mais qui pourrait n'avoir pas d'impact sur la compatibilité sur le réseau. Ces termes sont utilisés comme guide pour les concepteurs de modèles proposés à l'IETF pour rendre les conceptions compatibles avec les sous systèmes de la RFC 3411 et les interfaces de service abstraites (ASI, Abstract Service Interface). Les mises en œuvre sont libres d'agir différemment. Certains usages de ces termes en minuscules sont simplement l'usage normal en français.

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

Le présent document discute une extension à l'architecture modulaire de la RFC 3411 ; ceci n'est pas un document de protocole. Un "DOIT" architectural est une contrainte réellement stricte ; pour permettre l'évolution de la technologie et ne pas contraindre sans nécessité les futurs modèles, un "DEVRAIT" ou "devrait" est souvent plus approprié qu'un "DOIT" dans une architecture. De futurs modèles PEUVENT exprimer des exigences plus strictes pour leur propre traitement spécifique de modèle.

 	1.3	Conditions d'utilisation de cette extension
On suppose que les lecteurs du présent document auront lu les RFC 3410 et 3411, et ont une compréhension générale des fonctions définies dans les RFC 3412-3418.

Le "sous système de transport" est un composant supplémentaire pour le moteur SNMP décrit au paragraphe 3.1 de la RFC  3411.

Le diagramme suivant décrit sa place dans l'architecture de la RFC 3411.

   +-------------------------------------------------------------------+
   |  Entité SNMP                                                      |
   |                                                                   |
   |  +-------------------------------------------------------------+  |
   |  |  Moteur SNMP (identifié par snmpEngineID)                   |  |
   |  |                                                             |  |
   |  |  +------------+                                             |  |
   |  |  |Sous système|                                             |  |
   |  |  | Transport  |                                             |  |
   |  |  +------------+                                             |  |
   |  |                                                             |  |
   |  |  +------------+ +------------+ +-----------+ +-----------+  |  |
   |  |  | Répartiteur| |Sous système| |Ss système | |Ss système |  |  |
   |  |  |            | | traitement | |   de      | | contrôle  |  |  |
   |  |  |            | | de message | | sécurité  | | d'accès   |  |  |
   |  |  +------------+ +------------+ +-----------+ +-----------+  |  |
   |  +-------------------------------------------------------------+  |
   |                                                                   |
   |  +-------------------------------------------------------------+  |
   |  |  Application(s)                                             |  |
   |  |                                                             |  |
   |  |  +-------------+  +--------------+  +--------------+        |  |
   |  |  | Générateur  |  | Receveur de  |  | Transmetteur |        |  |
   |  |  | de commande |  | notification |  | mandataire   |        |  |
   |  |  +-------------+  +--------------+  +--------------+        |  |
   |  |                                                             |  |
   |  |  +-------------+  +--------------+  +--------------+        |  |
   |  |  | Répondeur   |  | Générateur de|  | Autre        |        |  |
   |  |  | de commande |  | notification |  |              |        |  |
   |  |  +-------------+  +--------------+  +--------------+        |  |
   |  +-------------------------------------------------------------+  |
   |                                                                   |
   +-------------------------------------------------------------------+

Les transpositions de transport définies dans la RFC 3417 ne fournissent pas de fonction de sécurité de couche inférieure, et ne fournissent donc pas de paramètre de sécurité spécifique du transport. Le présent document met à jour les RFC 3411 et RFC 3417 en définissant une extension architecturale et en modifiant les ASI que les transpositions de transport (qu'on appelle ici des "modèles de transport") peuvent utiliser pour passer des paramètres de sécurité spécifiques du transport aux autres sous systèmes, incluant des paramètres de sécurité spécifiques du transport qui sont traduits en les paramètres indépendants du transport "securityName" et "securityLevel".

Le modèle de sécurité du transport [RFC5591] et le modèle de transport Secure Shell [RFC5592] utilisent le sous système de transport. Le modèle de sécurité du transport est une solution de remplacement du modèle existant de sécurité de SNMPv1 [RFC3584], de SNMPv2c [RFC3584], et du modèle de sécurité fondé sur l'utilisateur de la [RFC3414]. Le modèle de transport Secure Shell est une solution de remplacement aux transpositions de transport existantes comme décrit dans la [RFC3417].

 	2.	Motifs

Tout comme il y a plusieurs façons de sécuriser sa maison ou son entreprise, dans un continuum de solutions de remplacement, il y a plusieurs façons de sécuriser un protocole de gestion de réseau. On examinera trois approches générales.

Dans la première approche, un individu pourrait se tenir sous sa porte d'entrée pour attendre les intrus. Dans la seconde approche, il pourrait engager un employé, programmer l'employé, positionner l'employé pour garder ce qu'il veut protéger, engager un second garde pour couvrir le cas où le premier serait malade, et ainsi de suite. Dans la troisième approche, il pourrait engager une entreprise de sécurité, lui dire ce qu'il veut protéger, et lui laisser régler les détails. Les considérations d'embauche et de formation des employés, de positionnement et de programmation des gardes, des dispositions de couverture, etc., sont de la responsabilité de l'entreprise de sécurité. L'individu réalise donc la sécurité désirée, avec significativement moins d'efforts de sa part sauf pour identifier les exigences et vérifier la qualité du service fourni.

Le modèle de sécurité fondé sur l'utilisateur (USM, User-based SecurityModel) défini dans la [RFC3414] utilise largement la première approche -- il fournit sa propre sécurité. Il utilise les mécanismes existants (par exemple, SHA) mais assure toute la coordination. USM assure l'authentification d'un principal, le chiffrement de message, la vérification de l'intégrité des données, que les vérifications sont faites en temps utile, etc.

USM a été conçu pour être indépendant des autres infrastructures de sécurité existantes. USM utilise donc une infrastructure séparée de gestion de principal et de clé. Les opérateurs ont rapporté que déployer une autre infrastructure de gestion de principal et de clé pour utiliser SNMPv3 serait dissuasif pour son déploiement. Il est possible d'utiliser des mécanismes externes pour traiter la distribution des clés pour l'usage de USM. La question la plus importante est que les opérateurs voulaient développer les infrastructures existantes de gestion d'utilisateur qui n'étaient pas spécifiques de SNMP.

Une architecture conforme à USM pourrait combiner le mécanisme d'authentification avec un mécanisme externe, comme RADIUS [RFC2865], pour fournir le service d'authentification. De même, il serait possible d'utiliser un protocole externe pour chiffrer un message, pour s'assurer que les vérifications sont faites en temps utile, pour vérifier l'intégrité des données, etc. Cependant, cela correspond à la seconde approche -- qui exige la coordination d'un certain nombre de services avec des   sous contrats différents. Construire une sécurité solide entre les divers services est difficile, et il y a un potentiel significatif de trous dans la sécurité.

Une autre approche pourrait être d'utiliser un ou plusieurs mécanismes de sécurité de couche inférieure pour fournir les services de sécurité en mode message requis. Cela inclurait l'authentification de l'envoyeur, le chiffrement, la vérification que les choses sont faites en temps utile, et la vérification de l'intégrité des données. Cela correspond à la troisième approche décrite ci-dessus. Un certain nombre de normes de l'IETF sont disponibles ou en cours de développement pour traiter ces problèmes à travers des couches de sécurité à la couche transport ou application, parmi lesquelles TLS [RFC5246], SASL [RFC4422], et SSH [RFC4251]

Du point de vue du fonctionnement, il est très souhaitable d'utiliser des mécanismes de sécurité qui peuvent unifier la gestion de sécurité administrative pour SNMPv3, les interfaces de ligne de commande (CLI, Command Line Interface) et les autres interfaces de gestion. L'utilisation de services de sécurité fournis par les couches inférieures est l'approche couramment utilisée pour la CLI, et est aussi l'approche proposée pour les autres protocoles de gestion de réseau, comme syslog [RFC5424] et NETCONF [RFC4741].

Le présent document définit une extension de sous système de transport à l'architecture de la RFC 3411 qui se fonde sur la troisième approche. Cette extension spécifie comment les autres protocoles de couche inférieure avec des infrastructures de  sécurité communes peuvent être utilisés en dessous du protocole SNMP et comment le but désiré d'une sécurité administrative unifiée peut être satisfait.

Cette extension permet que la sécurité soit fournie par un protocole externe connecté au moteur SNMP à travers un modèle de transport SNMP [RFC3417]. Un tel modèle de transport permettrait alors d'utiliser les mécanismes de sécurité existants, comme TLS [RFC5246] ou SSH [RFC4251], au sein de l'architecture de la RFC 3411.

Un certain nombre de protocoles et mécanismes de sécurité de l'Internet sont largement utilisés. Beaucoup d'entre eux essayent de fournir une infrastructure générique à utiliser par de nombreux protocoles de couche application différents. La motivation derrière le sous système de transport est de relayer ces protocoles lorsque cela paraît utile.

Un certain nombre de défis sont à relever pour transposer la sécurité fournie par un transport sûr dans l'architecture SNMP afin que SNMP continue d'assurer l'interopérabilité avec les mises en œuvre existantes. Ces défis sont décrits dans le détail par le présent document. Pour certaines questions clés, sont décrits les choix de conception qui pourraient être faits pour fournir une véritable solution satisfaisant les exigences opérationnelles et qui tienne dans l'architecture SNMP définie dans la [RFC3411].

 	3.	Exigences d'un modèle de transport
 	3.1	Exigences de sécurité du message
Les protocoles de sécurité du transport DEVRAIENT fournir une protection contre les menaces suivantes au niveau du message :
1.	modification des informations
2.	usurpation d'identité
3.	modification du flux de messages
4.	divulgation

Ces menaces sont décrites au paragraphe 1.4 de la [RFC3411]. Les exigences de sécurité mentionnées ici n'exigent pas de protection contre le déni de service ou l'analyse de trafic ; cependant, les protocoles de sécurité du transport ne devraient pas rendre ces menaces significativement pires.

 	3.1.1	Exigences de sécurité du protocole
Un certain nombre de protocoles standard pourraient être proposés comme solutions possibles au sein du sous système de transport. Certains facteurs devraient être considérés pour le choix d'un protocole.

Utiliser un protocole d'une manière pour laquelle il n'a pas été conçu pose de nombreux problèmes. Les caractéristiques dc sécurité d'un protocole pourraient dépendre de ce qu'il soit utilisé comme il a été conçu ; quand il est utilisé d'une autre manière, il pourrait ne pas donner les caractéristiques de sécurité attendues. Il est recommandé que tout modèle proposé inclue une description de l'applicabilité du modèle de transport.

Un modèle de transport NE DEVRAIT PAS exiger de modification au protocole sous-jacent. Modifier le protocole pourrait changer ses caractéristiques de sécurité de façons qui pourraient impacter d'autres usages existants. Si un changement est nécessaire, il DEVRAIT être une extension qui n'a pas d'impact sur les usages existants. Toute spécification de modèle de transport devrait inclure une description de l'impact potentiel sur les autres usages du protocole.

Comme plusieurs modèles de transport peuvent exister simultanément au sein du sous système de transport, les modèles de transport DOIVENT être capables de coexister avec chaque autre.

 	3.2	Exigences de SNMP
 	3.2.1	Exigences de modularité architecturale
SNMP version 3 (SNMPv3) est fondé sur une architecture modulaire (définie à la Section 3 de la [RFC3411]) pour permettre l'évolution des normes du protocole SNMP au fil du temps et minimise les effets collatéraux entre sous systèmes quand des changements sont faits.

L'architecture de la RFC 3411 inclut un sous système de traitement de message pour permettre que différentes versions de message soient traitées par un seul moteur, un sous système de sécurité pour permettre différentes méthodes de fourniture des services de sécurité, des applications pour prendre en charge différents types de processeurs d'application, et un sous système de contrôle d'accès pour permettre plusieurs approches du contrôle d'accès. L'architecture de la RFC 3411 ne comporte pas de sous système pour les modèles de transport, en dépit du fait qu'il y a plusieurs transpositions de transport déjà définies pour SNMP [RFC3417]. Le présent document décrit un sous système de transport qui est compatible avec l'architecture de la RFC 3411. Comme des travaux sont en cours pour utiliser des transports sécurisés comme SSH et TLS, utiliser un sous système va permettre une conception et une modularité cohérentes de ces modèles de transport.

La conception de ce sous système de transport accepte les buts de l'architecture de la RFC 3411 qui sont définis au paragraphe 1.5 de la [RFC3411]. Ce sous système de transport utilise une conception modulaire qui permet que les modèles de transport (qui pourraient ou non être à capacité de sécurité) d'être "en prise avec" l'architecture de la RFC 3411. Ces modèles de transport seraient indépendants des autres composants modulaires de SNMP autant que possible. Cette conception permet aussi que les modèles de transport soient avancés indépendamment dans le processus de normalisation des autres modèles de transport.

Le diagramme suivant décrit l'architecture de SNMPv3, incluant le nouveau sous système de transport défini dans le présent document et un nouveau modèle de sécurité du transport défini dans la [RFC5591].

   +------------------------------+
   |    Réseau                    |
   +------------------------------+
      ^       ^              ^
      |       |              |
      v       v              v
   +-------------------------------------------------------------------+
   | +--------------------------------------------------+              |
   | |  Sous système de transport                       |              |
   | | +-----+ +-----+ +-----+ +-----+       +-------+  |              |
   | | | UDP | | TCP | | SSH | | TLS | . . . | autres|  |              |
   | | +-----+ +-----+ +-----+ +-----+       +-------+  |              |
   | +--------------------------------------------------+              |
   |              ^                                                    |
   |              |                                                    |
   | Répartiteur  v                                                    |
   | +-------------------+ +---------------------+  +----------------+ |
   | | Répartition du    | | Sous système de     |  | Sous système de| |
   | | transport         | |traitement de message|  | sécurité       | |
   | |                   | |     +------------+  |  | +------------+ | |
   | |                   | |  +->| v1MP       |<--->| | USM        | | |
   | |                   | |  |  +------------+  |  | +------------+ | |
   | |                   | |  |  +------------+  |  | +------------+ | |
   | |                   | |  +->| v2cMP      |<--->| | Modèle de  | | |
   | | Répartition des   | |  |  +------------+  |  | | sécurité   | | |
   | | messages    <--------->|  +------------+  |  | |du transport| | |
   | |                   | |  +->| v3MP       |<--->| +------------+ | |
   | | Répartition des   | |  |  +------------+  |  | +------------+ | |
   | | PDU               | |  |  +------------+  |  | | Autres     | | |
   | +-------------------+ |  +->| autre MP   |<--->| | Modèles    | | |
   |              ^        |     +------------+  |  | +------------+ | |
   |              |        +---------------------+  +----------------+ |
   |              v                                                    |
   |      +-------+-------------------------+---------------+          |
   |      ^                                 ^               ^          |
   |      |                                 |               |          |
   |      v                                 v               v          |
   | +-------------+   +---------+   +--------------+  +-------------+ |
   | | Application |   | CONTRÔLE|   | Applications |  | Application | |
   | |RÉPONDEUR de |<->| D'ACCÈS |<->| NOTIFICATION |  | MANDATAIRE  | |
   | | COMMANDES   |   |         |   | de générateur|  | TRANSMETTEUR| |
   | +-------------+   +---------+   +--------------+  +-------------+ |
   |      ^                                 ^                          |
   |      |                                 |                          |
   |      v                                 v                          |
   | +----------------------------------------------+                  |
   | |            Instrumentation de MIB            |   Entité SNMP    |
   +-------------------------------------------------------------------+

 	3.2.1.1	Changements à l'architecture de la RFC 3411
L'architecture de la RFC3411 et le sous système de sécurité supposent qu'un modèle de sécurité soit invoqué par un modèle de traitement de messages et va effectuer plusieurs fonctions de sécurité au sein du sous système de sécurité. Un modèle de transport qui prend en charge un protocole de transport sûr pourrait effectuer des fonctions de sécurité similaires au sein du sous système de transport, incluant la traduction des paramètres de sécurité du transport de/vers des paramètres indépendants du modèle de sécurité.

Pour s'accommoder de cela, une antémémoire spécifique de la mise en œuvre d'informations spécifiques du transport va être décrite (non montrée) et les flux de données sur ce chemin vont être étendus pour passer des valeurs indépendantes du modèle de sécurité. Le présent document amende certaines des ASI définies dans la RFC 3411 ; ces changements sont traités à la Section 6 du présent document.

De nouveaux modèles de sécurité pourraient être définis qui comprennent comment fonctionner avec ces ASI modifiées et l'antémémoire d'informations de transport. Un tel modèle de sécurité, le modèle de sécurité du transport, est défini dans la [RFC5591].

 	3.2.1.2	Changements au traitement de la RFC 3411
L'introduction de transports sûrs affecte les responsabilités et l'ordre de traitement au sein de l'architecture de la RFC3411. Bien que les étapes soient les mêmes, elles pourraient se produire dans un ordre différent, et pourraient être faites par des sous systèmes différents. Avec l'architecture existante de la RFC3411, le traitement de la sécurité commence quand le modèle de traitement de messages décode des portions du message codé pour extraire les paramètres qui identifient quel modèle de sécurité DOIT traiter les tâches relatives à la sécurité.

Un transport sûr effectue ces fonctions de sécurité sur le message, avant que le message soit décodé. Certaines de ces fonctions pourraient alors être répétées par le modèle de sécurité choisi.

 	3.2.1.3	Passage des informations entre les moteurs SNMP
Un modèle de transport sûr va établir un tunnel authentifié et éventuellement chiffré entre les modèles de transport de deux moteurs SNMP. Après qu'un tunnel de couche transport est établi, les messages SNMP peuvent alors être envoyés à travers le tunnel d'un moteur SNMP à l'autre. Alors que les modèles de sécurité de communauté [RFC3584] et le modèle de sécurité fondé sur l'utilisateur établissent une association de sécurité pour chaque message SNMP, des modèles de transport plus récents PEUVENT prendre en charge l'envoi de plusieurs messages SNMP à travers le même tunnel pour amortir les coûts d'établissement d'une association de sécurité.

 	3.2.2	Exigences de contrôle d'accès
La RFC 3411 a pris des décisions de conception relatives à la prise en charge d'un sous système de contrôle d'accès. Cela inclut d'établir et de passer de manière indépendante du modèle les paramètres securityModel, securityName, et securityLevel, et de séparer l'authentification de message de l'autorisation des données d'accès.

 	3.2.2.1	Transposition de securityName et de securityLevel
Les contrôles de données d'accès de SNMP sont supposés fonctionner sur la base de qui peut effectuer quelles opérations sur quels sous ensembles de données, et sur la base des services de sécurité qui vont être fournis pour sécuriser les données en transit. Les paramètres securityModel et securityLevel établissent les protections pour le transit -- que les services d'authentification et de confidentialité soient ou aient été appliqués au message. Le securityName est un identifiant indépendant du modèle du "principal" de sécurité.

Un modèle de sécurité joue un rôle dans la sécurité qui va au delà de la protection du message -- il fournit une transposition entre le principal spécifique du modèle de sécurité pour un message entrant et le securityName indépendant du modèle de sécurité qui peut être utilisé pour la suite du traitement, comme le contrôle d'accès. Le securityName est transposé d'une identité spécifique d'un mécanisme, et cette transposition doit être faite pour les messages entrants par le modèle de sécurité avant qu'il passe le securityName au modèle de traitement de messages via l'ASI processIncoming.

Un modèle de sécurité est aussi chargé de spécifier, via le paramètre securityLevel, si les messages entrants ont été authentifiés et chiffrés, et pour s'assurer que les messages sortants sont authentifiés et chiffrés sur la base de la valeur de securityLevel.

Un modèle de transport PEUT fournir des valeurs suggérées pour securityName et securityLevel. Un modèle de sécurité pourrait avoir plusieurs sources pour déterminer le principal et les services de sécurité désirés, et un modèle de sécurité particulier pourrait ou non utiliser les valeurs proposées par un modèle de transport quand il décide de la valeur de securityName et securityLevel.

Les documents qui définissent un nouveau domaine de transport DOIVENT définir un préfixe qui PEUT être ajouté devant tous les securityNames passés par le modèle de sécurité. Le préfixe DOIT inclure un à quatre caractères alpha-numériques US-ASCII, n'incluant pas de caractère ":" (US-ASCII 0x3a). Si un préfixe est utilisé, un securityName est construit en enchaînant le préfixe et un caractère ":" (US-ASCII 0x3a) suivi par une identité non vide dans un format compatible avec snmpAdminString. Le préfixe peut être utilisé par les applications SNMP pour distinguer"alice" authentifiée par SSH de "alice" authentifiée par TLS. Les domaines de transport et leurs préfixes correspondants sont coordonnés via le registre IANA "Domaines de transport SNMP".

 	3.2.3	Exigences de passage de paramètre de sécurité
Un modèle de traitement de messages pourrait sortir les paramètres de sécurité spécifiques de SNMP d'un message entrant avant d'invoquer un modèle de sécurité spécifique pour le traitement relatif à la sécurité du message. Quand on utilise un modèle de transport sûr, certains paramètres de sécurité pourraient être extraits de la couche transport par le modèle de transport avant que le message soit passé au sous système de traitement de message.

Le présent document décrit un mécanisme d'antémémoire (voir la Section 5) dans lequel le modèle de transport met les informations sur le transport et les paramètres de sécurité appliqués à une connexion de transport ou à un message entrant ; un modèle de sécurité pourrait extraire ces informations de l'antémémoire. Un tmStateReference est passé comme paramètre supplémentaire dans les ASI entre le sous système de transport et les sous systèmes de traitement de message et de sécurité afin d'identifier l'antémémoire pertinente. Cette approche de passer une référence indépendante du modèle est cohérente avec l'antémémoire securityStateReference déjà passée dans les ASI de la RFC 3411.

 	3.2.4	Séparation de l'authentification et de l'autorisation
L'architecture de la RFC3411 définit une séparation de l'authentification et de l'autorisation d'accès et/ou de modifier les données de MIB. Un ensemble de paramètres indépendants du modèle (securityModel, securityName, et securityLevel) est passé entre le sous système de sécurité, les applications, et le sous système de contrôle d'accès.

Cette séparation est une décision délibérée du groupe de travail SNMPv3, afin de permettre la prise en charge des protocoles d'authentification qui ne fournissent pas de capacité d'autorisation des données d''accès, et afin de prendre en charge des schémas d'autorisation des données d'accès, comme le modèle de contrôle d'accès selon la vue (VACM, View-based access Control Model) qui n'effectuent pas leur propre authentification.

Un modèle de traitement de messages détermine quel modèle de sécurité est utilisé, soit sur la base de la version de message (par exemple, SNMPv1 et SNMPv2c) ou éventuellement par une valeur spécifiée dans le message (par exemple, le champ msgSecurityModel dans SNMPv3).

Le modèle de sécurité décide quelles valeurs de securityName et securityLevel sont passées comme paramètres indépendants du modèle à une application, qui les passe ensuite via l'ASI isAccessAllowed au sous système de contrôle d'accès.

Un modèle de contrôle d'accès effectue la transposition des paramètres de sécurité indépendants du modèle en une politique au sein du modèle de contrôle d'accès qui dépend du modèle de contrôle d'accès.

Un modèle de transport ne sait pas quel modèle de sécurité va être utilisé pour un message entrant, et donc ne peut pas savoir comment les paramètres securityName et securityLevel vont être déterminés. Il peut proposer une identité authentifiée (via le champ tmSecurityName) mais il n'est pas garanti que cette valeur va être utilisée par le modèle de sécurité. Par exemple, des modèles de sécurité ignorants du transport vont normalement déterminer le securityName (et securityLevel) sur la base du contenu du message SNMP lui-même. De tels modèles de sécurité vont simplement ne pas savoir que l'antémémoire tmStateReference existe.

De plus, même si le modèle de transport peut influencer le choix de securityName, il ne peut pas directement déterminer l'autorisation permise pour cette identité. Si deux différents modèles de transport authentifient chacun un principal de transport qui sont ensuite tous deux transposés en le même securityName, alors ces deux identités vont normalement être exactement affectées à la même autorisation par le modèle de contrôle d'accès.

La seule façon pour que le modèle de contrôle d'accès différencie entre les identités sur la base du modèle de transport sous-jacent serait que de telles identitiés de transport authentifiées soient transposées en des securityNames distincts. Comment cela est fait dépend du modèle de sécurité.

 	3.3	Exigences de session
Certains transports sûrs ont une notion de sessions, tandis que d'autres transports sûrs fournissent des mécanismes de canaux ou autres comme des sessions. Dans le présent document, le terme de "session" est utilisé au sens large pour couvrir des mécanismes de session de transport, de canal de transport, et d'autre couche de transport, comme des sessions. Les sessions de couche de transport qui peuvent sécuriser plusieurs messages SNMP au sein de la vie de la session sont considérées souhaitables parce que le coût de l'authentification peut être amorti sur potentiellement de nombreuses transactions. Comment une session de transport est réellement établie, ouverte, fermée, ou maintenue est spécifique d'un modèle de transport particulier.

Pour réduire la redondance, le présent document décrit les aspects qui sont supposés être communs à toutes les sessions de modèle de transport.

 	3.3.1	Sessions non SNMP
L'architecture définie dans la [RFC3411] et le sous système de transport défini dans le présent document ne prennent pas en charge les sessions SNMP ni n'incluent de sélecteur de session dans les interfaces de service abstraites.

Le sous système de transport pourrait prendre en charge les sessions de transport. Cependant, le sous système de transport n'a pas accès au pduType (c'est-à-dire, le type de fonctionnement SNMP) et donc ne peut pas choisir une session de transport donnée pour des types de trafic particuliers.

Certains paramètres des interfaces de service abstraites pourraient être utilisés pour guider le choix d'une session de transport appropriée à utiliser pour une demande donnée par une application.

Le transportDomain et la transportAddress identifient la connexion de transport à un nœud de réseau distant. Les éléments de l'adresse de transport (comme le numéro d'accès) pourraient être utilisés par une application pour envoyer un type particulier de PDU à une adresse de transport particulière. Par exemple, la SNMP-TARGET-MIB et la SNMP-NOTIFICATION-MIB [RFC3413] sont utilisées pour configurer les générateurs de notifications avec l'accès de destination auxquels les PDU SNMPv2-Trap ou Inform sont à envoyer, mais le sous système de transport ne regarde jamais dans la PDU.

Le securityName identifie avec quel principal de sécurité communiquer à cette adresse (par exemple, des applications différentes de système de gestion de réseau (NMS, Network Management System)) et le securityLevel pourrait permettre le choix d'ensembles différents de propriétés de sécurité pour différents objets (par exemple, des opérations SET chiffrées contre des opérations GET non chiffrées).

Cependant, parce que le traitement des sessions de transport est spécifique de chaque modèle de transport, certains modèles de transport PEUVENT restreindre le choix à une session de transport particulière. Une application d'utilisateur pourrait utiliser une combinaison unique de transportDomain, transportAddress, securityModel, securityName, et securityLevel pour essayer de forcer le choix d'une session de transport donnée. Cet usage est NON RECOMMANDÉ parce que il n'est pas garanti qu'il soit interopérable à travers les mises en œuvre et les modèles.

Les mises en œuvre DEVRAIENT être capables de maintenir un nombre raisonnable de sessions de transport concurrentes, et PEUVENT fournir des mécanismes internes non standard pour choisir les sessions de transport.

 	3.3.2	Exigences d'établissement de session
Les applications SNMP fournissent le transportDomain, transportAddress, securityName, et securityLevel à utiliser pour créer une nouvelle session.

Si le modèle de transport ne peut pas fournir au moins le niveau de sécurité requis, le modèle de transport devrait éliminer le message et devrait notifier au répartiteur que l'établissement d'une session et l'envoi du message ont échoué. De même, si la session ne peut pas être établie, alors le message devrait être éliminé et le répartiteur devrait en être notifié.

L'établissement d'une session de transport pourraient exiger de provisionner des accréditifs d'authentification à un moteur, statiquement ou dynamiquement. Comment cela est fait dépend du modèle de transport et de la mise en œuvre.

 	3.3.3	Exigences de maintenance de session
Un modèle de transport peut supprimer des sessions comme nécessaire. Il pourrait être nécessaire pour certaines mises en œuvre de supprimer des sessions par suite de contraintes de ressources, par exemple.

La décision de supprimer une session dépend de la mise en œuvre. Comment une mise en œuvre détermine qu'une opération est achevée dépend de la mise en œuvre. Bien qu'il soit possible de supprimer chaque session de transport après l'achèvement du traitement de chaque message, ceci n'est pas recommandé pour des raisons de performances.

Les éléments de procédure décrivent quand les informations en antémémoire peuvent être éliminées, et le rythme de nettoyage de l'antémémoire pourrait avoir des implications de sécurité, mais la gestion des antémémoires est une question de mise en œuvre.

Si un modèle de transport définit des objets de module de MIB pour conserver les informations d'état de session, alors le modèle de transport DOIT définir ce qui arrive aux objets quand la session en rapport est supprimée, car cela va impacter l'interopérabilité du module de MIB.

 	3.3.4	Sécurité de message contre sécurité de session
Un modèle de session de transport est associé à des informations d'état qui sont conservées pendant sa durée de vie. Ces informations d'état permettent l'application de divers services de sécurité pour plusieurs messages. Les clés de chiffrement associées à la session de transport DEVRAIENT être utilisées pour fournir les services d'authentification, de vérification d'intégrité, et de chiffrement, comme nécessaire, pour les données qui sont communiquées durant la session. Les protocoles cryptographiques utilisés pour établir les clés pour un modèle de session de transport DEVRAIENT s'assurer que de nouvelles clés de session fraîches sont générées pour chaque session. Cela va assurer qu'une attaque en répétition inter-sessions va échouer ; c'est-à-dire, un attaquant ne pourrait pas prendre un message observé dans une session et réussir à le répéter dans une autre session.

Un bon protocole de sécurité protégerait aussi contre les attaques en répétition au sein d'une session ; c'est-à-dire, un attaquant ne pourraient pas prendre un message observé dans une session et réussir à le répéter plus tard dans la même session. Une approche serait d'utiliser les informations de numéro de séquence au sein du protocole, permettant aux participants de détecter si les messages ont été répétés ou réarrangés au sein d'une session.

Si une session de transport sûr est close entre le moment où un message de demande est reçu et celui de l'envoi du message de réponse correspondant, le message de réponse DEVRAIT alors être éliminé, même si une nouvelle session a été établie.  Le groupe de travail SNMPv3 a décidé que ceci devrait être un "DEVRAIT" architectural, et si il faut l'EXIGER est une décision spécifique du modèle de sécurité. L'architecture ne rend pas obligatoire cette exigence afin de permettre de futurs modèles de sécurité où cela pourrait avoir un sens ; cependant, ne pas exiger cela pourrait conduire à plus de complexité et à des vulnérabilités, donc la plupart des modèles de sécurité DEVRAIENT l'exiger.

SNMPv3 a été conçu pour prendre en charge plusieurs niveaux de sécurité, choisis message par message par une application SNMP, parce que, par exemple, il n'y a pas beaucoup d'intérêt à utiliser un chiffrement pour un générateur de commandes pour interroger sur des données de performance potentiellement non sensibles sur des milliers d'interfaces toutes les dix minutes ; un tel chiffrement pourrait ajouter des frais généraux significatifs au traitement des messages.

Certains modèles de transport pourraient prendre en charge seulement des services spécifiques d'authentification et de chiffrement, comme d'exiger que tous les messages soient portés en utilisant à la fois l'authentification et le chiffrement, sans considération du niveau de sécurité demandé par une application SNMP. Un modèle de transport PEUT relever le niveau de sécurité demandé pas un modèle de sécurité conscient du transport, c'est-à-dire, noAuthNoPriv et authNoPriv pourraient être envoyés sur une session authentifiée et chiffrée. Un modèle de transport NE DOIT PAS dégrader le niveau de sécurité demandé par un modèle de sécurité conscient du transport et DEVRAIT éliminer tout message où cela arriverait. Ceci est un DEVRAIT plutôt qu'un DOIT seulement pour permettre le développement potentiel de modèles qui peuvent effectuer le traitement d'erreur d'une manière moins sévère que l'élimination du message. Cependant, tout modèle qui n'élimine pas le message dans ces circonstances devrait avoir une justification claire de pourquoi la non élimination ne créerait pas de vulnérabilité.

 	4.	Diagrammes de scénario et sous système de transport

Les paragraphes 4.6.1 et 4.6.2 de la RFC 3411 fournissent des diagrammes de scénarios pour illustrer comment un message sortant est créé et comment un message entrant est traité. La RFC 3411 ne définit pas les ASI pour les flèches "Envoi du message de demande SNMP au réseau", "Réception du message de réponse SNMP du réseau", "Réception du message SNMP du réseau" et "Envoi du message SNMP au réseau" dans ces diagrammes.

Le présent document définit deux ASI correspondant à ces flèches : une ASI sendMessage pour envoyer des messages SNMP au réseau et une ASI receiveMessage pour recevoir les messages SNMP provenant du réseau. Ces ASI sont utilisées pour tous les messages SNMP, sans considération du pduType.

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

Quand on effectue le traitement SNMP, il y a deux niveaux des informations d'état qui pourraient devoir être conservés : l'état immédiat reliant une paire demande-réponse et un état potentiellement à plus long terme relatif au transport et à la sécurité.

L'architecture de la RFC3411 utilise des antémémoires pour conserver l'état de message à court terme, et utilise des références dans les ASI pour passer cette information entre sous systèmes.

Le présent document définit les exigences pour qu'une antémémoire traite de l'état de message à court terme supplémentaire et des informations d'état de transport à plus long terme, en utilisant un paramètre tmStateReference pour passer cette information entre sous systèmes.

Pour simplifier les éléments de procédure, la livraison des informations d'état n'est pas toujours explicitement spécifiée. En règle générale, si les informations d'état sont disponibles quand un message traité est éliminé, l'état relatif à ce message devrait aussi être éliminé. Si les informations d'état sont disponibles quand une relation entre moteurs est rompue, comme la clôture d'une session de transport, les informations d'état pour cette relation devraient aussi être éliminées.

Comme le contenu d'une antémémoire n'a de signification qu'au sein d'une mise en œuvre, et non sur le réseau, le format de l'antémémoire est spécifique de la mise en œuvre.

 	5.1	securityStateReference
Le paramètre securityStateReference est défini dans la RFC 3411. Son principal objet est de fournir une transposition entre une demande et la réponse correspondante. Cette antémémoire n'est pas accessible aux modèles de transport, et une entrée est normalement seulement conservée pour la durée de vie d'une paire de messages de demande-réponse.

 	5.2	tmStateReference
Pour chaque session de transport, les informations sur la sécurité du transport sont mémorisées dans une antémémoire tmState ou magasin de données qui est référencé par une tmStateReference. Le paramètre tmStateReference est utilisé pour passer les paramètres spécifiques du modèle et du mécanisme entre le sous système de transport et les modèles de sécurité conscients du transport.

En général, quand c'est nécessaire, le tmState est rempli par le modèle de sécurité pour les messages sortants et par le modèle de transport pour les messages entrants. Cependant, dans les deux cas, le modèle qui remplit le tmState pourrait avoir des informations incomplètes et les informations manquantes pourraient être remplies par l'autre modèle quand les informations deviennent disponibles.

Le tmState pourrait contenir les informations de long terme et de court terme. Les informations de session restent normalement valides pour la durée de la session de transport, pourraient être utilisées pour plusieurs messages, et pourraient être mémorisées dans un magasin de données de configuration local. Certaines informations ont une durée de vie plus courte, comme un tmSameSecurity et tmRequestedSecurityLevel, qui sont associés à un message spécifique.

Comme cette antémémoire est seulement utilisée dans une mise en œuvre, et non sur le réseau, le contenu et le format précis de l'antémémoire dépendent de la mise en œuvre. Pour la modularité architecturale entre les modèles de transport et les modèles de sécurité conscients du transport, un tmState pleinement défini DOIT conceptuellement inclure au moins les champs suivants :
tmTransportDomain
tmTransportAddress
tmSecurityName
tmRequestedSecurityLevel
tmTransportSecurityLevel
tmSameSecurity
tmSessionID

Les détails de ces champs sont décrits dans les paragraphes qui suivent.

 	5.2.1	Informations de transport
Les informations sur la source d'un message SNMP entrant sont passées du sous système de transport jusqu'au sous système de traitement de message. Cependant, ces paramètres ne sont pas inclus dans l'ASI processIncomingMsg définie dans la RFC 3411 ; donc, ces informations ne sont pas directement disponibles au modèle de sécurité.

Un modèle de sécurité conscient du transport pourrait souhaiter prendre en compte le protocole de transport et l'adresse d'origine quand il authentifie la demande et règle les paramètres d'autorisation. Il est donc nécessaire que le modèle de transport inclue ces informations dans l'antémémoire tmStateReference afin qu'elles soient accessibles au modèle de sécurité.

o	tmTransportDomain : le protocole de transport (et donc le modèle de transport) utilisé pour recevoir le message entrant.

o	tmTransportAddress : la source du message entrant.

Les ASI utilisées pour traiter un message sortant incluent toutes les paramètres explicites transportDomain et transportAddress. Les valeurs dans l'antémémoire securityStateReference pourraient outrepasser ces paramètres pour les messages sortants.

 	5.2.2	securityName
Il y a actuellement trois "identités" distinctes qui peuvent être identifiées durant le traitement d'une demande SNMP sur un transport sûr :

o	transport principal : l'identité de transport authentifiée au nom de laquelle la connexion de transport sûre a été (ou devrait être) établie. Cette valeur est spécifique du transport, du mécanisme, et de la mise en œuvre, et est seulement utilisée dans un modèle de transport donné.

o	tmSecurityName : nom lisible par un humain (en format snmpAdminString) représentant cette identité de transport. Cette valeur est spécifique du transport et de la mise en œuvre, et est seulement utilisée (directement) par les modèles de transport et de sécurité.

o	securityName : nom lisible par un humain (en format snmpAdminString) représentant le principal SNMP d'une manière indépendante du modèle. Cette valeur est utilisée directement par les applications SNMP, le sous système de contrôle d'accès, le sous système de traitement de message, et le sous système de sécurité.

Le transport principal pourrait ou non être le même que le tmSecurityName. De même, le tmSecurityName pourrait ou non être le même que le securityName comme vu des sous systèmes Application et Contrôle d'accès. En particulier, un modèle de sécurité non conscient du transport va ignorer complètement le tmSecurityName quand il détermine le securityName SNMP.

Cependant, il est important que la transposition entre le transport principal et le securityName SNMP (pour les modèles de sécurité conscients du transport) soit cohérente et prévisible afin de permettre la configuration d'un contrôle d'accès convenable et l'établissement des connexions de transport.

 	5.2.3	securityLevel
Il y a deux problèmes distincts relatifs au niveau de sécurité appliqué aux transports sûrs. Pour être clair, ils sont traités par des champs séparés dans l'antémémoire tmStateReference :

o	tmTransportSecurityLevel : indication provenant du modèle de transport sur le niveau de sécurité offert par cette session. Le modèle de sécurité peut utiliser cela pour s'assurer que les messages entrants ont été convenablement protégés avant d'agir sur eux.

o	tmRequestedSecurityLevel : indication provenant du modèle de sécurité sur le niveau de sécurité dont la fourniture est exigée du protocole de transport. Le modèle de transport peut utiliser cela pour s'assurer que les messages sortants ne vont pas être envoyés sur une session insuffisamment sûre.

 	5.2.4	Informations de session
Pour des raisons de sécurité, si une session de transport sûr est fermée entre le moment où un message de demande est reçu et celui où le message de réponse correspondant est envoyé, alors le message de réponse DEVRAIT être éliminé, même si une nouvelle session a été établie. Le groupe de travail SNMPv3 a décidé que ceci devrait être architecturalement un "DEVRAIT", et c'est une décision spécifique du modèle de sécurité d'EXIGER cela.

o	tmSameSecurity : ce fanion est utilisé par un modèle de sécurité conscient du transport pour indiquer si le modèle de transport DOIT appliquer cette restriction.

o	tmSessionID : afin de vérifier si la session a changé, le modèle de transport doit être capable de comparer la session utilisée pour recevoir la demande d'origine avec celle utilisée pour envoyer la réponse. Cela exige normalement une certaine forme d'identifiant de session. Cette valeur est seulement utilisée par le modèle de transport, donc le format et l'interprétation de ce champ sont spécifiques du modèle et dépendants de la mise en œuvre.

Quand on traite un message sortant, si tmSameSecurity est vrai, alors le tmSessionID DOIT correspondre à la session de transport en cours ; autrement, le message DOIT être éliminé et le répartiteur être notifié de l'échec de l'envoi du message.

 	6.	Interfaces abstraites de service

Les interfaces de service abstraites ont été définies par la RFC 3411 pour décrire les flux conceptuels de données entre les divers sous systèmes au sein d'une entité SNMP et pour aider à garder les sous systèmes indépendants les uns des autres sauf pour les paramètres communs.

Le présent document introduit deux nouvelles ASI pour définir l'interface entre les sous systèmes de transport et de répartiteur ; il étend aussi certaines ASI définies dans la RFC 3411 pour inclure les informations relatives au transport.

Le présent document suit l'exemple de la RFC 3411 concernant la livraison des informations d'état et les indications d'erreur.

1)	La livraison des informations d'état n'est pas toujours explicitement spécifiée dans un modèle de transport. Comme règle générale, si des informations d'état sont disponibles quand un message est éliminé, les informations d'état de message devraient aussi être éliminées, et si des informations d'état sont disponibles quand une session est close, les informations d'état de session devraient aussi être éliminées. Garder des informations de sécurité sensibles plus longtemps que nécessaire pourrait introduire des vulnérabilités potentielles pour une mise en œuvre.

2)	Une indication d'erreur dans les statusInformation va normalement inclure l'identifiant d'objet (OID, Object Identifier) et une valeur pour un compteur d'erreurs incrémenté. Cela pourrait être réalisé par des valeurs pour contextEngineID et contextName pour ce compteur, une valeur pour securityLevel, et la référence d'état appropriée si les informations sont disponibles au moment où l'erreur est détectée.

 	6.1	ASI sendMessage
L'ASI sendMessage est utilisée pour passer un message du répartiteur au modèle de transport approprié pour l'envoi. L'ASI sendMessage définie dans le présent document remplace le texte "Envoi d'un message de demande SNMP au réseau" qui apparaît dans le diagramme du paragraphe 4.6.1 de la RFC 3411 et le texte "Envoi d'un message SNMP au réseau" qui apparaît au paragraphe 4.6.2 de la RFC 3411.

Si elle est présente et valide, la tmStateReference se réfère à une antémémoire contenant des paramètres spécifiques du modèle de transport pour le transport et la sécurité du transport. Comment il est déterminé qu'une tmStateReference est présente et valide dépend de la mise en œuvre. Comment les informations de l'antémémoire sont utilisées dépend du modèle de transport et de la mise en œuvre.

Cela pourrait sembler sous spécifié, mais un modèle de transport pourrait être quelque chose comme SNMP sur UDP sur IPv6, où aucune sécurité n'est fournie, de sorte qu'il pourrait n'y avoir aucun mécanisme pour utiliser une antémémoire tmStateReference.

statusInformation =
sendMessage(
IN   destTransportDomain	-- domaine de transport à utiliser
IN   destTransportAddress	-- adresse de transport à utiliser
IN   outgoingMessage	-- message à envoyer
IN   outgoingMessageLength	-- sa longueur
IN   tmStateReference	-- référence à l'état du transport
  )

 	6.2	Changements aux ASI sortantes de la RFC 3411
Des paramètres supplémentaires ont été ajoutés aux ASI définies dans la RFC 3411 qui concernent la communication entre le répartiteur et les sous systèmes de traitement de message, et entre les sous systèmes de traitement de message et de sécurité.

 	6.2.1	Primitives du sous système de traitement de message
Un paramètre tmStateReference a été ajouté comme paramètre OUT aux ASI prepareOutgoingMessage et prepareResponseMessage. Ceci est passé du sous système de traitement de message au répartiteur, et de là au sous système de transport.

Comment ou si le sous système de traitement de message modifie ou utilise le contenu de l'antémémoire est spécifique du modèle de traitement de message.

statusInformation = 	-- succès ou errorIndication
prepareOutgoingMessage(
IN  transportDomain	-- domaine de transport à utiliser
IN  transportAddress	-- adresse de transport à utiliser
IN  messageProcessingModel	-- normalement, version SNMP
IN  securityModel	-- modèle de sécurité à utiliser
IN  securityName	-- au nom de ce principal
IN  securityLevel	-- niveau de sécurité demandé
IN  contextEngineID	-- données de/vers cette entité
IN  contextName	-- données de/vers ce contexte
IN  pduVersion	-- version de la PDU
IN  PDU	-- unité de données de protocole SNMP
IN  expectResponse	-- VRAI ou FAUX
IN  sendPduHandle	-- la bride pour confronter les réponses entrantes
OUT  destTransportDomain	-- domaine du transport de destination
OUT  destTransportAddress	-- adresse du transport de destination
OUT  outgoingMessage	-- message à envoyer
OUT  outgoingMessageLength	-- sa longueur
OUT  tmStateReference	-- (NOUVEAU) référence à l'état du transport
    )

statusInformation =	-- succès ou errorIndication
prepareResponseMessage(
IN  messageProcessingModel	-- normalement, version SNMP
IN  securityModel	-- modèle de sécurité à utiliser
IN  securityName	-- au nom de ce principal
IN  securityLevel	-- niveau de sécurité demandé
IN  contextEngineID	-- données de/vers cette entité
IN  contextName	-- données de/vers ce contexte
IN  pduVersion	-- version de la PDU
IN  PDU	-- unité de données de protocole SNMP
IN  maxSizeResponseScopedPDU	-- taille maximum capable d'accepter
IN  stateReference	-- référence aux informations d'état présentées dans la demande
IN  statusInformation	-- succès ou errorIndication, OID/valeur de compteur d'erreurs si erreur
OUT destTransportDomain	-- domaine de transport de destination 
OUT destTransportAddress	-- adresse de transport de destination 
OUT outgoingMessage	-- message à envoyer
OUT outgoingMessageLength	-- sa longueur
OUT tmStateReference	-- (NOUVEAU) référence à l'état de transport
    )

 	6.2.2	Primitives du sous système de sécurité
Les paramètres transportDomain et transportAddress ont été ajoutés comme paramètres IN aux ASI generateRequestMsg et generateResponseMsg, et un paramètre tmStateReference a été ajouté comme paramètre OUT. Les paramètres transportDomain et transportAddress auront été passés dans le sous système de traitement de message provenant du répartiteur et sont passés au sous système de sécurité. Le paramètre tmStateReference va être repassé du sous système de sécurité au sous système de traitement de message, et aux sous systèmes de répartiteur et de transport.

Si une antémémoire existe pour une session identifiable à partir des tmTransportDomain, tmTransportAddress, tmSecurityName, et securityLevel demandés, alors un modèle de sécurité conscient du transport pourrait créer un paramètre tmStateReference à cette antémémoire et passer cela comme paramètre OUT.

statusInformation =
generateRequestMsg(
IN   transportDomain	-- (NOUVEAU) domaine de transport de destination
IN   transportAddress	-- (NOUVEAU) adresse de transport de destination
IN   messageProcessingModel	-- normalement, version SNMP
IN   globalData	-- en-tête de message, données administratives
IN   maxMessageSize	-- de l'entité SNMP envoyeuse
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 de 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) référence à l'état du transport
   )

statusInformation =
generateResponseMsg(
IN   transportDomain	-- (NOUVEAU) domaine de transport de destination
IN   transportAddress	-- (NOUVEAU) adresse de transport de destination
IN   messageProcessingModel	-- modèle de traitement de messages
IN   globalData	-- msgGlobalData
IN   maxMessageSize	-- provenant de msgMaxSize
IN   securityModel	-- comme déterminé par MPM
IN   securityEngineID	-- valeur de snmpEngineID
IN   securityName	-- au nom de ce principal
IN   securityLevel	-- pour le message sortant
IN   scopedPDU	-- comme fourni par MPM
IN   securityStateReference	-- comme fourni par MPM
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) référence à l'état du transport
   )

 	6.3	ASI receiveMessage
L'ASI receiveMessage est utilisée pour passer un message provenant du sous système de transport au répartiteur. L'ASI receiveMessage remplace le texte "Reçoit un message de réponse SNMP du réseau" qui apparaît dans le diagramme du paragraphe 4.6.1 de la RFC 3411 et le texte "Reçoit un message SNMP du réseau" du paragraphe 4.6.2 de la RFC3411.

Quand un message est reçu sur une session de transport donnée, si une antémémoire n'existe pas déjà pour cette session, le modèle de transport pourrait en créer une, référencée par tmStateReference. Le contenu de cette antémémoire est discuté à la Section 5. Comment ces informations sont déterminées est spécifique de la mise en œuvre et du modèle de transport.

"Pourrait en créer une" pourrait sembler sous spécifié, mais un modèle de transport pourrait être quelque chose comme SNMP sur UDP sur IPv6, où la sécurité du transport n'est pas fournie, de sorte qu'il ne pourrait pas créer d'antémémoire.

Le modèle de transport ne connaît pas le securityModel pour un message entrant ; cela va être déterminé par le modèle de traitement de messages d'une manière qui dépend du modèle de traitement de message.

statusInformation =
receiveMessage(
IN   transportDomain	-- domaine de transport d'origine
IN   transportAddress	-- adresse de transport d'origine
IN   incomingMessage	-- message reçu
IN   incomingMessageLength	-- sa longueur
IN   tmStateReference	-- référence à l'état du transport
  )

 	6.4	Changements aux ASI entrantes de la RFC 3411
Le paramètre tmStateReference a aussi été ajouté à certaines des ASI entrantes définies dans la RFC 3411. Comment ou si un modèle de traitement de messages ou modèle de sécurité utilise tmStateReference est spécifique du traitement de message et du modèle de sécurité.

Cela pourrait sembler sous spécifié, mais un modèle de traitement de messages pourrait avoir accès à toutes  les informations provenant de l'antémémoire et du message. Le modèle de traitement de messages pourrait déterminer que le modèle de sécurité USM est spécifié dans un en-tête de message SNMPv3 ; le modèle de sécurité USM n'a pas besoin de valeurs dans l'antémémoire tmStateReference pour authentifier et sécuriser le message SNMP, mais une application pourrait avoir spécifié d'utiliser un transport sûr comme fourni par le modèle de transport SSH pour envoyer le message à sa destination.

 	6.4.1	Primitive de sous système de traitement de message
Le paramètre tmStateReference de prepareDataElements est passé du répartiteur au sous système de traitement de message. Comment ou si le sous système de traitement de message modifie ou utilise le contenu de l'antémémoire est spécifique du modèle de traitement de message.

result =	-- SUCCÈS ou errorIndication
prepareDataElements(
IN   transportDomain	-- domaine d'origine du transport 
IN   transportAddress	-- adresse d'origine du transport 
IN   wholeMsg	-- comme reçu du réseau
IN   wholeMsgLength	-- comme reçu du réseau
IN   tmStateReference	-- (NOUVEAU) provenant du modèle de transport
OUT  messageProcessingModel	-- normalement, version SNMP
OUT  securityModel	-- modèle de sécurité à utiliser
OUT  securityName	-- au nom de ce principal
OUT  securityLevel	-- niveau de sécurité demandé
OUT  contextEngineID	-- données de/vers cette entité
OUT  contextName	-- données de/vers ce contexte
OUT  pduVersion	-- version de la PDU
OUT  PDU	-- unité de données de protocole SNMP
OUT  pduType	-- type de PDU SNMP
OUT  sendPduHandle	-- bride pour confronter la demande
OUT  maxSizeResponseScopedPDU	-- taille maximum que l'envoyeur peut accepter
OUT  statusInformation	-- succès ou errorIndication, OID/valeur de compteur d'erreurs si erreur
OUT  stateReference	-- référence aux informations d'état à utiliser pour une réponse possible
   )

 	6.4.2	Primitive de sous système de sécurité
L'ASI processIncomingMessage passe la tmStateReference du sous système de traitement de message au sous système de sécurité.

Si tmStateReference est présent et valide, un modèle de sécurité approprié pourrait utiliser les informations de l'antémémoire. Comment ou si le sous système de sécurité utilise les informations de l'antémémoire est spécifique du modèle de sécurité.

statusInformation = 	-- errorIndication ou succès, OID/valeur de compteur d'erreurs si erreur
processIncomingMsg(
IN   messageProcessingModel	-- normalement, version SNMP
IN   maxMessageSize	-- de l'entité SNMP envoyeuse
IN   securityParameters	-- pour le message reçu
IN   securityModel	-- pour le message reçu
IN   securityLevel	-- niveau de sécurité
IN   wholeMsg	-- comme reçu du réseau
IN   wholeMsgLength	-- longueur comme reçue du 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 (texte 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
   )

 	7.	Considérations sur la sécurité

Le présent document définit une approche architecturale qui permet à SNMP d'utiliser des services de sécurité de couche de transport. Chaque modèle de transport proposé devrait discuter les considérations sur la sécurité de ce modèle de transport.

Il est considéré comme désirable par certains segments de l'industrie que les modèles de transport SNMP utilisent la sécurité de couche de transport qui vise le secret de transmission parfait au moins pour les clés de chiffrement. Le secret de transmission parfait garantit que la compromission de clés secrètes à long terme ne résulte pas en la divulgation des clés de session passées. Chaque modèle de transport proposé devrait inclure une discussion dans ses considérations sur la sécurité sur si le secret de transmission parfait est approprié pour ce modèle de transport.

Les caractéristiques de déni de service de divers modèles de transport et protocoles de sécurité vont varier et devraient être évaluées quand on détermine l'applicabilité d'un modèle de transport à une situation de déploiement particulière.

Comme l'antémémoire va contenir des paramètres relatifs à la sécurité, les mises en œuvre DEVRAIENT mémoriser ces informations (dans une mémoire permanente) de manière à les protéger contre une divulgation et/ou modification non autorisée.

On doit veiller à s'assurer qu'un moteur SNMP envoie des paquets sur un transport en utilisant des accréditifs dont l'utilisation est légale pour ce moteur au nom de cet utilisateur. Autrement, un moteur qui a plusieurs transports ouverts pourrait être "trompé" à envoyer un message sur le mauvais transport.

Un modèle de sécurité pourrait avoir plusieurs sources à partir desquelles définir le securityName et securityLevel. L'utilisation d'un modèle de transport sûr n'implique pas que le securityName et securityLevel choisis par le modèle de sécurité représentent l'identité de transport authentifiée ou les services de sécurité fournis par le transport. Les paramètres securityModel, securityName, et securityLevel sont un ensemble en relation, et un administrateur devrait comprendre comment le modèle de sécurité spécifié choisit les securityName et securityLevel correspondants.

 	7.1	Coexistence, paramètres de sécurité, et contrôle d'accès
Dans l'architecture de la RFC3411, le modèle de traitement de messages prend la décision sur le modèle de sécurité à utiliser. Le changement architectural décrit par le présent document n'altère pas cela.

Le changement architectural décrit par le présent document permet cependant à SNMP de prendre en charge deux différentes approches de la sécurité -- la sécurité conduite par le message et la sécurité conduite par le transport. Avec la sécurité conduite par le message, SNMP fournit sa propre sécurité et passe les paramètres de sécurité dans le message SNMP ; avec la sécurité conduite par le transport, SNMP dépend d'une entité externe pour fournir la sécurité durant le transport en "enveloppant" le message SNMP.

Utiliser un modèle de sécurité sans conscience du transport sur un modèle de transport sûr n'est PAS RECOMMANDÉ pour les raisons suivantes.

Les modèles de sécurité définis avant le modèle de sécurité du transport (c'est-à-dire, SNMPv1, SNMPv2c, et USM) ne prennent pas en charge la sécurité fondée sur le transport et ont seulement accès aux paramètres de sécurité contenus dans le message SNMP. Ils ne connaissent pas les paramètres de sécurité associés à un transport sûr. Par suite, le sous système de contrôle d'accès fonde ses décisions sur les paramètres de sécurité extraits du message SNMP, et non des paramètres de sécurité fondés sur le transport.

Les implications de la combinaison des anciens modèles de sécurité avec les modèles de transport sûr sont connues. Le securityName utilisé pour les décisions de contrôle d'accès se fonde sur l'identité pilotée par le message, qui pourrait n'être pas authentifiée, et non sur l'identité authentifiée pilotée par le transport :

o	Un message SNMPv1 va toujours être apparié avec un modèle de sécurité SNMPv1 (selon la RFC 3584) sans considération de la transposition de transport ou du modèle de transport utilisé, et les contrôles d'accès vont être fondés sur le nom de communauté non authentifié.

o	Un message SNMPv2c va toujours être apparié avec un modèle de sécurité SNMPv2c (selon la RFC 3584) sans considération de la transposition de transport ou du modèle de transport utilisé, et les contrôles d'accès vont être fondés sur le nom de communauté non authentifié.

o	Un message SNMPv3 va toujours être apparié avec le modèle de sécurité spécifié dans le champ msgSecurityParameters du message (selon la RFC 3412) sans considération de la transposition de transport ou du modèle de transport utilisé. Si le message SNMPv3 spécifie le modèle de sécurité fondé sur l'utilisateur (USM) avec noAuthNoPriv, alors les contrôles d'accès vont être fondés sur l'utilisateur USM non authentifié.

o	Pour les messages sortants, si un modèle de transport sûr est choisi en combinaison avec un modèle de sécurité qui ne remplit pas une tmStateReference, le modèle de transport sûr DEVRAIT détecter le manque d'une tmStateReference valide et échouer.

Dans les moments de tension du réseau, un modèle de transport sûr pourrait ne pas fonctionner correctement si ses mécanismes de sécurité sous-jacents (par exemple, le protocole de l'heure du réseau (NTP) ou des protocoles d'authentification, autorisation, et comptabilité (AAA) ou des autorités de certificat) ne sont pas accessibles. Le modèle de sécurité fondé sur l'utilisateur a été conçu explicitement pour ne pas dépendre de services réseau externes, et fourni ses propres services de sécurité. Il est RECOMMANDÉ que les opérateurs provisionnent l'USM authPriv comme mécanisme de repli pour compléter tout modèle de sécurité ou modèle de transport qui a des dépendances externes, afin que des communications SNMP sûres puissent continuer quand le service réseau externe n'est pas disponible.

 	8.	Considérations relatives à l'IANA

L"IANA a créé un nouveau registre dans les espaces de numéros du protocole simple de gestion de réseau(SNMP, Simple Network Management Protocol). Le nouveau registre est appelé "Domaines de transport SNMP". Ce registre contient les chaînes alpha-numériques US-ASCII de un à quatre caractères pour identifier les préfixes pour les domaines de transport SNMP correspondants. Chaque domaine de transport DOIT avoir un OID alloué dans snmpDomains [RFC2578]. Les valeurs sont allouées via la procédure de "Spécification exigée" de la [RFC5226].

Le registre a été rempli avec les entrées initiales suivantes :

Nom de registre : domaines de transport SNMP
Références : [RFC2578] [RFC3417] [RFC5590]
Procédures d'enregistrement : spécification exigée
À chaque domaine est alloué un OID défini par la MIB sous snmpDomains

Préfixe	snmpDomains	Références
  udp	snmpUDPDomain	[RFC3417] [RFC5590]
  clns	snmpCLNSDomain	[RFC3417] [RFC5590]
  cons	snmpCONSDomain	[RFC3417] [RFC5590]
  ddp	snmpDDPDomain	[RFC3417] [RFC5590]
  ipx	snmpIPXDomain	[RFC3417] [RFC5590]
  prxy	rfc1157Domain	[RFC3417] [RFC5590]

 	9.	Remerciements

Le groupe de travail Sécurité intégrée pour SNMP souhaite remercier les personnes suivantes de leurs contributions au processus.
Les auteurs de propositions de modèle de sécurité soumis : Chris Elliot, Wes Hardaker, David Harrington, Keith McCloghrie, Kaushik Narayan, David Perkins, Joseph Salowey, et Juergen Schoenwaelder.
Les membres de l'équipe d'évaluation du protocole : Uri Blumenthal, Lakshminath Dondeti, Randy Presuhn, et Eric Rescorla.
Les membres du groupe de tavail qui ont effectué des relectures détaillées : Wes Hardaker, Jeffrey Hutzelman, Tom Petch, Dave Shield, et Bert Wijnen.

 	10.	Références
 	10.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)

[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)

 	10.2	Références pour information

[RFC2865]	C. Rigney et autres, "Service d'authentification à distance de l'utilisateur appelant (RADIUS)", juin 2000. (MàJ par RFC2868, RFC3575, RFC5080, RFC8044) (D.S.)

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

[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)

[RFC4251]	T. Ylonen et C. Lonvick, "Architecture du protocole Secure Shell (SSH)", janvier 2006. (P.S. ; MàJ par RFC8308)

[RFC4422]	A. Melnikov et K. Zeilenga, éd, "Authentification simple et couche de sécurité (SASL)", juin 2006. (P.S.)

[RFC4741]	R. Enns, éd., "Protocole de configuration NETCONF", décembre 2006. (P.S.)

[RFC5226]	T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, mai 2008. (Remplace RFC2434 ; remplacée par RFC8126) 

[RFC5246]	T. Dierks, E. Rescorla, "Version 1.2 du protocole de sécurité de la couche Transport (TLS)", DOI 10.17487/RFC5246, août 2008. (P.S. ; remplace RFC3268, 4346, 4366 ; MàJ RFC4492 ; rendue obsolète par la RFC8446)

[RFC5424]	R. Gerhards, "Le protocole Syslog", mars 2009. (Remplace la RFC3164, P. S.)

[RFC5591]	D. Harrington, W. Hardaker, "Modèle de sécurité du transport pour le protocole simple de gestion de réseau (SNMP)", juin  2009. (P. S.)

[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.	Pourquoi tmStateReference ?

Le présent appendice examine pourquoi une approche fondée sur l'antémémoire a été choisie pour passer les paramètres.

Il y a quatre approches qui pourraient être utilisées pour passer les informations entre le modèle de transport et un modèle de sécurité.
1.	On pourrait définir une ASI pour compléter les ASI existantes.
2.	On pourrait ajouter un en-tête pour encapsuler le message SNMP.
3.	On pourrait utiliser des champs déjà définis dans le message SNMPv3 existant.
4.	On pourrait passer les information dans une antémémoire spécifique de la mise en œuvre ou via un module de MIB.

 	A.1	Définir une interface abstraite de service 
Les interfaces de service abstraites (ASI) sont définies par un ensemble de primitives qui spécifient les services fournis et les éléments de données abstraits qui sont à passer quand les services sont impliqués. Définir des ASI additionnelles pour passer les informations de sécurité et de transport provenant du sous système de transport au sous système de sécurité présente l'avantage d'être cohérent avec la pratique existante des RFC 3411/3412 ; cela aide aussi à s'assurer que toute proposition de modèle de transport passe les données nécessaires et ne cause pas d'effets collatéraux en créant des dépendances spécifiques du modèle entre lui-même et les modèles ou sous systèmes autres que ceux qui sont clairement définis par une ASI.

 	A.2	Utilisation d'un en-tête d'encapsulation
Un en-tête pourrait encapsuler le message SNMP pour passer les informations nécessaires du modèle de transport au répartiteur et ensuite à un modèle de traitement de messages. L'en-tête de message serait inclus dans le paramètre d'ASI wholeMessage et serait supprimé par un modèle de traitement de messages correspondant. Cela impliquerait que le (un et seulement un) répartiteur de messages devrait être modifié pour déterminer quelle version de message SNMP était impliquée, et un nouveau modèle de traitement de messages devrait être développé qui sache comment extraire l'en-tête du message et le passer au modèle de sécurité.

 	A.3	Modification des champs existants dans un message SNMP
La [RFC3412] définit le message SNMPv3, qui contient des champs pour passer les paramètres relatifs à la sécurité. Le sous système de transport pourrait utiliser ces champs dans un message SNMPv3 (ou des champs comparables dans les autres formats de message) pour passer les informations entre les modèles de transport dans les différents moteurs SNMP et pour passer les informations entre un modèle de transport et un modèle de traitement de messages correspondant.

Si les champs dans un message SNMPv3 entrant sont changés par le modèle de transport avant de le passer au modèle de sécurité, alors le modèle de transport va devoir décoder le message ASN.1, modifier les champs, et recoder le message en ASN.1 avant de le passer au répartiteur de messages ou à la couche transport. Cela exigerait une connaissance intime du format de message et des versions de message afin que le modèle de transport sache quels champs pourraient être modifiés.  Cela violerait sérieusement la modularité de l'architecture.

 	A.4	Utilisation d'une antémémoire
Le présent document décrit une antémémoire dans laquelle le modèle de transport (TM) met les informations sur la sécurité appliquée à un message entrant ; un modèle de sécurité peut extraire ces informations de l'antémémoire. Étant donné qu'il pourrait y avoir plusieurs antémémoires de sécurité de TM, une tmStateReference est passée comme paramètre supplémentaire dans les ASI entre le sous système de transport et le sous système de sécurité afin que le modèle de sécurité sache quelle antémémoire des informations consulter.

Cette approche ne crée pas de dépendance entre un modèle de transport spécifique et un modèle de sécurité spécifique correspondant. Cependant, l'approche de passer une référence indépendante du modèle à une antémémoire dépendante du modèle est cohérente avec la securityStateReference déjà passée dans les ASI de la RFC 3411.

 	Adresse des auteurs
David Harrington	Juergen Schoenwaelder	
Huawei Technologies (USA)	Jacobs University Bremen	
1700 Alma Dr. Suite 100	Campus Ring 1	
Plano, TX 75075	28725 Bremen	
USA	Germany	
téléphone : +1 603 436 8634	téléphone : +49 421 200-3587	
mél : ietfdbh@comcast.net	mél : j.schoenwaelder@jacobs-university.de