V-Le protocole SNMPv2
publicité
UNIVERSITE LIBANAISE
(Faculté de Génie)
UNIVERSITE SAINT-JOSEPH
(Faculté d’Ingénierie, ESIB)
Sous l’égide de l’Agence des Universités Francophones
AUPELF – UREF
Diplôme d’Etudes Approfondies
Réseaux de Télécommunications
Etude de SNMPv3
par
Antoine AOUN
Soutenu le ?? / 12 / 1998 devant le jury composé de:
MM.
Samir TOHME
Maroun ASMAR
Imad MOUGHARBEL
Maroun CHAMOUN
Mahmoud DOUGHANE
Amjad HAJJAR
Nicholas ROUHANA
président
membre
membre
membre
membre
membre
membre
Le Protocole SNMPv3
Remerciements
Avant tout, je tiens à remercier Dr Ahmed SEHROUCHNI
et Mr Maroun CHAMOUN pour leur temps et leurs
conseils précieux qui étaient indispensables, ainsi que toute
personne qui m’a soutenu durant toutes les phases de ce
projet.
Projet DEA Réseaux de Telecom – 1998
1 / 85
Le Protocole SNMPv3
Table des matières
I-LA GESTION DES RESEAUX
4
I.1-Le protocole SNMP ..................................................................................................................... 5
II-STRUCTURE OF MANAGEMENT INFORMATION
8
II.1-Les identificateurs d’objets ........................................................................................................ 8
III-MANAGEMENT INFORMATION BASE - MIB
11
III.1-Les classes d’objets ................................................................................................................ 11
III.2-La MIB II ................................................................................................................................ 12
III.3-Le standard RMON ................................................................................................................ 12
IV-LE PROTOCOLE SNMP
14
IV.1-Buts de cette architecture ....................................................................................................... 14
IV.2-Les relations administratives .................................................................................................. 15
IV.3-Résolution de l’ambiguïté dans les MIB ................................................................................. 16
IV.4-Spécification du protocole ...................................................................................................... 16
IV.5-Procédures de traitements ...................................................................................................... 18
IV.6-Les types de PDU ................................................................................................................... 19
IV.6.1-GetRequestPDU .............................................................................................................................. 19
IV.6.2-GetNextRequestPDU....................................................................................................................... 20
IV.6.3-Exemple: ......................................................................................................................................... 20
IV.6.4-GetResponsePDU ............................................................................................................................ 22
IV.6.5-SetRequestPDU ............................................................................................................................... 23
IV.6.6-TrapPDU ......................................................................................................................................... 23
V-LE PROTOCOLE SNMPV2
25
V.1-L’évolution de SNMPv2 ........................................................................................................... 25
V.2-Transport de SNMPv2 ............................................................................................................. 26
V.3-Taille des messages SNMPv2................................................................................................... 26
V.4-Les requêtes SNMPv2 .............................................................................................................. 26
V.4.1-GetBulkRequest PDU: ...................................................................................................................... 26
V.4.2-Exemple 1: ........................................................................................................................................ 27
V.4.3-Exemple 2: ........................................................................................................................................ 28
V.5-Les messages d’erreurs en SNMPv2 ........................................................................................ 29
V.5.1-InformRequest PDU ......................................................................................................................... 30
V.5.2-Report PDU ...................................................................................................................................... 30
V.6-Les protocoles de transport de SNMPv2 .................................................................................. 31
V.6.1-Protocole UDP .................................................................................................................................. 31
V.6.2-Protocole OSI: .................................................................................................................................. 31
V.6.3-Protocole DDP .................................................................................................................................. 31
V.6.4-Protocole Apple Talk ........................................................................................................................ 31
V.6.5-Protocole IPX ................................................................................................................................... 32
V.7-Coexistence entre SNMPv1 et SNMPv2 ................................................................................... 32
V.7.1-Conversion SNMPv2 vers SNMPv1: ................................................................................................ 32
V.7.2-Conversion SNMPv1 vers SNMPv2 ................................................................................................. 32
V.7.3-Transparence de la station de gestion ............................................................................................... 33
VI-LE PROTOCOLE SNMPV3
34
VI.1-Les objectifs de cette architecture: ......................................................................................... 34
VI.2-Les exigences de sécurisations ............................................................................................... 34
VI.3-Les documentations de SNMPv3 ............................................................................................ 36
VI.4-Description du paquet SNMP ................................................................................................. 39
VI.5-Description d’une entité SNMPv3 .......................................................................................... 41
VI.5.1-Moteur SNMP ................................................................................................................................. 42
Distributeur............................................................................................................................................. 42
Traitement des messages ........................................................................................................................ 43
Système de sécurité ................................................................................................................................ 43
Le contrôle d’accès ................................................................................................................................. 44
Projet DEA Réseaux de Telecom – 1998
2 / 85
Le Protocole SNMPv3
Les applications ...................................................................................................................................... 44
Command Generator Applications ......................................................................................................... 45
Command Responder Applications ........................................................................................................ 45
Notification Originator Applications ...................................................................................................... 45
Notification Receiver Applications ........................................................................................................ 45
Proxy Forwarder Applications................................................................................................................ 45
VI.6-Architecture d’une station de gestion SNMPv3 ...................................................................... 47
VI.7-Architecture d’un agent SNMPv3 ........................................................................................... 48
VI.8-Diagrammes de fonctionnement ............................................................................................. 49
Générateur de commande ou Originateur de notification ........................................................................... 49
Application de réponse ............................................................................................................................... 50
VII-LA SECURITE DANS SNMPV3
51
VII.1-LES MENACES ............................................................................................................................ 51
VII.2-SERVICES DE SECURITE .............................................................................................................. 51
Le module d’alignement temporel .................................................................................................. 52
Le protocole d’authentification ...................................................................................................... 52
Le protocole de personnalisation ................................................................................................... 53
Génération d’un message SNMP sécurisé ...................................................................................... 53
Traitement d’un message reçu ........................................................................................................ 55
Les protocoles d’authentification HMAC-MD5-96 et HMAC-SHA-96 .......................................... 56
La localisation des mots de passe ............................................................................................................... 57
Le protocole d’Encryption CBC-DES ........................................................................................................ 58
VIII- DIFFERENTES CONFIGURATIONS D’UN MOTEUR SNMP
61
IX- LES NOUVELLES ARCHITECTURES
64
IX.1 - AgentX : Agent eXtensibility ................................................................................................. 64
IX.2 - Web Management ................................................................................................................. 66
IX.3 - DR Web................................................................................................................................. 72
Introduction ............................................................................................................................................ 72
Sécurité................................................................................................................................................... 73
BRASS ................................................................................................................................................... 73
IX.4 - L’agent EMANATE ............................................................................................................... 75
IX.5 - LATIN : Legacy Adapter to Internet ..................................................................................... 77
IX.6 - Le manager intermédiaire .................................................................................................... 79
IX.7 - L’approche TMN (Telecommunication management Network) de l’ITU ............................. 79
IX.8 - Le modèle d’information CIM .............................................................................................. 83
BIBLIOGRAPHIE
Projet DEA Réseaux de Telecom – 1998
86
3 / 85
Le Protocole SNMPv3
I-La gestion des réseaux
La gestion du réseau recouvre l’ensemble des activités de surveillance,
d’analyse, de contrôle et de planification du fonctionnement des ressources
d’un réseau de télécommunications dans le but de fournir des services de
télécommunications à des usagers avec un certain niveau de qualité
La gestion couvre de nombreuses opérations, telles que l’initialisation des
paramètres
de
configuration
du
système,
statistiques, les diagnostics, la gestion des
de
gestion
alarmes et
des
erreurs,
les
leur rapport, la
reconfiguration, la gestion des ressources, la sécurité,…
Pour arriver à interconnecter deux systèmes de gestion, une norme doit être
respectée qu’elle soit le droit ou le fait. Dans les normes de droit, on
retrouvera la normalisation provenant de l’ISO, que l’on appelle CMIS/CMIP
(Common Management Information Service / Protocol), et celle de l’UIT-T
qui porte le nom de TMN (Telecommunication Management Network) ou en
français RGT (Réseau de Gestion des Télécommunications). En fait ces deux
normes ne sont pas concurrentes, elles sont plutôt complémentaires. La
norme de fait la plus utilisée est SNMP (Simple Network Management
Protocol) qui provient de l’environnement Internet.
Suivant le type de système, les taches de gestion varient et doivent donc être
identifiées, et analysées. Des services et des protocoles de gestion sont
nécessaires pour gérer les ressources logicielles et matériels d’un réseau.
L’identification et la mise en œuvre des taches de gestion sont complexes en
raison de la nature distribuée du système. On peut citer les fonctions
suivantes:
+
Démarrage et arrêt du réseau: cette fonction de base est liée à la
configuration du réseau et à l’initialisation des paramètres;
+
Traitement des alarmes: cette fonction est nécessaire à la reprise
d’activité suite à une panne (du coupleur, d’une liaison,…)
Projet DEA Réseaux de Telecom – 1998
4 / 85
Le Protocole SNMPv3
+
Reconfiguration du réseau: Cette fonction est liée à l’ajout ou à la
suppression de points d’accès de terminaux. Par exemple, des éléments
du
réseau
doivent
être
mis
hors
circuit
en
cas
de
mauvais
fonctionnement;
+
Contrôle de la qualité: cette fonction est liée aux techniques de
contrôle, aux caractéristiques fonctionnelles du réseau et à la gestion
des rapports de changement d’états.
Les stations de gestion peuvent être matérielles ou logiciels. Les
moniteurs matériels s’occupent des phénomènes rapides; les moniteurs
logiciels sont plutôt orientes vers les applications.
+
Tests et diagnostics: les erreurs du système doivent être détectées. Un
message de diagnostic peut être émis pour signaler qu’une erreur s’est
produite et qu’un traitement peut avoir lieu. On doit pouvoir mettre un
élément du système en état de diagnostic afin de pouvoir exécuter des
séquences de tests;
+
Compte rendu d’alarmes: c’est une fonction destinée à notifier à
l’opérateur du système tout mauvais fonctionnement;
+
Contrôle du réseau: cette fonction est liée à l’allocation et à la
désallocation des ressources, et au contrôle de celles-ci.
Le système de gestion peut contrôler tous les changements. Il est aussi
responsable des allocations de noms, d’adresses et des associations
entre elles.
I.1-Le protocole SNMP
Le
protocole
simple
de
gestion
de
réseaux,
SNMP
(Simple
Network
Management Protocol), à été développé par un groupe de travail de l’IETF
(Internet Engineering Task Force) dans le cadre de la définition d’un système
de gestion des réseaux utilisant les protocoles TCP/IP.
SNMP à été approuvé par l’IAB (Internet Activities Board), responsable des
spécifications de TCP/IP.
Projet DEA Réseaux de Telecom – 1998
5 / 85
Le Protocole SNMPv3
Plusieurs documents définissent ce standard dont:
+
RFC 1155
SMI (Structure of management Information);
+
RFC 1156
MIB (Management Information Base);
+
RFC 1157
Protocole SNMP;
+
RFC 1158
MIB II (Management Information Base II).
Dans ce contexte, trois composants essentiels ont été définis:
+
Le
protocole
SNMP,
protocole
situé
au
niveau
application
de
l’architecture en couches de TCP/IP, définit la structure formelle des
communications;
+
La base d’informations de gestion: MIB regroupe l’ensemble des
variables relatives aux matériels et aux logiciels supportés par le
réseau, et définit les objets de gestion dans l’environnement TCP/IP;
+
Les spécifications de la structure de l’information de gestion: SMI qui
définit comment sont représentées, dans la MIB, les informations
relatives aux objets de gestion (Les ressources) et comment sont
obtenues ces informations.
Toutes les stations du réseau possèdent une base de ressources. Une station
de gestion NMS (Network Management Station), contient une base principale
qui représente toutes les ressources du réseau et les informations de gestion
associées.
La structure des paquets SNMP est définie en utilisant la syntaxe ASN.1
(Abstract Syntax Notation 1). L’environnement SNMP à été défini comme un
protocole destiné à surveiller la performance d’un réseau, détecter et analyser
les fautes d’un réseau, et configurer ses éléments.
Les systèmes SNMP ont deux éléments clés:
+
L’agent logiciel qui tourne dans les stations gérées. Ces stations sont
généralement des nœuds de réseaux IP qui peuvent être des systèmes hôtes
(Stations
de
travail,
serveurs…),
des
équipements
de
transmission
(multiplexeurs, …), des sondes ou des passerelles. Chaque agent comprend
une MIB, une base d’objets gérés et des variables;
Projet DEA Réseaux de Telecom – 1998
6 / 85
Le Protocole SNMPv3
+
La station de gestion de réseau (Manager), système hôte qui contient
le protocole de gestion de réseaux et les applications de gestion. Elle est
composée généralement d’un calculateur contenant une console et une base
de données représentant tous les périphériques gérés du réseau et toutes les
variables MIB de ces agents. Elle permet de récolter et d’analyser les données
relatives aux équipements physiques connectés au réseau (Ponts, Routeurs,
Hubs) et de les gérer. Il est à noter qu’un agent peut être géré par plusieurs
stations centrales. Il existe des agents appelés « proxy agents » qui permettent
à un système de gestion SNMP de gérer des nœuds ne supportant pas la suite
des protocoles Internet, c’est à dire des nœuds dialoguant avec un protocole
propriétaire ou ISO.
Projet DEA Réseaux de Telecom – 1998
7 / 85
Le Protocole SNMPv3
II-Structure of Management Information
La SMI (Structure and Identification of Management Information for TCP/IP
Based Internet) définit comment chaque élément d’information concernant
les périphériques gérés et les agents est représenté dans la base d’information
de gestion.
La syntaxe utilisée est un sous-ensemble de celle définie par la norme ASN.1
(Abstract Syntaxe Notation 1).
Chaque type d’objet a un nom, une syntaxe et un codage. Le nom est
représenté
uniquement
comme
« OBJECT
IDENTIFIER
» (Identificateur
d’objet), qui est un nom administratif.
Seuls quatre types de données sont utilisés:
+
Integer: type de données qui ne peut prendre que des valeurs entières;
+
Octet
String:
suite
d’octets
pouvant
prendre
des
valeurs
entre 0 et 255.
+
Object Identifier: type de donnée de type ASN.1
+
Nul
II.1-Les identificateurs d’objets
L’identificateur d’objet est une séquence de numéro entier traversant un arbre
global et séparé par des points (ex: 1.3.6.1.2.1). Cet arbre est formé d’une
racine non numérotée relier à un nombre de branche qui se termine par un
nœud identifié et unique. Le nombre minimal de nœud est 3: ISO(1),
CCITT(0)
et
Joint-ISO-CCITT(2).
Chaque
nœud
de
l’arbre
décrit
un
identificateur d’objet et peut par suite avoir d’autre nœud. Les feuilles de
l’arbre correspondent alors aux instances de l’objet qui sont les variables.
Sous le nœud ISO(1), l’ISO a désigné un seul nœud, à utiliser par les
organisations nationales ou internationales, nommé ORG(3). Sous ce nœud
Projet DEA Réseaux de Telecom – 1998
8 / 85
Le Protocole SNMPv3
on retrouve le DOD(6) (Department Of Defense) associé par la NBS (U.S.
National Bureau of Standards) à l’U.S. Department of Defense.
Racine
ISO(1)
CCITT(0)
Joint-ISO-CCITT(2)
ORG(3)
DOD(6)
Internet(1)
Directory(1) Mgmt(2)
Experimental(3)
MIB(1)
System(1) Interface(2) At(3)
IP(4)
Private(4)
Enterprise(1)
ICMP(5) TCP(6)
UDP(7)
Les identificateurs d’objets de la MIB
Sous le DOD(6) on retrouve l’INTERNET(1) géré par l’IAB. Cette branche
regroupe 4 nœuds:
Directory
OBJECT IDENTIFIER::= {internet 1}
Mgmt
OBJECT IDENTIFIER::= {internet 2}
Experimental OBJECT IDENTIFIER::= {internet 3}
Private
OBJECT IDENTIFIER::= {internet 4}
Directory
: Qui sera décrit dans le future
Mgmt
: Il est utilisé pour identifier les objets définit dans les
documents officiels de l’IAB.
Experimental
: Cette
branche
identifie
les
objets
d’expérimentation
Internet.
Private
: Identifie les objets définit unilatéralement.
Projet DEA Réseaux de Telecom – 1998
9 / 85
Le Protocole SNMPv3
Cette dernière branche contient au moins un nœud Enterprises(1). Ce nœud
permet aux producteurs de matériels réseaux d’enregistré les modèles de
leurs produits.
Ainsi si une entreprise veut définir son propre ensemble de variables de
gestion, elle enregistrera son numéro d’objet sous le nœud:
ISO.ORG.Internet.Private.Enterprise
Qui correspond à la racine: 1.3.6.1.4.1
Projet DEA Réseaux de Telecom – 1998
10 / 85
Le Protocole SNMPv3
III-Management Information Base - MIB
La MIB (Management Information Base) contient l’ensemble des variables
gérées. La MIB définit:
+
Un jeu de variables qui a trait à la fois au matériel et au logiciel.
+
Un jeu de points de test et de contrôle qu’un système supportant la
gestion SNMP est censée vérifier.
La
MIB
attribue
des
noms
aux
éléments
selon
une
hiérarchie
d’enregistrements définie par l’ISO pour la nomination des objets réseaux;
cela définit une structure dans laquelle les variables ayant une relation
logique sont regroupées en tables. Par exemple, les variables concernant la
vitesse, le taux d’erreurs et les adresses d’interface de communication sont
placées dans une table «interface». Les objets de la MIB sont classés en une
structure hiérarchisée de classes d’objets.
III.1-Les classes d’objets
Le premier niveau de classes d’objets de la MIB (MIB I) comprend les
groupes d’objets suivants:
+
System: pour la gestion du nœud lui-même;
+
Interfaces: pour les ports et interfaces réseaux;
+
Address translation: traduction d’adresses IP;
+
IP: Internet Protocol (Table de routage);
+
ICMP: Internet Control Message Protocol;
+
TCP: Transmission Control Protocol;
+
UDP: User Datagram Protocol;
+
EGP: Exterior Gateway Protocol .
Projet DEA Réseaux de Telecom – 1998
11 / 85
Le Protocole SNMPv3
Suivant
le
type
d’équipements
à
gérer,
seuls
certains
groupes
d’objets
peuvent être implémentés.
Cette structure propose un grand nombre d’entrées permettant de décrire la
majorité des objets réseau, mais certaines sociétés ont défini leur propre MIB.
Des entrées propres aux constructeurs ont d’ailleurs été prévues dans cette
organisation.
III.2-La MIB II
Le statut actuel de la MIB est défini dans les RFC 1066 et RFC 1158
(MIB II donne des extensions de la première génération de la MIB).
La MIB II comprend ce qui à été défini pour la MIB I en y ajoutant des
attributs ou des objets (2 groupes supplémentaires d’objets ont été définis:
transmissions et SNMP). La MIB II gère environ 200 variables.
III.3-Le standard RMON
Une autre version permet d’étendre les possibilités de SNMP: RMON MIB
(Remote Monitor Network Management Information Base). Elle permet aux
moniteurs distants de contrôler les flux de trafics circulant à travers le réseau
(elle est utilisée notamment pour les sondes).
Le standard RMON couvre neuf groupes de données:
Les statistiques (Par exemples, pour un réseau Ethernet, le
taux de collisions);
Les
historiques
qui
décrivent
le
comportement
du
réseau
pendant certaines périodes;
Les alarmes;
Les données relatives à la gestion des hôtes (enregistrement
des hôtes sur le réseau,…);
Les données rassemblant les statistiques d’un groupe hôtes
possédant
en
commun
un
critère
relatif
à
une
donnée
statistique;
Projet DEA Réseaux de Telecom – 1998
12 / 85
Le Protocole SNMPv3
Les matrices de trafic qui contiennent des données relatives
aux communications entre groupes d’adresses;
Les filtres;
Les paquets de contrôle envoyés aux stations de gestion;
Les événements générés par les agents.
RMON définit des variables relatives au contrôle du trafic sur réseaux
Ethernet, Token Ring, FDDI et X25.
Projet DEA Réseaux de Telecom – 1998
13 / 85
Le Protocole SNMPv3
IV-Le protocole SNMP
Le protocole SNMP décrit le langage que les agents et les stations de gestion
(managers) utilisent
pour se communiquer. C’est
un protocole de type
question/réponse asynchrone.
Les
stations
de
gestion
interrogent
les
agents
pour
observer
leur
fonctionnement et leur envoient des commandes pour les faire exécuter
certaines taches. Les agents renvoient les informations requises aux stations
de
gestion.
Certains
événements
transmission,
peuvent
déclencher
du
réseau,
tels
que
des
erreurs
de
des
alarmes
envoyées
aux
stations
de
gestion. Cependant, l’envoi de messages de façon spontanée de l’agent vers
le manager est limité. Les managers effectuent une interrogation périodique
des agents de manière à vérifier leur état.
IV.1-Buts de cette architecture
SNMP explicitement minimise le nombre et la complexité des fonctions de
gestion à réaliser par l’agent. Ce but implique les 4 points suivant:
La réduction du prix du développement du programme de
l’agent.
L’augmentation du nombre de fonctions de gestion à gérer à
distance,
permettant
ainsi
l’usage
de
l’Internet
dans
les
fonctions de gestions.
L’évolution des fonctions de gestion a permis la réduction
même l’élimination des restrictions sur les équipements à
gérer.
La
simplification,
des
modules
de
traitement,
permet
aux
programmeurs une simplicité dans l’écriture de leur code.
Projet DEA Réseaux de Telecom – 1998
14 / 85
Le Protocole SNMPv3
Un autre but de ce protocole, c’est la possibilité d’ajout ou l’extension de
module
de
contrôle
ou
de
surveillance,
même
de
nouveaux
modules
d’opération et de gestion.
Un troisième but de cette architecture, c’est quelle soit la plus possible
indépendante
de
l’architecture
et
du
fonctionnement
d’un
équipement
particulier.
IV.2-Les relations administratives
L’architecture de SNMP permet de créer des relations administratives entre
les entités qui participe dans le protocole. Les entités qui se trouvent dans les
stations de gestion et les éléments du réseau qui se communiquent entre eux à
travers SNMP sont les entités d’applications.
Un agent SNMP avec un nombre quelconque d’entités d’applications est
nommé une communauté SNMP. Chaque communauté est identifiée par une
chaîne de caractères.
Un message SNMP générer par une entité d’application SNMP qui appartient
à une communauté identifiée par les composants de la communauté est un
message SNMP
authentique.
Les
lois
qui
identifie un
message
SNMP
appartenant à une communauté s’appelle le schéma d’authentification. Une
implémentation
authentifié,
d’une
par
une
fonction
ou
qui
plusieurs
permet
l’identification
lois,
est
appelée
de
message
un
service
d’authentification.
Un couple de communauté SNMP avec un profil de communauté est appelé
une police d’accès SNMP. La police d’accès représente le profil d’échange
supporté par l’agent d’une communauté SNMP avec les autres membres de la
même communauté.
Toutes les relations administratives entre les entités d’applications SNMP
sont définit en fonctions des polices d’accès SNMP.
Pour chaque police d’accès, si l’élément du réseau ayant un agent ne
supportant pas la même forme de MIB de la communauté spécifié, alors la
police d’accès est dite une police d’accès SNMP proxy.
Projet DEA Réseaux de Telecom – 1998
15 / 85
Le Protocole SNMPv3
Un agent SNMP associé à une police d’accès proxy est dit agent proxy.
Les avantages d’un agent proxy sont:
Permet le contrôle et la surveillance des éléments du réseau
qui ne sont pas adressante en utilisant les protocoles de
gestion et de transport, d’où un agent proxy a une fonction de
conversion et d’adaptation protocolaire, permettant ainsi à une
station de gestion de contrôlé n’importe quel élément du
réseau,
même
les
équipements
comme
les
modems,
multiplexeurs et d’autres équipements qui supporte d’autres
cadres de gestions.
Offre
un
écran
pour
les
éléments
du
réseau
contre
les
élaborations des polices de contrôle d’accès.
Par
exemple,
sophistiquer,
un
agent
permettant
proxy
l’accès
peut
aux
implémenter
variables
des
d’une
contrôles
MIB
à
d’accès
différentes
stations de gestion, sans pourtant augmenter la complexité des éléments du
réseau.
IV.3-Résolution de l’ambiguïté dans les MIB
Comme les opérations d’SNMP sont conceptuellement limiter aux objets
d’un élément du réseau, et comme toutes les références aux objets d’une MIB
sont identifiés par des noms de variables uniques, alors c’est impossible
qu’un appel à une variable définie dans la MIB puisse conclure en une
réponse de plusieurs instances du même type.
IV.4-Spécification du protocole
Le protocole de gestion du réseau est un protocole d’application permettant
de lire ou de changer (mettre à jour) les valeurs des variables d’une MIB d’un
agent. La communication entre les entités du protocole se fait par des
messages, qui sont représenter entièrement et indépendamment par un seul
paquet UDP (User Datagram Protocol) utilisant le codage de l’ASN.1
Un message est formé d’un identificateur de version, un nom de communauté
et d’un Protocole Data Unit PDU.
Projet DEA Réseaux de Telecom – 1998
16 / 85
Le Protocole SNMPv3
Paquet SNMP
Version SNMP
Communauté
PDU
La version la plus utilisée est la version 1. Plusieurs versions 2 ont été
proposées par des
documents
de travail, mais
malheureusement, aucune
d’entre elles n’a jamais été adoptée comme standard. On place la valeur 0
dans le champ version pour SNMPv1, et la valeur 3 pour SNMPv3.
La communauté permet de créer des domaines d’administration. Par défaut,
la communauté est « PUBLIC ».
PDU
Variable Binding List
PDU
Type
Request
ID
PDU Type
Error
Status
: Type
Error
Index
de
PDU,
Object
Name
ceci
Object
Name
Value
peut
être
un
Value
GetRequest,
GetResponse,…
Type de PDU
Nom
0
GetRequest
1
GetNextRequest
2
SetRequest
3
GetResponse
4
Trap
Les types de PDU SNMP
Request ID
: Identificateur de requête, permet de correspondre une
requête avec une réponse.
Error Status
: Type d’erreur, il est utilisé par les réponses à des
requêtes. (Peut indiquer une valeur non existante, un
accès interdit, un paquet trop long,…)
Projet DEA Réseaux de Telecom – 1998
17 / 85
Le Protocole SNMPv3
Error Index
: Position de l’erreur, s’il y a une erreur, ce champ
indique quelle variable a causé l’erreur.
Variable Binding List: Liste des variables, cette liste de variables est
composée d’identificateurs et de valeurs.
Object Name
: Identificateur, c’est une suite de nombres comme décrit
dans la MIB.
: Valeur, peut être de n’importe quel type. Et correspond
Value
à
la
valeur
de
la
variable
tel
que
décrit
par
l’identificateur.
IV.5-Procédures de traitements
La génération d’un message SNMP suit les actions suivantes:
La construction de la PDU. Ex: GetRequest PDU en objet
ASN.1
Passage
de
cette
PDU
en
ASN.1,
avec
le
nom
de
la
communauté, et l’adresse de transport source et destination,
adresse de transport signifie dans le cas de UDP l’adresse IP
en question et le numéro de port de UDP. Dans le cas d’un
protocole de
transport
autre
qu’UDP,
il
faut
définir
une
adresse de transport en accord. Le passage est au service qui
implémentera le schéma d’authentification désirer. Ce service
d’authentification retourne un autre paquet en ASN.1
L’entité protocolaire construit un autre objet en ASN.1 en
utilisant le nom de communauté et l’objet ASN.1 résultant du
processus avant.
Finalement, le paquet est codé en utilisant le codage de base
de ASN.1 avant d’être renvoyé vers le service de transport.
Projet DEA Réseaux de Telecom – 1998
18 / 85
Le Protocole SNMPv3
De même, les actions nécessaires à la réception d’un message SNMP:
Le système fait une analyse du paquet reçu en utilisant le
décodage d’ASN.1. Si l’analyse échoue alors le paquet est
rejeté et le système revient à l’état d’attente.
Puis il vérifie la version du message. Si la version n’est pas la
même, il rejette le paquet et, le système s’arrête.
L’entité protocolaire passe le nom de communauté et le paquet
de donnée trouvé dans le message ASN.1 avant, avec les
adresses de transport source et destination, au service qui
implémente le schéma d’authentification désiré. Cette entité
retourne
un
autre
objet
ASN.1
ou
signale
une
fausse
authentification.
Dans le cas d’une fausse authentification, le protocole note
cette erreur, génère un message TrapPDU (probablement) et
rejette le paquet et s’arrête.
Le protocole fait une analyse de l’objet ASN.1 retrouvé par le
schéma d’authentification pour en tirer un objet ASN.1 qui
correspond à un PDU en ASN.1. Si l’analyse échoue, il rejette
le paquet et s’arrête.
Autrement, en utilisant le nom de la communauté, il retrouve le profil,
et par suite le PDU est exécuté.
Si comme résultat de l’exécution, une réponse doit être retourner, alors
l’adresse de la source de transport doit être identique à l’adresse destination
du paquet original, et le Request ID doit être le même.
IV.6-Les types de PDU
IV.6.1-GetRequestPDU
Ce message est généré par le protocole pour la recherche d’une entité
d’application SNMP.
Projet DEA Réseaux de Telecom – 1998
19 / 85
Le Protocole SNMPv3
IV.6.2-GetNextRequestPDU
Ce message est généré par le protocole pour la recherche d’une entité
d’application
SNMP.
Normalement
ce
message
est
précédé
par
un
GetRequestPDU. Ainsi, à la réception du message GetNextRequestPDU le
protocole recherche dans la table des objets de la MIB dans l’ordre
lexicographique des noms des objets, l’objet successeur de celui donnée dans
le message.
IV.6.3-Exemple:
Soit la table de routage suivante:
La
station
Destination
NextHop
Metric
10.0.0.99
89.1.1.42
5
9.1.2.3
99.0.0.3
3
10.0.0.51
89.1.1.42
5
de
gestion
GETNextRequestPDU,
envois
contenant
vers
comme
l’agent
valeur
des
SNMP
un
identificateur
message
d’objets
les noms des variable:
GetNextRequest (ipRouteDest, ipRouteNextHop, ipRouteMetric1)
La réponse de l’agent:
GetResponse ( (ipRouteDest.9.1.2.3
(ipRouteNextHop.9.1.2.3
(ipRouteMetric1.9.1.2.3
= “9.1.2.3”),
= “99.0.0.3”),
= 3))
La station de gestion continue avec:
GetNextRequest (
ipRouteDest.9.1.2.3,
ipRouteNextHop.9.1.2.3,
ipRouteMetric1.9.1.2.3)
L’agent répond par:
GetResponse ( (ipRouteDest.10.0.0.51
= “10.0.0.51”),
(ipRouteNextHop. 10.0.0.51 = “89.1.1.42”),
(ipRouteMetric1. 10.0.0.51 = 5))
La station de gestion continue avec:
Projet DEA Réseaux de Telecom – 1998
20 / 85
Le Protocole SNMPv3
GetNextRequest (
Projet DEA Réseaux de Telecom – 1998
ipRouteDest. 10.0.0.51,
ipRouteNextHop. 10.0.0.51,
ipRouteMetric1. 10.0.0.51)
21 / 85
Le Protocole SNMPv3
L’agent répond par:
GetResponse ( (ipRouteDest.10.0.0.99
= “10.0.0.99”),
(ipRouteNextHop. 10.0.0.99 = “89.1.1.42”),
(ipRouteMetric1. 10.0.0.99 = 5))
La station de gestion continue avec:
GetNextRequest (
ipRouteDest. 10.0.0.99,
ipRouteNextHop. 10.0.0.99,
ipRouteMetric1. 10.0.0.99)
L’agent répond par:
GetResponse ( (ipRouteDest.9.1.2.3
(ipRouteNextHop.9.1.2.3
(ipRouteMetric1.9.1.2.3
= “9.1.2.3”),
= “99.0.0.3”),
= 3))
L’agent ayant répondue par ce message, la station de gestion reconnut la fin
de la table de routage.
IV.6.4-GetResponsePDU
Ce message est généré par le protocole seulement après avoir reçu un
message
GetRequestPDU,
GetNextRequestPDU
ou
SetRequestPDU.
Ce
message peut contenir parfois des identificateurs d’erreurs, le tableau suivant
liste ces erreurs.
Valeur
Réponses
Description
0
No Error
Pas d’erreur
1
Too Big
Erreur de longueur
2
No Such Name
Objet non crée
3
Bad Value
Valeur erronée
4
Read Only
Pas de permission d’écrire
5
Gen err
Erreur d’autorisation
Les types de réponses d’erreurs de SNMP
Projet DEA Réseaux de Telecom – 1998
22 / 85
Le Protocole SNMPv3
IV.6.5-SetRequestPDU
Ce message est utilisé pour changer ou mettre à jour la valeur d’une variable
de la MIB.
IV.6.6-TrapPDU
Ce message est une notification d’un événement qui se passe dans l’agent.
Suite les messages Trap supportés par le protocole SNMP.
Valeur
Description
0
Cold Start
1
Warm Start
2
Link Down
3
Link Up
4
Authentification Failure
5
Egp Neighbor Loss
6
Enterprisespecific
Type des messages Trap.
Interprétations des messages Trap:
ColdStart Trap (0)
Un message ColdStart signifie que l’entité protocolaire se réinitialize,
ce qui peut changer la configuration actuelle de l’agent ou, les
paramètres de l’entité protocolaire.
WarmStart Trap (1)
Ce message
signifie
que
l’entité protocolaire
se
réinitialize,
sans
changer la configuration de l’agent et les paramètres de l’entité
protocolaire.
LinkDown Trap (2)
Ce message indique la coupure d’une liaison de communication de
l’agent avec la station de gestion. Le message LinkDown contient le
nom et l’index de la liaison affectée.
Projet DEA Réseaux de Telecom – 1998
23 / 85
Le Protocole SNMPv3
LinkUp Trap (3)
Ce message indique la connexion d’une liaison de communication.
L’index et le nom de cette liaison comme enregistrés dans l’agent
seront renvoyer dans ce message LinkUp Trap.
AuthentificationFailure Trap (4)
Ce message est émis quand l’entité protocolaire est adressée par un
message non authentifié.
Il est à noter qu’en cours d’installation du protocole SNMP la
génération de ce message doit être paramétrable, pour pouvoir générer
ou non ce message.
EGPNeighborLoss Trap (5)
Ce message signifie qu’un EGP voisin observé par l’entité protocolaire
(de renvoie) est marqué perdue et que l’observation de ce dernier est
arrêtée.
EnterpriseSpecific Trap (6)
Ce message indique la présence d’un événement spécifique pour le
constructeur.
Le
message
renvoyé
contient
dans
le
champ
"SpecificTrap" l’identificateur de l’événement en cours.
Projet DEA Réseaux de Telecom – 1998
24 / 85
Le Protocole SNMPv3
V-Le protocole SNMPv2
Comme la première version de SNMP ne comporte pas de sécurité, L’IETF a
voulu faire la mise à jour de cette version en travaillant sur SNMPv2.
V.1-L’évolution de SNMPv2
Les efforts pour définir un standard acceptable pour la sécurité, les études de
la plate-forme de gestion et les configurations à distance ont poussé l’IETF à
arrêter en septembre 1995, quand ils n’ont pas pu arriver à un accord sur ces
aspects. Depuis l’IETF a:
Abandonner les efforts d’accords sur la sécurité, les plateforme de gestions et les configurations à distance.
Publié des mises à jour pour une partie des spécifications de
SNMPv2 (Les RFC 1902 à 1908) qui sont devenues des
brouillons du standard.
Traduire les études antérieures de sécurité basé sur les groupes
(User-Based
Security),
les
plate-formes
de
gestion
et
les
configurations à distance. (Les RFC 1445 à 1447)
Publié une spécification expérimentale d’une plate-forme de
gestion transitoire appelée SNMPv2c(RFC 1901), cette étude
est basée sur SNMPv1 et par suite ne contient pas de sécurité.
SNMPv2* est une extension de SNMPv1 et SNMPv2c, introduisant des
nouvelles études de la plate-forme de gestion, sur le niveau authentification,
autorisation, contrôle d’accès et personnalisation, en plus des études pour la
configuration des objets de la MIB à distance.
De même SNMPv2* supporte une coexistence et une transition
douce
nécessaires pour la conservation des investissements des clients ayant installé
des stations de gestion SNMP.
Projet DEA Réseaux de Telecom – 1998
25 / 85
Le Protocole SNMPv3
Puis l’IETF a publié des nouvelles spécifications sur le plan de la sécurité
appelée SNMPv2U (les RFC 1909 et RFC 19010).
V.2-Transport de SNMPv2
Le protocole SNMPv2 comme SNMPv1 ne nécessite qu’un protocole de
transport de paquet non sûre, chaque message est envoyé totalement et
indépendamment dans un seul paquet. Ce protocole peut être transmis par
n’importe quel protocole de transport, mais le plus utilisé (Préféré) est UDP
(User Datagram Protocol).
V.3-Taille des messages SNMPv2
La taille maximale d’un message SNMPv2 est limitée par le minimum de:
La taille maximale d’un message SNMPv2 qui peut être
accepté par le système destination ou la station de gestion.
La taille maximale d’un message SNMPv2 qui peut être
généré par la source ou l’agent.
Il
faut
noter
que
les
messages
de
grandes
tailles
ne
sont
pas
trop
recommandées même si ces messages sont adaptés à l’agent et à la station de
gestion. Ces messages peuvent être plus grands que la taille des tampons des
nœuds de transfert des MTU (Message Transfer Unit) le long du chemin de
parcourt dans le réseau. Dans ce cas les messages seront fragmentés. La
fragmentation est considérée comme nuisible et, diminue la sûreté et de la
validité de message transmis.
V.4-Les requêtes SNMPv2
En plus des messages SNMPv1: GetRequest, GetNextRequest, Response et
SetRequest. SNMPv2 introduit d’autres types de messages: GetBulkRequest,
InformRequest, SNMPv2Trap et Report.
V.4.1-GetBulkRequest PDU:
Le but de ce message est le transport d’une large quantité de donnée, de
même c’est une méthode efficace et rapide de recherche des grandes tables.
Projet DEA Réseaux de Telecom – 1998
26 / 85
Le Protocole SNMPv3
L’agent répond à ce message par un message Response contenant les valeurs
des variables demandés par le message GetBulkRequest.
La suite montre deux exemples, le premier sans utiliser le message GetBulk,
et le second l’utilisant, permettant un transfert plus rapide.
V.4.2-Exemple 1:
Soit la table de routage suivante:
La
Numéro d’interface
Adresse réseau
Adresse physique
Type
1
10.0.0.51
00:00:10:01:23:45
statique
1
9.2.3.4
00:00:10:54:32:10
dynamique
2
10.0.0.15
00:00:10:98:76:54
dynamique
station
de
gestion
envois
vers
l’agent
SNMP
un
message
GETNextRequestPDU, contenant comme valeur des identificateurs d’objets
les noms des variables:
GetNextRequest (
SysUpTime,
ipNetToMediaPhysAddress,
ipNetToMediaType)
La réponse de l’agent:
GetResponse ( (SysUpTime.0
= “123456”),
(ipNetToMediaPhysAddress.1.9.2.3.4= “000010543210”),
(ipNetToMediaType.1.9.2.3.4 = «dynamique»))
La station de gestion continue avec:
GetNextRequest (
SysUpTime,
ipNetToMediaPhysAddress.1.9.2.3.4,
ipNetToMediaType.1.9.2.3.4)
L’agent répond par:
GetResponse ( (SysUpTime.0 = “123461”),
(ipNetToMediaPhysAddress.1.10.0.0.51= “000010012345”),
(ipNetToMediaType.1.10.0.0.51= “statique”))
La station de gestion continue avec:
GetNextRequest (
Projet DEA Réseaux de Telecom – 1998
SysUpTime,
ipNetToMediaPhysAddress.1.10.0.0.51,
ipNetToMediaType.1.10.0.0.51)
27 / 85
Le Protocole SNMPv3
L’agent répond par:
GetResponse ( (SysUpTime.0= “123466”),
(ipNetToMediaPhysAddress.2.10.0.0.15= “000010987654”),
(ipNetToMediaType.2.10.0.0.15= “dynamique”))
La station de gestion continue avec:
GetNextRequest (
SysUpTime,
ipNetToMediaPhysAddress.2.10.0.0.15,
ipNetToMediaType.2.10.0.0.15)
L’agent répond par:
GetResponse ( (SysUpTime.0= “123471”),
(ipNetToMediaPhysAddress.1.9.2.3.4= “9.2.3.4”),
(ipRoutimgDiscards.0=“2”))
L’agent ayant répondue par ce message, la station de gestion reconnut la fin
de la table de routage.
V.4.3-Exemple 2:
Cet
exemple
montre
l’usage
du
message
GetBulkRequest
comme
une
alternative du message GetNextRequest. La même traversée de la table de
l’exemple 1 sera exécuter en un moins de message d’échange.
La
station
de
gestion
commence
la
communication
par
un
message
GetBulkRequest:
GetBulkRequest
[non-repeaters=1,max-repetitions=2]
(SysUpTime,
ipNetToMediaPhysAddress,
ipNetToMediaType)
La réponse de l’agent:
Response (
(SysUpTime.0= “123456”),
(ipNetToMediaPhysAddress.1.9.2.3.4= “000010543210”),
(ipNetToMediaType.1.9.2.3.4 = «dynamique»)
(ipNetToMediaPhysAddress.1.10.0.0.51= “000010012345”),
(ipNetToMediaType.1.10.0.0.51= “statique”))
Projet DEA Réseaux de Telecom – 1998
28 / 85
Le Protocole SNMPv3
La station de gestion continue avec:
GetBulkRequest
[non-repeaters=1,max-repetitions=2]
(SysUpTime,
ipNetToMediaPhysAddress,
ipNetToMediaType)
L’agent répond par:
Response (
(SysUpTime.0= “123466”),
(ipNetToMediaPhysAddress.2.10.0.0.15= “000010987654”),
(ipNetToMediaType.2.10.0.0.15= “dynamique”))
(ipNetToMediaPhysAddress.1.9.2.3.4= “9.2.3.4”),
(ipRoutimgDiscards.0=“2”))
Ce message signale à la station de gestion la fin de traversée de la table.
Dans cet exemple on remarque bien la réduction du nombre de message
échanger entre les deux unités protocolaires.
V.5-Les messages d’erreurs en SNMPv2
En réponse à un message GetRequest, GetNextRequest ou GetBulkRequest
l’entité protocolaire répond en cas d’erreur l’un des identificateurs suivants,
dans le champs error-status:
NoError (0)
WrongValue (10)
TooBig (1)
NoCreation (11)
NoSuchName (2)
InconsistentValue (12)
BadValue (3)
ResourceUnavailbale (13)
ReadOnly (4)
CommitFailed (14)
GenErr (5)
UndoFailed (15)
NoAccess (6)
AuthorizationError (16)
WrongType (7)
NotWritable (17)
WrongLength (8)
InconsistentName (18)
WrongEncoding (9)
NoError
:
Projet DEA Réseaux de Telecom – 1998
Indique la présence d’aucune erreur.
29 / 85
Le Protocole SNMPv3
NoAccess
: Cet identificateur indique que la variable en question
n’est pas dans la MIB en cours.
WrongEncoding: Erreur générée par le décodeur ASN en cas d’échec.
WrongValue
: L’unité protocolaire génère cet identificateur quand elle
ne peut dans aucune circonstance affectée à la variable,
la valeur demandé par le message SetRequest.
NoCreation
: Indique l’impossibilité de création d’une variable non
existante et ne peut être jamais crée.
InconsistantValue: L’affectation d’une valeur à la variable ne peut pas
être faite à l’état actuel.
L’allocation
ResourceUnavailable:
l’affectation
d’une
d’une
valeur
ressource
à
une
nécessaire
variable
n’est
à
pas
possible à présent.
CommitFailed: Cet
indicateur
d’affectation
d’erreur
d’une
est
liste
renvoyé,
de
variable,
si
en
une
cours
variable
échoue à être affecter. Alors, toutes les affectations déjà
faites par ce message seront supprimées (Retour aux
anciennes valeurs).
NotWritable
: La variable existe mais sa valeur ne peut pas être
changer.
InconsistantName: Indique l’impossibilité de création d’une variable dans
les
circonstances
actuelles
(Peut
être
dans
d’autres
circonstances elle pourra être crée).
V.5.1-InformRequest PDU
Ce message est envoyé d’une station de gestion vers une autre station de
gestion pour lui indiquant des informations concernants les MIB des agents
contrôlés par l’application réceptrice.
V.5.2-Report PDU
Ce message n’est pas un message d’opération entre les agents et les stations
de gestion SNMPv2, mais un message de rapport d’erreur entre les entités de
Projet DEA Réseaux de Telecom – 1998
30 / 85
Le Protocole SNMPv3
SNMPv2. L’usage de ce message nécessite de l’administrateur une définition
de son usage et de sa sémantique.
V.6-Les protocoles de transport de SNMPv2
SNMPv2 est de préférence transporter par UDP, mais d’autres protocoles de
transport (Dite optionnel) peuvent être utilisés, tels que: OSI, DDP ou Apple
Talk.
V.6.1-Protocole UDP
Ce protocole est le plus utilisé pour le transport des paquets SNMP.
Un message SNMP est paquetisé dans un seul paquet UDP, de taille
minimale de 484 octets, des tailles plus larges sont recommandées.
Il est recommandé que les entités protocolaires des agents soient configurés
d’écouter le port 161 UDP, et les messages Trap seront envoyer sur le port
162 UDP.
V.6.2-Protocole OSI:
Avec ce protocole, le message est paquetisé dans un seul TSDU (Transport
Service Definition Unit) pour le mode non-connexion CLTS du service de
transport
(Connexion
Less
Transport
Service).
De
même
le
mode
CO
(Connexion Oriented) peut être aussi utiliser.
La taille minimale d’un paquet doit être de 484 octets, les tailles plus larges
sont recommandées.
V.6.3-Protocole DDP
Le message SNMP sera dans ce cas aussi paquetisé dans un seul paquet DDP.
Les paquets seront envoyer en utilisant le protocole DDP type 8. Les entités
protocolaires des agents écoutent sur le support 8 de DDP. Alors, que pour
les messages Trap in utilisent le support 9 de DDP.
V.6.4-Protocole Apple Talk
Vu le dynamisme d’adressage de ce protocole, SNMP a des problèmes à
pouvoir faire le contrôle de ces réseaux.
Projet DEA Réseaux de Telecom – 1998
31 / 85
Le Protocole SNMPv3
Les nœuds TCP/IP ont des adresses IP uniques, qui les différencient les une
des autres. Tandis qu’en Apple Talk, les adresses au niveau réseau peuvent
être changer au moment de la ré-initialisation des systèmes.
Alors, des systèmes comme NBP doivent être utilisé de façon à unifier
chaque nœud du réseau Apple Talk. Mais ce système doit être bien installé et
configuré de façon à ne pas surcharger le réseau et réduire la puissance utile
du CPU.
V.6.5-Protocole IPX
Le
message
SNMP
est
paquetisé
dans
un
seul
paquet
IPX,
l’entité
protocolaire doit être capable d’accepter 546 octets, les messages de largeur
supérieurs sont recommandés.
Les messages sont envoyés en utilisant le type 4 de IPX. Il est recommandé
que les agents soient configurer d’écouter le support 36879 d’IPX (900F
hexadécimale), et les messages Trap sur le support 36880 d’IPX (9010 hex).
V.7-Coexistence entre SNMPv1 et SNMPv2
Pour pouvoir avoir une coexistence au niveau du protocole, un mécanisme
proxy (relais de transfert) doit être utilisé.
V.7.1-Conversion SNMPv2 vers SNMPv1:
Si les messages sont du type GetRequest, GetNextRequest ou
SetRequest,
alors,
ils
sont
renvoyés
par
l’agent
proxy
sans
changement.
Si les messages sont du type GetBulkRequest, l’agent proxy met
les valeurs des champs de répétitions à zéro et change la valeur du
champ
type
de
message
de
façon
à
avoir
un
message
GetNextRequest.
V.7.2-Conversion SNMPv1 vers SNMPv2
Si le message est GetResponse il sera retransmis intact, même si
les types
d’erreur “NoSuchName”, “BadValue” ou “ReadOnly”
n’existe pas dans SNMPv2, l’agent doit les laisser pour que la
station de gestion puisse bien interpréter la réponse.
Projet DEA Réseaux de Telecom – 1998
32 / 85
Le Protocole SNMPv3
Les messages Trap doivent être adapté par l’agent proxy de
manière à être conforme au TrapSNMPv2 (Ajouter les variables:
SystemUpTime,…)
V.7.3-Transparence de la station de gestion
Sur la station de gestion ont peut installer les deux versions du protocole
SNMPv1 et SNMPv2. Et quand une application de gestion veut contacter un
agent, l’entité protocolaire recherche dans une base de donnée pour retrouver
la bonne entité protocolaire à utiliser. De même pour avoir une transparence
vis à vis des applications de gestion, l’entité de gestion doit traiter les
opérations comme si elle était un agent proxy.
Projet DEA Réseaux de Telecom – 1998
33 / 85
Le Protocole SNMPv3
VI-Le protocole SNMPv3
Le but du développement de SNMPv3, c’est de réaliser un protocole ayant
une architecture modulaire et évolutive, permettant l’évolution du protocole
SNMP avec le temps, et une gestion plus effective et sécurisée d’une variété
d’environnements et de configurations.
VI.1-Les objectifs de cette architecture:
L’utilisation du matériel existant. Se baser sur les études des
versions SNMPv2u et SNMPv2*.
Répondre aux besoins de la sécurisation des commandes de
mise à jour des agents (Commande SET), qui était un point
inefficace des versions SNMPv1 et SNMPv2c.
Définir une architecture qui permet une longévité des travaux
qui ont été déjà faites ou qui vont être faites.
Laisser SNMP le plus simple possible.
Réduire au plus le prix d’une implémentation minime et
conforme.
Pouvoir évoluer une partie de SNMP, sans avoir à renouveler
toute l’architecture.
Le support des fonctions nécessaires dans les larges réseaux,
avec des prix de support de ces fonctions directement liés aux
supports de ces fonctions.
VI.2-Les exigences de sécurisations
Les principaux menaces ou dangers pour lesquelles n’importe quel modèle de
sécurité utiliser dans cette architecture, doit protéger contre sont:
Projet DEA Réseaux de Telecom – 1998
34 / 85
Le Protocole SNMPv3
Modification des informations:
Le danger de modification est,
qu’une entité SNMP non authentifié change dans les messages
SNMP,
perturbant
les
valeurs
des
objets
en
effectuant
des
opérations de gestion non autorisé.
Mascarade: La menace de mascarade vient du danger qu’une
station de gestion non autorisée pour des opérations de gestion,
tente de généré ces opérations en prétendant l’identité d’une autre
station autorisée.
Modification du flux des messages: Le protocole SNMP se base
typiquement sur un protocole de transport non connecté travaillant
au-dessus de n’importe quel type de sous réseau de service. Le
délai, la répétition ou la ré-ordonnance des messages, sont des
événements qui peuvent exister et, existent parfois pendant le
fonctionnement
normal
de
quels
quelques
types
de
ces
sous
réseaux. La menace de ces modifications est que les messages
soient ré-ordonner, répéter ou retarder à une limite supérieure à la
limite qui existe normalement dans le réseau, par des stations de
gestion non autorisée.
Révélation: La menace de la révélation est le danger d’espionnage
sur les échanges entre les moteurs SNMP. La sécurisation contre
ces menaces peut être considérer comme une politique locale.
Il y a d’autres menaces pour lesquelles le modèle de sécurité ne doit pas offrir
une protection, dont:
Analyse du trafic: Le modèle de sécurité n’a pas besoin de
protéger
contre
les
menaces
des
demandes,
d’une
station
de
gestion non autorisée, pour des informations de trafics.
Refus de service: Le modèle de sécurité n’a pas besoin de sécurisé
toutes sortes d’attaque possible, à moins qu’ils ne soient pas
refuser par un utilisateur autorisé. En faite, ces modèles d’attaque
ne peuvent être identifiés des échoues ou pertes des réseaux de
services.
Projet DEA Réseaux de Telecom – 1998
35 / 85
Le Protocole SNMPv3
VI.3-Les documentations de SNMPv3
Vu la modularité de SNMPv3, des documents doivent expliquer chaque
module à part. Ce document doit contenir toutes les informations reliées à ce
module (les éléments des procédures, les objets MIB,…). Ces informations
ne doivent, au possible, être définie dans un document ailleurs.
La figure suivante montre les documentations adaptés à cette architecture:
Document Set
Document
Roadmap
Applicability
Statement
Coexistence &
Transition
Message Handling
Transport
Mappings
Processing &
Dispatching
Security
PDU Handling
Protocol
Operations
Applications
Access Control
Information Model
Textual
Conventions
SMI
Conformance
Statements
MIBs
Standard v1
RFC1157
Standard v1
RFC1212
Historic v2
RFC14XX
Draft V2
RFC19XX
A noter:
RFC14XX représente les RFC 1442, 1443 et 1444
RFC19XX représente les RFC 1902, 1903 et 1904.
Projet DEA Réseaux de Telecom – 1998
36 / 85
Le Protocole SNMPv3
Document Roadmap:
Un ou plusieurs documents peuvent être écrits pour décrire comment prendre
ensemble les documentations spécifiques à une plate forme de travail. La
configuration des documents peut changer avec le temps, alors le « Road map
» doit être maintenu à séparément des documents du standard.
Ce document n’est pas à présent décrit. Il sera décrit ou remplacer dans le
future.
Applicability statement
Le protocole SNMP est utilisé dans une variété de réseau caractérisé par leur
grandeur, complexité et, par leur organisation, qui ont des demandes de
gestion largement variées. Des modèles spécifiques seront désignés face à
des problèmes de gestion spécifiques, tels des messages de sécurité.
Alors,
un
ou
environnements
plusieurs
appropriés
documents
pour
certains
seront
écrit
modèles
pour
SNMP,
et
décrire
les
ceux
non
appropriés.
Coexistence and Transition
L’architecture évolutive permet le remplacement des anciens modules par des
nouveaux
modules.
L’interaction
entre
les
modèles
peut
causer
une
incompatibilité, des trous de sécurité, et d’autres effets…
Le but de ce document «coexistence and transition» est de détailler les
anomalies reconnut et de décrire les recommandations et les pré-requis pour
résoudre ces interactions entre les modèles d’une architecture.
Transport mappings
SNMP peut être transmis par n’importe quel protocole de transport. Le but de
ce document c’est de décrire l’interface entre SNMP et le protocole de
transport.
Message Processing
Dans ce document Message Processing (Traitement de message) on retrouve
une description du message SNMP, identifier par le champ version, qui existe
dans la tête du message.
Projet DEA Réseaux de Telecom – 1998
37 / 85
Le Protocole SNMPv3
Un moteur SNMP, peut contenir un ou plusieurs modèle de traitement de
message, et par suite devenir capable de recevoir et transmettre des messages
de plusieurs version SNMP.
Security
La sécurité est appliquée normalement à deux niveaux différents:
Au niveau de la transmission ou réception du message.
Au niveau d’analyse du contenu du message.
La sécurité au niveau protocole sera décrite dans les documents «Access
Control», tandis que la sécurité au niveau message sera décrite sous le
document «Security».
L’authentification, le codage et l’alignement temporelle sont des fonctions du
niveau analyse.
Les documents de sécurité décrivent un modèle de sécurité, les menaces qu’il
protège, les buts du modèle de sécurité, les protocoles qu’il utilise pour
aboutir à ses buts, et définir une vue de la MIB pour décrire les données dont
il a besoin en cour de traitement, et de permettre la configuration à distance
des paramètres de sécurité, comme les mots de passe.
Plusieurs modèles de sécurité peuvent être supportés en même temps par un
même moteur SNMP.
Access Control
Ce document définit les procédures des permissions d’accès à un objet
contrôlé. Un modèle de contrôle d’accès est défini par une MIB, utilisée
pendant l’analyse, et permet la configuration à distance des polices de
contrôle d’accès.
Protocol Operations
Les messages SNMP contiennent un PDU (Protocol Data Unit). Ce document
définit les opérations pour le traitement de ses PDU.
Projet DEA Réseaux de Telecom – 1998
38 / 85
Le Protocole SNMPv3
Applications
Une entité SNMP contient plusieurs applications. Les applications utilisent
les moteurs SNMP pour accomplir leurs travaux, et utilisent les messages
SNMP pour communiquer avec d’autres entités.
Le document d’une application décrit le but de l’application, les services
nécessaires du moteur SNMP, ainsi que les opérations du protocole que
l’application utilise pour exécuter ces opérations de gestion.
Structure of Management Information SMI
SMI
définit
comment
chaque
élément
d’information
concernant
les
périphériques gérés et les agents est représenté dans la base d’information
virtuelle, qui est la MIB.
Dans ce document on retrouve les syntaxes pour définir les objets, modules,
et d’autres éléments des informations de gestion.
Textual Conventions
Ce document contient des nouveaux types de variables, similaire à ceux qui
existent dans la SMI mais avec une sémantique plus précise ou une
sémantique approprié à eux.
Conformance Statements
Dans ce document, seront définit les limites minimales d’une implémentation
en accord avec les niveaux d’acquisition actuels.
Management Information Base Modules - MIB
Un document MIB définit une collection d’objet décrivant le nœud à
contrôler. De même, on retrouve des descriptions de l’architecture de SNMP,
comme les documents des modèles de traitement des messages, de la
sécurité,…Et ceci pour l’instrumentation de ces modèles.
VI.4-Description du paquet SNMP
Le format du paquet de SNMPv3est différent du format de SNMPv1, ils sont
toutefois
codés
tous
deux
Projet DEA Réseaux de Telecom – 1998
dans
le
format
ASN.1,
assurant
ainsi
une
39 / 85
Le Protocole SNMPv3
compatibilité des types de données entres les ordinateurs d’architectures
différentes.
La figure suivante montre un paquet SNMPv3:
SNMPv3 Message
Version
SNMP
Header Data
MsgID
Max Size Flags
Security
Parameters
(Model Specific)
Security Model
Scoped PDU Data
Context
EngineID
Context
Name
PDU Data
Description du paquet SNMPv3
Version SNMP: Utilisé pour l’envoyé le paquet vers le bon
module de décodage. Pour SNMPv3 on place 3, et pour
SNMPv1 on place 0.
MsgID: Identificateur de message, utilisé pour repérer les
requêtes et les réponses.
Max Size: Taille maximale du paquet réponse, ce champ
indique à la station génératrice de la réponse de ne pas
dépasser cette taille qui est limité par les capacités des
mémoires tampons du moteur générateur de la requête.
Flags: Drapeaux, indiquant si une réponse est attendue et si un
modèle de sécurité a été utilisé.
0 0 0 0 0 1 1 1
Reportable Flag
Privacy Flag
Authentification Flag
1. Reportable Flag: indique si une réponse est attendue à
la réception de ce flag
2. Privacy Flag: indique si une encryption a été utilisé.
3. Authentification
Flag:
indique
si
un
modèle
d’authentification a été utilisé.
Projet DEA Réseaux de Telecom – 1998
40 / 85
Le Protocole SNMPv3
Security Model: ce champ identifie le modèle de sécurité
utilisé, pour envoyer le paquet vers le bon module de sécurité.
Security Parameters: Informations de sécurité, comme les clés
publiques, les arrangements entre protocoles de sécurité,…
Ce champ n’est pas décrit dans le standard SNMPv3, il est laissé
au soin des modules de sécurité. Le module de sécurité DES a
standardisé le contenu de ce champ.
Context EngineID et Context Name: Identifie le context, une
carte interface, un routeur,…
Ce champ permet d’avoir plusieurs fois les mêmes variables. Par
exemple, un commutateur ATM contient plusieurs cartes qui
peuvent avoir chacune leurs propres bases d’informations. Le
context permet de distinguer entre plusieurs bases d’informations
et même plusieurs agents.
PDU Data: Charge payante, les valeurs demandées ou les
réponses à des demandes.
PDU
PDU
Type
Variable Binding List
Request ID
Error Status
Error Index
Object Name Value
Object Name Value
Description du PDU
VI.5-Description d’une entité SNMPv3
Une entité SNMP consiste d’un moteur SNMP et d’une ou plusieurs
applications.
Projet DEA Réseaux de Telecom – 1998
41 / 85
Le Protocole SNMPv3
SNMP Entity
SNMP Engine
Message
Processing
Subsystem
Dispatcher
Security
Subsystem
Access
Control
Subsystem
Applications
Command
Generator
Notification
Receiver
Proxy
Forwarder
Command
Responder
Notification
Originator
Other
VI.5.1-Moteur SNMP
Le moteur SNMP, c’est le centre du système, il offre les services pour
émettre
et
recevoir
les
messages,
l’authentification
et
l’encription
des
messages, de même que le contrôle d’accès aux objets à contrôler.
Le moteur contient:
Distributeur des travaux (Dispatcher)
Traitement des messages
Système de sécurité
Système de contrôle d’accès.
Distributeur
Il y a un seul distributeur dans un moteur SNMP. Il permet le support de
plusieurs version SNMP en même temps. Son rôle est:
Emettre et recevoir des messages du et vers le réseau.
Déterminer la version SNMP d’un message, pour passer le
message
à
la
procédure
de
traitement
de
message
correspondante.
Projet DEA Réseaux de Telecom – 1998
42 / 85
Le Protocole SNMPv3
Offrir une interface abstraite pour les applications, pour la
livraison d’un PDU à une application.
Offrir
une
interface
abstraite
pour
les
applications
qui
permettent la transmission de PDU vers une entité SNMP
distante.
Traitement des messages
Le rôle de la procédure de traitement des messages c’est de préparer les
messages à émettre, et d’extraire les informations d’un message reçu. Une
procédure de traitement des messages peut contenir plusieurs modèles de
traitement.
Système de traitement des messages
SNMPv3
Traitement
de message
SNMPv1
Traitement
de message
SNMPv2c
Traitement
de message
Autre
modèle de
Traitement
Chaque modèle de traitement des messages définit le format d’une version
SNMP particulière et, prépare et extrait de chaque message les informations
spécifiques d’une version.
Système de sécurité
Le
système
l’authentification
de
et
sécurité
la
offre
les
personnalisation
services
d’un
de
message.
sécurité,
Ce
comme
système
peut
contenir plusieurs modèle de sécurité.
Système de sécurité
User-Based
Modèle de
sécurité
Projet DEA Réseaux de Telecom – 1998
Autre
modèle de
sécurité
Autre
modèle de
sécurité
43 / 85
Le Protocole SNMPv3
Un modèle de sécurité définit les menaces contre lesquelles il offre une
protection, les buts de ses services, et les protocoles de sécurité nécessaires
pour les services sécurisés comme l’authentification et la privatisation.
Les protocoles de sécurité contiennent les procédures, les algorithmes et les
données MIB nécessaire pour les services de sécurités.
Le contrôle d’accès
Le contrôle d’accès offre les services d’autorisations, moyennant un ou
plusieurs modèles de contrôle d’accès.
Contrôle d’accès
View-Based
Modèle de
contrôle d’accès
Autre
modèle de
contrôle d’accès
Autre
modèle de
contrôle d’accès
Un modèle de contrôle d’accès définit une fonction particulière d’accès, de
façon à pouvoir faire des décisions concernant les permis d’accès.
Les applications
Les applications SNMP peuvent être regroupées en cinq types:
Des
applications
d’initiation
de
requête
Get,
GetNext,
GetBulk et/ou Set, qui sont appelées ‘Command Generator’.
Des applications qui répondent aux requêtes Get, GetNext,
GetBulk et/ou Set, sont appelées ‘Command Responder’.
Des
applications
qui
génèrent
des
notifications,
appelées
reçoivent
des
notifications,
appelées
‘Notification Originators’.
Des
applications
qui
‘Notification Receivers’.
Des applications qui transit des requêtes SNMP Get, GetNext,
GetBulk
et/ou
Set,
ou
des
notifications,
appelées
‘Proxy
Forwarder’.
Projet DEA Réseaux de Telecom – 1998
44 / 85
Le Protocole SNMPv3
A noter, qu’il n’y a aucune restriction sur l’association de ces applications
ensembles avec un moteur SNMP particulier. Par exemple, un moteur SNMP
peut être associé en même temps avec les deux applications ‘Command
Responder’ et ‘Command Generator’.
Command Generator Applications
Ces applications génèrent des requêtes SNMP Get, GetNext, GetBulk et/ou
Set, de même que le traitement de la réponse à une requête qu’il a généré.
Command Responder Applications
Ces applications reçoivent les requêtes SNMP Get, GetNext, GetBulk et/ou
Set, destinées au système local, ceci se fait en comparant le ContextEngineID
dans la requête reçue avec le contexte du moteur local. Cette application
utilise le module de contrôle d’accès et génère un message réponse à envoyer
à l’application génératrice de la requête de demande.
Notification Originator Applications
Cette application surveille le système pour des événements particuliers ou
conditions,
et
génère
des
messages
Trap
et/ou
Inform,
baser
sur
ces
conditions et ces événements. Cette application doit être capable de décider
où envoyer les messages, quelle version SNMP utilisé et les paramètres de
sécurité à utiliser pour l’envoi du message.
Notification Receiver Applications
Cette application attend les messages de notification, et génère un message
réponse à des requêtes Inform.
Proxy Forwarder Applications
Cette application transit les messages SNMP.
Le rôle de cette application est:
Le transit des requêtes SNMP vers d’autres entités, sans égard
aux types d’objets de gestion. Par exemple, le transport d’un
Projet DEA Réseaux de Telecom – 1998
45 / 85
Le Protocole SNMPv3
message
SNMP
d’un
domaine
à
un
autre,
ou
bien,
la
translation d’un message d’une version à une autre.
La translation d’une requête, dans un environnement nonSNMP, en un message formater SNMP.
Supporte l’assemblage des objets de gestion ou les valeurs
d’une instance d’objet, dépend des valeurs d’autres éléments
des informations de gestion.
Projet DEA Réseaux de Telecom – 1998
46 / 85
Le Protocole SNMPv3
VI.6-Architecture d’une station de gestion SNMPv3
La
figure
suivante
montre
l’architecture
d’une
plate
forme
de
gestion
SNMPv3, on remarque le bloc distributeur qui est au milieu du système et
gère tous les ordres de travail.
SNMP entity
NOTIFICATION
ORIGINATOR
applications
NOTIFICATION
RECEIVER
application
COMMAND
GENERATOR
application
Message Processing
Subsystem
Security
Subsystem
PDU Dispatcher
v1MP
Security
Dispatcher
Model
v3MP
Transport
Mapping
User-based
(e.g. RFC1906)
Security
otherMP
UDP
Other
Message
IPX
Model
other
Network
De même, on remarque que les différentes fonctions sont séparées permettant
un une simple évolution du protocole.
Projet DEA Réseaux de Telecom – 1998
47 / 85
Le Protocole SNMPv3
VI.7-Architecture d’un agent SNMPv3
La figure suivante montre l’architecture d’un agent SNMPv3, on remarque la
présence d’un module de contrôle d’accès
SNMP entity
MIB instrumentation
COMMAND
RESPONDER
application
NOTIFICATION
ORIGINATOR
application
ACCESS CONTROL
Message Processing
Subsystem
PROXY FORWARDER
application
Security
Subsystem
PDU Dispatcher
v1MP
Message
Dispatcher
v3MP
Transport
Mapping
(e.g. RFC1906)
otherMP
UDP
IPX
Other
Security
Model
User-based
Security
Model
other
Network
Projet DEA Réseaux de Telecom – 1998
48 / 85
Le Protocole SNMPv3
VI.8-Diagrammes de fonctionnement
Générateur de commande ou Originateur de notification
Le diagramme qui
suit, montre une requête d’envoi
d’un PDU, d’un
générateur de commande ou d’un originateur de notification, et la réception
en mode asynchrone d’un message réponse à cette requête.
Command
Generator
Dispatcher
Message
Processing
Model
Security Model
Send PDU
Préparer le
message de sortie
Générer le message
de requête
Envoyer le message
requête sur le réseau
Recevoir le message
réponse du réseau
Préparer les
éléments de donnée
Préparer les
éléments de donnée
Traiter le PDU
réponse
Projet DEA Réseaux de Telecom – 1998
49 / 85
Le Protocole SNMPv3
Application de réponse
Le diagramme qui suit, montre comment se fait le traitement d’un PDU reçu
par une application de réponse « Command Responder » ou un récepteur de
notification, et comment la réponse à ce message est renvoyé en mode
asynchrone.
On remarque bien le rôle du distributeur (Dispatcher), qui est au centre du
travail, et gère toutes les transactions entre les différents modules
de
traitement du protocole.
Command
Responder
Dispatcher
Message
Security Model
Processing Model
Enregistrer un
type de PDU
Recevoir un message
SNMP du réseau
Préparer les
éléments de donnée
Traiter le message
reçu
Traiter le PDU
Réponse PDU
Préparer le message
réponse
Générer le message
de réponse
Envoyer le message
réponse sur le réseau
Projet DEA Réseaux de Telecom – 1998
50 / 85
Le Protocole SNMPv3
VII-La sécurité dans SNMPv3
La sécurité de SNMPv3 est du type ‘User Based Security’ décrit dans
RFC2274. Le principe est l’utilisation du concept utilisateur, identifié par un
UserName, auquel sont associées les informations de sécurité.
VII.1-Les menaces
Les principales menacent contre lesquels le modèle de sécurité doit offrir une
protection sont:
Modification des informations
Mascarade
D’autres menaces secondaires doivent être prises en compte:
Révélation
Modification des flux de messages
Les deux menaces qui suivent ne doivent pas être prises en considération:
Analyse du trafic
Refus du service
VII.2-Services de sécurité
Les services nécessaires pour le support des buts de ce modèle de sécurité
dans SNMPv3, sont:
Data integrity : S’assurer que les données ne sont pas changer
ou détruit d’une manière non autorisée.
Data
origin
l’identité
authentification
qu’il
proclame,
:
S’assurer
même
si
le
que
l’émetteur
message
a
a
une
autorisation valide.
Projet DEA Réseaux de Telecom – 1998
51 / 85
Le Protocole SNMPv3
Data Confidentiality: C’est la provision de la propriété des
informations et de ne pas les passer ou révéler, à une entité ou
un individuel ou un traiteur non autorisé.
Message timeliness and limited replay protection: C’est la
provision qu’un message dont le temps de génération dépasse
une fenêtre temporelle, ne sera pas accepté. A noter que le réordonnement des messages ne sera pas pris en compte, et des
événements pareils peuvent se trouver dans des conditions
normales.
La sécurité dans SNMPv3 est découpé en trois modules:
Le module d’authentification.
Le module d’alignement temporel.
Le module de privatisation.
Le module d’alignement temporel
Le champ du temps de création, dans le message émis, est utilisé pour faire le
test de l’alignement temporel. Mais le test d’alignement temporel ne se fait
que si le message est authentifié. Après le contrôle d’authentification du
message, le champ du temps de création est considéré sûre, et par suite le test
peut se faire.
Le protocole d’authentification
Les protocoles d’authentifications supportés par le «User Based Security
Model» sont le HMAC-MD5-96 qui est un MUST, et le HMAC-SHA-96.
Le
“User
Based
Security Model”
ordonne
que
si
l’authentification
est
utilisée, alors tout le message doit être testé pour son intégrité par le module
d’authentification.
Un message authentifié doit
passé le test
d’authentification et
le
test
d’alignement temporel qui est obligatoire dans le “User Based Security
Model”.
Projet DEA Réseaux de Telecom – 1998
52 / 85
Le Protocole SNMPv3
Le protocole de personnalisation
Le protocole de
personnalisation, utilisé
dans
le
«User Based
Security
Model» est le CBC-DES (Symetric Encryption Protocol).
Le «User Based Security Model” force une protection contre les révélations
quand les messages sont envoyés avec une personnalisation. Et dans ce cas le
message doit être authentifié.
Génération d’un message SNMP sécurisé
L’algorithme qui suit, décrit la procédure suivit par un moteur SNMP pour la
génération d’un message de gestion (Request, Response, Notification ou
Report) avec un niveau de sécurité particulier.
Projet DEA Réseaux de Telecom – 1998
53 / 85
Le Protocole SNMPv3
Début
Recherche dans la base de donnée de sécurité les informations
concernant la station destination
Oui
Non
Oui
Destination supporte
l’authentification et la
personnalisation ??
Oui
Non
Non
Protection
contre la
révélation?
Non
Message à
Authentifié?
Destination
Supporte
L’authentification?
Oui
Passage au module de
personnalisation
Message
Personnalisé?
Non
Oui
Passage au module
d’authentification
Non
Erreure
Sortie
Projet DEA Réseaux de Telecom – 1998
Message
authentifié?
Oui
Fin
54 / 85
Le Protocole SNMPv3
Traitement d’un message reçu
L’algorithme suivant décrit la procédure de traitement dans le moteur SNMP,
d’un message reçu contenant des informations de gestion, en provenance
d’un utilisateur (Destination) avec un niveau de sécurité particulière
Début
Non
Oui
Paramètres de
Sécurité du message
Valide?
Incrémenter
l’identificateur
d’erreure
Extraction des
paramètres de référence
et de sécurité
Incrémenter
l’identificateur
d’erreure
Non
Oui
Autorisation
Permissible?
Extraction des
informations utilisateurs
Incrémenter
l’identificateur
d’erreure
Non
Oui
Utilsateur Reconnu aves
un niveau sécuritaire?
Passage au module
d’authentification
Incrémenter
l’identificateur
d’erreure
Non
Message
authentifié?
Oui
A
Projet DEA Réseaux de Telecom – 1998
55 / 85
Le Protocole SNMPv3
A
Extarction des paramètres
du temps
Incrémenter
l’identificateur
d’erreure
Non
Oui
Conditions temporelles
valides?
Passage au module
de personnalisation
Incrémenter
l’identificateur
d’erreure
Non
Oui
Personalisation
Valider?
Sauvegarde des données
de sécurité
Erreure
Sortie
Message valider
Retour au module initial
Les protocoles
HMAC-SHA-96
d’authentification
HMAC-MD5-96
et
Ces protocoles d’authentification sont utilisés par le “User Based Security
Model”. HMAC-MD5-96 utilise la fonction de hachage MD5 décrit par le
RFC2104 tronquer à 96 bits. HMAC-SHA-96 utilise la fonction de hachage
SHA
décrite
par
SHA-NIST
(National
Institut
of
Standards
and
Technologies) dans le RFC2104, tronquer aussi à 96 bits.
-
Pour le support de l’intégrité des données, un algorithme de message
élaborer est nécessaire. La variable d’élaboration calculé du message
Projet DEA Réseaux de Telecom – 1998
56 / 85
Le Protocole SNMPv3
SNMP, cette variable inclus dans le message SNMP est envoyé au
récepteur.
-
Pour
le
support
des
intégrités
des
données
et
les
données
d’authentifications, un mot secret est ajouté au message SNMP avant
le passage au module d’élaboration. La variable calculé est ajoutée au
message SNMP avant la transmission.
Donnée
Mot secret
MD5
Fonction de Hashage
Donnée
Hash Code
Authentification d’un message - Transmetteur
Donnée
Hash Code
Donnée
Hash Code
MD5
?
Hash Code 2
Authentification d’un message - Récepteur
La localisation des mots de passe
Une station de gestion gère une dizaines ou quelquefois des centaines
d’agents. Si chaque agent à un mot de passe, alors la station de gestion doit
connaître tous les mots de passe ce qui n’est pas raisonnable.
Projet DEA Réseaux de Telecom – 1998
57 / 85
Le Protocole SNMPv3
Ou bien, si on utilise un seul mot de passe pour tous les agents; on court le
risque si un agent est volé de dévoiler tous les messages d’administration du
même domaine.
Pour ne pas courir le risque, SNMPv3 a adopté la solution d’un seul mot de
passe avec une localisation. La localisation consiste à utiliser le mot de passe
avec le «Context EngineID» (Qui est un identificateur unique pour chaque
agent), ainsi on tire un mot de passe dit localiser et unique pour chaque agent.
Localisation d’un mot de passe
Context EngineID
Mot de Passe
MD5
Mot de passe localisé
Le protocole d’Encryption CBC-DES
Le protocole d’encryption CBC-DES (Symmetric Encryption Protocol, Data
Encryption Standard) est le premier protocole de personnalisation définie
pour le «User based Security Model».
Les données à crypter seront traitées comme une séquence d’octets. La clé est
formée de 64 bits, comme DES crypte à la fois 64 bits alors si la longueur des
données n’est pas un multiple de 64, des tampons si nécessaire seront ajoutés
à la fin.
Projet DEA Réseaux de Telecom – 1998
58 / 85
Le Protocole SNMPv3
La figure suivante montre le principe de cryptage avec DES.
Mot de passe
Données
Données
Vecteur d’init
Données
Données
Données
DES
Cipher1
Données
DES
Cipher2
Données
DES
Cipher3
Données
DES
Cipher4
Projet DEA Réseaux de Telecom – 1998
59 / 85
Le Protocole SNMPv3
Projet DEA Réseaux de Telecom – 1998
60 / 85
Le Protocole SNMPv3
VIII- Différentes configurations d’un moteur
SNMP
Un moteur SNMP peut jouer plusieurs rôles. Il peut être agent, plate-forme,
proxy… Un agent répond à des requêtes de gestion, la plate-forme fait des
requêtes et le proxy relaie les requêtes et les réponses.
Un moteur SNMP peut fonctionner dans un environnement déjà existant, et
SNMPv1
Internet
SNMPv1
Agent SNMPv1
Application
Application
de gestion
Module
Module
de traitement
de traitement
Application
de gestion
MIB
par suite contrôler les agents SNMPv1, sans avoir à les changer.
Une autre implémentation du moteur SNMP, c’est la possibilité d’une
communication entre gestionnaire et agent avec un modèle de sécurité et
d’authentification offrant une privatisation des messages échanger entre eux.
Projet DEA Réseaux de Telecom – 1998
61 / 85
Le Protocole SNMPv3
SNMPv3
Application
Application
SNMPv3
Agent SNMPv3
Application
de gestion
Internet
Module de
traitement
SNMPv3
Module
de traitement
SNMPv3
MIB
de gestion
Module
de sécurité
Sécurité
Comme il y a coexistence d’appareils SNMP de différentes versions, ou que
ces appareils n’auront pas toujours SNMPv3 avec les modules d’encryption
et d’authentification convenable, il est souvent nécessaire d’utiliser un agent
proxy pour assurer des conversations sécuritaires ou le dialogue entre des
versions différentes de SNMP.
Projet DEA Réseaux de Telecom – 1998
62 / 85
Le Protocole SNMPv3
SNMPv3
SNMP
SNMPv3
SNMPv3
Internet
Internet
Application
Agent SNMPv3
SNMPv1
Agent SNMPv1
Application
Proxy
Application
de gestion
Application
de gestion
Module de
traitement
SNMPv3
Module
de sécurité
Projet DEA Réseaux de Telecom – 1998
Module de
traitement
SNMPv3
SNMPv1
Module
de sécurité
Module de
traitement
SNMPv3
SNMPv1
MIB
63 / 85
Le Protocole SNMPv3
IX- Nouvelles architectures de SNMP
IX.1 - AgentX : Agent eXtensibility
Le protocole AgentX permet à plusieurs sous agents, d’avoir une MIB
d’information utilisable d’une manière transparente à une station de gestion
SNMP.
Avant ce protocole les utilisateurs devaient utiliser des solutions non standard
ou
bien
d’installer
plusieurs
agent
SNMP
sur
plusieurs
port
UDP,
probablement utilisé des agents proxy pour adapter l’accès aux ports UDP
standard.
Mais les deux solutions ont des problèmes. Le manque de standard exige que
les développeurs des sous agents doivent supporter plusieurs protocoles de
sous agents si le même sous agents est supporté par plusieurs système
d’opération. Les proxy ne sont pas transparent pour la station de gestion et
par suite demande une intelligence supérieure de la part des stations de
gestion.
Le
protocole
AgentX
offre
une
solution
standard
pour
le
problème
d’extension d’agent. Il a été décrit dune manière à ce qu’il soit indépendant
de la version SNMP. Un sous agent d’AgentX travail avec SNMPv1,
SNMPv2 et/ou SNMPv3 comme agent principal sans aucun changement.
Le protocole AgentX spécifie une méthode pour les sous agents d’échanger
avec l’agent principal les informations qu’ils désirent gérer. Chacun des sous
AgentX
s’exécute
dans
son
propre
espace
de
travail,
fournissant
une
alternative plus robuste qu’un agent SNMP tout seul.
Les processus d’exécution sur les machines offrent un accès à leur état
interne au protocole d’AgentX, qui est par suite accessible par une station de
gestion moyennant SNMP.
Projet DEA Réseaux de Telecom – 1998
64 / 85
Le Protocole SNMPv3
Un environnement d’AgentX consiste de deux systèmes: un agent principale
et un ou plus sous agents, communiquant les un avec les autres en utilisant le
protocole TCP ou à travers un protocole Unix. L’agent principal contient les
deux protocoles AgentX et SNMP, et c’est son rôle de maintenir une table de
référence pour chaque sous agent et la section de la MIB dont il est
responsable.
Quand l’AgentX reçoit une requête SNMP, il recherche le sous agent (ou les
sous agents) responsable de la zone MIB demandé et transfert la requête vers
le sous agent moyennant le protocole AgentX.
L’AgentX
principal
n’a
pas
de
rôle
administratif
à
l’exception
des
informations concernant les sous agents connectés et les allocations des zones
MIB.
Du point de vue sécurité le protocole AgentX, n’a pas des méthodes de
contrôle d’accès pour l’enregistrement d’un sous agent dans la MIB d’un
agent principal, et par suite un agent non autorisé pourra accéder à la MIB de
l’agent principal et ainsi envoyer des fausses informations à la station de
gestion même si le transfert des messages SNMP entre l’agent principal et la
station de gestion est sécuritaire.
Projet DEA Réseaux de Telecom – 1998
65 / 85
Le Protocole SNMPv3
IX.2 - Solution Web Management
La solution WBEM (Web-Based Entreprise Management) est née d’une
initiative de CISCO, Microsoft, Intel, Compaq, BMC Software et bien
d’autres industriels le 17 juillet 1997. Ceux-ci se sont retrouvés autour d’une
charte commune insistant sur les efforts de l’industrie pour trouver des
solutions d’administration interopérables, mais en intégrant les technologies
déjà existantes.
L'objectif du projet WBEM est de consolider et d'unifier les données fournies
par des technologies d'administration existantes. Il ne remplacera jamais les
protocoles d'administration existants (SNMP, CMIP, ...), mais il fournit un
point d'intégration pour les données issues de ces technologies.
Un autre objectif de WBEM est d’utiliser le browser Web comme principale
interface usager, ce qui
offre une indépendance de l’interface homme-
machine par rapport à la plate-forme.
L’architecture de WEBM s’articule autour de trois composantes principales :
l’HyperMedia Management Schema (HMMS) : c’est un schéma objet hérité
du
Common
Information
Model
(CIM)
et
utilisé
pour
modéliser
les
ressources à administrer;
l’HyperMedia Management Protocol (HMMP) : il s’agit du protocole de
communication qui sera utilisé pour accéder au HMMS;
l’HyperMedia Object Manager (HMOM), qui gère les éléments du réseau
comme des objets, et rend les services d’administration.
Le HMOM joue un rôle central : il est à la fois en relation avec les objets à
gérer, et avec les applications de gestion. De plus, c’est par son intermédiaire
que l’accès se fait au HMMS.
Projet DEA Réseaux de Telecom – 1998
66 / 85
Le Protocole SNMPv3
Internet Browser
Plates-formes & Applications
Applet
Services de Directory Accès aux données
(ex LDAP)
(ex ODBC)
HMMP
Autres
Services d’administration
( HMOM)
SNMP, DMI, Autres
Equipement ou
Application
Equipement ou
Application
HMMS
HMMP
Equipement ou
Application
HMMP : Hyper Media Management Protocol
HMOM : Hyper Media Object Manager
HMMS : Hyper Media Management Schema
Cette architecture offre une accessibilité certaine. En effet, il est possible de
créer des fournisseurs de données d’administration (providers) pour tous les
protocoles de gestion existant (SNMP, CMIP, DMI, ...). De plus, ces données
d’administration peuvent être publiées ou affichées par les protocoles HMMP
ou HTML, puisque il est possible de développer des applets ou des
applications utilisant l’accès HMMP.
Projet DEA Réseaux de Telecom – 1998
67 / 85
Le Protocole SNMPv3
Autres Accès
Applet
Servcies de
Directoire
Internet Browser
ODBC
Hyper Media Management protocol
Hyper Media Object manager
Hyper Media
Management
Schema
Hyper Media Management Protocol
Object Providers
HTTP Access
SNMP sur UDP
HMMP
HTML sur HTTP
HMOM
DMI sur RPC
Equipement, Programmes ou Collection
Par
ailleurs,
d’HyperMedia
il
est
également
Management
avec
possible
les
d’interconnecter
services
de
les
services
Directory
comme
Lightweight Directory Access Protocol (LDAP), ou encore avec des services
d’accès aux données comme ODBC.
Les clients peuvent être de simples process d'administration d'un équipement
particulier, ou ils peuvent être également un navigateur interactif capable
d'administrer n'importe quel objet administrante par HMMP. Les rôles de
client et de serveur peuvent être combinés dans la même entité pour former
un management hiérarchique et distribué. On peut distinguer deux types de
serveurs les managers et les providers.
Le serveur qui implémente une grande partie du protocole et qui combine les
rôles de client et serveur pour agir comme un proxy pour propager les
requêtes des clients est appelé HyperMedia Object Manager (HMOM). Le
Projet DEA Réseaux de Telecom – 1998
68 / 85
Le Protocole SNMPv3
serveur qui implémente un sous-ensemble réduit du protocole, et qui se
cantonne au rôle de serveur est appelé provider. En général, les clients se
mettent en relation d'abord avec un HMOM, qui peut dans la plupart des cas
satisfaire la requête du client. Si ce n'est pas le cas, le HMOM devient un
client lui-même qui propage la requête au provider concerné.
Cette architecture permet aux clients de ne pas avoir à s'inquiéter de la
localisation des
équipements, ni
d'avoir à gérer une multitude de ces
équipements. En effet, les clients envoient leurs requêtes à un HMOM
désigné qui cache la complexité de la procédure et répartit les requêtes aux
providers adéquats. Les providers rassemblent les données en utilisant des
mécanismes standards ou propriétaires (CMIP, SNMP, ..) et les renvoient au
HMOM. Le HMOM est donc un provider pour d'autres providers.
Server Side
Client Side
Application
HMMP
HMMP
HMMP
Client
Provider
SNMP
Provider
CMIP
HMOM
HMMP
HMMP
Web
Browser
CIM
Le Client/Serveur
Une entité HMMP qui travaille avec une opération HMMP peut agir comme
un client ou un serveur. Cette entité joue le rôle de serveur quand elle
effectue une tâche d’administration (y compris la réponse à une opération
HMMP) suite à la réception d’une demande d’opération HMMP. Par contre,
cette entité joue le rôle de client quand elle est à l’origine de tâches
d’administration
en
générant
Projet DEA Réseaux de Telecom – 1998
une
demande
d’opération
HMMP,
ou
en
69 / 85
Le Protocole SNMPv3
agissant selon des réponses d’opérations HMMP. Une entité HMMP peut
jouer un ou les deux rôles selon son implémentation ou sa configuration.
Producteur/Consommateur
Une entité HMMP qui travaille avec une indication HMMP peut agir comme
un
producteur
ou
un
consommateur.
Cette
entité
joue
le
rôle
de
consommateur quand elle effectue une tâche d’administration (y compris
l’envoi d’un acquittement à une indication HMMP) suite à la réception d’une
indication HMMP. Par contre, cette entité joue le rôle de producteur quand
elle envoie une indication HMMP. Comme pour les rôles précédents, une
entité HMMP peut jouer un ou les deux rôles selon son implémentation ou sa
configuration.
Les modes
HMMP utilise deux modes de procédures : opération et indication.
Le client envoie une demande d’opération HMMP au serveur qui retourne
une ou plusieurs réponses d’opération au client. Les opérations s’effectuent
pour :
Ramener des données d’administration du serveur;
Modifier des données d’administration présentes sur le serveur;
Exécuter une méthode;
Le
producteur
éventuellement
envoie
(si
une
demandé
indication
par
le
HMMP
producteur)
au
consommateur,
renvoie
un
qui
acquittement
d’indication au producteur.
L’interface entre HMMP et SNMP est réalisée par l’intermédiaire de deux
providers SNMP. Ceux-ci intègrent la modélisation et la manipulation des
Projet DEA Réseaux de Telecom – 1998
70 / 85
Le Protocole SNMPv3
données SNMP dans WBEM. Ainsi, on remarque que WBEM permet déjà,
sans développement supplémentaire, d’intégrer la technologie SNMP.
Conclusion
WBEM permet donc de réduire la complexité des solutions d’administration,
dans la mesure où elle offre une visualisation complète, et personnalisable
par le biais d’un browser Web, des données d’administration. En effet,
l’interface utilisateur est unique quel que soit la machine grâce à l’utilisation
de browsers.
Ensuite, WBEM fournit une uniformité dans la gestion des réseaux, des
systèmes et des applications, puisqu’il permet l’accès et l’association de
données de sources différentes.
Puis,
l’architecture
est
multitiers.
Elle
est
donc
dimensionnelle
et
distribuable. De plus, elle est basée sur des standards et elle est compatible
avec les standards et protocoles existants, on peut donc dire qu’elle utilise des
technologies déjà éprouvées.
Par ailleurs, les frais d’investissements et de maintenance sont faibles. En
effet, il n’y a pas besoin d’une station de travail coûteuse dédiée ou d’un
framework compliqué, l’utilisation des browsers offre un coût faible et une
utilisation indépendante des plates-formes bien que facilement extensible.
Enfin, cette architecture permet de créer des nouveaux services, puisque
l’intégration de services
élémentaires permet la construction de services
spécialisés.
Projet DEA Réseaux de Telecom – 1998
71 / 85
Le Protocole SNMPv3
IX.3 - DR Web
Introduction
Le gestionneur DR-Web est une autre solution basée sur le Web, et elle est
proposée par SNMP Research. Elle permet l’usage des gestionneurs SNMP
moyennant les browsers Web populaire.
Elle permet aux browsers Web l’accès aux informations basées sur SNMP
dans un agent SNMP quelconque sans avoir à modifier ni le browser, ni
l’agent SNMP.
Le manager DR-Web permet à plusieurs Web browser d’accéder à des
informations de gestion de plusieurs agent SNMP.
Web
Browser
Web
Browser
HTTP
Protocole
Web Server
DR – Web Manager
BRASS System
SNMPv1
Protocole
SNMPv2
Protocole
Agent
SNMPv1
Aucun
changement
Agent
SNMPv2
est
nécessaire
SNMPv3
Protocole
Agent
SNMPv3
dans
l’architecture
de
SNMP
pour
l’introduction du manager DR-Web. Mais, il suffit d’ajouter une interface
Web à cette architecture existante.
Projet DEA Réseaux de Telecom – 1998
72 / 85
Le Protocole SNMPv3
Alors, de ce fait l’introduction de DR-Web n’affecte pas le réseau de gestion,
basé sur SNMP, déjà implémenter, mais il offre une présentation des
informations sur un browser Web qui est une interface simple, familière,
portable et un coût faible.
Sécurité
L’interaction entre le Web browser et le manager DR Web est authentifié en
utilisant un nom utilisateur et un mot de passe HTTP. L’utilisateur HTTP
authentifié sera identifié pour retrouver les informations d’interaction avec
l’agent SNMP ou bien, l’utilisateur fournira l’authentification SNMP dans
l’URL ou bien après une demande du manager DR Web.
Le manager DR Web utilise le même modèle administrative que SNMP pour
la gestion des contrôles d’accès aux informations de gestion. Ainsi, un
utilisateur HTTP aura un accès limité à la lecture, tandis qu’un autre
utilisateur aura un accès non conditionné lecture/écriture pour un ensemble
d’agents SNMP.
La communication entre le Web browser et le manager DR Web pourra être
sécurisé en utilisant SSL (Secure Socket Layer).
BRASS
BRASS
renforçant
ou
Bilingual
Request
l’infrastructure
d’une
And
Security
plate-forme
de
Subsystem
gestion
est
en
une
API
offrant
une
architecture extensible des manager. Cette API permet aux applications de
gestion de partager les bases de donnée d’un agent au lieu d’implémenter ces
structures dans chaque application. En plus, BRASS est conçue de manière à
permettre à plusieurs programmes l’usage simultané de l’API, sans avoir des
conflits entre les applications.
BRASS permet aux stations de gestion une extensibilité et une simplicité de
plusieurs manières:
Le support de SNMPv1, SNMPv2 et SNMPv3 simultanément.
Projet DEA Réseaux de Telecom – 1998
73 / 85
Le Protocole SNMPv3
Les applications de gestion peuvent être ajouter sans avoir à comprendre les
détailles de SNMP.
Simplifie la configuration de sécurité pour les versions SNMPv2 et SNMPv3.
Allouer un seul groupe de paramètres de sécurité pour chaque plate-forme de
gestion.
L’utilisation de BRASS dans une station de gestion simplifie la configuration
des fichiers pour chaque agent du réseau, car avec cette conception chaque
agent doit être configuré avec un seul groupe de paramètres de sécurité et
pouvoir être contacter par un large système de gestion. Sans cette conception,
chaque application de gestion aurait dû configurer l’agent pour pouvoir
supporté ses paramètres de sécurité.
L’architecture suivante montre une station de gestion utilisant BRASS. Un
seul multiplexeur de gestion BRASS offre les services SNMP pour plusieurs
applications. Ces services comprennent l’exécution des requêtes SNMP et la
Application 1
Plate-forme d’une Station de gestion
Application 2
Multiplexeur
De Gestion
BRASS
Application 5
Application 6
Base de Donnée de
configuration
Application 4
Réseau
réception des Trap SNMP.
Projet DEA Réseaux de Telecom – 1998
74 / 85
Le Protocole SNMPv3
IX.4 - L’agent EMANATE
L’agent
EMANATE
(Enhanced
MANagement
Agent
Through
Extensions)
étend l’architecture des gestions SNMP par des agents SNMP extensibles.
L’agent hiérarchique, modulaire EMANATE se constitue d’un agent Master
avec zéro ou plusieurs sous agents supportant plusieurs modules MIB.
Ce type d’agent est idéal pour les environnements supportant plusieurs type
de produits et de constructeurs, tel que les équipements de contrôle et de
surveillance des serveurs et des stations de travail…
Les spécifications des interfaces EMANATE sont faciles à implémenter, et
ceci en offrant un ensemble de API (Application Program Interface) utilisable
par les développeurs pour étendre la capacité de gestion d’un agent.
La modularité du modèle d’EMANATE réduit le niveau de coordination
entre les différents groupes de développements d’un même projet. Ainsi
plusieurs groupes de développement peuvent implémenter leurs éléments de
gestion comme des sous agents indépendants, et par suite faciliter
les
problèmes d’intégration de produits, la paquetisation et le test.
L’architecture
d’EMANATE
offre
un
environnement
ouvert
permettant
à
plusieurs sous agents de coexister dans le même environnement, offrant aux
utilisateurs une architecture plus flexible et extensible. En même temps,
l’agent Master et les sous agents apparaissent à la station de gestion comme
un simple agent, offrant une vue monolithique des données, et facilitant la
configuration du système.
Les approches basées sur les agents proxy sont incapables d’offrir la
simplicité et l’usage facile, avec une telle vue monolithique. Les sous agents
EMANATE sont totalement compatibles avec les approches de sécurité et de
Projet DEA Réseaux de Telecom – 1998
75 / 85
Le Protocole SNMPv3
privatisation définit récemment pour les plate-formes SNMP, et par suite
peuvent être utiliser pour implémenter des approches proxy.
Sous
Agent
Kernel
Sous
Agent
PPP
Sous
Agent
Manager
Sous
Agent
Proxy
API
API
API
API
Sous
Agent
RMON
Interface Indépendante du système
Interface Dépendante du système
API
Element
Proxy
Sous
Agent
Application
API
Interface Dépendante du système
Interface Indépendante du système
Sous
Agent
Système
EMANATE
Agent MASTER
API
Sous
Agent
Application
API
Réseau
Projet DEA Réseaux de Telecom – 1998
76 / 85
Le Protocole SNMPv3
IX.5 - LATIN : Legacy Adapter to Internet
LATIN offre une nouvelle plate-forme de gestion SNMP adapté pour
les systèmes basés sur les ports d’interfaces séries. LATIN est une interface
entre les ports RS232 des équipements déjà existants (Equipements legs) et
une station supportant le protocole d’interconnexion réseau TCP/IP.
Tous les éléments des réseaux actuels sont basés sur SNMP, mais tous
les réseaux contiennent à présents des éléments ne supportant pas SNMP.
Ainsi une solution doit être adaptée à ces types d’équipements legs.
LATIN offre un système permettant :
Détection accélérer des problèmes, en envoyant des SNMP
Trap à la station de gestion en accord avec les messages
provenant de l’équipement legs.
Une analyse plus rehausser, en groupant et catégorisants les
messages
de
ces
équipements,
filtré
les
messages
non
intéressants, sauvegardé une large quantité de message pour le
support des problèmes de trace.
Evolution de la sécurité, les équipements contrôler peuvent être
configurés pour un contrôle d’accès dépendant des catégories
de
messages.
De
même,
élimine
le
besoin
d’accéder
physiquement ses systèmes pour des raisons de diagnostiques,
permettant à l’administrateur de restreindre l’accès physique
aux systèmes sensibles (En bloquant l’accès aux chambres des
ses équipements).
Adaptation
aux
besoins
clients,
les
clients
décident
la
catégorisation des messages, quels messages natives envoient
des messages SNMP Trap, et quels messages natifs à filtrer.
Economisation, réduire le temps d’arrêt des systèmes legs,
réutiliser
les
équipements
déjà
existant
sans
avoir
à
les
remplacer par des nouveaux contrôlables à distant, faire la
sauvegarde des messages sur des fichiers électroniques au lieu
que sur des papiers.
Projet DEA Réseaux de Telecom – 1998
77 / 85
Le Protocole SNMPv3
Projet DEA Réseaux de Telecom – 1998
78 / 85
Le Protocole SNMPv3
IX.6 - Le manager intermédiaire
Le manager intermédiaire (Mid Level Manager) a un double rôle, il peut agir
en même temps comme un agent d’une part et comme un manager d’une
autre part.
Pour les managers qui demandent des requêtes d’informations du manager
intermédiaire, il apparaît comme un agent, et pour les agents qu’il interroge,
il est un manager. Ce manager est utilisé le plus dans la gestion des réseaux
distribués.
La figure suivante montre comment un manager intermédiaire s’adapte à une
hiérarchie de gestion de réseau, et ses relations avec ses supérieures et ses
subordonnés.
Manager
d’entreprise
Manager
Intermédiaire
Manager
d’entreprise
Manager
Intermédiaire
Manager
Intermédiaire
Agent SNMPv1, SNMPv2 et SNMPv3
Quand un manager intermédiaire est placé à distance du réseau local et est
connecté
à
travers
un
WAN
(Wide
Area
Network)
avec
le
manager
d’entreprise, cette architecture permet la réduction du trafic sur le réseau
WAN (qui peut se traduire par une réduction significative des prix) tout en
réservant
le
même
niveau
Projet DEA Réseaux de Telecom – 1998
de
gestion
des
agents
par
les
managers
79 / 85
Le Protocole SNMPv3
intermédiaires. Ces managers intermédiaires offrent une réponse de premier
niveau aux problèmes des agents, laissant les managers d’entreprises en
position d’autorisation finale.
De même, si le WAN est bloqué ou arrêté, le manager intermédiaire pourra
toujours continuer la gestion des agents au niveau local.
Des codes applications peuvent être envoyés par des requêtes SNMP (Set
request) des managers d’entreprises vers les managers intermédiaires, pour
que ces derniers exécutes ses codes périodiquement ou sur demande. Et ainsi
le trafic sur le WAN est réduit comme le scrute se fait localement.
Ses
codes
d’applications
sont
flexibles
et
configurables
de
manières
à
permettre par exemple à un manager d’entreprise de lancer une seule requête
vers un manager intermédiaire, qui se traduit par des requêtes attaquant
plusieurs agents.
Projet DEA Réseaux de Telecom – 1998
80 / 85
Le Protocole SNMPv3
IX.7 - L’approche TMN (Telecommunication management
Network) de l’ITU
L’ITU-T décrit une architecture physique et fonctionnelle qui puisse prendre
en charge la gestion de tous les types de réseaux de télécommunication.
Le TMN est une norme de l’ITU-T, applicable aux réseaux publics et privés,
aux réseaux à commutation de circuits et de paquets et aux équipements
associés. Les recommandations originales (M.3010), l’architecture du TMN
est conceptuellement définie pour être une base de travail qui couvre tous les
types
de
réseaux,
dans
les
faits
le
TMN
est
plutôt
orienté
vers
l’administration des réseaux de types circuits commutés que l’on rencontre
dans les environnements de télécommunication.
Le TMN détermine une structure des fonctions, des protocoles et des
messages que l’administrateur de réseau peut sélectionner. Ces ensembles
forment les spécifications d’un système TMN. Le TMN ne spécifie pas le
système
d’administration
de
réseau.
Il
ne
donne
aucune
idée
sur
l’implantation du système et il ne spécifie pas la manière dont les fonctions
TMN sont implantées. Seule une liste de fonctions qui peuvent être utilisées
par l’administration de réseau. De plus, le TMN est applicable uniquement
pour l’administration des ressources de communication, il ne l’est pas pour
l’administration des applications.
Le
TMN
offre
une
structure
l’interconnexion
de
équipements
télécommunication
de
différents
de
types
réseaux
de
définie
systèmes
regroupés
en
pour
permettre
d’exploitation
architectures
t
des
hétérogènes.
Ceci permet l’administration de différents réseaux et fournit un ensemble de
normes
à
respecter
par
les
constructeurs
des
équipements
de
télécommunications. De façon conceptuelle, c’est un réseau indépendant qui
interface les réseaux de télécommunications en différant points pour en
recevoir les informations et pour en contrôler les opérations.
Le TMN utilise les architectures normalisées existantes comme le modèle
OSI (Open System Interconnect) ou le modèle de l’ITU-T pour l’ATM
(Asynchronous Transfert Mode) Dans le cas du modèle OSI, on retrouve
l’architecture
de
gestion
Projet DEA Réseaux de Telecom – 1998
normalisée
par
l’ISO
(International
Standard
81 / 85
Le Protocole SNMPv3
Organization): l’environnement CMIP / CMIS. Pour le modèle de l’ITU-T,
une adaptation de CMIS / CMIP est effectuée.
Le TMN est conceptuellement basé sur un réseau de communication de
données, appelé DCN (Data Communication Network), séparé du réseau de
Système d’Opération Système d’Opération Système d’Opération
Accès à Distance
DCN :Data
Communication Network
Réseau de
Télécommunication
télécommunication à gérer.
Projet DEA Réseaux de Telecom – 1998
82 / 85
Le Protocole SNMPv3
IX.8 - Le modèle d’information CIM
CIM (Common Information Model) est un modèle d’information mis au
point par la DMTF (Desktop Management Task Force). CIM fournit un
ensemble de classes avec leurs propriétés et des associations permettant une
vue conceptuelle de la plate-forme sur laquelle on peut implémenter les
informations et objets de l’environnement à administrer ou à gérer.
CIM est structuré en plusieurs couches, les modèles.
Modèle noyau, décrit un modèle d’information regroupant
les notions applicables à tous les champs de gestion.
Modèle
commun,
décrit
un
modèle
d’information
regroupant les notions communes à un champ de gestion,
mais
indépendamment
implémentation
d’une
particulière.
Ce
technologie
ou
modèle
recouvre
d’une
les
systèmes, les applications, les réseaux et les circuits. Le
modèle d’information est expliciter à un niveau permettant
d’offrir une base pour les développeurs d’application de
gestion.
Extension de schémas, représente les extensions du modèle
commun
pour
décrire
une
technologie
particulière.
Ces
schémas sont spécifiques à un environnement comme par
exemples
les
systèmes
d’opérations
(Unix,
Microsoft
Windows…)
Le modèle noyau représente la racine pour l’extension du modèle commun.
L’ajout de nouveau modèle noyau est toujours possible. Une ré-interprétation
des modèles noyaux n’est pas à prévoir.
Les extensions du modèle commun, sont des ajouts aux spécifications d’une
plate-forme fournissant des classes concrètes et des implémentations des
Projet DEA Réseaux de Telecom – 1998
83 / 85
Le Protocole SNMPv3
classes du modèle commun. Ces extensions du modèle commun offrent une
liste plus étendue des informations.
CIM est un modèle conceptuel qui n’est pas limiter à une implémentation
particulière. Ceci permet son utilisation pour l’échange d’information de
gestion de plusieurs méthodes et avec des combinaisons de ces dernières.
Meta modèle de CIM
Contenu de CIM
À des
instances
Réalisation de CIM
Réalisation
Classe
Objets
(Instances de classes)
Stock
Sauvegarde du meta
modèle d’information
pour les programmes
d’accès.
Application DBMS
Transforme les
définitions conceptuelles
en un schéma physique
adapté à une technologie
de base de donnée.
Objets d’applications
Définit un ensemble de
donnée orienté
application qui peut être
instancié ou exécuté
dans la technologie
destination.
Transfert de paramètre
Le contenu d’une CIM
est une instance de
structure entre les
applications
Méthodes d’usage d’une CIM
La première méthode (Stock), consiste à stocker la structure des informations
dans une base de donnée. Ces structures ne sont pas des instances de l’objet,
ni des relations… Mais des définitions utilisables pour l’établissement des
objets et des relations. Le meta modèle utilisé par CIM est stocké dans un
stock qui sera une représentation du meta modèle. Ceci est fait en balayant la
structure du meta modèle en un schéma physique, puis en les stockant dans le
stock sous forme de classe avec leurs propriétés exprimées en modèle noyau,
modèle commun et extension de schéma.
Projet DEA Réseaux de Telecom – 1998
84 / 85
Le Protocole SNMPv3
Pour une application DBMS (Data Base Management Schema), la CIM est
balayée en un schéma physique de la technologie de la base de donnée
(Relationnelle par exemple). Ces informations stockées dans la base de
donnée sont ainsi des instances de la structure actuelle et, les applications
peuvent échanger des informations s’ils ont accès à un DBMS commun et le
balayage se fait d’une manière prédite.
Pour les objets d’applications, La CIM est utilisée pour créer un ensemble
d’objets d’applications définit par un langage particulier. Les applications
peuvent ainsi échanger des informations de la CIM, s’ils ont une liaison avec
les objets applications.
Pour le transfert de paramètres, la CIM, exprimée en une forme de syntaxe
agréer, est une classe neutre utiliser pour l’échange des informations de
gestion, moyennant un ensembles d’API standards. L’échange se fait en
appelant directement une ou plusieurs API, ou bien en envoyant une API
orienté
échange
qui
peut
créer
les
objets
demandés
localement
dans
l’implémentation.
Le mécanisme d’échange des informations de gestion est le format d’objet de
gestion
MOF
(Management
Object
Format).
La
syntaxe
MOF
est
une
manière pour décrire les définitions d’objets en une forme textuelle. MOF
établit la syntaxe d’écriture d’une définition. Les composants primaires des
spécifications
d’une
MOF
associations,
propriétés,
sont
des
références,
descriptions
méthodes
et
textuelles
des
des
classes,
déclarations
des
instances. Les remarques sont permises.
Projet DEA Réseaux de Telecom – 1998
85 / 85
Le Protocole SNMPv3
Bibliographie
[RFC 1155]
Structure and identification of Management information for
TCP/IP-based internets
STD 16, RFC 1155, May 1990
[RFC 1157]
The Simple Network Management Protocol
STD 15, RFC 1157, May 1990
[RFC 1212]
Concise MIB Definitions
STD 16, RFC 1212, March 1991
[RFC 1901]
Introduction to Community based SNMPv2
RFC 1901, January 1996
[RFC 1902]
Structure of Management Information for Version 2 of the
Simple Network Management Protocol (SNMPv2)
RFC 1902, January 1996
[RFC 1905]
Protocol Operations for Version 2 of the Simple Network
Management Protocol (SNMPv2)
RFC 1905, January 1996
[RFC 1906]
Transport Mappings for Version 2 of the Simple Network
Management Protocol (SNMPv2)
RFC 1906, January 1906
[RFC 1907]
Management Information Base for Version 2 of the Simple
Network Management Protocol (SNMPv2)
RFC 1907, January 1906
[RFC 1908]
Coexistence between Version 1 and Version 2 of the Internet
standard Network Management Framework
RFC 1908, January 1996
[RFC 1909]
An Administrative Infrastructure for SNMPv2
RFC 1909, February 1996
Projet DEA Réseaux de Telecom – 1998
86 / 85
Le Protocole SNMPv3
[RFC 1910]
User Based Security Model for SNMPv2
RFC 1910, February 1996
[RFC 2271]
An
Architecture
for
Describing
SNMP
Management
Frameworks
RFC 2271, January 1998
[RFC 2272]
Message Processing and Dispatching for the Simple Network
Management Protocol (SNMP)
RFC 2272, January 1998
[RFC 2273]
SNMPv3 Applications
RFC 2273, January 1998
[RFC 2274]
The User Based Security Model for Version 3 of the Simple
Network Management Protocol (SNMPv3)
RFC 2274, January 1998
[RFC 2275]
View Based Access Control Model for the Simple Network
Management Protocol (SNMP)
RFC 2275, January 1998
Ressources Internet
http://www.ietf.org/
http://www.ietf.org/html.charters/snmpv3-charter.html
http://www.simple-times.org/
http://www.cis.ohio-state.edu/htbin/rfc/rfc-index.thml
http://www.ibr.cs.tu-bs.de/projects/snmpv3/
http://www.snmp.com/
ftp://ftp.tis.com/pub/ietf/snmpv3
ftp://ds.internic.net/rfc/rfcxxxx.txt
Projet DEA Réseaux de Telecom – 1998
87 / 85
